about summary refs log tree commit diff
path: root/compiler/rustc_codegen_gcc
diff options
context:
space:
mode:
authorMatthias Krüger <matthias.krueger@famsik.de>2021-10-15 07:44:44 +0200
committerGitHub <noreply@github.com>2021-10-15 07:44:44 +0200
commit36a1076d24697621a3bb67ef654b4eb79647aa54 (patch)
tree744b06ca3ccc0f0371d2b920e58508a424e5785d /compiler/rustc_codegen_gcc
parente1e9319d93aea755c444c8f8ff863b0936d7a4b6 (diff)
parentc07f5c43fca9a39da4efdac38fa2c6e301d267d8 (diff)
downloadrust-36a1076d24697621a3bb67ef654b4eb79647aa54.tar.gz
rust-36a1076d24697621a3bb67ef654b4eb79647aa54.zip
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?
Diffstat (limited to 'compiler/rustc_codegen_gcc')
0 files changed, 0 insertions, 0 deletions