Skip to content
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

error: expected ; or } but found } #6610

Closed
huonw opened this issue May 19, 2013 · 2 comments
Closed

error: expected ; or } but found } #6610

huonw opened this issue May 19, 2013 · 2 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR)

Comments

@huonw
Copy link
Member

huonw commented May 19, 2013

trait Foo { fn a() }

fn main() {}
bad-expect.rs:1:19: 1:20 error: expected `;` or `}` but found `}`
bad-expect.rs:1 trait Foo { fn a() }
                                   ^

Presumably the or }`` is incorrect.

@hatahet
Copy link
Contributor

hatahet commented May 19, 2013

To the devs: does this simply require changing the error message in libsyntax/parse/parser.rs:538 (part of parse_trait_methods)? If so, I would like to call dibs on this one to be my first contribution :)

@thestinger
Copy link
Contributor

This is still an issue.

bors added a commit that referenced this issue Aug 18, 2013
When parsing a trait function, the function must end with either `;` or
`{` (signifying a default implementation). The error message incorrectly
stated that it must be `;` or `}`.

Fixes #6610.
@bors bors closed this as completed in 1fcb7ed Aug 18, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 24, 2022
Migrate `dbg_macro` to late pass

changelog: Make `dbg_macro` work with crate level attributes and inside macro calls

One down for rust-lang#6610, fixes rust-lang#7275

Also fixes rust-lang#7274, and adds parenthesis around the suggestion for `dbg!(1, 2, 3)` as it expands to a tuple
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-frontend Area: Compiler frontend (errors, parsing and HIR)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants