| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Region constraint nits
Couple miscellaneous region constraints that have a bit to do with rust-lang/rust#143545 but stand on their own.
|
|
[COMPILETEST-UNTANGLE 6/N] Use `TestSuite` enum instead of stringly-typed test suites
This is part of a patch series to untangle `compiletest` to hopefully nudge it towards being more maintainable.
This PR should contain no functional changes.
|
|
warn on align on fields to avoid breaking changes
r? `@workingjubilee`
|
|
r=jdonszelmann
Port `#[omit_gdb_pretty_printer_section]` to the new attribute parsing
Ports `#[omit_gdb_pretty_printer_section]` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163
r? ```@jdonszelmann```
|
|
Rename `stable_mir` and `rustc_smir`
This PR only renames the two crate names.
There is no doubt that we want to rename `stable_mir` to `rustc_public`, while it hasn't been discussed yet that what the new name for `rustc_smir` should be.
This PR proposes a new name for `rustc_smir`, that is `rustc_public_shim`, since `rustc_smir` now is mostly a proxy to do calls to rustc queries and the public API of rustc that is invoked by the `rustc_public` crate.
However, I don't think that name is good enough. I hope there would be a way better name.
r? `@oli-obk`
|
|
Updates to random number generation APIs
Updates based on discussions about random number generation.
- Add comment on `RandomSource::fill_bytes` about multiple calls, to allow
efficient implementations for random sources that generate a word at a time.
- Drop the `Random` trait in favor of `Distribution<T>`, which will let people
make calls like random(1..=6), and which allows for future expansion to
non-uniform distributions, as well as floating-point. (For now, this is only
implemented for `RangeFull`, to get the interface in place. Subsequent PRs
will implement it for other range types.)
|
|
Don't call WSACleanup on process exit
This isn't necessary as cleanup will happen when the process exits regardless.
fixes rust-lang/rust#141799
|
|
|
|
|
|
This is needed to split the lint crate.
changelog: none
|
|
Previously expect_fun_call would too eagerly convert cases like
`foo.expect(if | block | match)` into `foo.unwrap_or_else`.
Additionally, it would also add to_string() even though the argument is
being passed into format!() which can accept a &str. I also discovered
some other cases where this lint would either produce invalid results,
or be triggered unnecessarily:
- Clippy would suggest changing expect to unwrap_or_else even if the
expression inside expect contains a return statement
- opt.expect(const_fn()) no longer triggers the lint
- The lint would always add braces to the closure body, even if the body
of expect is a single expression
- opt.expect({"literal"}) used to get turned into
```opt.unwrap_or_else(|| panic!("{}", {"literal"}.to_string()))```
Fixes rust-lang/rust-clippy#15056
changelog: [`expect_fun_call`]: fix expect_fun_call producing invalid
suggestions
|
|
|
|
|
|
|
|
|
|
Key changes include:
- Removal of the word "syntax" from the lint message. More accurately,
it could have been something like "syntax group" or "syntax
category", but avoiding it completely is easier.
- The primary lint message now reflects exactly which mismatch is
occurring, instead of trying to be general. A new `help` line is
general across the mismatch kinds.
- Suggestions have been reduced to be more minimal, no longer also
changing non-idiomatic but unrelated aspects.
- Suggestion text no longer mentions changes when those changes don't
occur in that specific suggestion.
|
|
Key changes include:
- Removal of the word "syntax" from the lint message. More accurately,
it could have been something like "syntax group" or "syntax
category", but avoiding it completely is easier.
- The primary lint message now reflects exactly which mismatch is
occurring, instead of trying to be general. A new `help` line is
general across the mismatch kinds.
- Suggestions have been reduced to be more minimal, no longer also
changing non-idiomatic but unrelated aspects.
- Suggestion text no longer mentions changes when those changes don't
occur in that specific suggestion.
|
|
changelog: fix false positive: [`ptr_arg`] no longer triggers with
underscore binding to `&mut` argument
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#143217 (Port #[link_ordinal] to the new attribute parsing infrastructure)
- rust-lang/rust#143681 (bootstrap/miri: avoid rebuilds for test builds)
- rust-lang/rust#143724 (Tidy cleanup)
- rust-lang/rust#143733 (Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand)
- rust-lang/rust#143850 (Compiletest: Simplify {Html,Json}DocCk directive handling)
- rust-lang/rust#143875 (update issue number for `const_trait_impl`)
- rust-lang/rust#143881 (Use zero for initialized Once state)
- rust-lang/rust#143887 (Run bootstrap tests sooner in the `x test` pipeline)
- rust-lang/rust#143917 (Change "allocated object" to "allocation".)
- rust-lang/rust#143918 (Tier check cleanup)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Tier check cleanup
clippy cleanup + edition 2024
|
|
r=oli-obk
Change "allocated object" to "allocation".
These seem like they were missed in <https://github.com/rust-lang/rust/pull/141224>
|
|
Run bootstrap tests sooner in the `x test` pipeline
With the recently added bootstrap snapshot tests, and in general with our plans to test more things in bootstrap, I feel like the original comment isn't accurate anymore. Recently, on several occasions I had to wait for 40+ minutes of CI just to find out that the bootstrap snapshot tests have failed. I think we should run bootstrap tests towards the beginning instead now.
r? ```@jieyouxu```
|
|
Use zero for initialized Once state
By re-labeling which integer represents which internal state for `Once` we can ensure that the initialized state is the all-zero state. This is beneficial because some CPU architectures (such as Arm) have specialized instructions to specifically branch on non-zero, and checking for the initialized state is by far the most important operation.
As an example, take this:
```rust
use std::sync::atomic::{AtomicU32, Ordering};
const INIT: u32 = 3;
#[inline(never)]
#[cold]
pub fn slow(state: &AtomicU32) {
state.store(INIT, Ordering::Release);
}
pub fn ensure_init(state: &AtomicU32) {
if state.load(Ordering::Acquire) != INIT {
slow(state)
}
}
```
If `INIT` is 3 (as is currently the state for `Once`), we see the following assembly on `aarch64-apple-darwin`:
```asm
example::ensure_init::h332061368366e313:
ldapr w8, [x0]
cmp w8, #3
b.ne LBB1_2
ret
LBB1_2:
b example::slow::ha042bd6a4f33724e
```
By changing the `INIT` state to zero we get the following:
```asm
example::ensure_init::h332061368366e313:
ldapr w8, [x0]
cbnz w8, LBB1_2
ret
LBB1_2:
b example::slow::ha042bd6a4f33724e
```
So this PR saves 1 instruction every time a `LazyLock` gets accessed on platforms such as these.
|
|
update issue number for `const_trait_impl`
r? project-const-traits
cc rust-lang/rust#67792 rust-lang/rust#143874
|
|
Compiletest: Simplify {Html,Json}DocCk directive handling
So much more maintainable and extensible.
r? ````@jieyouxu```` as discussed
|
|
Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand
This is a followup to rust-lang/rust#142379 to make the bootstrap option `tool.TOOL_NAME.features` work on any subcommand instead of just build (so also run/test/...). I also made the `TOOL_NAME` comparisons look at the tool path instead of the tool name to determine to which tool a `TOOL_NAME` refers to, so you can specify tools by path like in other places of the bootstrap (e.g. `tool."tools/miri".features`).
|
|
Tidy cleanup
|
|
bootstrap/miri: avoid rebuilds for test builds
When building Miri in its own repo, we always build with `--all-targets`:
https://github.com/rust-lang/rust/blob/a00961269107703772c4e8f071f0accbe0f1a7e5/src/tools/miri/miri-script/src/util.rs#L167-L174
This saves a bunch of time since some of Miri's dependencies get more features enabled by some of Miri's dev-dependencies, and they all get built twice otherwise if you do `cargo build && cargo test` (which is typically what you end up doing inside `./miri test` and also inside `./x test miri`).
This applies the same approach to bootstrap, drastically reducing the edit-compile cycle for Miri work here. :)
|
|
Port #[link_ordinal] to the new attribute parsing infrastructure
Ports link_ordinal to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
|
|
Update README.md
|
|
Update LLVM to 20.1.8
I made a new branch with patches that aren't yet in LLVM 20.1.8.
|
|
|
|
Fix several issues with `manual_is_multiple_of`
- `&a % &b == 0` compiles, but requires dereferencing `b` when replacing
with `a.is_multiple_of(b)`.
- In `a % b == 0`, if type of `a` is not certain, `a.is_multiple_of(b)`
might not be typable.
- In `a % b == 0`, `a` and `b` must be unsigned integers, not any
arbitrary types implementing `Rem` and outputing an integer.
Those fixes have required increasing the precision of type certainty
determination in the two first patches.
Fixes rust-lang/rust-clippy#15203
Fixes rust-lang/rust-clippy#15204
changelog: [`manual_is_multiple_of`]: fix various false positive
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These seem like they were missed in <https://github.com/rust-lang/rust/pull/141224>
|
|
Closes rust-lang/rust-clippy#15227
changelog: [`manual_assert`] fix wrong suggestions for macros
|
|
Fixes: rust-lang/rust-clippy#15247
changelog: Fix the false negative of [`expect_used`] when metting
`Option::ok().expect`.
|
|
|
|
|
