| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #128643 (Refactor `powerpc64` call ABI handling)
- #128655 (std: refactor UNIX random data generation)
- #128745 (Remove unused lifetime parameter from spawn_unchecked)
- #128841 (bootstrap: don't use rustflags for `--rustc-args`)
- #128983 (Slightly refactor `TargetSelection` in bootstrap)
- #129026 (CFI: Move CFI ui tests to cfi directory)
- #129040 (Fix blessing of rmake tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix blessing of rmake tests
Fixes #129038.
When running in `--bless` mode, we now set the value of `RUSTC_BLESS_TEST` to the current test's source directory. This allows the diff helper in `run_make_support` to find the original snapshot file in the source directory and bless that, instead of unhelpfully blessing the temporary copy in `build`.
r? `@jieyouxu`
|
|
rcvalle:rust-cfi-move-cfi-ui-tests-to-cfi-directory, r=compiler-errors
CFI: Move CFI ui tests to cfi directory
Move the CFI ui tests to the cfi directory and removes the cfi prefix from tests file names similarly to how the cfi codegen tests are organized.
|
|
Slightly refactor `TargetSelection` in bootstrap
Mostly a drive-by refactoring of `TargetSelection` to reduce some manual "windows-gnu" detection and also accesses to the `triple` field.
r? `@onur-ozkan`
|
|
bootstrap: don't use rustflags for `--rustc-args`
r? `@onur-ozkan`
This is going to require a bit of context.
https://github.com/rust-lang/rust/pull/47558 has added `--rustc-args` to `./x test` to allow passing flags when building `compiletest` tests. It was made specifically because using `RUSTFLAGS` would rebuild the compiler/stdlib, which would in turn require the flag you want to build tests with to successfully bootstrap.
#113178 made the request that it also works for other tests and doctests. This is not trivial to support across the board for `library`/`compiler` unit-tests/doctests and across stages. This issue was closed in #113948 by using `RUSTFLAGS`, seemingly incorrectly since https://github.com/rust-lang/rust/pull/123489 fixed that part to make it work.
Unfortunately #123489/#113948 have regressed the goals of `--rustc-args`:
- now we can't use rustc args that don't bootstrap, to run the UI tests: we can't test incomplete features. The new trait solver doesn't bootstrap, in-progress borrowck/polonius changes don't bootstrap, some other features are similarly incomplete, etc.
- using the flag now rebuilds everything from scratch: stage0 stdlib, stage1 compiler, stage1 stdlib. You don't need to re-do all this to compile UI tests, you only need the latter to run stdlib tests with a new flag, etc. This happens for contributors, but also on CI today. (Not to mention that in doing that it will rebuild things with flags that are not meant to be used, e.g. stdlib cfgs that don't exist in the compiler; or you could also imagine that this silently enables flags that were not meant to be enabled in this way).
Since then, https://github.com/rust-lang/rust/pull/125011/commits/bd71c71ea04b4a4f954e579c2a6d44113274846a has started using it to test a stdlib feature, relying on the fact that it now rebuilds everything. So #125011 also regressed CI times more than necessary because it rebuilds everything instead of just stage 1 stdlib.
It's not easy for me to know how to properly fix #113178 in bootstrap, but #113948/#123489 are not it since they regress the initial intent. I'd think bootstrap would have to know from the list of test targets that are passed that the `library` or `compiler` paths that are passed could require rebuilding these crates with different rustflags, probably also depending on stages. Therefore I would not be able to fix it, and will just try in this PR to unregress the situation to unblock the initial use-case.
It seems miri now also uses `./x miri --rustc-args` in this incorrect meaning to rebuild the `library` paths they support to run with the new args. I've not made any bootstrap changes related to `./x miri` in this PR, so `--rustc-args` wouldn't work there anymore. I'd assume this would need to use rustflags again but I don't know how to make that work properly in bootstrap, hence opening as draft, so you can tell me how to do that. I assume we don't want to break their use-case again now that it exists, even though there are ways to use `./x test` to do exactly that.
`RUSTFLAGS_NOT_BOOTSTRAP=flag ./x test library/std` is a way to run unit tests with a new flag without rebuilding everything, while with #123489 there is no way anymore to run tests with a flag that doesn't bootstrap.
---
edit: after review, this PR:
- renames `./x test --rustc-args` to `./x test --compiletest-rustc-args` as it only applies there, and cannot use rustflags for this purpose.
- fixes the regression that using these args rebuilt everything from scratch
- speeds up some CI jobs via the above point
- removes `./x miri --rustc-args` as only library tests are supported, needs to rebuild libstd, and `./x miri --compiletest-rustc-args` wouldn't work since compiletests are not supported.
|
|
Remove unused lifetime parameter from spawn_unchecked
Amanieu caught this when reviewing the stabilization proposal in https://github.com/rust-lang/rust/issues/55132.
The `'a` lifetime here is useless. The signature is asking the caller of `spawn_unchecked` to "give me any lifetime that is shorter than your F's and T's lifetime", which they can always to with no effect, because arbitrarily short lifetimes exist.
|
|
std: refactor UNIX random data generation
This PR makes a number of changes to the UNIX randomness implementation:
* Use `io::Error` for centralized error handling
* Move the file-fallback logic out of the `getrandom`-specific module
* Stop redefining the syscalls on macOS and DragonFly, they have appeared in `libc`
* Add a `OnceLock` to cache the random device file descriptor
|
|
Refactor `powerpc64` call ABI handling
As the [specification](https://openpowerfoundation.org/specifications/64bitelfabi/) for the ELFv2 ABI states that returned aggregates are returned like arguments as long as they are at most two doublewords, I've merged the `classify_arg` and `classify_ret` functions to reduce code duplication. The only functional change is to fix #128579: the `classify_ret` function was incorrectly handling aggregates where `bits > 64 && bits < 128`. I've used the aggregate handling implementation from `classify_arg` which doesn't have this issue.
`@awilfox` could you test this on `powerpc64-unknown-linux-musl`? I'm only able to cross-test on `powerpc64-unknown-linux-gnu` and `powerpc64le-unknown-linux-gnu` locally at the moment, and as a tier 3 target `powerpc64-unknown-linux-musl` has zero CI coverage.
Fixes: #128579
|
|
std::fs: get_mode implementation for all unix
|
|
|
|
|
|
|
|
|
|
miri: make vtable addresses not globally unique
Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair.
To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.)
r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3737
|
|
Port rustc perf cmp command
I've integrated bench_cmp and bench_local into the bootstrap.
r? `@Kobzol`
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #128712 (Normalize struct tail properly for `dyn` ptr-to-ptr casting in new solver)
- #128912 (Store `do_not_recommend`-ness in impl header)
- #129000 (bootstrap: clear miri ui-test deps when miri sysroot gets rebuilt)
- #129013 (Remove unused script from run-make tests)
- #129017 (Replace `std::fmt:FormatterFn` with `std::fmt::from_fn`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Moves the CFI ui tests to the cfi directory and removes the cfi prefix
from tests file names similarly to how the cfi codegen tests are
organized.
|
|
Replace `std::fmt:FormatterFn` with `std::fmt::from_fn`
Modelled after the suggestion made in [this](https://github.com/rust-lang/rust/issues/117729#issuecomment-1837628559) comment, this should bring this functionality in line with the existing `array::from_fn` & `iter::from_fn`
|
|
Remove unused script from run-make tests
Its last usage was removed in https://github.com/rust-lang/rust/pull/128636.
Tracking issue: https://github.com/rust-lang/rust/issues/121876
r? jieyouxu
|
|
bootstrap: clear miri ui-test deps when miri sysroot gets rebuilt
Second attempt after https://github.com/rust-lang/rust/pull/128683: seems like it's not the compiler changing that we care about, but the sysroot changing.
I did some local testing with sysroot rebuilds and it works fine for at least those cases I checked.
r? ``@onur-ozkan``
|
|
Store `do_not_recommend`-ness in impl header
Alternative to #128674
It's less flexible, but also less invasive. Hopefully it's also performant. I'd recommend we think separately about the design for how to gate arbitrary diagnostic attributes moving forward.
|
|
Normalize struct tail properly for `dyn` ptr-to-ptr casting in new solver
Realized that the new solver didn't handle ptr-to-ptr casting correctly.
r? lcnr
Built on #128694
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #128149 (nontemporal_store: make sure that the intrinsic is truly just a hint)
- #128394 (Unify run button display with "copy code" button and with mdbook buttons)
- #128537 (const vector passed through to codegen)
- #128632 (std: do not overwrite style in `get_backtrace_style`)
- #128878 (Slightly refactor `Flags` in bootstrap)
- #128886 (Get rid of some `#[allow(rustc::untranslatable_diagnostic)]`)
- #128929 (Fix codegen-units tests that were disabled 8 years ago)
- #128937 (Fix warnings in rmake tests on `x86_64-unknown-linux-gnu`)
- #128978 (Use `assert_matches` around the compiler more)
- #128994 (Fix bug in `Parser::look_ahead`.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
to pick up changes to `./x miri` and `./x test` commands
|
|
|
|
|
|
|
|
|
|
|
|
r=compiler-errors
Fix bug in `Parser::look_ahead`.
The special case was failing to handle invisible delimiters on one path.
Fixes (but doesn't close until beta backported) #128895.
r? `@davidtwco`
|
|
Use `assert_matches` around the compiler more
It's a useful assertion, especially since it actually prints out the LHS.
|
|
Fix warnings in rmake tests on `x86_64-unknown-linux-gnu`
r? `@jieyouxu`
This PR fixes some warnings I saw in rmake tests. I didn't deny more warnings in this PR until `@jieyouxu` gives their opinion, but maybe we should actually deny all warnings in `rmake.rs` files?
I've also only looked at non-ignored tests on `x86_64-unknown-linux-gnu`, and denying warnings would require a try build for all targets 😓.
|
|
Fix codegen-units tests that were disabled 8 years ago
I don't know if any of these tests still have value. They were disabled by https://github.com/rust-lang/rust/pull/33890, and we've survived without them for a while. But considering how small this test suite is, maybe it's worth having them.
I also had to add some normalization to the codegen-units tests output. I think the fact that I had to add some underscores how poor our test coverage is.
|
|
Get rid of some `#[allow(rustc::untranslatable_diagnostic)]`
`@rustbot` label +A-translation
cc https://github.com/rust-lang/rust/issues/100717
|
|
Slightly refactor `Flags` in bootstrap
The next step for https://github.com/rust-lang/rust/issues/126819 is to track commands executed inside `Config::parse`. This is quite challenging, because (tracked) command execution needs to access some state that is stored inside `Config`, which creates a sort of a chicken-and-egg problem.
I would like to first untangle `Config::parse` a little bit, which is what this PR starts with.
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
|
|
std: do not overwrite style in `get_backtrace_style`
If another thread calls `set_backtrace_style` while a `get_backtrace_style` is reading the environment variables, `get_backtrace_style` will overwrite the value. Use an atomic CAS to avoid this.
|
