diff options
| author | bors <bors@rust-lang.org> | 2024-08-13 04:32:34 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-08-13 04:32:34 +0000 |
| commit | 591ecb88dffdb0f233e2fae74fd3d7c81d65ff0c (patch) | |
| tree | cd2dcd52c2c7eb4220eb42027136efad1f4976c4 /compiler/rustc_mir_build/src/errors.rs | |
| parent | e9e27ab0cf3759e420eeaa6bab7c7d454d9c10cd (diff) | |
| parent | 4763d12207561037847cc7dea4b695f3c129f1d7 (diff) | |
| download | rust-591ecb88dffdb0f233e2fae74fd3d7c81d65ff0c.tar.gz rust-591ecb88dffdb0f233e2fae74fd3d7c81d65ff0c.zip | |
Auto merge of #128742 - RalfJung:miri-vtable-uniqueness, r=saethlin
miri: make vtable addresses not globally unique Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair. To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.) r? `@saethlin` Fixes https://github.com/rust-lang/miri/issues/3737
Diffstat (limited to 'compiler/rustc_mir_build/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
