| Age | Commit message (Collapse) | Author | Lines |
|---|
|
WIX toolset works only on Windows hosts and we need to boostrap this
host.
|
|
Disable download-rustc on CI
Should resolve https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/aarch64-apple.20try.20job.20doesn.27t.20work/with/522659759.
r? `@jieyouxu`
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#129121 (Stabilize `tcp_quickack`)
- rust-lang/rust#142192 (De-duplicate f16 & f128 doctest attributes)
- rust-lang/rust#142193 (add tests for pattern binding drop order edge cases)
- rust-lang/rust#142222 (Dont make `ObligationCtxt`s with diagnostics unnecessarily)
- rust-lang/rust#142228 (rustc-dev-guide subtree update)
- rust-lang/rust#142231 (Run `calculate_matrix` job on `master` to cache citool builds)
- rust-lang/rust#142232 (add `Cargo.lock` to CI-rustc allowed list for non-CI env)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add `Cargo.lock` to CI-rustc allowed list for non-CI env
Changes to dependencies usually require modifying `Cargo.toml`, which would already invalidate the CI-rustc cache if done in non-allowed paths. On non-CI environment, it should be safe to add `Cargo.lock` to the list of allowed paths as there is no real risk aside from a very rare false positive in cases like minor bumps to non-allowed path dependencies without modifying the `Cargo.toml` files.
Fixes rust-lang/rust#141986
|
|
Run `calculate_matrix` job on `master` to cache citool builds
As discussed in https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/PR.20ci.20seems.20much.20to.20slow/with/523028903, the current `rust-cache` solution for `citool` doesn't work, because we don't ever write to the cache from `master`, so the cache is empty on PR CI jobs.
This PR runs the `calculate_matrix` job on `master`, with the only motivation to actually prime the cache.
r? `@marcoieni`
|
|
rustc-dev-guide subtree update
r? `@ghost`
|
|
Dont make `ObligationCtxt`s with diagnostics unnecessarily
just a nit, shouldn't affect perf b/c `ObligationCtxt::new_with_diagnostics` should only be more expensive in the new trait solver, and I don't expect either of these to encounter errors today anyways.
r? oli-obk
|
|
add tests for pattern binding drop order edge cases
This adds tests for rust-lang/rust#142163, rust-lang/rust#142057, and rust-lang/rust#142056. I'm using these tests to help make sure I don't commit breaking changes when implementing match lowering for guard patterns, but I think it makes sense to add them separately. They don't directly have anything to do with guard patterns.
r? `@Nadrieril` or reassign
|
|
De-duplicate f16 & f128 doctest attributes
Now that rustdoc supports `#[doc(test(attr(...)))]` at every level, thanks to https://github.com/rust-lang/rust/pull/140560, we can de-duplicate the f16 & f128 doctest attributes.
Unfortunately we can de-duplicate the `cfg`s attribute as rustdoc would complain about missing `main`, but it's already much better than before.
Addresses https://github.com/rust-lang/rust/pull/140323/files#r2062702761
r? `@tgross35`
|
|
Stabilize `tcp_quickack`
to stabilise the quickack part for now, tcp_deferaccept had been added at a later stage.
The related API calls are the following
```rust
// std::os::linux::net
// sealed trait, implemented for std::net::TcpStream
pub trait TcpStreamExt: Sealed{
fn quickack(&self) -> io::Result<bool>;
fn set_quickack(&self, quickack: bool) -> io::Result<()>;
}
```
Closes: https://github.com/rust-lang/rust/issues/96256
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#141751 (Remap compiler vs non-compiler sources differently (bootstrap side))
- rust-lang/rust#142160 (Only allow `bootstrap` cfg in rustc & related)
- rust-lang/rust#142191 (early return in trait detection for non-trait item)
- rust-lang/rust#142211 (Do not checkout GCC submodule for the tidy job)
- rust-lang/rust#142218 (CI: rfl: move job forward to Linux v6.16-rc1)
- rust-lang/rust#142224 (Avoid a gratuitous 10s wait in a stress test)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
joshtriplett:remove-gratuitous-wait-in-stress-test, r=workingjubilee
Avoid a gratuitous 10s wait in a stress test
`stress_recv_timeout_two_threads`, in the mpmc and mpsc testsuites, is a stress test of the `recv_timeout` function. This test processes and ignores timeouts, and just ensures that every sent value gets received. As such, the exact length of the timeouts is not critical, only that the timeout and sleep durations ensure that at least one timeout occurred.
The current tests have 100 iterations, half of which sleep for 200ms, causing the test to take 10s. This represents around 2/3rds of the *total* runtime of the `library/std` testsuite, and is the only standard library test that takes more than a second.
Reduce this to 50 iterations where half of them sleep for 10ms, causing the test to take 0.25s.
Add a check that at least one timeout occurred.
|
|
CI: rfl: move job forward to Linux v6.16-rc1
Another hopefully routine upgrade to Linux v6.16-rc1, just released.
r? `@lqd` `@Kobzol`
try-job: x86_64-rust-for-linux
`@rustbot` label A-rust-for-linux
`@bors` try
|
|
Do not checkout GCC submodule for the tidy job
This is not a fully general solution, but the GCC submodule checkout is so slow that I think it's worth it to special-case it. This brings down the time required to checkout submodules from ~1.5 minute to ~0.5 minute.
|
|
early return in trait detection for non-trait item
Fixes rust-lang/rust#135863
|
|
Only allow `bootstrap` cfg in rustc & related
Fixes https://github.com/rust-lang/rust/issues/142150
r? bootstrap
|
|
Remap compiler vs non-compiler sources differently (bootstrap side)
See [#t-compiler/help > Span pointing to wrong file location (`rustc-dev` component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083).
The path remapping and unremapping for compiler sources (distributed via `rustc-dev` dist component) is broken because bootstrap currently remaps all sources unconditionally (if remapping is enabled) to the `/rustc/{hash}` form. However, the `rustc-dev` dist component (compiler sources) and `rust-src` dist component (library sources) unpacks differently:
- `rust-src` unpacks sources to a path like `$sysroot/lib/rustlib/src/rust`, whereas
- `rustc-dev` unpacks sources to a path like `$sysroot/lib/rustlib/rustc-src/rust`[^note],
meaning that the compiler need to unremap them differently. But the same remapping means that the compiler has no way to distinguish between compiler and non-compiler (esp. standard library) sources. To remedy this, this PR adopts the approach of:
- remapping compiler sources (corresponding to `rustc-dev` dist component) with `/rustc-dev/{hash}` (this is `RemapScheme::Compiler`), and
- remapping non-compiler sources (corresponding to `rust-src` dist component or other non-compiler sources) with `/rustc/{hash}` (this is `RemapScheme::NonCompiler`).
A different remapping allows the compiler to reverse the remapping differently.
This PR implements the bootstrap side. A follow-up compiler-side change is needed to implement the unremapping change to address the reported issue completely.
This PR introduces another env var `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` that is made available to the compiler when building compiler sources to know what the remap scheme for `rustc-dev` (`RemapScheme::Compiler`) is. Compiler sources are built with the compiler remapping scheme.
As far as I know, this change should not introduce new regressions, because the compiler source unremapping (through `rustc-dev`) is already broken.
[^note]: (Notice the `src` vs `rustc-src` difference.)
|
|
|
|
This allows us to reuse its cache on PR CI jobs.
|
|
So that we can make sure that they are reproducible locally.
|
|
r=workingjubilee
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
|
|
Rustc pull update
|
|
|
|
|
|
`stress_recv_timeout_two_threads`, in the mpmc and mpsc testsuites,
is a stress test of the `recv_timeout` function. This test processes and
ignores timeouts, and just ensures that every sent value gets received.
As such, the exact length of the timeouts is not critical, only that
the timeout and sleep durations ensure that at least one timeout
occurred.
The current tests have 100 iterations, half of which sleep for 200ms,
causing the test to take 10s. This represents around 2/3rds of the
*total* runtime of the `library/std` testsuite.
Reduce this to 50 iterations where half of them sleep for 10ms, causing
the test to take 0.25s.
Add a check that at least one timeout occurred.
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#141803 (Remove rustc's notion of "preferred" alignment AKA `__alignof`)
- rust-lang/rust#142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`)
- rust-lang/rust#142089 (Replace all uses of sysroot_candidates with get_or_default_sysroot)
- rust-lang/rust#142108 (compiler: Add track_caller to AbiMapping::unwrap)
- rust-lang/rust#142132 (`tests/ui`: A New Order [6/N])
- rust-lang/rust#142162 (UnsafePinned: update get() docs and signature to allow shared mutation)
- rust-lang/rust#142171 (`tests/ui`: A New Order [7/N])
- rust-lang/rust#142179 (store `target.min_global_align` as an `Align`)
- rust-lang/rust#142183 (Added test for 30904)
- rust-lang/rust#142194 (Remove all unused feature gates from the compiler)
- rust-lang/rust#142199 (Do not free disk space in the `mingw-check-tidy` job)
- rust-lang/rust#142210 (Run `mingw-check-tidy` on auto builds)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Run `mingw-check-tidy` on auto builds
This has two advantages:
- It moves `auto` builds closer to being a superset of PR CI builds
- It allows us to reuse the Docker cache for the job in PR CI, thus speeding up the job in PR CI considerably
Discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/PR.20ci.20seems.20much.20to.20slow).
r? ``@Mark-Simulacrum``
|
|
Do not free disk space in the `mingw-check-tidy` job
It's not needed an it slows down the job considerably. It took ~2 minutes out of the total 8-9 minutes of running `mingw-check-tidy`.
|
|
Remove all unused feature gates from the compiler
|
|
Added test for 30904
Test that was deleted by mistake in this commit
https://github.com/rust-lang/rust/commit/564c78a6981174b32079f576eb6e7f965a13945e#diff-85d65712084246fc61f287664eef63b0b25ba0a5c8b69a4a59a9454b6a3ebac4
The original issue is still open and the problem is not solved (if this is even a problem, but the error is still here at least)
|
|
store `target.min_global_align` as an `Align`
Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
|
|
`tests/ui`: A New Order [7/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
|
|
r=workingjubilee,traviscross
UnsafePinned: update get() docs and signature to allow shared mutation
Follow-up to https://github.com/rust-lang/rust/pull/140638, making `get` consistent with the fact that there's an `UnsafeCell` inside this type now by returning `*mut T` instead of `*const T`.
Cc ``@rust-lang/libs-api``
Tracking issue: https://github.com/rust-lang/rust/issues/125735
|
|
`tests/ui`: A New Order [6/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `````@jieyouxu`````
auxiliary tag means some changes in realted auxiliary file for test
|
|
compiler: Add track_caller to AbiMapping::unwrap
Same reason as it is on Option's.
|
|
Replace all uses of sysroot_candidates with get_or_default_sysroot
Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used:
* `get_or_default_sysroot` which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path.,
* `sysroot_candidates` which takes the former and additionally does another attempt at locating using `librustc_driver.so` except without linux multiarch handling and then returns both paths.,
The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the `--sysroot` passed in does not contain a copy of cg_llvm. Back then `get_or_default_sysroot` did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing `sysroot_candidates` can break things is if you have a custom driver inside what looks like a sysroot including the `lib/rustlib` directory, but which is missing some parts of the full sysroot like eg rust-lld.
Follow up to https://github.com/rust-lang/rust/pull/138404
|
|
Add new Tier-3 targets: `loongarch32-unknown-none*`
MCP: https://github.com/rust-lang/compiler-team/issues/865
NOTE: LoongArch32 ELF object support is available starting with object v0.37.0.
|
|
Remove rustc's notion of "preferred" alignment AKA `__alignof`
In PR rust-lang/rust#90877 T-lang decided not to remove `intrinsics::pref_align_of`. However, the intrinsic and its supporting code
1. is a nightly feature, so can be removed at compiler/libs discretion
2. requires considerable effort in the compiler to support, as it necessarily complicates every single site reasoning about alignment
3. has been justified based on relevance to codegen, but it is only a requirement for C++ (not C, not Rust) stack frame layout for AIX[^1], in ways Rust would not consider even with increased C++ interop
4. is only used by rustc to overalign some globals, not correctness[^2]
5. can be adequately replaced by other rules for globals, as it mostly affects alignments for a few types under 16 bytes of alignment
6. has only one clear beneficiary: automating C -> Rust translation for GNU extensions like `__alignof`[^3]
7. such code was likely intended to be `alignof` or `_Alignof`, because the GNU extension is a "false friend" of the C keyword, which makes the choice to support such a mapping very questionable
8. makes it easy to do incorrect codegen in the compiler by its mere presence as usual Rust rules of alignment (e.g. `size == align * N`) do not hold with preferred alignment[^4]
Despite an automated translation tool like c2rust using it, we have made multiple attempts to find a crate that actually has been committed to public repositories, like GitHub or crates.io, using such translated code. We have found none. While it is possible someone privately uses this intrinsic, it seems unlikely, and it is behind a feature gate that will warn about using the internal features of rustc.
The implementation is clearly damaging the code quality of the compiler. Thus it is within the compiler team's purview to simply rip it out. If T-lang wishes to have this intrinsic restored for c2rust's benefit, it would have to use a radically different implementation that somehow does not cause internal incorrectness.
Until then, remove the intrinsic and its supporting code, as one tool and an ill-considered GCC extension cannot justify risking correctness.
Because we touch a fair amount of the compiler to change this at all, and unfortunately the duplication of AbiAndPrefAlign is deep-rooted, we keep an "AbiAlign" type which we can wean code off later.
[^1]: https://github.com/rust-lang/rust/issues/91971#issuecomment-2451330704
[^2]: as viewable in the code altered by this PR
[^3]: c2rust: https://github.com/immunant/c2rust/blame/3b1ec86b9b0cf363adfd3178cc45a891a970eef2/c2rust-transpile/src/translator/mod.rs#L3175
[^4]: https://github.com/rust-lang/rustc_codegen_cranelift/issues/1560
|
|
We will want to remove many cases of `.abi`, including `.abi.thing`,
so this may simplify future PRs and certainly doesn't hurt.
We omit DerefMut because mutation is much rarer and localized.
|
|
In PR 90877 T-lang decided not to remove `intrinsics::pref_align_of`.
However, the intrinsic and its supporting code
1. is a nightly feature, so can be removed at compiler/libs discretion
2. requires considerable effort in the compiler to support, as it
necessarily complicates every single site reasoning about alignment
3. has been justified based on relevance to codegen, but it is only a
requirement for C++ (not C, not Rust) stack frame layout for AIX,
in ways Rust would not consider even with increased C++ interop
4. is only used by rustc to overalign some globals, not correctness
5. can be adequately replaced by other rules for globals, as it mostly
affects alignments for a few types under 16 bytes of alignment
6. has only one clear benefactor: automating C -> Rust translation
for GNU extensions like `__alignof`
7. such code was likely intended to be `alignof` or `_Alignof`,
because the GNU extension is a "false friend" of the C keyword,
which makes the choice to support such a mapping very questionable
8. makes it easy to do incorrect codegen in the compiler by its mere
presence as usual Rust rules of alignment (e.g. `size == align * N`)
do not hold with preferred alignment
The implementation is clearly damaging the code quality of the compiler.
Thus it is within the compiler team's purview to simply rip it out.
If T-lang wishes to have this intrinsic restored for c2rust's benefit,
it would have to use a radically different implementation that somehow
does not cause internal incorrectness.
Until then, remove the intrinsic and its supporting code, as one tool
and an ill-considered GCC extension cannot justify risking correctness.
Because we touch a fair amount of the compiler to change this at all,
and unfortunately the duplication of AbiAndPrefAlign is deep-rooted,
we keep an "AbiAlign" type which we can wean code off later.
|
|
const-eval error: always say in which item the error occurred
I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const.
r? `@oli-obk`
|
|
Atomic intrinsics : use const generic ordering, part 2
This completes what got started in https://github.com/rust-lang/rust/pull/141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new.
Blocked on:
- https://github.com/rust-lang/rust/pull/141507
- https://github.com/rust-lang/rust/pull/141687
- https://github.com/rust-lang/stdarch/pull/1811
- https://github.com/rust-lang/rust/pull/141964
r? `@bjorn3`
|
|
remove the archived ICE ping groups
|
|
|
|
Remove the comment on top as well, since that issue is now fixed in this
new tag.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Signed-off-by: Jakub Beránek <berykubik@gmail.com>
|
|
|
