Skip to content

Putting a lifetime on @ skips the next token and forces fn. #8615

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
huonw opened this issue Aug 19, 2013 · 1 comment
Closed

Putting a lifetime on @ skips the next token and forces fn. #8615

huonw opened this issue Aug 19, 2013 · 1 comment
Labels
A-parser Area: The parsing of Rust source code to an AST

Comments

@huonw
Copy link
Member

huonw commented Aug 19, 2013

fn main() {
    // expected `fn`, but found `;`
    // let _: @'static int;

    let _: @'static whatever fn();
    let _: @'static + fn() = || {};
    let _: @'static for fn() = || {};
    let _: @'static "a string" fn() = || {};
    let _: @'static 'a fn() = || {};

    // Illegal lifetime: named region `&'a` not in scope here
    // let _: @'a whatever fn();
}

The last example is just showing that the 'static actually get parsed as a lifetime.

@lilyball
Copy link
Contributor

My PR only fixes the skipped token. I assume forcing fn is actually correct, because what other @-boxes have lifetimes?

@bors bors closed this as completed in 8aa4799 Aug 22, 2013
djkoloski pushed a commit to djkoloski/rust that referenced this issue Sep 21, 2022
Migrate write.rs to a late pass

changelog: Migrates write.rs from a pre expansion pass to a late pass
changelog: [`positional_named_format_parameters`] is renamed in favour of the rustc lint `named_arguments_used_positionally`

- Macros are now identified by diagnostic items, so will no longer lint user defined macros named, e.g. a custom `print!`
- `print_literal`/`write_literal` no longer lint no longer lint literals that come from macro expansions, e.g. `env!("FOO")`
- `print_with_newline`/`write_with_newline` no longer lint strings with any internal `\r` or `\n`s

~~A false negative, `print_literal`/`write_literal` don't lint format strings that produce `FormatSpec`s, e.g. ones containing pretty print/width/align specifiers~~

Suggestion changes:
- ~~`print_literal`/`write_literal` no longer have suggestions, as the spans for the `{}`s were not easily obtainable~~
-  `print_with_newline`/`write_with_newline` has a better suggestion for a sole literal newline, but no longer has suggestions for len > 1 strings that end in a literal newline
- ~~`use_debug` spans are less precise, now point to the whole format string~~

The diff for write.rs is pretty unwieldy, other than for the `declare_clippy_lint!`s I think you'd be better off viewing it as a brand new file rather than looking at the diff, as it's mostly written from scratch

cc rust-lang#6610, fixes rust-lang#5721, fixes rust-lang#7195, fixes rust-lang#8615
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser Area: The parsing of Rust source code to an AST
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants