diff options
| author | bors <bors@rust-lang.org> | 2024-07-22 05:56:05 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-07-22 05:56:05 +0000 |
| commit | ae7b1c191695f351e69ef7ad32c0897048bba73e (patch) | |
| tree | ee32bbe1cf95e1e0b30ab57d94e43747e0a5f91d /compiler/rustc_traits/src/codegen.rs | |
| parent | ee0fd6caf770e8b3baa403b4da3ef0c7e274dc21 (diff) | |
| parent | 107cf981d5f122bd8770987eb2d3dfea5b7429e1 (diff) | |
| download | rust-ae7b1c191695f351e69ef7ad32c0897048bba73e.tar.gz rust-ae7b1c191695f351e69ef7ad32c0897048bba73e.zip | |
Auto merge of #127442 - saethlin:alloc-decoding-lock, r=oli-obk
Try to fix ICE from re-interning an AllocId with different allocation contents As far as I can tell, based on my investigation in https://github.com/rust-lang/rust/issues/126741, the racy decoding scheme implemented here was never fully correct, but the arrangement of Allocations that's required to ICE the compiler requires some very specific MIR optimizations to create. As far as I can tell, GVN likes to create the problematic pattern, which is why we're noticing this problem now. So the solution here is to not do racy decoding. If two threads race to decoding an AllocId, one of them is going to sit on a lock until the other is done.
Diffstat (limited to 'compiler/rustc_traits/src/codegen.rs')
0 files changed, 0 insertions, 0 deletions