Implement core::ptr::Unique on top of NonNull

[eduardosm]

Removes the use rustc_layout_scalar_valid_range_start and some unsafe blocks.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• a stabilization of a library feature
• introducing new or changes existing unstable library APIs
• changes to public documentation in ways that create new stability guarantees

[rust-highfive]

r? @thomcc

(rust-highfive has picked a reviewer for you, use r? to override)

[tmiasko]

You probably need to change the code generation by adding one additional extract_field / project_field when dereferencing a box (those correspond to the first field Box, the first field of Unique, and now in addition to that the first field of NonNull):

rust/compiler/rustc_codegen_ssa/src/mir/place.rs

Lines 450 to 454 in f38c5c8

	if cg_base.layout.ty.is_box() && !cg_base.layout.field(cx,1).is_zst(){
	let ptr = cg_base.extract_field(bx,0).extract_field(bx,0);
	ptr.deref(bx.cx())
	}else{

rust/compiler/rustc_codegen_ssa/src/mir/place.rs

Lines 465 to 469 in f38c5c8

	// a box with a non-zst allocator should not be directly dereferenced
	if cg_base.layout.ty.is_box() && !cg_base.layout.field(cx,1).is_zst(){
	let ptr = cg_base.project_field(bx,0).project_field(bx,0);
	bx.load_operand(ptr).deref(bx.cx())

[eduardosm]

You probably need to change the code generation by adding one additional extract_field / project_field when dereferencing a box (those correspond to the first field Box, the first field of Unique, and now in addition to that the first field of NonNull):

Thanks for the tip

[thomcc]

Hmm, yeah, never really did understand what the deal with Unique was, so I'm gonna to punt this to someone else. Naïvely, it looks fine.

r? rust-lang/libs

[m-ou-se]

@bors r+

[bors]

📌 Commit a22a9a9 has been approved by m-ou-se

[tmiasko]

FYI: @antoyo, @bjorn3 this pull request modifies Box, in case mini_core or other backends need matching changes.

[eduardosm]

Can we run MSVC CI on this PR to test CDB without waiting for rollup?

[m-ou-se]

Can we run MSVC CI on this PR to test CDB without waiting for rollup?

It's possible, but there's no bot command or something to do that. You'd have to temporarily modify src/ci/github-actions/ci.yml in this PR to include that test runner in the ones that run on PRs. (And run ./x.py run src/tools/expand-yaml-anchors/ to update .github/workflows/ci.yml.)

[eduardosm]

MSVC tests have finally passed, reverted PR CI changes

[klensy]

MSVC tests have finally passed, reverted PR CI changes

You can squash commits a little, instead of having unrelated ones in history.

[eduardosm]

You can squash commits a little, instead of having unrelated ones in history.

Done

[eduardosm]

@rustbot label -S-waiting-on-bors +S-waiting-on-review

[tmiasko]

@bors r=m-ou-se,tmiasko rollup=never

[bors]

📌 Commit 7ba0292 has been approved by m-ou-se,tmiasko

[bors]

⌛ Testing commit 7ba0292 with merge ac8b118...

[bors]

☀️ Test successful - checks-actions
Approved by: m-ou-se,tmiasko
Pushing ac8b118 to master...

[rust-timer]

Finished benchmarking commit (ac8b118): comparison url.

Summary:

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	20	10	0	6	20
mean2	0.6%	1.3%	N/A	-0.4%	0.6%
max	1.2%	2.5%	N/A	-0.5%	1.2%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

1. number of relevant changes↩

2. the arithmetic mean of the percent change↩

[pnkfelix]

• This seems like it introduced a regression into the compilation times for a lot of important crates.
• I'm not clear on what its buying us, it seems like internal code cleanup? That doesn't justify a >=1% compile-time regression to webrender and syn.

@eduardosm or @m-ou-se , do either of you have time to look into the cause of this? I'm tempted to suggest we revert it, unless someone can present an argument for why we need it.

[pnkfelix]

nominating for attention from T-libs, in the hopes that someone can address my concerns above.