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

[ER] Suboptimal error message in a case of min_const_generics inference failure #79557

Closed
leonardo-m opened this issue Nov 30, 2020 · 4 comments · Fixed by #79734
Closed

[ER] Suboptimal error message in a case of min_const_generics inference failure #79557

leonardo-m opened this issue Nov 30, 2020 · 4 comments · Fixed by #79734
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

Comments

@leonardo-m
Copy link

This code:

#![feature(min_const_generics)]
fn foo<const N: usize, const K: usize>(data: [u32; N]) -> [u32; K] {
    [0; K]
}
fn main() {
    let a = foo::<_, 2>([0, 1, 2]);
}

Gives (with rustc 1.50.0-nightly 349b3b3 2020-11-29):

error[E0747]: type provided when a constant was expected
 --> ...\test.rs:6:19
  |
6 |     let a = foo::<_, 2>([0, 1, 2]);
  |                   ^

Two problems:

  1. In the code I've used the underscore hoping rustc to infer the value of N, but for some reason it failed.
  2. Beside the type inference failure, the error message is not the best possible. I didn't provide a type. A better error message could say "unable to infer the const argument N, please specify".
@leonardo-m leonardo-m changed the title ]Suboptimal error message in a case of min_const_generics inference failure [ER] Suboptimal error message in a case of min_const_generics inference failure Nov 30, 2020
@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. F-min_const_generics labels Nov 30, 2020
@lcnr lcnr added the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label Dec 4, 2020
@lcnr
Copy link
Contributor

lcnr commented Dec 4, 2020

Using _ for a const parameter is currently not possible, though that seems both like something we are able to support and probably should.

Until we implement this we probably want to add a help here which says that _ is not allowed for const arguments, only for types. Will open a topic on zulip about this https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/.60_.60.20as.20const.20param.20help.20msg

@varkor
Copy link
Member

varkor commented Dec 4, 2020

Fixing this requires essentially the same strategy as fixing #66615 (and, to a lesser extent, #77773).

@leonardo-m
Copy link
Author

leonardo-m commented Dec 30, 2020

Now (rustc 1.51.0-nightly 158f8d0 2020-12-29) this code:

fn main() {
    fn init<const N: usize, const M: usize>(foos: &mut [bool; M]) {}
    const N: usize = 5;
    let mut foos = [false; 10];
    init::<N, _>(&mut foos);
}

Gives:

error[E0747]: type provided when a constant was expected
 --> ...\test.rs:5:15
  |
5 |     init::<N, _>(&mut foos);
  |               ^
  |
  = help: const arguments cannot yet be inferred with `_`
  = note: type arguments must be provided before constant arguments
  = help: reorder the arguments: consts: `<N, M>`

The last two lines (the note and the second help) seem off to me.

@varkor
Copy link
Member

varkor commented Dec 30, 2020

Opened #80528 for actually supporting this feature, rather than diagnostics suggesting it to be invalid.

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 C-enhancement Category: An issue proposing an enhancement or a PR with one. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants