Recursively transform predicates in ty::Dynamic rather than using identity

[compiler-errors]

It is not correct to be using the identity trait ref for a dyn type. This leads to us downstream not being able to assert the non-existence of things like ty::Alias, ty::Param, ty::ReEarlyParam, etc. and also doesn't allow us to distinguish, e.g., dyn Trait<i32> and dyn Trait<&str>, lol.

Instead, just recursively transform the dyn predicates. We also should definitely be keeping around the projection predicates too.

cc @rcvalle@maurer

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in compiler/rustc_symbol_mangling/src/typeid

cc @rust-lang/project-exploit-mitigations, @rcvalle

[compiler-errors]

Is there a way to bulk fix the tests/codegen/sanitizer/cfi/*.rs tests? They're kind of excruciating to edit.

[compiler-errors]

@rcvalle: Specifically, I don't understand what you mean in #116404 (comment). If you disagree w/ this approach, I would appreciate if you constructed a test example that SIGILLs after this PR and not before (or at least describe such a case).

[rcvalle]

I agree with this approach. I just didn't know it was possible/how to do it at the time I implemented it using the identity of the trait that implemented the method (see also my comment on #123012 (comment)).

[maurer]

This looks reasonable to me as well.

[rcvalle]

Is there a way to bulk fix the tests/codegen/sanitizer/cfi/*.rs tests? They're kind of excruciating to edit.

Sorry, I've been creating and maintaining them manually 😞. One thing that might help is to look at the .ll file to get the correct encoding, double check it, and put it in the tests (if you're not doing this already).

[compiler-errors]

Ok well it's gonna take approximately 5 millennia to bless those tests then 💀

[rcvalle]

No worries! I can work on that and send a PR later.

[maurer]

This raised a thought in my mind - once we're done getting everything working, should transform_ty maybe be rewritten to use a type visitor? It seems like we would have gotten this one right "for free" without needing compiler_errors' wisdom if we had been using a visitor instead of manual recursion.

[compiler-errors]

Yes, it could be implemented as a TypeFolder, though we'd need to be careful to walk types correctly given those transform options. Still very doable.

[rcvalle]

I don't know, maybe? If we can do depth-first transformation of types using it, I guess it should work. If it's an improvement, I'm definitively up to it later.

[rcvalle]

FWIW, I don't know how type visitor works in detail, but how we do it now at least forces us to explicitly maintain the types we support encoding for, and are let known otherwise.

[compiler-errors]

I strongly agree that this should be rewritten as a TypeFolder. If you want to guarantee you're actually transforming the types correctly for each specific variant, then just use an exhaustive match. That is off-topic for this PR, though.

[lcnr]

lacking some context, will review once I am back from RustNation

[lcnr]

why is this needed? please add a comment why we have to sort here

[compiler-errors]

Because it transforms types to other types, which possibly change their stable order.

[compiler-errors]

Actually, this doesn't matter. We only sort by def path rn lol

[rustbot]

Some changes occurred in tests/codegen/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle

[bors]

☔ The latest upstream changes (presumably #123455) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

this pr is stuck in review hell and @maurer has volunteered to just do it themselves and i'm just gonna r+ that