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

Improve "no type for local variable" error when in check_const_with_ty #24414

Closed
pnkfelix opened this issue Apr 14, 2015 · 3 comments · Fixed by #38449
Closed

Improve "no type for local variable" error when in check_const_with_ty #24414

pnkfelix opened this issue Apr 14, 2015 · 3 comments · Fixed by #38449
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@pnkfelix
Copy link
Member

The control flow for rustc_typeck::check::check_const_with_ty can end up spitting out an error of the form:

non-constant-expr-for-fixed-len-vec.rs:15:25: 15:26 error: no type for local variable 10
non-constant-expr-for-fixed-len-vec.rs:15         let _x: [isize; n];

With the compiler as it stands today, this is usually coupled with an error of the form:

error: array length constant evaluation error: non-constant path in constant expr

but other changes being made may lead to only the "no type for local variable" message being emitted.

We can do better here, e.g. by passing along knowledge that we are looking at a const-expr and then reporting that local variables simply are invalid within const-exprs.

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label Apr 20, 2015
@dgopstein
Copy link

Just received a lone no type for local variable. It's reproducible with the following program:

fn main() {
  let len: usize = 1;
  let arr: [char; len] = ['a'];
}

@pyk
Copy link

pyk commented Sep 19, 2016

Any update for more informative error message? as described in #31082

@eddyb
Copy link
Member

eddyb commented Dec 16, 2016

This is an outright bug, the correct behavior is for the use of a variable from a constant to not resolve.
Fixed on an in-progress branch, self-assigning for tracking.

@eddyb eddyb self-assigned this Dec 16, 2016
bors added a commit that referenced this issue Dec 28, 2016
[10/n] Split constants and functions' arguments into disjoint bodies.

_This is part of a series ([prev](#38053) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._

<hr>

Finishes the signature-body split started in #37918, namely:
* `trait` items are separated just like `impl` items were, for uniformity, closing #37712
* `static`s, `const`s (including associated ones), `enum` discriminants and array lengths get bodies
  * even the count in "repeat expressions", i.e. `n` in `[x; n]`, which fixes #24414
* arguments' patterns are moved to the bodies, with the types staying in `FnDecl`
  * `&self` now desugars to `self: &Self` instead of `self: &_` (similarly for other `self` forms)
  * `astconv`'s and metadata's (for rustdoc) informative uses are explicitly ignored for the purposes of the dep graph. this could be fixed in the future by hashing the exact information being extracted about the arguments as opposed to generating a dependency on *the whole body*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants