| Age | Commit message (Collapse) | Author | Lines |
|---|
|
internal: More `shrink_to_fit()` and upgrade dashmap and hashbrown
|
|
|
|
It's the intended use.
|
|
And adapt `intern` to the changes in the API.
|
|
Rollup of 8 pull requests
Successful merges:
- #137096 (Stabilize flags for doctest cross compilation)
- #140148 (CI: use aws codebuild for job dist-arm-linux)
- #140187 ([AIX] Handle AIX dynamic library extensions within c-link-to-rust-dylib run-make test)
- #140196 (Improved diagnostics for non-primitive cast on non-primitive types (`Arc`, `Option`))
- #140210 (Work around cygwin issue on condvar timeout)
- #140213 (mention about `x.py setup` in `INSTALL.md`)
- #140229 (`DelimArgs` tweaks)
- #140248 (Fix impl block items indent)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
This saves 18mb on `analysis-stats .`, without regressing speed.
|
|
|
|
Revert compiletest new-executor, to re-land without download-rustc
Revert <https://github.com/rust-lang/rust/pull/139998> because the original merge triggered download-rustc, which messes with test metrics and prevents us from properly comparing them before/after the change.
The plan is to re-land this PR as-is, combined with a trivial compiler change to avoid download-rustc and get proper test metrics for comparison.
This reverts commit be181dd75c83d72fcc95538e235768bc367b76b9, reversing changes made to 645d0ad2a4f145ae576e442ec5c73c0f8eed829b.
r? ghost
|
|
|
|
|
|
Enable PGO optimizations when installing rust-analyzer with the
--pgo flag. This mirrors functionality already available in dist
command, allowing developers to create optimized local builds.
Example:
cargo xtask install --server --pgo clap-rs/clap
PGO code has been extracted to a dedicated module for reuse.
|
|
|
|
Stabilize flags for doctest cross compilation
This makes the following changes in preparation for supporting doctest cross-compiling in cargo:
- Renames `--runtool` and `--runtool-arg` to `--test-runtool` and `--test-runtool-arg` to maintain consistency with other `--test-*` arguments.
- Stabilizes the `--test-runtool` and `--test-runtool-arg`. These are needed in order to support cargo's `target.runner` option which specifies a runner to execute a cross-compiled doctest (for example, qemu).
- Stabilizes the `--enable-per-target-ignores` flag by removing it and making it unconditionally enabled. This makes it possible to disable a doctest on a per-target basis, which I think will be helpful for rolling out this feature.
These changes were suggested in https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stabilizing.20doctest.20xcompile/near/409281127
The intent is to stabilize the doctest-xcompile feature in cargo. This will help ensure that for projects that do cross-compile testing that their doctests are also covered. Currently there is a somewhat surprising behavior that they are ignored.
Closes https://github.com/rust-lang/rust/issues/64245
try-job: x86_64-msvc-1
|
|
r=jieyouxu
Remove git repository from git config
It is no longer needed after https://github.com/rust-lang/rust/pull/138591. We could even remove the `nightly_branch` field, but it still has one usage.
r? ``@jieyouxu``
|
|
Make algebraic functions into `const fn` items.
Tracking issue: #136469
This PR makes the algebraic intrinsics and the unstable, algebraic functions of `f16`, `f32`, `f64`, and `f128` into `const fn` items:
```rust
impl f16 {
pub const fn algebraic_add(self, rhs: f16) -> f16;
pub const fn algebraic_sub(self, rhs: f16) -> f16;
pub const fn algebraic_mul(self, rhs: f16) -> f16;
pub const fn algebraic_div(self, rhs: f16) -> f16;
pub const fn algebraic_rem(self, rhs: f16) -> f16;
}
impl f32 {
pub const fn algebraic_add(self, rhs: f32) -> f32;
pub const fn algebraic_sub(self, rhs: f32) -> f32;
pub const fn algebraic_mul(self, rhs: f32) -> f32;
pub const fn algebraic_div(self, rhs: f32) -> f32;
pub const fn algebraic_rem(self, rhs: f32) -> f32;
}
impl f64 {
pub const fn algebraic_add(self, rhs: f64) -> f64;
pub const fn algebraic_sub(self, rhs: f64) -> f64;
pub const fn algebraic_mul(self, rhs: f64) -> f64;
pub const fn algebraic_div(self, rhs: f64) -> f64;
pub const fn algebraic_rem(self, rhs: f64) -> f64;
}
impl f128 {
pub const fn algebraic_add(self, rhs: f128) -> f128;
pub const fn algebraic_sub(self, rhs: f128) -> f128;
pub const fn algebraic_mul(self, rhs: f128) -> f128;
pub const fn algebraic_div(self, rhs: f128) -> f128;
pub const fn algebraic_rem(self, rhs: f128) -> f128;
}
// core::intrinsics
pub const fn fadd_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn fsub_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn fmul_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn fdiv_algebraic<T: Copy>(a: T, b: T) -> T;
pub const fn frem_algebraic<T: Copy>(a: T, b: T) -> T;
```
This PR does not preserve the initial behaviour of these functions yielding non-deterministic output under Miri; it is most likely desired to reimplement this behaviour at some point.
|
|
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc
implements #136067
Rust has helper methods for many kinds of safe transmutes, for example integer<->bytes. This is a lint against using transmute for these cases.
```rs
fn bytes_at_home(x: [u8; 4]) -> u32 {
transmute(x)
}
// other examples
transmute::<[u8; 2], u16>();
transmute::<[u8; 8], f64>();
transmute::<u32, [u8; 4]>();
transmute::<char, u32>();
transmute::<u32, char>();
```
It would be handy to suggest `u32::from_ne_bytes(x)`.
This is implemented for `[u8; _]` -> `{float int}`
This also implements the cases:
`fXX` <-> `uXX` = `{from_bits, to_bits}`
`uXX` -> `iXX` via `cast_unsigned` and `cast_signed`
{`char` -> `u32`, `bool` -> `n8`} via `from`
`u32` -> `char` via `from_u32_unchecked` (note: notes `from_u32().unwrap()`) (contested)
`u8` -> `bool` via `==` (debatable)
---
try-job: aarch64-gnu
try-job: test-various
|
|
Arena allocate `LifetimeRef`s
|
|
Rollup of 8 pull requests
Successful merges:
- #139261 (mitigate MSVC alignment issue on x86-32)
- #140075 (Mention average in midpoint documentations)
- #140184 (Update doc of cygwin target)
- #140186 (Rename `compute_x` methods)
- #140194 (minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`)
- #140195 (triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes)
- #140214 (Remove comment about handling non-global where bounds with corresponding projection)
- #140228 (Revert overzealous parse recovery for single colons in paths)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`
To preserve CFI directives in assembly tests, as `//@ add-core-stubs` already imply `-C panic=abort`.
This is a blocker for https://github.com/rust-lang/rust/pull/140037#issuecomment-2816665358.
cc ```@RalfJung```
r? ```@bjorn3```
|
|
|
|
|
|
|
|
|
|
fix: Fix type argument mismatch incorrectly triggering on inferred trait args
|
|
|
|
|
|
Previously this being incorrect wasn't a problem, it just meant we put an error type that then changed to infer type, so exactly what rustc does at the end. But now there is a diagnostic.
|
|
|
|
|
|
|
|
Stabilize the `cell_update` feature
Included API:
```rust
impl<T: Copy> Cell<T> {
pub fn update(&self, f: impl FnOnce(T) -> T);
}
```
FCP completed once at https://github.com/rust-lang/rust/issues/50186#issuecomment-2198783432 but the signature has since changed.
Closes: https://github.com/rust-lang/rust/issues/50186
|
|
And also, prepare for correct lowering of lifetime. We still don't handle most lifetimes correctly, but a bit more of the foundation to lifetime elision is now implemented.
|
|
Revert <https://github.com/rust-lang/rust/pull/139998> because the original
merge triggered download-rustc, which messes with test metrics and prevents us
from properly comparing them before/after the change.
The plan is to re-land this PR as-is, combined with a trivial compiler change
to avoid download-rustc and get proper test metrics for comparison.
This reverts commit be181dd75c83d72fcc95538e235768bc367b76b9, reversing
changes made to 645d0ad2a4f145ae576e442ec5c73c0f8eed829b.
|
|
This commit updates the vendored `wasm-component-ld` binary to 0.5.13
which includes some various bug fixes and new feature updates for
upcoming component model features coming down the pike. Not expected to
break any existing workflows, just a normal update.
|
|
Clippy subtree update
r? `@Manishearth`
Cargo.lock update due to the Clippy version bump and because Clippy moved from rinja (unmaintained) to askama.
Last sync was skipped due to the askama issue and me not getting to fixing this in time.
|
|
|
|
compiletest: Use the new non-libtest executor by default
The new executor was implemented in #139660, but required a manual opt-in. This PR activates the new executor by default, but leaves the old libtest-based executor in place (temporarily) to make reverting easier if something unexpectedly goes horribly wrong.
Currently the new executor can be explicitly disabled by passing the `-N` flag to compiletest (e.g. `./x test ui -- -N`), but eventually that flag will be removed, alongside the removal of the libtest dependency. The flag is mostly there to make manual comparative testing easier if something does go wrong.
As before, there *should* be no user-visible difference between the old executor and the new executor.
---
I didn't get much of a response to my [call for testing thread on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/Call.20for.20testing.3A.20New.20test.20executor.20for.20compiletest/with/512452105), and the reports I did get (along with my own usage) indicate that there aren't any problems. So I think it's reasonable to move forward with making this the default, in the hopes of being able to remove the libtest dependency relatively soon.
When the libtest dependency is removed, it should be reasonable to build compiletest against pre-built stage0 std by default, even after the stage0 redesign. (Though we should probably have at least one CI job using in-tree stage1 std instead, to guard against the possibility of the `#![feature(internal_output_capture)]` API actually changing.)
|
|
|
|
To preserve CFI directives in assembly tests.
|
|
|
|
It is no longer needed after a recent refactoring.
|
|
'f16', 'f32', 'f64', and 'f128' into 'const fn' items;
|
|
|
|
|
|
Refactor git change detection in bootstrap
While working on https://github.com/rust-lang/rust/pull/138395, I finally found the courage to delve into the insides of git path change detection in bootstrap, which is used (amongst other things) to detect if we should rebuilt od download `[llvm|rustc|gcc]`. I found it a bit hard to understand, and given that this code was historically quite fragile, I thought that it would be better to rebuild it from scratch.
The previous approach had a bunch of limitations:
- It separated the computation of "are there local changes?" and "what upstream SHA should we use?" even though these two things are intertwined.
- It used hacks to work around what happens on CI.
- It had special cases for CI scattered throughout the codebase, rather than centralized in one place.
- It wasn't documented enough and didn't have tests for the git behavior.
The current approach should hopefully resolve all of that. I implemented a single entrypoint called `check_path_modifications` (naming bikeshed pending, half of the time I spend on this PR was thinking about names, as it's quite tricky here..) that explicitly receives a mode of operation (in CI or outside CI), and accordingly figures out that upstream SHA that we should use for downloading artifacts and it also figures out if there are any local changes. Users of this function can then use this unified output to implement `download-ci-X` and other functionality. Notably, this change detection no longer uses `git merge-base`, which makes it easier to use and doesn't require setting up remotes.
I also added a bunch of integration tests that literally spawn a git repository on disk and then check that the function can deal with various situations (PR CI, auto/try CI, local builds).
After I built this inner layer, I used it for downloading GCC, LLVM and rustc. The latter two (and especially rustc) were using the `last_modified_commit` function before, but in all cases but one this function was actually only used to check if there are any local changes, which was IMO confusing. The LLVM handling would deserve a bit of refactoring, but that's a larger change that can be done as a follow-up.
I hope that the implementation is now clear and easy to understand, so that in combination with the tests we can have more confidence that it does what we want. I tried to include a lot of documentation in the code, so I won't be repeating the actual implementation details here, if there are any questions, I'll add the answers to the documentation too :)
The new approach explicitly supports three scenarios:
- Running on PR CI, where we have one upstream bors parent commit and one PR merge commit made by GitHub.
- Running on try/auto CI, where we have one upstream bors parent commit and one PR merge commit made by bors.
- Running locally, where we assume that we have at least one upstream bors parent commit in our git history.
I removed the handling of upstreams on CI, as I think that it shouldn't be needed and I considered it to be a hack. However, it's possible that there are other use-cases that I haven't considered, so I want to ask around if people have other situations than the three use-cases described above. If there are other such use-cases, I would like to include them in the new centralized implementation and add them to the git test suite, rather than going back to the old ways :)
In particular, the code before relied on `git merge-base`, but I don't see why we can't just lookup the most recent bors commit and assume that is a merge commit that is also upstream? I might be running into Chesterton's Fence here :)
CC `@pietroalbini` To make sure that this won't break downstream users of Rust's CI.
Best reviewed commit by commit.
Companion PRs:
- For testing beta: https://github.com/rust-lang/rust/pull/138597
r? `@onur-ozkan`
Fixes: https://github.com/rust-lang/rust/issues/101907
try-job: x86_64-gnu-aux
try-job: aarch64-gnu
try-job: dist-x86_64-apple
|
|
Currently the new executor can be explicitly disabled by passing the `-N` flag
to compiletest (e.g. `./x test ui -- -N`), but eventually that flag will be
removed, alongside the removal of the libtest dependency.
|
