Merged
Conversation
…k-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.
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/rust#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
…ulacrum Fix SGX delayed host lookup via ToSocketAddr rust-lang/rust#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/rust#152848 cc @joboet
…tgross35 use libm for acosh and asinh Fixes rust-lang/rust#153878 Uses libm for `acosh` and `asinh`
…acrum More informative `Debug for vec::ExtractIf` While working on rust-lang/rust#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.
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/rust#154452
…Simulacrum Panic/return false on overflow in no_threads read/try_read impl As per discussion with Mark in rust-lang/rust#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).
…omez 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/rust#154733
…uwer Rollup of 8 pull requests Successful merges: - rust-lang/rust#149868 (rustc: Stop passing `--allow-undefined` on wasm targets) - rust-lang/rust#153555 (Clarified docs in std::sync::RwLock + added test to ensure that max reader count is respected) - rust-lang/rust#152851 (Fix SGX delayed host lookup via ToSocketAddr) - rust-lang/rust#154051 (use libm for acosh and asinh) - rust-lang/rust#154581 (More informative `Debug for vec::ExtractIf`) - rust-lang/rust#154461 (Edit the docs new_in() and with_capacity_in()) - rust-lang/rust#154526 (Panic/return false on overflow in no_threads read/try_read impl) - rust-lang/rust#154798 (rustdoc-search: match path components on words)
[Debugger Visualizers] Optimize lookup behavior # Background Almost all of the commands in `lldb_commands` used a regex to associate a type with the `synthetic_lookup` and `summary_lookup` python functions. When looking up a type, LLDB iterates through the commands in reverse order (so that new commands can overwrite old ones), stopping when it finds a match. These lookups are cached, but it's a shallow cache (e.g. when `Vec<T>` is matched by lldb, it will always point to `synthetic_lookup`, NOT the result of `synthetic_lookup` which would be `StdVecSyntheticProvider`). This becomes a problem because within `synthetic_lookup` and `summary_lookup` we run `classify_rust_type` which checks exact same regexes again. This causes 2 issues: 1. running the regexes via lldb commands is even more of a waste because the final check is a `.*` regex that associates with `synthetic_lookup` anyway 2. Every time lldb wants to display a value, that value must run the entirety of `synthetic_lookup` and run its type through 19 regexes + some assorted checks every single time. Those checks take between 1 and 100 microseconds depending on the type. On a 10,000 element `Vec<i32>` (which bypasses `classify_struct` and therefore the 19 regexes), ~30 milliseconds are spent on `classify_rust_type`. For a 10,000 element `Vec<UserDefinedStruct>` that jumps up to ~350 milliseconds. The salt on the wound is that some of those 19 regexes are useless (`BTreeMap` and `BTreeSet` which don't even have synthetic/summary providers so it doesn't matter if we know what type it is), and then the results of that lookup function use string-comparisons in a giant `if...elif...elif` chain. # Solution To fix all of that, the `lldb_commands` now point directly to their appropriate synthetic/summary when possible. In cases where there was extra logic, streamlined functions have been added that have much fewer types being passed in, thus only need to do one or two simple checks (e.g. `classify_hashmap` and `classify_hashset`). Some of the `lldb_commands` regexes were also consolidated to reduce the total number of commands we pass to lldb (e.g. `NonZero` An extra upshot is that `summary_lookup` could be completely removed due to being redundant.
…mulacrum
float: Fix panic at max exponential precision
Rust's formatting machinery allows precision values of up to u16::MAX. Exponential formatting works out the number of significant digits to use by adding one (for the integral digit before the decimal point).
This previously used usize precision, so the maximum validated precision did not overflow, but in commit fb9ce0297682 ("Limit formatting width and precision to 16 bits.") the precision type was narrowed to u16 without widening that addition first.
As a result an exponential precision value of 65535 is no longer handled correctly, because the digit count wraps to 0, and thus "{:.65535e}" panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits > 0". Other formats (and the parser) accept values up to u16::MAX.
A naive fix would be to widen that addition back to usize, but that still does not properly address 16-bit targets, where usize is only guaranteed to be able to represent values up to u16::MAX. The real issue is that this internal API is expressed in the wrong units for the formatter.
Fix this by changing exact exponential formatting to take fractional digits internally as well, and compute the temporary significant digit bound only when sizing the scratch buffer. To support that let's also make formatted length accounting saturate so that extremely large rendered outputs do not reintroduce overflows in padding logic.
This preserves the existing intent and keeps FormattingOptions compact while making formatting work consistently again.
fix compilation of time/hermit.rs rust-lang/rust#154518 has broken compiling std for Hermit by unwrapping an `i32`. This PR converts the `i32` to an `io::Result` before unwrapping. Closes rust-lang/rust#154626. Closes hermit-os/hermit-rs#965. r? @Mark-Simulacrum
…crum Make `substr_range` and `subslice_range` return the new `Range` type Makes the unstable `substr_slice` and `substr_range` functions return the new `core::range::Range` type, instead of the old `core::ops::Range`. Unblocks the [stabilization](rust-lang/rust#141266) of `#![feature(substr_range)]`, see rust-lang/rust#141266 (comment)
…uwer Rollup of 6 pull requests Successful merges: - rust-lang/rust#147552 ([Debugger Visualizers] Optimize lookup behavior) - rust-lang/rust#154052 (float: Fix panic at max exponential precision) - rust-lang/rust#154706 (fix compilation of time/hermit.rs) - rust-lang/rust#154707 (Make `substr_range` and `subslice_range` return the new `Range` type) - rust-lang/rust#154767 (triagebot: roll library reviewers for `{coretests,alloctests}`) - rust-lang/rust#154797 (bootstrap: Include shorthand aliases in x completions)
`BorrowedCursor`: make `init` a boolean This PR changes uninitialized bytes tracking in `BorrowedBuf` from being byte-wise to being buffer-wise. I've put all the API around `init` a new unstable feature `borrowed_buf_init`, to split the part that needs it and the part that doesn't. It will avoids accidental stabilization of this part. I'm not really convinced of the rename of `advance_unchecked` to `advance`, but I did it anyway. The old `advance` was kept as `advance_checked`. Alternative of rust-lang/rust#148937 Cc rust-lang/rust#78485 rust-lang/rust#117693 Cc @joshtriplett r? @Amanieu
miri subtree update Subtree update of `miri` to ce20bd3. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…uwer Rollup of 2 pull requests Successful merges: - rust-lang/rust#150129 (`BorrowedCursor`: make `init` a boolean) - rust-lang/rust#154830 (miri subtree update)
This updates the rust-version file to c92036b45babceee1d8d31cac5536207a26369a5.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@c92036b Filtered ref: a4b2f0c Upstream diff: rust-lang/rust@55e86c9...c92036b This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two. |
Member
|
@tgross35 we seem to need a higher ULP tolerance on i686-unknown-linux-gnu. Is that expected...? |
Member
|
Strangely, I cannot reproduce this locally, not even when I try many different seeds. It really has to be something with the libm on that host I think... |
RalfJung
force-pushed
the
rustup-2026-04-05
branch
from
ca6786f to
64599f1
Compare
Contributor
|
There were some inaccuracies in the inverse hyperbolic functions that recently got improved rust-lang/rust#154051, it's fine to increase further if they don't line up. I'm not sure about how exactly the CI works here but if Miri is built with a previous nightly but testing std from the most recent nightly (think that would be stage1?), that could explain the extra imprecision too. |
Member
|
The odd part is where it failed: let (val, sign) = (-0.5f64).ln_gamma();
assert_approx_eq!(val, (2.0 * f64_consts::PI.sqrt()).ln());I guess one point that makes this tricky is that we have imprecise functions on both sides, which doubles the maximum error. But there must still be something about the ln_gamma or ln implementation on the i686-unknown-linux-gnu runner that's less precise than on my system or else I'd have expected to reproduce the problem locally. Whatever, I hope adding another 4 ULP margin is enough. :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge ref 'c92036b45bab' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: rust-lang/rust@c92036b
Filtered ref: a4b2f0c
Upstream diff: rust-lang/rust@55e86c9...c92036b
This merge was created using https://github.com/rust-lang/josh-sync.