| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix(lexer): Allow '-' in the frontmatter infostring continue set
This more closely matches the RFC and what our T-lang contact has asked
for, see https://github.com/rust-lang/rust/issues/136889#issuecomment-3212715312
Tracking issue: rust-lang/rust#136889
|
|
Refactor lint buffering to avoid requiring a giant enum
Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it.
Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly.
Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case.
---
With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection.
Also remove an unused `BuiltinLintDiag` variant.
|
|
tests: Ignore basic-stepping.rs on LoongArch
|
|
doc: fix some typos in comment
fix some typos in comment
|
|
lolbinarycat:rustdoc-search-type-cleanup-continued, r=GuillaumeGomez
rustdoc js: Even more typechecking improvments
made another pass at eliminating typescript errors, this time mainly focused on adding fields to `window` that weren't declared before.
r? `@notriddle`
|
|
Uplift rustc_mir_transform::coverage::counters::union_find to rustc_data_structures.
I was wondering if we had some union-find implementation in the compiler. We do. So put it where we can find it.
|
|
triagebot: Update style team reviewers
|
|
lolbinarycat:rustdoc-search-generic-pointer-142385, r=notriddle
Make raw pointers work in type-based search
fixes rust-lang/rust#142385
|
|
Experiment: Reborrow trait
Tracking issue: rust-lang/rust#145612
Starting off really small here: just introduce the unstable feature and the feature gate, and one of the two traits that the Reborrow experiment deals with.
### Cliff-notes explanation
The `Reborrow` trait is conceptually a close cousin of `Copy` with the exception that it disables the source (`self`) for the lifetime of the target / result of the reborrow action. It can be viewed as a method of `fn reborrow(self: Self<'a>) -> Self<'a>` with the compiler adding tracking of the resulting `Self<'a>` (or any value derived from it that retains the `'a` lifetime) to keep the `self` disabled for reads and writes.
No method is planned to be surfaced to the user, however, as reborrowing cannot be seen in code (except for method calls [`a.foo()` reborrows `a`] and explicit reborrows [`&*a`]) and thus triggering user-code in it could be viewed as "spooky action at a distance". Furthermore, the added compiler tracking cannot be seen on the method itself, violating the Golden Rule. Note that the userland "reborrow" method is not True Reborrowing, but rather a form of a "Fancy Deref":
```rust
fn reborrow(&'short self: Self<'long>) -> Self<'short>;
```
The lifetime shortening is the issue here: a reborrowed `Self` or any value derived from it is bound to the method that called `reborrow`, since `&'short` is effectively a local variable. True Reborrowing does not shorten the lifetime of the result.
To avoid having to introduce new kinds of references, new kinds of lifetime annotations, or a blessed trait method, no method will be introduced at all. Instead, the `Reborrow` trait is intended to be a derived trait that effectively reborrows each field individually; `Copy` fields end up just copying, while fields that themselves `Reborrow` get disabled in the source, usually leading to the source itself being disabled (some differences may appear with structs that contain multiple reborrowable fields). The goal of the experiment is to determine how the actual implementation here will shape out, and what the "bottom case" for the recursive / deriving `Reborrow` is.
`Reborrow` has a friend trait, `CoerceShared`, which is equivalent to a `&'a mut T -> &'a T` conversion. This is needed as a different trait and different operation due to the different semantics it enforces on the source: a `CoerceShared` operation only disables the source for writes / exclusive access for the lifetime of the result. That trait is not yet introduced in this PR, though there is no particular reason why it could not be introduced.
|
|
Fix the ABI parameter inconsistency issue in debug.rs for LoongArch64
Issue: rust-lang/rust#145692
|
|
Introduce ProjectionElem::try_map.
Small utility function useful to manipulate MIR place projections.
|
|
r=GuillaumeGomez
rustdoc-search: GUI tests check for `//` in URL
Follow up https://github.com/rust-lang/rust/pull/145650
When this fails, you get output that looks like:
/home/user/rust/tests/rustdoc-gui/search-result-impl-disambiguation.goml search-result-impl-disambiguation... FAILED
[ERROR] `tests/rustdoc-gui/utils.goml` around line 49
from `tests/rustdoc-gui/search-result-impl-disambiguation.goml` line 25: JS errors occurred: Event: Event
Making the error message more informative requires patching browser-ui-test.
|
|
On E0277, point at type that doesn't implement bound
When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
|
|
Fix some typos in LocalKey documentation
A few minor grammatical/wording changes in the `std::thread::LocalKey` documentation.
|
|
resolve: Remove `ScopeSet::Late`
It's better to decouple the late/early stage from scope set, because in https://github.com/rust-lang/rust/pull/144131#discussion_r2283200511 we'll need the stage for `ScopeSet::Module` as well.
See individual commits for the refactoring details.
r? ``@b-naber``
|
|
Add an experimental unsafe(force_target_feature) attribute.
This uses the feature gate for https://github.com/rust-lang/rust/issues/143352, but is described in https://github.com/rust-lang/rfcs/pull/3820 which is strongly tied to the experiment.
|
|
Add codegen-llvm regression tests
Most of these regressions deal with elimination of panics and bounds checks that were fixed upstream by LLVM.
closes https://github.com/rust-lang/rust/issues/141497
closes https://github.com/rust-lang/rust/issues/131162
closes https://github.com/rust-lang/rust/issues/129583
closes https://github.com/rust-lang/rust/issues/110971
closes https://github.com/rust-lang/rust/issues/91109
closes https://github.com/rust-lang/rust/issues/80075
closes https://github.com/rust-lang/rust/issues/74917
closes https://github.com/rust-lang/rust/issues/71997
closes https://github.com/rust-lang/rust/issues/71257
closes https://github.com/rust-lang/rust/issues/59352
|
|
r=Mark-Simulacrum
[Debuginfo] improve enum value formatting in LLDB for better readability
> TL;DR: When debugging with CodeLLDB, I noticed enum values were often hard to read because LLDB lists every possible variant, resulting in a verbose and cluttered view, even though only one variant is actually valid. Interestingly, raw enum types display nicely. After some investigation, I found that `&enum` values get classified as `Other`, so it falls back to `DefaultSyntheticProvider`, which causes this verbose output.
## What does this PR do?
This PR contains 2 commits:
1. change the enum value formatting from showing 2 separate fields (`value` for attached data and `$discr$` for the discriminator) to a concise `<readable variant name>: <attached data>` format
2. dereference pointer types in `classify_rust_type` so that it can return more accurate type for reference type
## Self-test proof
Before:
<img width="1706" height="799" alt="before" src="https://github.com/user-attachments/assets/b66c7e22-990a-4da5-9036-34e3f9f62367" />
After:
<img width="1541" height="678" alt="after" src="https://github.com/user-attachments/assets/36db32e2-f822-4883-8f17-cb8067e509f6" />
|
|
print raw lifetime idents with r#
This replaces rust-lang/rust#143185 and fixes rust-lang/rust#143150
cc ``@fmease``
|
|
Implementation: `#[feature(nonpoison_rwlock)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR continues the effort made in https://github.com/rust-lang/rust/pull/144022 by adding the implementation of `nonpoison::rwlock`.
Many of the changes here are similar to the changes made to implement `nonpoison::mutex`. The only real difference is that this PR includes a reorganizing of the existing `poison::rwlock` file that hopefully makes both variants more readable.
### Related PRs
- `nonpoison_condvar` implementation: https://github.com/rust-lang/rust/pull/144651
- `nonpoison_once` implementation: https://github.com/rust-lang/rust/pull/144653
|
|
Convert moves of references to copies in ReferencePropagation
This is a fix for https://github.com/rust-lang/rust/issues/141101.
The root cause of this miscompile is that the SsaLocals analysis that MIR transforms use is supposed to detect locals that are only written to once, in their single assignment. But that analysis is subtly wrong; it does not consider `Operand::Move` to be a write even though the meaning ascribed to `Operand::Move` (at least as a function parameter) by Miri is that the callee may have done arbitrary writes to the caller's Local that the Operand wraps (because `Move` is pass-by-pointer). So Miri conwiders `Operand::Move` to be a write but both the MIR visitor system considers it a read, and so does SsaLocals.
I have tried fixing this by changing the `PlaceContext` that is ascribed to an `Operand::Move` to a `MutatingUseContext` but that seems to have borrow checker implications, and changing SsaLocals seems to have wide-ranging regressions in MIR optimizations.
So instead of doing those, this PR adds a new kludge to ReferencePropagation, which follows the same line of thinking as the kludge in CopyProp that solves this same problem inside that pass: https://github.com/rust-lang/rust/blob/a5584a8fe16037dc01782064fa41424a6dbe9987/compiler/rustc_mir_transform/src/copy_prop.rs#L65-L98
|
|
Fix host code appearing in Wasm binaries
This is a direct fix for issue [132802](https://github.com/rust-lang/rust/issues/132802).
Followed the outline as follows:
> * give a hard error in bootstrap when using gcc to compile for wasm
> * change our CI to use clang instead of gcc
> * add a test that compiling a sample program for wasm32-unknown doesn't give any linker warnings
The `test-various` ci job was also changed.
try-job: test-various
try-job: dist-various-1
try-job: dist-various-2
try-job: x86_64-msvc-1
|
|
Recover `param: Ty = EXPR`
Fixes #137310
Pretty basic recovery here, but better than giving an unexpected token error.
|
|
Fix overly restrictive lifetime in `core::panic::Location::file` return type
Fixes #131770 by relaxing the lifetime to match what's stored in the struct. See that issue for more details and discussion.
Since this is a breaking change, I think a crater run is in order. Since this change should only have an effect at compile-time, I think just a check run is sufficient.
|
|
|
|
Split transmute check from HIR typeck
This resolves a FIXME in the implementation of `check_transmute`.
`check_transmute` needs to compute type layout, hence needing to see reveal opaques and all type aliases.
Having this inside typeck causes a cycle. For instance: `tests/ui/impl-trait/transmute/in-defining-scope.rs`.
This PR moves the transmute check outside of typeck, by putting the list of deferred transmute checks in typeck results.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
inside expansion spans
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This [feature](https://forge.rust-lang.org/triagebot/range-diff.html)
shows the changes when a PR is rebased, while the GitHub UI would mix
the actual changes with the ones coming from the rebase.
|
|
Closes rust-lang/rust-clippy#15493
Closes rust-lang/rust-clippy#15536
changelog: [`derivable_impls`] fix wrong suggestions on `derive_const`
|
|
|
|
|
|
|
|
Only unpack span data once to compute end_point and next_point.
Split from https://github.com/rust-lang/rust/pull/144930
|
|
The issue that this PR was opened to fix
(https://github.com/rust-lang/rust-clippy/issues/15367), talked about
how, for `!x == false`, this lint suggests both:
1. `x != false`
2. `x`
I initially wanted to make the lint short-circuit after emitting the
first suggestion (since that was the easier change code-wise), but that
was not optimal for two reasons:
1. suggestion 2 is obviously better (the other one requires one more
round of Clippy)
2. suggestion 1 is actually already covered by `nonminimal_bool`
And so I instead decided to completely remove the code path that emits
suggestion 1.
Fixes https://github.com/rust-lang/rust-clippy/issues/15367
changelog: [`bool_comparison`]: no longer lint on `!x != y`
|
|
there are a lot of MCVEs there, so this is only a few of them, not all
duplicates that were opened
|
|
|
