Skip to content

Option<*T> should be represented as a pointer #10570

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nikomatsakis opened this issue Nov 19, 2013 · 5 comments
Closed

Option<*T> should be represented as a pointer #10570

nikomatsakis opened this issue Nov 19, 2013 · 5 comments
Labels
A-codegen Area: Code generation

Comments

@nikomatsakis
Copy link
Contributor

Just like Option<~T> and Option<&T>.

cc @jld

@nikomatsakis
Copy link
Contributor Author

Put another way, this test should pass:

assert_eq!(sizeof::<Option<*int>>(), sizeof::<uint>())

@jld
Copy link
Contributor

jld commented Nov 24, 2013

As mentioned in #10571, this depends on *T being non-nullable and vice versa.

@brendanzab
Copy link
Member

Not sure if this is related, but we are also having difficulties with Option<extern fn()> on i386. See PistonDevelopers/glfw-rs#67:

On i386, rustc expects Option instances to be returned on the stack. The caller
passes a pointer to allocated stack space and the callee fills it in. This is
not the calling convention expected by C functions like glfwSetErrorCallback
that return a pointer in EAX.

Somehow this led to a segfault on i386 because the stack pointer was incorrect
when returning from the caller. This didn't happen on x86-64.

I couldn't find any documentation on using Option types with the FFI. If this is supposed
to work then I'll file an issue against rustc instead.

@rlane

@jld
Copy link
Contributor

jld commented Jan 4, 2014

Function pointers should already be non-nullable (and thus an Option of one will be optimized as expected), but... the Option will still wrap a layer of LLVM struct around them, which I think changes the calling convention on i386?

That could be changed without too much trouble, I think, but it probably ought to be a separate issue.

@alexcrichton
Copy link
Member

Closing because #10571 was closed as well.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
…, r=xFrednet

Add redundant type annotations lint

Hello, I'm trying to add the `redundat_type_annotations` lint.

It's still WIP but I'd like to start gathering some feedbacks to be sure that I'm not doing things 100% wrong :)

Right now it still misses lints like:

- [x] `let foo: u32 = 5_u32`,
- [x] `let foo: String = STest2::func()`
- [x] `let foo: String = self.func()` (`MethodCall`)
- [x] refs
- [ ] Generics

I've some problems regarding the second example above, in the `init` part of the `Local` I have:

```rust
init: Some(
                Expr {
                    hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).58),
                    kind: Call(
                        Expr {
                            hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).59),
                            kind: Path(
                                TypeRelative(
                                    Ty {
                                        hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).61),
                                        kind: Path(
                                            Resolved(
                                                None,
                                                Path {
                                                    span: src/main.rs:77:21: 77:27 (#0),
                                                    res: Def(
                                                        Struct,
                                                        DefId(0:17 ~ playground[e1bd]::STest2),
                                                    ),
                                                    segments: [
                                                        PathSegment {
                                                            ident: STest2#0,
                                                            hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).60),
                                                            res: Def(
                                                                Struct,
                                                                DefId(0:17 ~ playground[e1bd]::STest2),
                                                            ),
                                                            args: None,
                                                            infer_args: true,
                                                        },
                                                    ],
                                                },
                                            ),
                                        ),
                                        span: src/main.rs:77:21: 77:27 (#0),
                                    },
                                    PathSegment {
                                        ident: get_numb#0,
                                        hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).62),
                                        res: Err,
                                        args: None,
                                        infer_args: true,
                                    },
                                ),
                            ),
                            span: src/main.rs:77:21: 77:37 (#0),
                        },
                        [],
                    ),
                    span: src/main.rs:77:21: 77:39 (#0),
                },
            ),
```

And I'm not sure how to get the return type of the function `STest2::func()` since the resolved path `DefId` points to the struct itself and not the function. Do you have any idea on how I could get this information in this case?

Thanks!

changelog: changelog: [`redundant_type_annotations`]: New lint to warn on redundant type annotations

fixes rust-lang#9155
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation
Projects
None yet
Development

No branches or pull requests

4 participants