Rollup of 9 pull requests #146157
Closed
Rollup of 9 pull requests #146157
+1,024
−620
Conversation
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
To make changes in table size obvious from git diffs
Include the sizes of the `to_lowercase` and `to_uppercase` tables in the total size calculations.
The `merge_ranges` function was very complicated and hard to understand. Forunately, we can use `slice::chunk_by` to achieve the same thing.
Rewrite `generate_tests` to be more idiomatic.
reading through the editorconfig spec, using `!` to negate an entire glob is simply not a feature. you can use `!` to negate a charachter class, but that's not what was going on here.
For `wasm32-wasip2`-and-beyond this tool is required, so in case it's disabled in `config.toml` add a sanity-check that it's present in the environment.
This commit is the start of an effort to support WASIp2 natively in the standard library. Before this commit the `wasm32-wasip2` target behaved exactly like `wasm32-wasip1` target by importing APIs from the core wasm module `wasi_snapshot_preview1`. These APIs are satisfied by the `wasm-component-ld` target by using an [adapter] which implements WASIp1 in terms of WASIp2. This adapter comes at a cost, however, in terms of runtime indirection and instantiation cost, so ideally the adapter would be removed entirely. The purpose of this adapter was to provide a smoother on-ramp from WASIp1 to WASIp2 when it was originally created. The `wasm32-wasip2` target has been around for long enough now that it's much more established. Additionally the only thing historically blocking using WASIp2 directly was implementation effort. Work is now underway to migrate wasi-libc itself to using WASIp2 directly and now seems as good a time as any to migrate the Rust standard library too. Implementation-wise the milestones here are: * The `wasm32-wasip2` target now also depends on the `wasi` crate at version 0.14.* in addition to the preexisting dependency of 0.11.*. The 0.14.* release series binds WASIp2 APIs instead of WASIp1 APIs. * Some preexisting naming around `mod wasi` or `wasi.rs` was renamed to `wasip1` where appropriate. For example `std::sys::pal::wasi` is now called `std::sys::pal::wasip1`. * More platform-specific WASI modules are now split between WASIp1 and WASIp2. For example getting the current time, randomness, and process arguments now use WASIp2 APIs directly instead of using WASIp1 APIs that require an adapter. It's worth pointing out that this PR does not migrate the entire standard library away from using WASIp1 APIs on the `wasm32-wasip2` target. Everything related to file descriptors and filesystem APIs is still using WASIp1. Migrating that is left for a future PR. In the meantime the goal of this change is to lay the groundwork necessary for migrating in the future. Eventually the goal is to drop the `wasi` 0.11.* dependency on the `wasm32-wasip2` target (the `wasm32-wasip1` target will continue to retain this dependency). [adapter]: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/README.md
The `loongarch64-unknown-none` target is a bare-metal target with hardware floating-point support and should not enable SIMD extensions by default. However, LLVM's LoongArch64 backend enables LSX implicitly, inadvertently activating SIMD instructions for this target. This patch explicitly disable LSX feature to prevent unintended SIMD usage.
In writing up the reference for frontmatter, I realized that we probably shouldn't be accepting Unicode Line Ending characters between the code fence and infostring or trailing after the infostring or a code fence. In digging into the unicode specification we use for Whitespace, it divides it up into categories, so I'm deferring to what it says for horizontal whitespace for what should be used within a line. Note, I am leaving out support for Unicde Default Ignorable characters. I figure that can be discussed outside of this change within the reference and tracking issue.
a more general version of rust-lang#146080. after a bit of hacking in [`fluent.rs`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_fluent_macro/src/fluent.rs), i discovered that i'm not the only one that is bad at following guidelines 😅. this pr lowercases the first letter of all the error messages in the codebase. (i did not change things that are traditionally uppercased such as _MIR_, _ABI_ or _C_) i think it's reasonable to run a `@bors try` so all the test suite is checked, as i cannot run some of the tests on my machine. i double checked (and replaced manually) all the old error messages, but better be safe than sorry. in the future i will try to add a check in `x test tidy` that errors if an error message starts with an uppercase letter.
This upgrades the Rust CI from v6.16-rc1 plus a temporary commit for the >= 1.91 target spec [1] to v6.17-rc3 with two commits pending to be merged upstream -- one for the same target spec format change [1] and another for the `file_as_c_str` change [2]. Link: rust-lang#144443 [1] Link: rust-lang#145928 [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
… r=tgross35 Constify conversion traits (part 1) This is the first part of rust-lang#144289 being split into smaller pieces. It adds/moves constness of several traits under the `const_convert` feature: * `From` * `Into` * `TryFrom` * `TryInto` * `FromStr` * `AsRef` * `AsMut` * `Borrow` * `BorrowMut` * `Deref` * `DerefMut` There are a few methods that are intrinsically tied to these traits which I've included in the feature. Particularly, those which are wrappers over `AsRef`: * `ByteStr::new` (unstable under `bstr` feature) * `OsStr::new` * `Path::new` Those which directly use `Into`: * `Result::into_ok` * `Result::into_err` And those which use `Deref` and `DerefMut`: * `Pin::as_ref` * `Pin::as_mut` * `Pin::as_deref_mut` * `Option::as_deref` * `Option::as_deref_mut` * `Result::as_deref` * `Result::as_deref_mut` (note: the `Option` and `Result` methods were suggested by `@npmccallum` initially as rust-lang#146101) The parts which are missing from this PR are: * Anything that involves heap-allocated types * Making any method const than the ones listed above * Anything that could rely on the above, *or* could rely on system-specific code for `OsStr` or `Path` (note: this mostly makes these methods useless since `str` doesn't implement `AsRef<OsStr>` yet, but it's better to track the method for now and add impls later, IMHO) r? `@tgross35` (who mostly already reviewed this)
…, r=joshtriplett,tgross35 unicode-table-generator refactors Split off from rust-lang#145219
…uillaumeGomez editorconfig: don't use nonexistent syntax reading through the editorconfig spec, using `!` to negate an entire glob is simply not a feature. you can use `!` to negate a charachter class, but that's not what was going on here.
…ss35 std: Start supporting WASIp2 natively This commit is the start of an effort to support WASIp2 natively in the standard library. Before this commit the `wasm32-wasip2` target behaved exactly like `wasm32-wasip1` target by importing APIs from the core wasm module `wasi_snapshot_preview1`. These APIs are satisfied by the `wasm-component-ld` target by using an [adapter] which implements WASIp1 in terms of WASIp2. This adapter comes at a cost, however, in terms of runtime indirection and instantiation cost, so ideally the adapter would be removed entirely. The purpose of this adapter was to provide a smoother on-ramp from WASIp1 to WASIp2 when it was originally created. The `wasm32-wasip2` target has been around for long enough now that it's much more established. Additionally the only thing historically blocking using WASIp2 directly was implementation effort. Work is now underway to migrate wasi-libc itself to using WASIp2 directly and now seems as good a time as any to migrate the Rust standard library too. Implementation-wise the milestones here are: * The `wasm32-wasip2` target now also depends on the `wasi` crate at version 0.14.* in addition to the preexisting dependency of 0.11.*. The 0.14.* release series binds WASIp2 APIs instead of WASIp1 APIs. * Some preexisting naming around `mod wasi` or `wasi.rs` was renamed to `wasip1` where appropriate. For example `std::sys::pal::wasi` is now called `std::sys::pal::wasip1`. * More platform-specific WASI modules are now split between WASIp1 and WASIp2. For example getting the current time, randomness, and process arguments now use WASIp2 APIs directly instead of using WASIp1 APIs that require an adapter. It's worth pointing out that this PR does not migrate the entire standard library away from using WASIp1 APIs on the `wasm32-wasip2` target. Everything related to file descriptors and filesystem APIs is still using WASIp1. Migrating that is left for a future PR. In the meantime the goal of this change is to lay the groundwork necessary for migrating in the future. Eventually the goal is to drop the `wasi` 0.11.* dependency on the `wasm32-wasip2` target (the `wasm32-wasip1` target will continue to retain this dependency). [adapter]: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/README.md
…rcote resolve: Avoid a regression from splitting prelude into two scopes Fixes rust-lang#145575.
Explicity disable LSX feature for `loongarch64-unknown-none` target The `loongarch64-unknown-none` target is a bare-metal target with hardware floating-point support and should not enable SIMD extensions by default. However, LLVM's LoongArch64 backend enables LSX implicitly, inadvertently activating SIMD instructions for this target. This patch explicitly disable LSX feature to prevent unintended SIMD usage.
fix(lexer): Only allow horizontal whitespace in frontmatter In writing up the reference for frontmatter, I realized that we probably shouldn't be accepting Unicode Line Ending characters between the code fence and infostring or trailing after the infostring or a code fence. In digging into the unicode specification we use for Whitespace, it divides it up into categories, so I'm deferring to what it says for horizontal whitespace for what should be used within a line. Note, I am leaving out support for Unicode Default Ignorable characters. I figure that can be discussed outside of this change within the reference and tracking issue. Fixes rust-lang#145971 Frontmatter tracking issue: rust-lang#136889
…leLapkin don't uppercase error messages
CI: rfl: move job forward to Linux v6.17-rc3 plus 2 commits This upgrades the Rust CI from v6.16-rc1 plus a temporary commit for the >= 1.91 target spec [1] to v6.17-rc3 with two commits pending to be merged upstream -- one for the same target spec format change [1] and another for the `file_as_c_str` change [2]. Link: rust-lang#144443 [1] Link: rust-lang#145928 [2] r? `@lqd` `@Kobzol` try-job: x86_64-rust-for-linux `@rustbot` label A-rust-for-linux `@bors` try
rustbot
added
A-attributes
rustbot
added
A-query-system
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Sep 3, 2025
Rollup of 9 pull requests Successful merges: - #145279 (Constify conversion traits (part 1)) - #145414 (unicode-table-generator refactors) - #145823 (editorconfig: don't use nonexistent syntax) - #145944 (std: Start supporting WASIp2 natively ) - #145961 (resolve: Avoid a regression from splitting prelude into two scopes) - #146032 (Explicity disable LSX feature for `loongarch64-unknown-none` target) - #146106 (fix(lexer): Only allow horizontal whitespace in frontmatter ) - #146112 (don't uppercase error messages) - #146154 (CI: rfl: move job forward to Linux v6.17-rc3 plus 2 commits) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Successful merges:
loongarch64-unknown-nonetarget #146032 (Explicity disable LSX feature forloongarch64-unknown-nonetarget)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup