| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Add multi-producer, multi-consumer channel (mpmc)
Closes #125712
Tracking issue: #126840
r? m-ou-se
|
|
Enable `f16` tests on non-GNU Windows
There is a MinGW ABI bug that prevents `f16` and `f128` from being usable on `windows-gnu` targets. This does not affect MSVC; however, we have `f16` and `f128` tests disabled on all Windows targets.
Update the gating to only affect `windows-gnu`, which means `f16` tests will be enabled. There is no effect for `f128` since the default fallback is `false`.
try-job: x86_64-msvc
try-job: i686-msvc
|
|
Stabilize expr_2021 fragment specifier in all editions
This is part of the `expr`/`expr_2021` fragment specifier for Edition 2024 (#123742). The RFC says we can support expr_2021 in as many editions as is practical, and there's nothing particularly hard about supporting it all the way back to 2015.
In editions 2021 and earlier, `expr` and `expr_2021` are synonyms. Their behavior diverges starting in Edition 2024. This is checked by the `expr_2021_inline_const.rs` test.
cc `@vincenzopalazzo` `@rust-lang/wg-macros` `@traviscross`
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
Co-authored-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
|
|
rustdoc: rewrite stability inheritance as a doc pass
Since doc inlining can almost arbitrarily change the module hierarchy, we can't just use the HIR ancestors of an item to compute its effective stability. This PR moves the stability inheritance that I implemented in https://github.com/rust-lang/rust/pull/130798 into a new doc pass `propagate-stability` that runs after doc inlining and uses the post-inlining ancestors of an item to correctly compute its effective stability.
fixes https://github.com/rust-lang/rust/issues/131020
r? `@notriddle`
|
|
There is a MinGW ABI bug that prevents `f16` and `f128` from being
usable on `windows-gnu` targets. This does not affect MSVC; however, we
have `f16` and `f128` tests disabled on all Windows targets.
Update the gating to only affect `windows-gnu`, which means `f16` tests
will be enabled. There is no effect for `f128` since the default
fallback is `false`.
|
|
r=notriddle,jyn514
Add `field@` and `variant@` doc-link disambiguators
I'm not sure if this is big enough to need an fcp or not, but this is something I found missing when trying to refer to a field in macro-generated docs, not knowing if a method might be defined as well. Obviously, there are definitely other uses.
In the case where it's not disambiguated, methods (and I suppose other associated items in the value namespace) still take priority, which `@jyn514` said was an oversight but I think is probably the desired behavior 99% of the time anyway - shadowing a field with an accessor method is a very common pattern. If fields and methods with the same name started conflicting, it would be a breaking change. Though, to quote them:
> jyn: maybe you can break this only if both [the method and the field] are public
> jyn: rustc has some future-incompat warning level
> jyn: that gets through -A warnings and --cap-lints from cargo
That'd be out of scope of this PR, though.
Fixes #80283
|
|
Rollup of 5 pull requests
Successful merges:
- #129638 (Hook up std::net to wasi-libc on wasm32-wasip2 target)
- #130877 (rustc_target: Add RISC-V atomic-related features)
- #130914 (Mark some more types as having insignificant dtor)
- #130961 (Enable `f16` tests on x86 Apple platforms)
- #130966 (make ptr metadata functions callable from stable const fn)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
make ptr metadata functions callable from stable const fn
So far this was done with a bunch of `rustc_allow_const_fn_unstable`. But those should be the exception, not the norm. If we are confident we can expose the ptr metadata APIs *indirectly* in stable const fn, we should just mark them as `rustc_const_stable`. And we better be confident we can do that since it's already been done a while ago. ;)
In particular this marks two intrinsics as const-stable: `aggregate_raw_ptr`, `ptr_metadata`. This should be uncontroversial, they are trivial to implement in the interpreter.
Cc `@rust-lang/wg-const-eval` `@rust-lang/lang`
|
|
Enable `f16` tests on x86 Apple platforms
These were disabled because Apple uses a special ABI for `f16`. `compiler-builtins` merged a fix for this in [1], which has since propagated to rust-lang/rust. Enable tests since there should be no remaining issues on these platforms.
[1]: https://github.com/rust-lang/compiler-builtins/pull/675
try-job: x86_64-apple-1
try-job: x86_64-apple-2
|
|
Mark some more types as having insignificant dtor
These were caught by https://github.com/rust-lang/rust/pull/129864#issuecomment-2376658407, which is implementing a lint for some changes in drop order for temporaries in tail expressions.
Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory.
See some discussion on #89144 for what makes a drop impl "significant"
|
|
rustc_target: Add RISC-V atomic-related features
This adds the following three target features to unstable riscv_target_feature.
- `zaamo` (Zaamo Extension 1.0.0): Atomic Memory Operations (`amo*.{w,d}{,.aq,.rl,.aqrl}`)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L229-L231), [available since LLVM 19](https://github.com/llvm/llvm-project/commit/8be079cdddfd628d356d9ddb5ab397ea95fb1030))
- `zabha` (Zabha Extension 1.0.0): Byte and Halfword Atomic Memory Operations (`amo*.{b,h}{,.aq,.rl,.aqrl}`)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L238-L240), [available since LLVM 19](https://github.com/llvm/llvm-project/commit/6b7444964a8d028989beee554a1f5c61d16a1cac))
- `zalrsc` (Zalrsc Extension 1.0.0): Load-Reserved/Store-Conditional Instructions (`lr.{w,d}{,.aq,.rl,.aqrl}` and `sc.{w,d}{,.aq,.rl,.aqrl}`)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L261-L263), [available since LLVM 19](https://github.com/llvm/llvm-project/commit/8be079cdddfd628d356d9ddb5ab397ea95fb1030))
(Zacas Extension is not included here because it is still marked as experimental in LLVM 19 https://github.com/llvm/llvm-project/commit/70e7d26e560173c8b9db4c75ab4a3004cd5f021a and will become non-experimental in LLVM 20 https://github.com/llvm/llvm-project/commit/614aeda93b2225c6eb42b00ba189ba7ca2585c60)
`a` implies `zaamo` and `zalrsc`, and `zabha` implies `zaamo`:
- After Zaamo and Zalrsc Extensions are frozen, riscv-isa-manual says "The A extension comprises instructions provided by the Zaamo and Zalrsc extensions" (https://github.com/riscv/riscv-isa-manual/commit/e87412e621f11f4aac61a3b9d5e73e98a64b3432), and [`a` implies `zaamo` and `zalrsc` in GCC](https://github.com/gcc-mirror/gcc/blob/08693e29ec186fd7941d0b73d4d466388971fe2f/gcc/config/riscv/arch-canonicalize#L44). However, in LLVM, [`a` does not define them as implying `zaamo` and `zalrsc`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L206).
- Zabha and Zaamo are in a similar situation, [riscv-isa-manual](https://github.com/riscv/riscv-isa-manual/blob/main/src/zabha.adoc) says "The Zabha extension depends upon the Zaamo standard extension", and [`zabha` implies `zaamo` in GCC](https://github.com/gcc-mirror/gcc/blob/08693e29ec186fd7941d0b73d4d466388971fe2f/gcc/config/riscv/arch-canonicalize#L45-L46), but [does not in LLVM (but enabling `zabha` without `zaamo` or `a` is not allowed)](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/TargetParser/RISCVISAInfo.cpp#L776-L778).
r? `@Amanieu`
`@rustbot` label +O-riscv +A-target-feature
|
|
Hook up std::net to wasi-libc on wasm32-wasip2 target
One of the improvements of the `wasm32-wasip2` target over `wasm32-wasip1` is better support for networking. Right now, p2 is just re-using the `std::net` implementation from p1. This PR adds a new net module for p2 that makes use of net from `sys_common` and calls wasi-libc functions directly.
There are currently a few limitations:
- Duplicating a socket is not supported by WASIp2 (directly returns an error)
- Peeking is not yet implemented in wasi-libc (we could let wasi-libc handle this, but I opted to directly return an error instead)
- Vectored reads/writes are not supported by WASIp2 (the necessary functions are available in wasi-libc, but they call WASIp1 functions which do not support sockets, so I opted to directly return an error instead)
- Getting/setting `TCP_NODELAY` is faked in wasi-libc (uses the fake implementation instead of returning an error)
- Getting/setting `SO_LINGER` is not supported by WASIp2 (directly returns an error)
- Setting `SO_REUSEADDR` is faked in wasi-libc (since this is done from `sys_common`, the fake implementation is used instead of returning an error)
- Getting/setting `IPV6_V6ONLY` is not supported by WASIp2 and will always be set for IPv6 sockets (since this is done from `sys_common`, wasi-libc will return an error)
- UDP broadcast/multicast is not supported by WASIp2 (since this is configured from `sys_common`, wasi-libc will return appropriate errors)
- The `MSG_NOSIGNAL` send flag is a no-op because there are no signals in WASIp2 (since explicitly setting this flag would require a change to `sys_common` and the result would be exactly the same, I opted to not set it)
Do those decisions make sense?
While working on this PR, I noticed that there is a `std::os::wasi::net::TcpListenerExt` trait that adds a `sock_accept()` method to `std::net::TcpListener`. Now that WASIp2 supports standard accept, would it make sense to remove this?
cc `@alexcrichton`
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #131023 (Copy correct path to clipboard for modules/keywords/primitives)
- #131035 (Preserve brackets around if-lets and skip while-lets)
- #131038 (Fix `adt_const_params` leaking `{type error}` in error msg)
- #131053 (Improve `--print=check-cfg` documentation)
- #131056 (enable compiler fingerprint logs in verbose mode)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
enable compiler fingerprint logs in verbose mode
This provides very useful logs especially when debugging build cache-related stuff.
|
|
Improve `--print=check-cfg` documentation
This PR improves the `--print=check-cfg` documentation by:
1. switching to a table for better readability
2. adding a clear indication where the specific check-cfg syntax starts
3. adding a link to the main `--check-cfg` documentation
`@rustbot` label +F-check-cfg
|
|
r=compiler-errors
Fix `adt_const_params` leaking `{type error}` in error msg
Fixes the confusing diagnostic described in #118179. (users would see `{type error}` in some situations, which is pretty weird)
`adt_const_params` tracking issue: #95174
|
|
Preserve brackets around if-lets and skip while-lets
r? `@jieyouxu`
Tracked by #124085
Fresh out of #129466, we have discovered 9 crates that the lint did not successfully migrate because the span of `if let` includes the surrounding brackets `(..)` like the following, which surprised me a bit.
```rust
if (if let .. { .. } else { .. }) {
// ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// the span somehow includes the surrounding brackets
}
```
There is one crate that failed the migration because some suggestion spans cross the macro expansion boundaries. Surely there is no way to patch them with `match` rewrite. To handle this case, we will instead require all spans to be tested for admissibility as suggestion spans.
Besides, there are 4 false negative cases discovered with desugared-`while let`. We don't need to lint them, because the `else` branch surely contains exactly one statement because the drop order is not changed whatsoever in this case.
```rust
while let Some(value) = droppy().get() {
..
}
// is desugared into
loop {
if let Some(value) = droppy().get() {
..
} else {
break;
// here can be nothing observable in this block
}
}
```
I believe this is the one and only false positive that I have found. I think we have finally nailed all the corner cases this time.
|
|
Copy correct path to clipboard for modules/keywords/primitives
Fixes #131021
|
|
Bump `cc` and run `cargo update` for bootstrap
Bump `cc` to 1.1.22, which includes a caching fix. Also run `cargo update` which does a minor increment on a few dependencies.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #130895 (make type-check-4 asm tests about non-const expressions)
- #131057 (Reject leading unsafe in `cfg!(...)` and `--check-cfg`)
- #131060 (Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags to fix stage 1 cargo rebuilds)
- #131061 (replace manual verbose checks with `Config::is_verbose`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
replace manual verbose checks with `Config::is_verbose`
self-explanatory
|
|
Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags to fix stage 1 cargo rebuilds
The conditionally applied `-Zon-broken-pipe=kill` flag trigger rebuilds because they can invalidate previous tool build cache due to differing flags. This PR removes those flags to stop tool build cache invalidation.
> The build cache for clippy will be broken because bootstrap sets `-Zon-broken-pipe=kill` for every invocation except for cargo. Which means building cargo will invalidate any tool build cache which was built previously.
>
> *From <https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Modifying.20run-make.20tests.20unnecessarily.20rebuild.20stage.201.20cargo/near/473486972>*
Fixes #130980.
But introduces #131059 (breaks 2 cargo tests that relied upon some behavior related to `-Zon-broken-pipe=kill` being set).
r? `@onur-ozkan` (or bootstrap)
|
|
Reject leading unsafe in `cfg!(...)` and `--check-cfg`
This PR reject leading unsafe in `cfg!(...)` and `--check-cfg`.
Fixes (after-backport) https://github.com/rust-lang/rust/issues/131055
r? `@jieyouxu`
|
|
make type-check-4 asm tests about non-const expressions
These tests recently got changed in https://github.com/rust-lang/rust/pull/129759. I asked the PR author to make the tests read from a `static mut` (rather than just making them "pass"), but I now think that was a mistake: previously the tests failed because the const was not a valid const expression, after the PR they failed because the const failed to evaluate.
So this PR restores the tests to "fail because the const is not a valid const expression". That can be done in a target-independent way so I unified the x86 and aarch64 tests into one.
Cc `@oli-obk` as the original [author](https://github.com/rust-lang/rust/commit/0d88631059742db30c44edadd1c8a2f51c8eb971) of these tests -- not sure if you still remember what they were intended to test.
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
These conditionally applied flags trigger rebuilds because they can
invalidate previous cargo build cache.
|
|
add has_enzyme/needs-enzyme to the test infra
This unblocks merging the Enzyme / Autodiff frontend.
For the full implementation, see: https://github.com/rust-lang/rust/pull/129175
We don't want to run tests that require Enzyme / Autodiff support when we build rustc without the required features.
It correctly filtered out a test which started with `//@ needs-enzyme`.
```
running 80 tests
i...............................................................................
test result: ok. 79 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 380.41ms
```
Tracking:
- https://github.com/rust-lang/rust/issues/124509
r? jieyouxu
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
weekly update: add header to compiler deps update
Look at #131000: library and rustbook have nice headers for deps updates (i.e. `library dependencies:`), but not compiler one. Fixes this.
|
|
avoid `{type error}` being leaked in user-facing messages,
particularly when using the `adt_const_params` feature
|
|
Miri subtree update
r? `@ghost`
|
|
properly elaborate effects implied bounds for super traits
Summary: This PR makes it so that we elaborate `<T as Tr>::Fx: EffectsCompat<somebool>` into `<T as SuperTr>::Fx: EffectsCompat<somebool>` when we know that `trait Tr: ~const SuperTr`.
Some discussion at https://github.com/rust-lang/project-const-traits/issues/2.
r? project-const-traits
`@rust-lang/project-const-traits:` how do we feel about this approach?
|
|
|
|
In redesigned rustdoc toolbar: Adjust spacings and sizing to improve behavior with over-long names
Fixes #130993.
Some additional adjustments also fix more issues I’ve noticed such as:
* on small screens, opening search made the 3 bottons move down very slightly (because the row with the crate picker got larger, enlarging the whole grid), this is fixed with a `min-height: 60px` on the toolbar
* with long names in the “breadcrumps” area, wrapping was very broken
* 
* fixed:
* 
* the left grid area has a minimal width (105px); like before, that leaves about enough space for crate names becoming as short as “all cra…”;
to save even more space, there’s support for a little bit of extra squeezing of the buttons
* 
* 
* 
I’m really not super good with HTML or CSS stuff at all; there seem to be many magical numbers already, I’ve just used `px` values until things look right, I hope that’s okay 🤷♂️
r? `@GuillaumeGomez`
cc `@notriddle`
|
|
|
|
|
|
let rustfmt format imports
This matches the recent change in rustc.
`@rust-lang/miri` what do you think?
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #123932 (restate GlobalAlloc method safety preconditions in terms of what the caller has to do for greater clarity)
- #129003 (Improve Ord docs)
- #130972 (stabilize const_cell_into_inner)
- #130990 (try to get rid of mir::Const::normalize)
r? `@ghost`
`@rustbot` modify labels: rollup
|
