| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Complete span AST lowering.
r? `@ghost`
|
|
When a bare CR is present in a four slashes comment, keep triggering the
lint but do not issue a fix suggestion as bare CRs are not supported in
doc comments. An extra note is added to the diagnostic to warn the user
about it.
I have put the test in a separate file to make it clear that the bare CR
is not a formatting error.
Fixes rust-lang/rust-clippy#15174
changelog: [`four_forward_slashes`]: warn about bare CR in comment, and
do not propose invalid autofix
|
|
|
|
Closes rust-lang/rust-clippy#15102
changelog: [`search_is_some`] fix wrong suggestions inside macro
|
|
This updates the wasi-sdk used in CI to build release binaries and run
CI with. No major motivation beyond keeping things up-to-date and
following the development of wasi-sdk.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#144560 (coverage: Treat `#[automatically_derived]` as `#[coverage(off)]`)
- rust-lang/rust#144566 (Simplify `align_of_val::<[T]>(…)` → `align_of::<T>()`)
- rust-lang/rust#144587 (expand: Micro-optimize prelude injection)
- rust-lang/rust#144589 (Account for `.yield` in illegal postfix operator message)
- rust-lang/rust#144615 (Make resolve_fn_signature responsible for its own rib.)
- rust-lang/rust#144634 (Fix typo in `DropGuard` doc)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix typo in `DropGuard` doc
Follows-up rust-lang/rust#144236 (I happened to see the typo yesterday but didn’t think it should delay the PR’s merge so I kept quiet, sorryyyyy).
|
|
Make resolve_fn_signature responsible for its own rib.
Small simplification in late resolver rib bookkeeping.
r? `@petrochenkov`
|
|
r=petrochenkov
Account for `.yield` in illegal postfix operator message
Fixes rust-lang/rust#144527
|
|
expand: Micro-optimize prelude injection
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
|
|
Simplify `align_of_val::<[T]>(…)` → `align_of::<T>()`
I spotted this while working on the inliner (rust-lang/rust#144561). In particular, if [`Layout::for_value`](https://doc.rust-lang.org/std/alloc/struct.Layout.html#method.for_value) inlines, then it can be pretty easy to end up with an `align_of_val::<[T]>` today (demo: <https://rust.godbolt.org/z/Tesnscj4a>) where we can save at least a block, if not more, by using the version that's an rvalue and not a call.
|
|
coverage: Treat `#[automatically_derived]` as `#[coverage(off)]`
One of the contributing factors behind https://github.com/rust-lang/rust/issues/141577#issuecomment-3120667286 was the presence of derive-macro-generated code containing nested closures.
Coverage instrumentation already has a heuristic for skipping code marked with `#[automatically_derived]` (rust-lang/rust#120185), because derived code is usually not worth instrumenting, and also has a tendency to trigger vexing edge-case bugs in coverage instrumentation or coverage codegen.
However, the existing heuristic only applied to the associated items directly within an auto-derived impl block, and had no effect on closures or nested items within those associated items.
This PR therefore extends the search for `#[coverage(..)]` attributes to also treat `#[automatically_derived]` as an implied `#[coverage(off)]` for the purposes of coverage instrumentation.
---
This change doesn’t rule out an entire category of bugs, because it only affects code that actually uses the auto-derived attribute. But it should reduce the overall chance of edge-case macro span bugs being observed in the wild.
|
|
|
|
Benchmark results with LLVM 21 on LA664:
```
OLD:
test bench_is_contained_in ... bench: 43.63 ns/iter (+/- 0.04)
NEW:
test bench_is_contained_in ... bench: 12.81 ns/iter (+/- 0.01)
```
|
|
|
|
On LLVM 21 additional %esp adjustments are generated. Don't use
NEXT to allow these.
|
|
fix: When displaying a projection into a type parameter that has bounds as `impl Trait`, collect only the bounds of this projection
|
|
Trait`, collect only the bounds of this projection
It used to collect the bounds of them all.
|
|
|
|
Use GH app for authenticating pull PRs
|
|
|
|
Improve settings tree title and descriptions
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
Rollup of 13 pull requests
Successful merges:
- rust-lang/rust#144022 (Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`)
- rust-lang/rust#144167 (Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.)
- rust-lang/rust#144407 (fix(debuginfo): disable overflow check for recursive non-enum types)
- rust-lang/rust#144451 (fix: Reject upvar scrutinees for `loop_match`)
- rust-lang/rust#144482 (Add explicit download methods to download module in bootstrap)
- rust-lang/rust#144500 (thread name in stack overflow message)
- rust-lang/rust#144511 (tidy: increase performance of auto extra checks feature)
- rust-lang/rust#144599 (bootstrap: enable tidy auto extra checks on tools profile)
- rust-lang/rust#144600 (Ensure external paths passed via flags end up in rustdoc depinfo)
- rust-lang/rust#144609 (feat: Right align line numbers)
- rust-lang/rust#144623 (miri subtree update)
- rust-lang/rust#144626 (cc dependencies: clarify comment)
- rust-lang/rust#144627 (Add a test case for the issue rust-lang/rust#129882)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add a test case for the issue #129882
It ensures that using the `generic_const_exprs` feature in a library crate without enabling it in a dependent crate does not lead to an ICE.
Closes https://github.com/rust-lang/rust/issues/129882.
|
|
cc dependencies: clarify comment
This caused confusion in https://github.com/rust-lang/rust/pull/144570
r? ``@jieyouxu``
|
|
miri subtree update
Subtree update of `miri` to https://github.com/rust-lang/miri/commit/fc4d9a2720d38f815d3e20627b805b4a379e5c8b.
Created using https://github.com/rust-lang/josh-sync.
r? `@ghost`
|
|
feat: Right align line numbers
As part of my work on getting `annotate-snipptes` to be used as `rustc`'s renderer, I realized that `rustc` left-aligned line numbers, while `annotate-snippets` right-aligned them. This PR switches `rustc` to right-align the line numbers, matching `annotate-snippets`. In practice, this change isn't very noticeable in day-to-day output, as it only shows up when a diagnostic span contains line numbers with different lengths (9->10, 99->100, 999->1000, etc.).
`rustc`
```
error[E0412]: cannot find type `F` in this scope
--> $DIR/ui-testing-optout.rs:92:10
|
4 | type A = B;
| ----------- similarly named type alias `A` defined here
...
92 | type E = F;
| ^ help: a type alias with a similar name exists: `A`
```
`annotate-snippets`
```
error[E0412]: cannot find type `F` in this scope
--> $DIR/ui-testing-optout.rs:92:10
|
4 | type A = B;
| ----------- similarly named type alias `A` defined here
...
92 | type E = F;
| ^ help: a type alias with a similar name exists: `A`
```
r? ``@compiler-errors``
|
|
Ensure external paths passed via flags end up in rustdoc depinfo
rustdoc has many flags to pass external HTML/Markdown/CSS files that end up in the build. These need to be recorded in depinfo so that Cargo will rebuild the crate if they change.
|
|
lolbinarycat:bootstrap-build.tidy-extra-checks-enable-for-tools, r=Kobzol
bootstrap: enable tidy auto extra checks on tools profile
alternative to https://github.com/rust-lang/rust/pull/144461
this won't affect CI or any `./configure` based workflows, and will also not affect every rust contributor like that PR will. a slower rollout of this feature should reduce disruption if issues are discovered with it.
r? ``@Kobzol``
|
|
tidy: increase performance of auto extra checks feature
Removes the repeated calls to git diff.
Halves the overhead of the tidy extra checks feature from 0.1 seconds to 0.05 on my machine, but probably will be more significant on systems on slow disks or less memory for i/o cache.
r? ``@Kobzol``
|
|
thread name in stack overflow message
Fixes rust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628.
This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR.
This PR also amends the stack overflow test to check for thread names, so we don't run into this again.
``@rustbot`` label +beta-nominated
|
|
Shourya742:2025-07-24-have-explicit-download-methods, r=Kobzol
Add explicit download methods to download module in bootstrap
This PR attempts to decouple the default initialization of the config object from parse_inner. It moves specific download methods, previously used during the initial config setup, into standalone functions outside the config implementation.
r? ``@Kobzol``
|
|
fix: Reject upvar scrutinees for `loop_match`
Fixes https://github.com/rust-lang/rust/issues/144051
I think we should reject upvars as they are not locals but somewhat like field access
|
|
r=wesleywiser
fix(debuginfo): disable overflow check for recursive non-enum types
Commit b10edb4 introduce an overflow check when generating debuginfo for expanding recursive types. While this check works correctly for enums, it can incorrectly prune valid debug information for structures.
For example see rust-lang/rust#143241 (https://github.com/rust-lang/rust/issues/143241#issuecomment-3073721477). Furthermore, for structures such check does not make sense, since structures with recursively expanding types simply will not compile (there is a `hir_analysis_recursive_generic_parameter` for that).
closes rust-lang/rust#143241
|
|
Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.
`Range*<&T> as RangeBounds<T>` impls have been tried to be relaxed to `T: ?Sized` at least twice:
* https://github.com/rust-lang/rust/pull/61584
* https://github.com/rust-lang/rust/pull/64327
I also was just about to make another PR to do it again until I `./x.py test library/alloc` and rediscovered the type inference regression, then searched around and found the previous PRs. Hence this PR instead so hopefully that doesn't keep happening :stuck_out_tongue:.
These impls cannot be relaxed for two reasons:
1. Type inference regressions: See ``@SimonSapin's`` explanation from a previous PR: https://github.com/rust-lang/rust/pull/61584#issuecomment-499601046
2. It's a breaking change: `impl RangeBounds<MyUnsizedType> for std::ops::Range<&MyUnsizedType>` is allowed after the coherence rebalance ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f704a6fe53bfc33e55b2fc246d895ec2)), and relaxing these impls would conflict with that downstream impl.
This PR adds doc-comments explaining that not having `T: ?Sized` is intentional[^1], and gives an explicit alternative: `(Bound<&T>, Bound<&T>)`.
Technically, the impls for the unstable new `std::range` types could be relaxed, as they are still unstable so the change would not be breaking, but having them be different in this regard seems worse (and the non-iterable `RangeTo/RangeToInclusive` range types are shared between the "new" and "old" so cannot be changed anyway), and then the type inference regression would pop up in whatever edition the new range types stabilize in.
The "see \<link\> for discussion of those issues" is intentionally left as a non-doc comment just for whoever may try to relax these impls again in the future, but if it is preferred to have the link in the docs I can add that.
Closes https://github.com/rust-lang/rust/issues/107196 (as wontfix)
CC https://github.com/rust-lang/rust/issues/64027
[^1]: "intentional" is maybe a bit of strong wording, should it instead say something like "was stabilized without it and it would be breaking to change it now"?
|
|
Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`
Continuation of https://github.com/rust-lang/rust/pull/134663
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR implements a new `sync/nonpoison` module, as well as the `nonpoison` variant of the `Mutex` lock.
There are 2 main changes here, the first is the new `nonpoison::mutex` module, and the second is the `mutex` integration tests.
For the `nonpoison::mutex` module, I did my best to align it with the current state of the `poison::mutex` module. This means that several unstable features (`mapped_lock_guards`, `lock_value_accessors`, and `mutex_data_ptr`) are also in the new `nonpoison::mutex` module, under their respective feature gates. Everything else in that file is under the correct feature gate (`#[unstable(feature = "nonpoison_mutex", issue = "134645")]`).
Everything in the `nonpoison::mutex` file is essentially identical in spirit, as we are simply removing the error case from the original `poison::mutex`.
The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always `unwrap`ped.
~~I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other `nonpoison` locks when they eventually get implemented, but I'll leave that for a later discussion.~~
|
|
The two xors get folded into the select.
|
|
This is now printed on the same line. Use NEXT/SAME depending on
the LLVM version.
|
|
fix: In generate_mut_trait_impl, don't add a tabstop if the client does not support snippets
|
|
|
