Fix a layout possible miscalculation in alloc::RawVec

[a1phyr]

A layout miscalculation could happen in RawVec when used with a type whose size isn't a multiple of its alignment. I don't know if such type can exist in Rust, but the Layout API provides ways to manipulate such types. Anyway, it is better to calculate memory size in a consistent way.

[rust-highfive]

r? @joshtriplett

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

[bjorn3]

I don't know if such type can exist in Rust

I don't think so.

but the Layout API provides ways to manipulate such types.

Makes sense.

Anyway, it is better to calculate memory size in a consistent way.

I found at least one other place that used * size_of::<T>() inside shrink. There may be others.

[JohnTitor]

This seems reasonable and I agree that we should also take a look at shrink:

rust/library/alloc/src/raw_vec.rs

Lines 470 to 479 in 451e98e

	let (ptr, layout) = if let Some(mem) = self.current_memory() { mem } else { return Ok(()) };
	let new_size = amount * mem::size_of::<T>();
	let ptr = unsafe {
	let new_layout = Layout::from_size_align_unchecked(new_size, layout.align());
	self.alloc.shrink(ptr, layout, new_layout).map_err(|_| TryReserveError::AllocError {
	layout: new_layout,
	non_exhaustive: (),
	})?
	};

r=me once it's addressed.

[JohnCSimon]

Ping from triage:
@a1phyr

r=me once it's addressed.

Can you please address this

[a1phyr]

Done, also fixed capacity_from_bytes that did the same assumption.

[bors]

☔ The latest upstream changes (presumably #87408) made this pull request unmergeable. Please resolve the merge conflicts.

[a1phyr]

Rebased

[JohnTitor]

Sorry for the delay!
r? @JohnTitor @bors r+

[bors]

📌 Commit 03498aa has been approved by JohnTitor

[bors]

⌛ Testing commit 5376317 with merge ed9196e48a1c25c95588058b775e6c71cd47eb83...

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

.......... (50/60)
.......... (60/60)


/checkout/src/test/rustdoc-gui/search-result-description.goml An exception occured: Failed to launch the browser process!
Inconsistency detected by ld.so: dl-tls.c: 493: _dl_allocate_tls_init: Assertion `listp->slotinfo[cnt].gen <= GL(dl_tls_generation)' failed!


TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/master/docs/troubleshooting.md
== STACKTRACE ==
Error
Error
    at innerRunTestCode (/node-v14.4.0-linux-x64/lib/node_modules/browser-ui-test/src/index.js:468:16)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

[bors]

💔 Test failed - checks-actions

[JohnTitor]

Uhm, another spurious failure came up... @bors retry

[bors]

⌛ Testing commit 5376317 with merge 5bd1ec3...

[bors]

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 5bd1ec3 to master...

[rust-timer]

Finished benchmarking commit (5bd1ec3): comparison url.

Summary: This benchmark run shows 54 relevant regressions 😿 to instruction counts.

• Average relevant regression: 0.5%
• Largest regression in instruction counts: 1.2% on incr-unchanged builds of deeply-nested-async debug

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

[rylev]

@JohnTitor @a1phyr the perf regressions are somewhat small but still there are enough of them to warrant a check in on what's going on. I assume a small perf regression would be expected since we're now strictly doing more (e.g., checked multiplication), but is the magnitude of the regression here expected?