Allow reallocation to different alignment in AllocRef

[TimDiekmann]

The allocator-wg has decided to support reallocating to a different alignment in AllocRef. For more details please see the linked issue.

r? @Amanieu

closes rust-lang/wg-allocators#5

[Amanieu]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 438c40e with merge 0b22c8a0d3ea0197f040b0d363462264e8646d10...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 0b22c8a0d3ea0197f040b0d363462264e8646d10 (0b22c8a0d3ea0197f040b0d363462264e8646d10)

[rust-timer]

Queued 0b22c8a0d3ea0197f040b0d363462264e8646d10 with parent e7f6ed1, future comparison URL.

[rust-timer]

Finished benchmarking try commit (0b22c8a0d3ea0197f040b0d363462264e8646d10): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[TimDiekmann]

That's an interesting report. The regression mainly occured in doc-runs (1.2% to 0.7%). Then almost only check-, doc-, and debug-runs betwee 0.5% and 0.1%). opt-runs are not affected. Mainly the regression will come from optimizing out the third match arm in grow and shrink as this case does not occure in std. I think this is mainly as the regression almost only occure in non-incremental full build starting with empty cache.

I think the stats are looking fine 🙂

[Amanieu]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 46b547c with merge e99efcbbc9cdf3dccd23122582a09ab2bd98d1ca...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: e99efcbbc9cdf3dccd23122582a09ab2bd98d1ca (e99efcbbc9cdf3dccd23122582a09ab2bd98d1ca)

[rust-timer]

Queued e99efcbbc9cdf3dccd23122582a09ab2bd98d1ca with parent 1a22a0f, future comparison URL.

[rust-timer]

Finished benchmarking try commit (e99efcbbc9cdf3dccd23122582a09ab2bd98d1ca): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[TimDiekmann]

Wow, didn't expected that! Nice observation.

[Amanieu]

@bors r+

[bors]

📌 Commit 46b547c has been approved by Amanieu

[bors]

⌛ Testing commit 46b547c with merge 79e6f4f5d592f9c34349ef841f802b473060eb84...

[bors]

💔 Test failed - checks-actions

[TimDiekmann]

We just entered the beta week.

[TimDiekmann]

No Breakage Week is over, let's merge this. 🙂

[Amanieu]

@bors retry

[bors]

⌛ Testing commit 46b547c with merge ffd59bf...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: Amanieu
Pushing ffd59bf to master...

[rust-log-analyzer]

Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

[RalfJung]

@rust-lang/infra something odd happened here... this is the PR that broke Miri, but for some reason CI only noticed this when the next PR (#75966) landed?

[RalfJung]

A bunch of recent PRs have a "Your PR failed" message after landing -- not just this one, also e.g. #75912.

[RalfJung]

See Zulip