| Age | Commit message (Collapse) | Author | Lines |
|---|
|
mention lint group in default level lint note
### Summary
This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any.
Fixes: rust-lang/rust#65464.
### Example
```rust
fn main() {
let x = 5;
}
```
Before:
```
= note: `#[warn(unused_variables)]` on by default
```
After:
```
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
```
### Unchanged Cases
Messages remain the same when the lint level is explicitly set, e.g.:
* Attribute on the lint `#[warn(unused_variables)]`:
```
note: the lint level is defined here
LL | #[warn(unused_variables)]
| ^^^^^^^^^^^^^^^^
```
* Attribute on the group `#[warn(unused)]:`:
```
= note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
```
* CLI option `-W unused`:
```
= note: `-W unused-variables` implied by `-W unused`
= help: to override `-W unused` add `#[allow(unused_variables)]`
```
* CLI option `-W unused-variables`:
```
= note: requested on the command line with `-W unused-variables`
```
|
|
|
|
Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups
Fixes https://github.com/rust-lang/rust/issues/145470.
First commit fixes the issue, second one performs some desperately needed cleanups.
The fix shouldn't be a breaking change because IINM the parser always ensures that all brackets are balanced (via a buffer of brackets). Meaning even though we used to accept `(use<>` as a valid precise capturing list, it was guaranteed that we would fail in the end.
|
|
Implement declarative (`macro_rules!`) derive macros (RFC 3698)
This is a draft for review, and should not be merged yet.
This is layered atop https://github.com/rust-lang/rust/pull/145153 , and has
only two additional commits atop that. The first handles parsing and provides a
test for various parse errors. The second implements expansion and handles
application.
This implements RFC 3698, "Declarative (`macro_rules!`) derive macros".
Tracking issue: https://github.com/rust-lang/rust/issues/143549
This has one remaining issue, which I could use some help debugging: in
`tests/ui/macros/macro-rules-derive-error.rs`, the diagnostics for
`derive(fn_only)` (for a `fn_only` with no `derive` rules) and
`derive(ForwardReferencedDerive)` both get emitted twice, as a duplicate
diagnostic.
From what I can tell via adding some debugging code,
`unresolved_macro_suggestions` is getting called twice from
`finalize_macro_resolutions` for each of them, because
`self.single_segment_macro_resolutions` has two entries for the macro, with two
different `parent_scope` values. I'm not clear on why that happened; it doesn't
happen with the equivalent code using attrs.
I'd welcome any suggestions for fixing this.
|
|
|
|
This handles various kinds of errors, but does not allow applying the
derive yet.
This adds the feature gate `macro_derive`.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Tweak invalid builtin attribute output
- Add link to reference/docs when possible
- More accurate suggestions by supporting multiple alternative suggestions
```
error: malformed `crate_type` attribute input
--> $DIR/crate-type-macro-call.rs:1:1
|
LL | #![crate_type = foo!()]
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= note: for more information, visit <https://doc.rust-lang.org/reference/linkage.html>
help: the following are the possible correct uses
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "bin"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "cdylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "dylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "lib"]
|
= and 4 other candidates
```
|
|
|
|
This is a technically a breaking change for what can be parsed in
`#[cfg(false)]`.
|
|
|
|
`tests/ui/issues/`: The Issues Strike Back [4/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ````````@jieyouxu````````
|
|
|
|
Account for bare tuples and `Pin` methods in field searching logic
When looking for the field names and types of a given type, account for tuples. This allows suggestions for incorrectly nested field accesses and field name typos to trigger as intended. Previously these suggestions only worked on `ty::Adt`, including tuple structs which are no different to tuples, so they should behave the same in suggestions.
When suggesting field access which would encounter a method not found, do not suggest pinning when those methods are on `impl Pin` itself.
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: one of the expressions' fields has a method of the same name
|
LL | let x = f.0.get_ref();
| ++
```
instead of
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: consider pinning the expression
|
LL ~ let mut pinned = std::pin::pin!(f);
LL ~ let x = pinned.as_ref().get_ref();
|
```
Fix rust-lang/rust#144602.
|
|
|
|
This handles various kinds of errors, but does not allow applying the
attributes yet.
This adds the feature gate `macro_attr`.
|
|
When looking for the field names and types of a given type, account for tuples. This allows suggestions for incorrectly nested field accesses and field name typos to trigger as intended. Previously these suggestions only worked on `ty::Adt`, including tuple structs which are no different to tuples, so they should behave the same in suggestions.
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: one of the expressions' fields has a method of the same name
|
LL | let x = f.0.get_ref();
| ++
```
|
|
Parser: Recover from attributes applied to types and generic args
r? compiler
Add clearer error messages for invalid attribute usage in types or generic types
fixes rust-lang/rust#135017
fixes rust-lang/rust#144132
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#144397 (`tests/ui/issues/`: The Issues Strike Back [2/N])
- rust-lang/rust#144410 (Make tier 3 musl targets link dynamically by default)
- rust-lang/rust#144708 (Add tracing to step.rs and friends)
- rust-lang/rust#144730 (Create a typed wrapper for codegen backends in bootstrap)
- rust-lang/rust#144771 (Remove some noisy triagebot pings for myself)
- rust-lang/rust#144772 (add unsupported_calling_conventions to lint list)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`tests/ui/issues/`: The Issues Strike Back [2/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ``@jieyouxu``
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
`tests/ui/issues/`: The Issues Strike Back [1/N]
I believe I’ve finally brought [my program](https://github.com/Kivooeo/test-manager) to life -- it now handles multiple test moves in one go: plain moves first, then a gentle touch on each file depends on given options. The process should be much smoother now.
Of course, I won’t rush through everything in a few days -- that would be unkind to `@Oneirical.` I’ll pace myself. And also I can't have more than one such PR because `issues.txt` will conflict with previous parts after merging them which is not fun as well.
This PR is just that: first commit - moves; second - regression comments and the occasional .stderr reblesses, also issue.txt and tidy changes. Nothing special, but progress nonetheless. This is for the purpose of preserving test file history during restructuring
Part of https://github.com/rust-lang/rust/issues/133895.
r? `@jieyouxu`
|
|
Add `ignore-backends` annotations in failing GCC backend ui tests
Follow-up of https://github.com/rust-lang/rust/pull/144125.
In the GCC backend, we don't support all ui tests yet and we have a list of tests we currently ignore available [here](https://github.com/rust-lang/rustc_codegen_gcc/blob/master/tests/failing-ui-tests.txt).
This PR adds the `ignore-backends` annotations to the corresponding ui tests.
The second commit is a fix to compiletest, complaining about `ignore-backends`.
r? ```@jieyouxu```
|
|
|
|
|
|
don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
|
|
|
|
More robustly deal with relaxed bounds and improve their diagnostics
Scaffolding for https://github.com/rust-lang/rust/issues/135229 (CC https://github.com/rust-lang/rust/pull/135331)
Fixes https://github.com/rust-lang/rust/issues/136944 (6th commit).
Fixes https://github.com/rust-lang/rust/issues/142718 (8th commit).
|
|
Distinguish delim kind to decide whether to emit unexpected closing delimiter
Fixes #138401
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
Constify `Index` traits
tracking issue: rust-lang/rust#143775
the `SliceIndex` trait cannot be implemented by users as it is sealed. While it would be useful for the `get` method on slices, it seems weird to have a feature gate for that that isn't also gating index syntax at the same time, so I put them under the same feature gate.
r? ```````@fee1-dead```````
|
|
|
|
Recover and suggest to use `;` to construct array type
Fixes rust-lang/rust#143828
r? compiler
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Additionally, remove unused `tests/ui/auxiliary/svh-*` crates that are duplicates of `tests/ui/svh/auxiliary/svh-*`.
|
|
|
|
`tests/ui`: A New Order [27/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
|
|
|
|
`tests/ui`: A New Order [23/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Most macro tests use `macro` in the name, making it easy to find and run
tests relevant to macros. However, a few use `mbe` instead. Rename those
to say `macro`.
|
|
The `macro` directory contains most of the macro tests, but not all of
them; move the remainder into `macro`.
|
|
`tests/ui`: A New Order [24/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
|
|
`tests/ui`: A New Order [18/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
|
