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

better error message when there is a missing semicolon with an expression #1481

Closed
nikomatsakis opened this issue Jan 10, 2012 · 6 comments
Closed
Assignees
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@nikomatsakis
Copy link
Contributor

Something like:

fn foo() {
    task::spawn {|| } //! ERROR type mismatch: expected '()' but got 'tast'
    bar();
}

fn bar() {
}

will yield an error something like the one above. It would be better if it said, "statement with non-unit return type requires a semicolon" or something like that. This would be easy-ish to fix: the ast has a type "stmt_expr" and "stmt_semi", and "stmt_expr" must have a unit type.

lht added a commit to lht/rust that referenced this issue Jan 15, 2012
@lht
Copy link
Contributor

lht commented Jan 15, 2012

My first change to the typechecking code. I'm not very confident this is the "easy-ish" fix @nikomatsakis mentioned. Please help review. It passed tests on all bots.

@nikomatsakis
Copy link
Contributor Author

I don't think that's quite I had in mind. If I read the patch correctly, won't the new msg trigger anytime you unify unit type with non-unit type? I had in mind replacing the line bot = check_expr_with(fcx, expr, ty::mk_nil(fcx.ccx.tcx)); in check_stmt() with something that performed a similar check but issued a different error msg.

@nikomatsakis
Copy link
Contributor Author

One other thing... this may not be a tiny patch, because it seems like using the unify routines is the right thing to be doing, but we want to change the error msg. Maybe passing in some context to the unify routine to influence the error it emits is the right thing to do...?

@nikomatsakis
Copy link
Contributor Author

OK, last comment: what I am specifically concerned about is something like a function with type signature " fn(A)->A", where it might not be fully resolvable but could still be unified to unit.

@lht
Copy link
Contributor

lht commented Jan 16, 2012

Thanks a lot for the information, Niko! I will try again when I understood how it works.

@catamorphism
Copy link
Contributor

Removing the comment, the error message now is:

error: expected ; or } after expression but found bar

which is a parser error rather than a type error. So I think that's close enough to what we wanted.

bjorn3 added a commit to bjorn3/rust that referenced this issue Apr 23, 2024
Allow MaybeUninit in input and output of inline assembly
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

3 participants