| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Rustup
|
|
|
|
|
|
path: add more Windows tests
|
|
|
|
Ergonomic ref counting: optimize away clones when possible
This PR build on top of https://github.com/rust-lang/rust/pull/134797. It optimizes codegen of ergonomic ref-counting when the type being `use`d is only known to be copy after monomorphization. We avoid codening a clone and generate bitwise copy instead.
RFC: https://github.com/rust-lang/rfcs/pull/3680
Tracking issue: https://github.com/rust-lang/rust/issues/132290
Project goal: https://github.com/rust-lang/rust-project-goals/issues/107
r? `@nikomatsakis`
This PR could better sit on top of https://github.com/rust-lang/rust/pull/131650 but as it did not land yet I've decided to just do minimal changes. It may be the case that doing what I'm doing regress the performance and we may need to go the full route of https://github.com/rust-lang/rust/pull/131650.
cc `@saethlin` in this regard.
|
|
Implement FreeBSD syscall _umtx_op for futex support
|
|
Futex support
|
|
|
|
Rigidly project missing item due to guaranteed impossible sized predicate
This is a somewhat involved change, but it amounts to treating missing impl items due to guaranteed impossible where clauses (dyn/str/slice sized, cc #135480) as *rigid projections* rather than projecting to an error term, since that was preventing either reporting a proper error (in an empty param env) *or* successfully type checking the code (in the presence of trivially false where clauses).
Fixes https://github.com/rust-lang/rust/issues/138970
r? `@lcnr` `@oli-obk`
|
|
Bump boostrap compiler to new beta
try-job: `*msvc*`
|
|
Rollup of 10 pull requests
Successful merges:
- #138470 (Test interaction between RFC 2229 migration and use closures)
- #138628 (Add more ergonomic clone tests)
- #139164 (std: improve documentation for get_mut() methods regarding forgotten guards)
- #139488 (Add missing regression GUI test)
- #139489 (compiletest: Add directive `dont-require-annotations`)
- #139513 (Report higher-ranked trait error when higher-ranked projection goal fails in new solver)
- #139521 (triagebot: roll compiler reviewers for rustc/unstable book)
- #139532 (Update `u8`-to-and-from-`i8` suggestions.)
- #139551 (report call site of inlined scopes for large assignment lints)
- #139575 (Remove redundant words)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
error reporting
|
|
|
|
triagebot: enable `[canonicalize-issue-links]` and `[no-mentions]`
|
|
|
|
Remove redundant words
Remove redundant words
|
|
report call site of inlined scopes for large assignment lints
Addressed issue: #121672
Tracking issue: #83518
r? `@oli-obk`
I tried to follow your comment about what to do [here](https://github.com/rust-lang/rust/issues/121672#issuecomment-1972783675). However, I'm totally unfamiliar with the code so far (this is my first contribution touching compiler code), so I apologize in advance if I did something stupid :sweat_smile:
In particular, I'm not sure I use the _correct_ source scope to look for inline data, as there is a whole `IndexVec` of them. My changes definitely did something, as can be seen by the added ui test. However, the result is not as anticipated in the issue:
```
LL | let cell = std::cell::UnsafeCell::new(data);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ value moved from here
```
instead of
```
LL | let cell = std::cell::UnsafeCell::new(data);
| ^^^^ value moved from here
```
raising my suspicion that maybe I got the wrong source scope.
|
|
Update `u8`-to-and-from-`i8` suggestions.
`u8::cast_signed` and `i8::cast_unsigned` have been stabilised, but `i8::from_ne_bytes` et al. still suggest using `as i8` or `as u8`.
|
|
r=GuillaumeGomez,ehuss
triagebot: roll compiler reviewers for rustc/unstable book
r? compiler
|
|
Report higher-ranked trait error when higher-ranked projection goal fails in new solver
~~See HACK comment inline. Not actually sure if it should be marked as a *HACK*, b/c~~ it's kinda a legitimate case we want to care about unless we're going to make the proof tree visitor *smarter* about the leak check than the actual trait solver itself.
Encountered this while battling with `NiceRegionError`s in the old solver b/c I wondered what this code ended up giving us in the *new* solver as a comparison:
```rust
trait Foo {}
impl<T: FnOnce(&())> Foo for T {}
fn baz<T: Foo>() {}
fn main() {
baz::<fn(&'static ())>();
}
```
On master it's pretty bad:
```
error[E0271]: type mismatch resolving `<fn(&()) as FnOnce<(&(),)>>::Output == ()`
--> <source>:8:11
|
8 | baz::<fn(&'static ())>();
| ^^^^^^^^^^^^^^^ types differ
|
note: required for `fn(&'static ())` to implement `Foo`
--> <source>:3:22
|
3 | impl<T: FnOnce(&())> Foo for T {}
| ----------- ^^^ ^
| |
| unsatisfied trait bound introduced here
```
After this PR it's much better:
```
error[E0277]: the trait bound `fn(&'static ()): Foo` is not satisfied
--> /home/mgx/test.rs:8:11
|
8 | baz::<fn(&'static ())>();
| ^^^^^^^^^^^^^^^ the trait `for<'a> FnOnce(&'a ())` is not implemented for `fn(&'static ())`
|
= note: expected a closure with arguments `(&'static (),)`
found a closure with arguments `(&(),)`
note: required for `fn(&'static ())` to implement `Foo`
--> /home/mgx/test.rs:3:22
|
3 | impl<T: FnOnce(&())> Foo for T {}
| ----------- ^^^ ^
| |
| unsatisfied trait bound introduced here
note: required by a bound in `baz`
--> /home/mgx/test.rs:5:11
|
5 | fn baz<T: Foo>() {}
| ^^^ required by this bound in `baz`
```
r? lcnr
|
|
compiletest: Add directive `dont-require-annotations`
for making matching on specific diagnostic kinds non-exhaustive.
E.g. `//@ dont-require-annotations:ERROR`, like in the examples in this PR.
cc https://github.com/rust-lang/rust/pull/139427#issuecomment-2782827583
Closes #132647 FYI `@BoxyUwU` since you've wanted this.
r? `@jieyouxu`
|
|
Add missing regression GUI test
Add missing GUI test for #139282 (and also fixes the invalid CSS).
cc `@lolbinarycat`
r? `@notriddle`
|
|
std: improve documentation for get_mut() methods regarding forgotten guards
Fixes #139034
This PR improves the documentation for `get_mut()` methods in `Mutex`, `RefCell`, and `RwLock` to clarify their behavior when lock guards are forgotten (e.g., via std::mem::forget).
The current documentation for these methods states that a mutable borrow "statically guarantees no locks exist", which is not entirely accurate. While a mutable borrow prevents new locks from being created, it does not clear or detect previously abandoned locks through `forget()`. This can lead to counterintuitive behavior:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=e68cefec12dcd435daf2237c16824ed3
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=81263ad652c752afd63c903113d3082c
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=311baa4edb3abf82a25c8d7bf21a4a52
r? libs
|
|
r=nikomatsakis
Add more ergonomic clone tests
I've added some extra tests.
r? `@nikomatsakis`
|
|
r=nikomatsakis
Test interaction between RFC 2229 migration and use closures
r? `@nikomatsakis`
Fixes #138101
|
|
r=tgross35
speed up `String::push` and `String::insert`
Addresses the concerns described in #116235.
The performance gain comes mainly from avoiding temporary buffers.
Complex pattern matching in `encode_utf8` (introduced in #67569) has been simplified to a comparison and an exhaustive `match` in the `encode_utf8_raw_unchecked` helper function. It takes a slice of `MaybeUninit<u8>` because otherwise we'd have to construct a normal slice to uninitialized data, which is not desirable, I guess.
Several functions still have that [unneeded zeroing](https://rust.godbolt.org/z/5oKfMPo7j), but a single instruction is not that important, I guess.
`@rustbot` label T-libs C-optimization A-str
|
|
new solver
|
|
Rollup of 7 pull requests
Successful merges:
- #138869 (Try not to use verbatim paths in `Command::current_dir`)
- #138993 (Make `cfg_match!` a semitransparent macro)
- #139099 (Promise `array::from_fn` is generated in order of increasing indices)
- #139364 (Make the compiler suggest actual paths instead of visible paths if the visible paths are through any doc hidden path.)
- #139468 (Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`)
- #139481 (Add job summary links to post-merge report)
- #139573 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Miri subtree update
r? `@ghost`
|
|
Add job summary links to post-merge report
This should make it much easier to investigate the individual job test/duration changes.
The GitHub API handling is a bit crude, but I didn't want to include octocrab, because it more than doubles the current number of dependencies of `citool`...
Can be tested with:
```bash
$ cargo run --manifest-path src/ci/citool/Cargo.toml post-merge-report bad13a970a136389187dd1cf2f2fc737a8bea5fc 1e008dd5d83e782ad37fc9cf6824733f824cc8cd
```
r? ```@marcoieni```
|
|
Don't call `Span::with_parent` on the good path in `has_stashed_diagnostic`
More unnecessary incurred span tracking avoided by not calling `span.with_parent(None)`. This is useless on its own but makes it much easier to fix other "span tracking on the good path" issues in the future.
r? oli-obk
|
|
Make the compiler suggest actual paths instead of visible paths if the visible paths are through any doc hidden path.
close #127011
Currently, when emitting a diagnostic about a valid trait, the compiler suggestes using visible paths of the trait even if they are through a doc hidden path. This PR updates the compiler to suggest actual paths in these cases.
|
|
Promise `array::from_fn` is generated in order of increasing indices
Fixes #139061
I agree this needs to be documented because of the `FnMut`, either with a guarantee or to explicitly disclaim one.
I'm pretty sure this will be non-controversial (like the other "well sure you *could* do it in a different order, but why?" things were), but I couldn't find any previous libs-api decision on it so it's seemingly a new promise that will need FCP.
Basically, yes, it would be plausible to fill in the reverse order, but there's no obvious way we could ever know that that might even be a good idea, so forward seems like an easy thing to promise. We could always add a `from_fn_rev` or something later if there's ever a strong enough need, but it seems unlikely.
Let's just do the obvious thing so it matches what `[gen(0), gen(1), …, gen(N-1)]` does.
|
|
Make `cfg_match!` a semitransparent macro
IIUC this is preferred when (potentially) stabilizing `macro` items, to avoid potentially utilizing def-site hygiene instead of mixed-site.
Tracking issue: #115585
|
|
Try not to use verbatim paths in `Command::current_dir`
If possible, we should try not to use verbatim paths in `Command::current_dir`. It might work but it might also break code in the subprocess that assume the current directory isn't verbatim (including Windows APIs). cc ``@ehuss``
Side note: we now have a lot of ad-hoc fixes like this spread about the place. It'd be good to make a proper `WindowsPath` type that handles all this in one place. But that's a bigger job for another PR.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Improve performance of `String` methods by avoiding unnecessary memcpy
for the character bytes, with added codegen check to ensure compliance.
|
