Add tests for `-Zunpretty=expanded` ported from stringify's tests
This PR adds a new set of tests for the AST pretty-printer.
Previously, pretty-printer edge cases were tested by way of `stringify!` in [tests/ui/macros/stringify.rs](https://github.com/rust-lang/rust/blob/1.78.0/tests/ui/macros/stringify.rs), such as the tests added by 419b26931b and 527e2eac17.
Those tests will no longer provide effective coverage of the AST pretty-printer after #124141. `Nonterminal` and `TokenKind::Interpolated` are being removed, and a consequence is that `stringify!` will perform token stream pretty printing, instead of AST pretty printing, in all of the `stringify!` cases including $:expr and all other interpolations.
This PR adds 2 new ui tests with `compile-flags: -Zunpretty=expanded`:
- **tests/ui/unpretty/expanded-exhaustive.rs** — this test aims for exhaustive coverage of all the variants of `ExprKind`, `ItemKind`, `PatKind`, `StmtKind`, `TyKind`, and `VisibilityKind`. Some parts could use being fleshed out further, but the current state is roughly on par with what exists in the old stringify-based tests.
- **tests/ui/unpretty/expanded-interpolation.rs** — this test covers tricky macro metavariable edge cases that require the AST pretty printer to synthesize parentheses in order for the printed code to be valid Rust syntax.
r? `@nnethercote`
Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability
In #123537, I tweaked the hack from #93892 to use `resolve_vars_if_possible` instead of `shallow_resolve`. This considers more inference guidance ambiguous. This resulted in crater regressions in #125196.
I've effectively reverted the change to the old behavior. That being said, I don't *like* this behavior, but I'd rather keep it for now since #123537 was not meant to make any behavioral changes. See the attached example.
This also affects the new solver, for the record, which doesn't have any rules about not guiding inference from param-env candidates which may constrain GAT args as a side-effect.
r? `@lcnr` or `@jackh726`
Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
Improve parser
Fixes#124935.
- Add a few more help diagnostics to incorrect semicolons
- Overall improved that function
- Addded a few comments
- Renamed diff_marker fns to git_diff_marker
Fix println! ICE when parsing percent prefix number
This PR fixes#125002 ICE occurring, for example, with `println!("%100000", 1)` or `println!("% 100000", 1)`.
## Test Case/Change Explanation
The return type of `Num::from_str` has been changed to `Option<Self>` to handle errors when parsing large integers fails.
1. The first `println!` in the test case covers the change of the first `Num::from_str` usage in `format_foreign.rs:426`.
2. The second `println!` in the test case covers the change of the second `Num::from_str` usage in line 460.
3. The 3rd to 5th `Num::from_str` usages behave the same as before.
The 3rd usage would cause an ICE when `num > u16::MAX` in the previous version, but this commit does not include a fix for the ICE in `println!("{:100000$}")`. I think we need to emit an error in the compiler and have more discussion in another issue/PR.
Update `expr` matcher for Edition 2024 and add `expr_2021` nonterminal
This commit adds a new nonterminal `expr_2021` in macro patterns, and `expr_fragment_specifier_2024` feature flag.
This change also updates `expr` so that on Edition 2024 it will also match `const { ... }` blocks, while `expr_2021` preserves the current behavior of `expr`, matching expressions without `const` blocks.
Joint work with `@vincenzopalazzo.`
Issue #123742
expand: fix minor diagnostics bug
The error mentions `///`, when it's actually `//!`:
```
error[E0658]: attributes on expressions are experimental
--> test.rs:4:9
|
4 | //! wah
| ^^^^^^^
|
= note: see issue https://github.com/rust-lang/rust/issues/15701 <https://github.com/rust-lang/rust/issues/15701> for more information
= help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable
= help: `///` is for documentation comments. For a plain comment, use `//`.
```
Rename `${length()}` to `${len()}`
Implements the rename suggested in https://github.com/rust-lang/rust/pull/122808#issuecomment-2047722187
> I brought this up in the doc PR but it belongs here – `length` should probably be renamed `len` before stabilization. The latter is de facto standard in the standard library, whereas the former is only used in a single unstable API. These metafunctions aren’t library items of course, but should presumably still be consistent with established names.
r? `@c410-f3r`
Fix the dedup error because of spans from suggestion
Fixes#116502
I believe this kind of issue is supposed resolved by #118057, but the `==` in `span` respect syntax context, here we should only care that they point to the same bytes of source text, so should use `source_equal`.
Rollup of 7 pull requests
Successful merges:
- #119838 (style-guide: When breaking binops handle multi-line first operand better)
- #124844 (Use a proper probe for shadowing impl)
- #125047 (Migrate `run-make/issue-14500` to new `rmake.rs` format)
- #125080 (only find segs chain for missing methods when no available candidates)
- #125088 (Uplift `AliasTy` and `AliasTerm`)
- #125100 (Don't do post-method-probe error reporting steps if we're in a suggestion)
- #125118 (Use new utility functions/methods in run-make tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't do post-method-probe error reporting steps if we're in a suggestion
Currently in method probing, if we fail to pick a method, then we reset and try to collect relevant candidates for method errors:
34582118af/compiler/rustc_hir_typeck/src/method/probe.rs (L953-L993)
However, we do method lookups via `lookup_method_for_diagnostic` and only care about the result if the method probe was a *success*.
Namely, we don't need to do a bunch of other lookups on failure, since we throw away these results anyways, such as an expensive call to:
34582118af/compiler/rustc_hir_typeck/src/method/probe.rs (L959)
And:
34582118af/compiler/rustc_hir_typeck/src/method/probe.rs (L985)
---
This PR also renames some methods so it's clear that they're for diagnostics.
r? `@nnethercote`
only find segs chain for missing methods when no available candidates
Fixes#124946
This PR includes two changes:
- Extracting the lookup for the missing method in chains into a single function.
- Calling this function only when there are no candidates available.
Warn against changes in opaque lifetime captures in 2024
Adds a (mostly[^1]) machine-applicable lint `IMPL_TRAIT_OVERCAPTURES` which detects cases where we will capture more lifetimes in edition 2024 than in edition <= 2021, which may lead to erroneous borrowck errors.
This lint is gated behind the `precise_capturing` feature gate and marked `Allow` for now.
[^1]: Except when there are APITs -- I may work on that soon
r? oli-obk
Rollup of 4 pull requests
Successful merges:
- #116675 ([ptr] Document maximum allocation size)
- #124997 (Fix ICE while casting a type with error)
- #125072 (Add test for dynamic dispatch + Pin::new soundness)
- #125090 (Migrate fuchsia docs from `pm` to `ffx`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `NtIdent` and `NtLifetime`
This is one part of the bigger "remove `Nonterminal` and `TokenKind::Interpolated`" change drafted in #114647. More details in the individual commit messages.
r? `@petrochenkov`
This commit adds a new nonterminal `expr_2021` in macro patterns, and
`expr_fragment_specifier_2024` feature flag. For now, `expr` and
`expr_2021` are treated the same, but in future PRs we will update
`expr` to match to new grammar.
Co-authored-by: Vincezo Palazzo <vincenzopalazzodev@gmail.com>
This span records the declaration of the metavariable in the LHS of the macro.
It's used in a couple of error messages. Unfortunately, it gets in the way of
the long-term goal of removing `TokenKind::Interpolated`. So this commit
removes it, which degrades a couple of (obscure) error messages but makes
things simpler and enables the next commit.
Pretty-print let-else with added parenthesization when needed
Rustc used to produce invalid syntax for the following code, which is problematic because it means we cannot apply rustfmt to the output of `-Zunpretty=expanded`.
```rust
macro_rules! expr {
($e:expr) => { $e };
}
fn main() {
let _ = expr!(loop {}) else { return; };
}
```
```console
$ rustc repro.rs -Zunpretty=expanded | rustfmt
error: `loop...else` loops are not supported
--> <stdin>:9:29
|
9 | fn main() { let _ = loop {} else { return; }; }
| ---- ^^^^^^^^^^^^^^^^
| |
| `else` is attached to this loop
|
= note: consider moving this `else` clause to a separate `if` statement and use a `bool` variable to control if it should run
```
