compiletest: Rename `//@ ignore-pass` to `//@ no-pass-override`
By convention, compiletest directives starting with `ignore-*` normally cause the test itself to be skipped under certain conditions.
The `//@ ignore-pass` directive was the only exception to that convention. The new name should hopefully do a better job of communicating its effect, which is to cause the `--pass` flag to not override the test's `build-pass` or `run-pass` directive.
The `//@ no-pass-override` directive is mainly useful for tests that expect warnings produced during codegen.
---
r? jieyouxu
The compiletest `--pass` flag only affects tests with a `*-pass` directive,
i.e. `check-pass`, `build-pass`, or `run-pass`.
It has no effect in `*-fail` tests, or in auxiliary crates.
Validate source snippet when format input is raw string
Fixesrust-lang/rust#114865
The issue occurred because the user's proc macro respanned the format arg to an unrelated multi-byte string and we ICE'd by landing in the middle of a multi-byte char.
This PR adds validation that prevents the parser from trying to walk such obviously wrong snippets. Such validation already existed for non-raw strings. This PR adds it for raw strings as well.
`span_suggestions` is to provide mutually exclusive suggestions. When it was introduced, we made its behavior be that if a single suggestion is given to it, we present the suggestion inline, otherwise in patch format. Changing this to make all of its uses be verbose, as that is closer in intent of output.
Use fine grained component-wise span tracking in use trees
This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).
also removes E0452 and splits
`tests/rustdoc-ui/lints/renamed-lint-still-applies` into 2 tests
this is because of delayed warn lint being lost on compiler aborting on
error
Add hygiene annotations for tokens in `macro_rules!` bodies
`-Zunpretty=expanded,hygiene` was not printing syntax context annotations for identifiers and lifetimes inside `macro_rules!` bodies. These tokens are printed via `print_tt()` → `token_to_string_ext()`, which converts tokens to strings without calling `ann_post()`. This meant that macro-generated `macro_rules!` definitions with hygienic metavar parameters (e.g. multiple `$marg` distinguished only by hygiene) were printed with no way to tell them apart.
This was fixed by adding a match on `token.kind` in `print_tt()` to call `ann_post()` for `Ident`, `NtIdent`, `Lifetime`, and `NtLifetime` tokens, matching how `print_ident()` and `print_lifetime()` already handle AST-level identifiers and lifetimes.
- On `const` and `static` point at the type (like we do for let bindings)
- On fn calls, point at const parameter in fn definition
- On type, point at const parameter in type definition
- On array type lengths, explain that array length is always `usize`
- On enum variant discriminant, mention `repr`
`-Zunpretty=expanded,hygiene` was not printing syntax context annotations
for identifiers and lifetimes inside `macro_rules!` bodies. These tokens
are printed via `print_tt()` → `token_to_string_ext()`, which converts
tokens to strings without calling `ann_post()`. This meant that
macro-generated `macro_rules!` definitions with hygienic metavar
parameters (e.g. multiple `$marg` distinguished only by hygiene) were
printed with no way to tell them apart.
This was fixed by adding a match on `token.kind` in `print_tt()` to call
`ann_post()` for `Ident`, `NtIdent`, `Lifetime`, and `NtLifetime`
tokens, matching how `print_ident()` and `print_lifetime()` already
handle AST-level identifiers and lifetimes.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
reduce the amount of panics in `{TokenStream, Literal}::from_str` calls
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/147859)*
Before this PR, calling `TokenStream::from_str` or `Literal::from_str` with an invalid argument would always cause a compile error, even if the `TokenStream` is not used afterwards at all.
This PR changes this so it returns a `LexError` instead in some cases.
This is very theoretically a breaking change, but the doc comment on the impl already says
```
/// NOTE: some errors may cause panics instead of returning `LexError`. We reserve the right to
/// change these errors into `LexError`s later.
```
Fixes some cases of rust-lang/rust#58736.
remove the explicit error for old `rental` versions
This was converted to a hard error 20 months ago (in rust-lang/rust#125596). This seems like enough time for anyone still using it to notice, so remove the note entirely now.
In comparison, the explicit note for the more impactful `time` breakage was already removed after 6 months (rust-lang/rust#129343).
Closesrust-lang/rust#73933.
Closesrust-lang/rust#83125.
r? @petrochenkov
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
```
note: required for `B<C>` to implement `Copy`
--> $DIR/deriving-copyclone.rs:9:10
|
LL | #[derive(Copy, Clone)]
| ^^^^ unsatisfied trait bound introduced in this `derive` macro
LL | struct B<T> {
| - would need to be `Copy`
```
When encountering a bound coming from a derive macro, suggest manual impl of the trait.
Use the span for the specific param when adding bounds in builtin derive macros, so the diagnostic will point at them as well as the derive macro itself.
```
error[E0277]: can't compare `SomeNode` with `SomeNode`
--> f29.rs:24:15
|
24 | accept_eq(&node);
| --------- ^^^^^ no implementation for `SomeNode == SomeNode`
| |
| required by a bound introduced by this call
|
= note: -Ztrack-diagnostics: created at compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs:279:39
= help: the trait `PartialEq` is not implemented for `SomeNode`
note: required for `Id<SomeNode>` to implement `PartialEq`
--> f29.rs:3:10
|
3 | #[derive(PartialEq, Eq)]
| ^^^^^^^^^ unsatisfied trait bound introduced in this `derive` macro
4 | pub struct Id<T>(PhantomData<T>);
| -
= help: consider manually implementing `PartialEq` to avoid undesired bounds
note: required by a bound in `accept_eq`
--> f29.rs:15:23
|
15 | fn accept_eq(_: &impl PartialEq) { }
| ^^^^^^^^^ required by this bound in `accept_eq`
help: consider annotating `SomeNode` with `#[derive(PartialEq)]`
|
13 + #[derive(PartialEq)]
14 | struct SomeNode();
|
```
Better handle when trying to iterate on a `Range` of a type that isn't `Step`
Mention when a trait bound corresponds to an unstable trait.
Mention `Range` when `Step` bound is unment, and explain that only some std types impl `Iterator` for `Range`.
CC rust-lang/rust#151026
Currently all core and std macros are automatically added to the prelude
via #[macro_use]. However a situation arose where we want to add a new macro
`assert_matches` but don't want to pull it into the standard prelude for
compatibility reasons. By explicitly exporting the macros found in the core and
std crates we get to decide on a per macro basis and can later add them via
the rust_20xx preludes.
Add regression test for issue #99173Closerust-lang/rust#99173.
Adds a regression test for rust-lang/rust#99173, which was an ICE that occurred when a proc-macro generated code that invoked another proc-macro returning an empty `TokenStream`.
许杰友 Jieyou Xu (Joe)