Rollup of 8 pull requests#154815
Conversation
This commit updates how the linker is invoked on WebAssembly targets
(all of them) to avoid passing the `--allow-undefined` flag to the
linker. Historically, if I remember this correctly, when `wasm-ld` was
first integrated this was practically required because at the time it
was otherwise impossible to import a function from the host into a wasm
binary. Or, at least, I'm pretty sure that was why this was added.
At the time, as the documentation around this option indicates, it was
known that this was going to be a hazard. This doesn't match behavior on
native, for example, and can easily paper over what should be a linker
error with some sort of other obscure runtime error. An example is that
this program currently compiles and links, it just prints null:
unsafe extern "C" {
static nonexistent: u8;
}
fn main() {
println!("{:?}", &raw const nonexistent);
}
This can easily lead to mistakes like rust-lang/libc/4880 and defer what
should be a compile-time link error to weird or unusual behavior at link
time. Additionally, in the intervening time since `wasm-ld` was first
introduced here, lots has changed and notably this program works as
expected:
#[link(wasm_import_module = "host")]
unsafe extern "C" {
fn foo();
}
fn main() {
unsafe {
foo();
}
}
Notably this continues to compile without error and the final wasm
binary indeed has an imported function from the host. What this change
means, however, is that this program:
unsafe extern "C" {
fn foo();
}
fn main() {
unsafe {
foo();
}
}
this currently compiles successfully and emits an import from the `env`
module. After this change, however, this will fail to compile with a
link error stating that the `foo` symbol is not defined.
…e can reach max reader
Since the length of a path is treated as sorting criteria, and every path that contains the query without exactly matching it must be longer, exact matches will always sort first if they exist.
…ed, r=Mark-Simulacrum
rustc: Stop passing `--allow-undefined` on wasm targets
This commit updates how the linker is invoked on WebAssembly targets (all of them) to avoid passing the `--allow-undefined` flag to the linker. Historically, if I remember this correctly, when `wasm-ld` was first integrated this was practically required because at the time it was otherwise impossible to import a function from the host into a wasm binary. Or, at least, I'm pretty sure that was why this was added.
At the time, as the documentation around this option indicates, it was known that this was going to be a hazard. This doesn't match behavior on native, for example, and can easily paper over what should be a linker error with some sort of other obscure runtime error. An example is that this program currently compiles and links, it just prints null:
unsafe extern "C" {
static nonexistent: u8;
}
fn main() {
println!("{:?}", &raw const nonexistent);
}
This can easily lead to mistakes like rust-lang/libc#4880 and defer what should be a compile-time link error to weird or unusual behavior at link time. Additionally, in the intervening time since `wasm-ld` was first introduced here, lots has changed and notably this program works as expected:
#[link(wasm_import_module = "host")]
unsafe extern "C" {
fn foo();
}
fn main() {
unsafe {
foo();
}
}
This continues to compile without error and the final wasm binary indeed has an imported function from the host. This program:
unsafe extern "C" {
fn foo();
}
fn main() {
unsafe {
foo();
}
}
this currently compiles successfully and emits an import from the `env` module. After this change, however, this will fail to compile with a link error stating that the `foo` symbol is not defined.
…lacrum Clarified docs in std::sync::RwLock + added test to ensure that max reader count is respected This addresses the issue with the [`std::sync::RwLock` docs](https://doc.rust-lang.org/std/sync/struct.RwLock.html) in rust-lang#115338. It centers around the following lines: > An `RwLock` will allow any number of readers to acquire the lock as long as a writer is not holding the lock. It's true that the `RwLock` in theory should allow any number of readers to acquire the lock when a writer is not holding it, but this may not be true in the implementation and could be os dependent. I decided to replace "any number of readers" to "multiple", so that it implies that more than 1 reader can acquire the lock, but you can't necessarily take away that this value is unbounded. @rustbot label +A-docs
…=Mark-Simulacrum Fix SGX delayed host lookup via ToSocketAddr rust-lang#146541 introduced a regression in the `x86_64-fortanix-unknown-sgx` target, where arguments to TcpStream::connect and TcpListener::bind are no longer being passed down correctly to the underlying platform, resulting in connection/bind failures * Add a test for the desired behavior (this test passes on Rust 1.33 through 1.91) * Refactor lookup_host logic again Fixes rust-lang#152848 cc @joboet
…asinh, r=tgross35 use libm for acosh and asinh Fixes rust-lang#153878 Uses libm for `acosh` and `asinh`
…ark-Simulacrum More informative `Debug for vec::ExtractIf` While working on rust-lang#154318, I've realized that `vec::ExtractIf` actually maintains a valid prefix and a valid suffix in the underlying vector at all times with all the temporarily-invalid elements being only in the middle. So why not make the `Debug` output more informative? I guess we could even expose something like `get_retained_mut(&mut self) -> &mut [T]` and `get_remainder_mut(&mut self) -> &mut [T]`, but that would add new backwards compatibility burden, unlike the `Debug` implementation, which (IIRC) can be changed at any time.
…acrum Edit the docs new_in() and with_capacity_in() I have updated the documentation for new_in(). While reviewing the code, I noticed that the documentation for with_capacity_in() was also inaccurate, so I have corrected it. Close rust-lang#154452
…, r=Mark-Simulacrum Panic/return false on overflow in no_threads read/try_read impl As per discussion with Mark in rust-lang#153555, it's possible for `no_threads` impl of `RwLock` to trigger a silent overflow on `RwLock::read`/`RwLock::try_read` if we try to acquire more than `isize::MAX` read locks. This PR adds an explicit panic/return false when our read lock counter is at `isize::MAX` for `RwLock::read`/`RwLock::try_read`; the message is similar to that of sys/sync/rwlock/futex.rs [here](https://github.com/rust-lang/rust/blob/fb27476aaf1012f1f6ace6306f9b990e0d989c31/library/std/src/sys/sync/rwlock/futex.rs#L143).
…uillaumeGomez rustdoc-search: match path components on words Since the length of a path is treated as sorting criteria, and every path that contains the query without exactly matching it must be longer, exact matches will always sort first if they exist. Fixes rust-lang#154733
|
@bors r+ rollup=never p=5 |
|
Trying commonly failed jobs |
This comment has been minimized.
This comment has been minimized.
Rollup of 8 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
|
📌 Perf builds for each rolled up PR:
previous master: 0312a55fe4 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 0312a55 (parent) -> e0e95a7 (this PR) Test differencesShow 2098 test diffsStage 1
Stage 2
Additionally, 2094 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard e0e95a71872dfe9e15d22bddea9ac45c85ddda1a --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (e0e95a7): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 2.2%, secondary -0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 1.1%, secondary 2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 489.356s -> 489.285s (-0.01%) |
Successful merges:
--allow-undefinedon wasm targets #149868 (rustc: Stop passing--allow-undefinedon wasm targets)Debug for vec::ExtractIf#154581 (More informativeDebug for vec::ExtractIf)r? @ghost
Create a similar rollup