]> git.lizzy.rs Git - rust.git/commit - src/tools/rust-analyzer
Rollup merge of #86011 - tlyu:correct-sized-bound-spans, r=estebank
authorMatthias Krüger <matthias.krueger@famsik.de>
Fri, 15 Oct 2021 05:44:44 +0000 (07:44 +0200)
committerGitHub <noreply@github.com>
Fri, 15 Oct 2021 05:44:44 +0000 (07:44 +0200)
commit36a1076d24697621a3bb67ef654b4eb79647aa54
tree744b06ca3ccc0f0371d2b920e58508a424e5785d
parente1e9319d93aea755c444c8f8ff863b0936d7a4b6
parentc07f5c43fca9a39da4efdac38fa2c6e301d267d8
Rollup merge of #86011 - tlyu:correct-sized-bound-spans, r=estebank

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 #85998, at least partially. ~~Based on #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 #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 #85947; how would you like to resolve that?