Skip to content

in 《A 30-minute Introduction to Rust》 rustc dangling.rs output need update #17588

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
electricface opened this issue Sep 27, 2014 · 2 comments

Comments

@electricface
Copy link

Save this program as dangling.rs. When you try to compile this program with rustc dangling.rs, you'll get an interesting (and long) error message:

dangling.rs:3:12: 3:14 error: `i` does not live long enough
dangling.rs:3     return &i;
                         ^~
dangling.rs:1:23: 4:2 note: reference must be valid for the anonymous lifetime #1 defined on the block at 1:22...
dangling.rs:1 fn dangling() -> &int {
dangling.rs:2     let i = 1234;
dangling.rs:3     return &i;
dangling.rs:4 }
dangling.rs:1:23: 4:2 note: ...but borrowed value is only valid for the block at 1:22
dangling.rs:1 fn dangling() -> &int {
dangling.rs:2     let i = 1234;
dangling.rs:3     return &i;
dangling.rs:4 }
error: aborting due to previous error

rustc 0.12.0

dangling.rs:1:18: 1:22 error: missing lifetime specifier [E0106]
dangling.rs:1 fn dangling() -> &int {
                               ^~~~
error: aborting due to previous error
@huonw huonw added the A-docs label Sep 27, 2014
@steveklabnik
Copy link
Member

The 30 minute guide is being re-done in #16641 , so while this is an error, it's already going away shortly.

@steveklabnik
Copy link
Member

Closed since #16641 was merged.

lnicola pushed a commit to lnicola/rust that referenced this issue Jul 28, 2024
feat: Add incorrect case diagnostics for enum variant fields and all variables/params

Updates the incorrect case diagnostic to check:

1. Fields of enum variants. Example:
```rust
enum Foo {
    Variant { nonSnake: u8 }
}
```
2. All variable bindings, instead of just let bindings and certain match arm patters. Examples:
```rust
match 1 { nonSnake => () }
match 1 { nonSnake @ 1 => () }
match 1 { nonSnake1 @ nonSnake2 => () } // slightly cursed, but these both introduce new
                                        // bindings that are bound to the same value.

const ONE: i32 = 1;
match 1 { nonSnake @ ONE } //  ONE is ignored since it is not a binding

match Some(1) { Some(nonSnake) => () }

struct Foo { field: u8 }
match (Foo { field: 1 } ) {
    Foo { field: nonSnake } => ();
}

struct Foo { nonSnake: u8 } // diagnostic here, at definition
match (Foo { nonSnake: 1 } ) { // no diagnostic here...
    Foo { nonSnake } => ();    // ...or here, since these are not where the name is introduced
}

for nonSnake in [] {}

struct Foo(u8);
for Foo(nonSnake) in [] {}
```
3. All parameter bindings, instead of just top-level binding identifiers. Examples:
```rust
fn func(nonSnake: u8) {} // worked before

struct Foo { field: u8 }
fn func(Foo { field: nonSnake }: Foo) {} // now get diagnostic for nonSnake
```

This is accomplished by changing the way binding identifier patterns are filtered:
- Previously, all binding idents were skipped, except a few classes of "good" binding locations that were checked.
- Now, all binding idents are checked, except field shorthands which are skipped.

Moving from a whitelist to a blacklist potentially makes the analysis more brittle:
If new pattern types are added in the future where ident pats don't introduce new names, then they may incorrectly create diagnostics.

But the benefit of the blacklist approach is simplicity: I think a whitelist approach would need to recursively visit patterns to collect renaming candidates?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants