Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

offset_of: allow (unstably) taking the offset of slice tail fields #126150

Merged
merged 1 commit into from
Jun 9, 2024

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Jun 8, 2024

Fields of type [T] have a statically known offset, so there is no reason to forbid them in offset_of!. This PR adds the offset_of_slice feature to allow them.

I created a tracking issue: #126151.

@rustbot
Copy link
Collaborator

rustbot commented Jun 8, 2024

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot
Copy link
Collaborator

rustbot commented Jun 8, 2024

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 8, 2024
Comment on lines +403 to +404
let lang_item = self.tcx.require_lang_item(LangItem::Sized, None);
self.require_type_meets(ty, span, code, lang_item);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

require_type_is_sized should be a tiny bit more concise

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That also duplicates some of the logic, though.

Comment on lines -3415 to -3417
for ty in tys.iter().take(index + 1) {
self.require_type_is_sized(ty, expr.span, ObligationCauseCode::Misc);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the justification for removing this? Trivial that this is implied by the well-formedness of the type?

For annoying level of completetness, is there a test that exercises this? If not, pls add. Maybe something like offset_of!(([i32], i32), 1)

Copy link
Member Author

@RalfJung RalfJung Jun 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made sure all tests still pass and couldn't see any reason why the loop existed, and there was no comment explaining it, so I removed it.

We don't have a similar loop for ADTs either. Not sure what is the point of a test for an obviously ill-formed type... and why only for tuples? Such a test, if we want it, is entirely orthogonal for this PR and could cover all sorts of axes of ill-definedness of a type.

EDIT: Turns out we had a good place to put such a test. 🤷

@@ -3391,8 +3391,19 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> {
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't leave an inline comment bc github is dumb, but there's a:

// FIXME: DSTs with static alignment should be allowed

...above for the enum case.

But we don't allow that for enums, since their tails are required to be sized. Can you tweak that message so it doesn't look like something that someone may be interested in fixing, since it's not really actionable unless we were to tweak enums in general.

@WaffleLapkin
Copy link
Member

I think this is a good improvement on its own, but as a sidenote: I wish there would be a trait for types with static alignment, so that this is not just a special case.

@compiler-errors
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jun 8, 2024

📌 Commit eb584a2 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 8, 2024
@bors
Copy link
Contributor

bors commented Jun 9, 2024

⌛ Testing commit eb584a2 with merge a595f32...

@bors
Copy link
Contributor

bors commented Jun 9, 2024

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing a595f32 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 9, 2024
@bors bors merged commit a595f32 into rust-lang:master Jun 9, 2024
7 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jun 9, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a595f32): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.3% [-0.3%, -0.3%] 2
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 3.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
3.9% [3.9%, 3.9%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 3.9% [3.9%, 3.9%] 1

Cycles

Results (primary -2.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.3% [-2.3%, -2.3%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.3% [-2.3%, -2.3%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: missing data
Artifact size: 319.68 MiB -> 319.87 MiB (0.06%)

@fmease fmease added the F-offset_of_slice `#![feature(offset_of_slice)]` label Jun 9, 2024
@RalfJung RalfJung deleted the offset_of_slice branch June 10, 2024 13:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-offset_of_slice `#![feature(offset_of_slice)]` merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants