Conversation
|
I don't expect this to have perf effects but it's a widely-used type so let's check. @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Remove `OpaqueListContents`
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (7c5a6c1): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary -4.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 483.566s -> 485.77s (0.46%) |
This comment has been minimized.
This comment has been minimized.
69f7f82 to
4c8c82f
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
4c8c82f to
bf4d123
Compare
Ok, so in the details you mention the "first part" which is actually lost here, that |
| // SAFETY: `data_ptr` has the same provenance as `self` and can therefore | ||
| // access the `self.skel.len` elements stored at `self.skel.data`. | ||
| // Note that we specifically don't reborrow `&self.skel.data`, because that | ||
| // would give us a pointer with provenance over 0 bytes. |
There was a problem hiding this comment.
Does this provenance still work when the compiler thinks it does know the size? i.e. &self might have more limited range than when it was unsized.
There was a problem hiding this comment.
I don't know much about provenance, so I don't even know how a change here would manifest in practice.
These will be augmented in the next commit.
`RawList::opaque` has type `OpaqueListContents`, which is commented thusly: > A dummy type used to force `List` to be unsized while not requiring > references to it be wide pointers. The first part is true: it does make `List` unsized. This is a little annoying at times, requiring special handling. The second part is false: `&List<T>` is a narrow pointer whether the `opaque` field is present or not. This commit removes `RawList::opaque` and `OpaqueListContents`. Consequences: - `List`/`RawList` are now sized and we can add size assertions. - The `Erasable` impls for `&List`/`&ListWithCachedTypeInfo` are no longer necessary, because the impl for `&T` now covers them. - The unsafe `DynSync` and `Aligned` impls can be removed. - The `ptr_alignment_type` feature is no longer needed by `rustc_middle`.
They now have identical layout, so we don't need both.
bf4d123 to
25f7a58
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
ty::Listhas anOpaqueListContentsfield that supposedly prevents&Listfrom being a fat pointer but (a) it doesn't actually do that and (b) it causes other annoyances and complications. This PR removes it. Details in individual commits.r? @cuviper