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

All fixed-size array impls show up as <unevaluated[]> #49208

Closed
eira-fransham opened this issue Mar 20, 2018 · 5 comments · Fixed by #49262
Closed

All fixed-size array impls show up as <unevaluated[]> #49208

eira-fransham opened this issue Mar 20, 2018 · 5 comments · Fixed by #49262
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug.

Comments

@eira-fransham
Copy link

eira-fransham commented Mar 20, 2018

After #46882, when a trait bound fails and the trait was implemented by fixed-size arrays, the compiler will display an error like:

   = help: the following implementations were found:
             <[T; <unevaluated[]>] as Trait>
             <[T; <unevaluated[]>] as Trait>
             <[T; <unevaluated[]>] as Trait>
             <[T; <unevaluated[]>] as Trait>
           and 31 others

Which is pretty unhelpful. A solution would be to evaluate these and/or to show evaluated bounds preferably.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 20, 2018

I can't reproduce triggering an error with these messages, do you have an example? I need it for a regression test, the fix was indeed as simple

to evaluate these and/or to show evaluated bounds preferably.

@kennytm kennytm added A-diagnostics Area: Messages for errors, warnings, and lints A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-bug Category: This is a bug. labels Mar 20, 2018
@eira-fransham
Copy link
Author

It only appears if you explicitly disambiguate the trait, like <[T; N] as Foo>::foo(). Playground link here.

@estebank
Copy link
Contributor

@oli-obk are you displaying these as <[(); _] as Foo>? I feel that'd be a reasonable output for this.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 22, 2018

@estebank that would be a better fallback than <unevaluated[]>, but I'm currently trying to get at the actual value (though that triggers cycle errors atm when building libcore's array impls ^^)

@eira-fransham
Copy link
Author

@estebank That's better in some ways, but kinda implies that for<const T> [(); T]: Foo

frewsxcv added a commit to frewsxcv/rust that referenced this issue Mar 23, 2018
…ebank

Produce nice array lengths on a best effort basis

fixes rust-lang#49208

r? @estebank
frewsxcv added a commit to frewsxcv/rust that referenced this issue Mar 23, 2018
…ebank

Produce nice array lengths on a best effort basis

fixes rust-lang#49208

r? @estebank
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 23, 2018
…ebank

Produce nice array lengths on a best effort basis

fixes rust-lang#49208

r? @estebank
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants