Closed
Description
Updated bug report
Compiling this (erroneous) program:
struct mutex;
fn main() {
let x = mutex { }; // this should be `let x = mutex;`
println(fmt!("%?", x));
}
yields:
/tmp/foo.rs:3:18: 3:19 error: expected `;` but found `{`
/tmp/foo.rs:3 let x = mutex { };
We currently emit a nice error message if you incorrectly write the struct mutex
definition as:
struct mutex { }
that tells you that you need to write the Unit-like struct as struct mutex;
; we should do the same for the struct initialization expression.
Original bug report
struct mutex { }
fn main() {
let x = mutex { };
}
gives:
struct.rs:3:18: 3:19 error: expected `;` but found `{`
struct.rs:3 let x = mutex { };
but if you comment out the let x
line, it gives:
struct.rs:1:0: 1:16 error: a class must have at least one field
struct.rs:1 struct mutex { }
Personally, I think we should be allowed to have empty structs, but either way, the latter error message should have higher priority(?) than the former.
Activity
catamorphism commentedon Aug 13, 2012
Parsing happens before typechecking, and the "at least one field" error is a type error. So this won't change.
We discussed it a while ago and agreed to disallow empty structs, but if you want to reopen the discussion, feel free to file a separate RFC bug.
bblum commentedon Aug 13, 2012
@catamorphism Maybe the parser could allow
mutex { }
, so that it doesn't fail until typechecking?catamorphism commentedon Aug 13, 2012
Sorry, I was reading too fast and didn't understand at first that the parser is essentially checking for the same thing that the typechecker is.
That seems reasonable to me.
bblum commentedon Aug 22, 2012
I attempted to fix this. Something like (libsyntax/parse/parse.rs):
But it seems like this makes the grammar ambiguous with empty-bodied 'do' statements --
do unkillable { }
failed to parse.I wonder if this will stop being ambiguous once type names have to be camel case?
nikomatsakis commentedon Aug 22, 2012
Type names will never have to be camel case---that's intended to be a convention. I think that's a known ambiguity that was supposed to be resolved by
do
(andfor
) favoring one interpretation. @pcwalton can confirm (I know we did discuss it). We could always require parentheses indo
/for
to remove the ambiguity, but that would mean:Which, admittedly, is not so bad.
bblum commentedon Aug 22, 2012
it occurred to me that the grammar might not have to be ambiguous after all, and it was just my fix that was wrong. we have something like:
and
do path { }
got confused withpath { }
. i think to resolve it, either parsingdo
should use lookahead in the same way as my code above, or my code above should somehow have lower priority. the latter seems better, but i'm not sure how it would be written.pcwalton commentedon May 16, 2013
I think this bug is just asking for a better parser error message when you try to create an empty structure. That doesn't seem backwards incompatible to me. Renominating.
graydon commentedon Jun 13, 2013
just a bug, removing milestone/nomination.
pnkfelix commentedon Aug 8, 2013
Visiting for triage email from 2013-07-29.
I think I can revise the parser in a disciplined manner to put in a better error message (as pcwalton suggested). I spent some time Monday hacking on that, I'll have a draft up for people to look at soon.
struct_id { }
form. #8418auto merge of #8418 : pnkfelix/rust/fsk-issue3192-improve-parse-error…
2 remaining items
{}
and semi-colons. #7981Fix for rust-lang#3192 that is semi-melded with a Tracing infrastruct…
Auto merge of rust-lang#3192 - eduardosm:x86-avx-intrinsics, r=RalfJung
Perform cargo update because of yanked libc version (rust-lang#3192)