diff options
| author | bors <bors@rust-lang.org> | 2023-11-15 06:05:54 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-11-15 06:05:54 +0000 |
| commit | 698fcc8219e6dd690b148a23af10a0e5747621fe (patch) | |
| tree | 7700b54768a83251b1437e9f250d88e17822fa03 /tests/rustdoc-js/slice-array.rs | |
| parent | cc8681b64b6f085bb64c0bbbe6739789d3b1eecf (diff) | |
| parent | c036a10ed501cd2c4b501af03c920af3f28d360f (diff) | |
| download | rust-698fcc8219e6dd690b148a23af10a0e5747621fe.tar.gz rust-698fcc8219e6dd690b148a23af10a0e5747621fe.zip | |
Auto merge of #117517 - klinvill:smir-projections, r=ouz-a
Add richer structure for Stable MIR Projections Resolves https://github.com/rust-lang/project-stable-mir/issues/49. Projections in Stable MIR are currently just strings. This PR replaces that representation with a richer structure, namely projections become vectors of `ProjectionElem`s, just as in MIR. The `ProjectionElem` enum is heavily based off of the MIR `ProjectionElem`. This PR is a draft since there are several outstanding issues to resolve, including: - How should `UserTypeProjection`s be represented in Stable MIR? In MIR, the projections are just a vector of `ProjectionElem<(),()>`, meaning `ProjectionElem`s that don't have Local or Type arguments (for `Index`, `Field`, etc. objects). Should `UserTypeProjection`s be represented this way in Stable MIR as well? Or is there a more user-friendly representation that wouldn't drag along all the `ProjectionElem` variants that presumably can't appear? - What is the expected behavior of a `Place`'s `ty` function? Should it resolve down the chain of projections so that something like `*_1.f` would return the type referenced by field `f`? - Tests should be added for `UserTypeProjection`
Diffstat (limited to 'tests/rustdoc-js/slice-array.rs')
0 files changed, 0 insertions, 0 deletions