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

E0277 wrong span in diagnostic with explicit Sized bound #85998

Closed
tlyu opened this issue Jun 4, 2021 · 0 comments · Fixed by #86011
Closed

E0277 wrong span in diagnostic with explicit Sized bound #85998

tlyu opened this issue Jun 4, 2021 · 0 comments · Fixed by #86011
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-trait-system Area: Trait system A-type-system Area: Type system D-papercut Diagnostics: An error or lint that needs small tweaks. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@tlyu
Copy link
Contributor

tlyu commented Jun 4, 2021

Given the following code: (playground)

struct A<T: Sized>(T);
struct B(A<[u8]>);

The current output is:

error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
 --> src/lib.rs:2:10
  |
1 | struct A<T: Sized>(T);
  |          - required by this bound in `A`
2 | struct B(A<[u8]>);
  |          ^^^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `[u8]`

Ideally the output should look like:

error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
 --> src/lib.rs:2:10
  |
1 | struct A<T: Sized>(T);
  |             ----- required by this bound in `A`
2 | struct B(A<[u8]>);
  |          ^^^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `[u8]`

When the implicit Sized bound is added for generic type parameters, it goes at the front of the emitted predicate list. This means that its span, which is limited to the identifier of the generic, is what shows up in the error. It would be better if the error span pointed to the actual occurrence of the explicit Sized bound. Moving that implicit predicate to the end of the list would improve at least some of the error spans where there is an explicit Sized bound.

I'm working on a pull request for this issue.

@rustbot claim
@rustbot label +A-traits +A-typesystem +D-papercut

@tlyu tlyu added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 4, 2021
@rustbot rustbot added A-trait-system Area: Trait system A-type-system Area: Type system D-papercut Diagnostics: An error or lint that needs small tweaks. labels Jun 4, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this issue Oct 15, 2021
…stebank

move implicit `Sized` predicate to end of list

In `Bounds::predicates()`, move the implicit `Sized` predicate to the
end of the generated list. This means that if there is an explicit
`Sized` bound, it will be checked first, and any resulting
diagnostics will have a more useful span.

Fixes rust-lang#85998, at least partially. ~~Based on rust-lang#85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter.

I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason.

I also ran into an instance of rust-lang#84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.

`@estebank` this seems likely to conflict (slightly?) with your work on rust-lang#85947; how would you like to resolve that?
@bors bors closed this as completed in 36a1076 Oct 15, 2021
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 A-trait-system Area: Trait system A-type-system Area: Type system D-papercut Diagnostics: An error or lint that needs small tweaks. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants