diff options
| author | bors <bors@rust-lang.org> | 2023-09-21 07:58:28 +0000 | 
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-09-21 07:58:28 +0000 | 
| commit | e4a361a48a59ead52b302aaa2e1d9d345264935a (patch) | |
| tree | c7b1c39afdc5368b770522b72fb73cacf5956ddf /compiler/rustc_codegen_cranelift/src/inline_asm.rs | |
| parent | 0a689c1be85d635bf61ffb7922ef9ce02587a3b1 (diff) | |
| parent | 614760f612fa72ba9d6955c00624c592b884d28f (diff) | |
| download | rust-e4a361a48a59ead52b302aaa2e1d9d345264935a.tar.gz rust-e4a361a48a59ead52b302aaa2e1d9d345264935a.zip | |
Auto merge of #115996 - lcnr:intercrate_ambiguity_causes-uwu, r=compiler-errors
implement `intercrate_ambiguity_causes` in the new solver I added some comments but this is still somewhat of a mess. I think we should for the most part be able to treat all of this as a black box, so I can accept that this code isn't too great. I also believe that some of the weirdness here is unavoidable, as proof trees - and their visitor - hide semantically relevant information, so they cannot perfectly represent the actual solver behavior. There are some known bugs here when testing with `./x.py test tests/ui --bless -- --target-rustcflags -Ztrait-solver=next-coherence`. While I haven't diagnosed them all in detail I believe we are able to handle them all separately - `structurally_normalize` currently does not normalize opaque types, resulting in divergence between the solver internal `trait_ref_is_knowable` and the one when computing intercrate ambiguity causes. - we don't add an `intercrate_ambiguity_cause` for reserved impls - we should `deeply_normalize` the trait ref before printing it, that requires a "best effort" version of `deeply_normalize` r? `@compiler-errors`
Diffstat (limited to 'compiler/rustc_codegen_cranelift/src/inline_asm.rs')
0 files changed, 0 insertions, 0 deletions
