Remove `ast::Guard`
With the introduction of `ast::ExprKind::Let` in https://github.com/rust-lang/rust/pull/60861, the `ast::Guard` structure is now redundant in terms of representing [`if let` guards](https://github.com/rust-lang/rust/issues/51114) in AST since it can be represented by `ExprKind::Let` syntactically. Therefore, we remove `ast::Guard` here.
However, we keep `hir::Guard` because the semantic representation is a different matter and this story is more unclear right now (might involve `goto 'arm` in HIR or something...).
r? @petrochenkov
Run rustfmt on some libsyntax files
As part of #62008, run rustfmt on:
- src/libsyntax/ext/tt/macro_rules.rs
- src/libsyntax/ext/tt/quoted.rs
There is no semantic change. To fix potential merge conflicts, simply choose the other side then run rustfmt and fix any tidy check (like line length).
[let_chains, 2/6] Introduce `Let(..)` in AST, remove IfLet + WhileLet and parse let chains
Here we remove `ast::ExprKind::{IfLet, WhileLet}` and introduce `ast::ExprKind::Let`.
Moreover, we also:
+ connect the parsing logic for let chains
+ introduce the feature gate
+ rewire HIR lowering a bit.
However, this does not connect the new syntax to semantics in HIR.
That will be the subject of a subsequent PR.
Per https://github.com/rust-lang/rust/issues/53667#issuecomment-471583239.
Next step after https://github.com/rust-lang/rust/pull/59288.
cc @Manishearth re. Clippy.
r? @oli-obk
Fix meta-variable binding errors in macros
The errors are either:
- The meta-variable used in the right-hand side is not bound (or defined) in the
left-hand side.
- The meta-variable used in the right-hand side does not repeat with the same
kleene operator as its binder in the left-hand side. Either it does not repeat
enough, or it uses a different operator somewhere.
This change should have no semantic impact.
Found by https://github.com/rust-lang/rust/pull/62008
The errors are either:
- The meta-variable used in the right-hand side is not bound (or defined) in the
left-hand side.
- The meta-variable used in the right-hand side does not repeat with the same
kleene operator as its binder in the left-hand side. Either it does not repeat
enough, or it uses a different operator somewhere.
This change should have no semantic impact.
rustc: disallow cloning HIR nodes.
Besides being inefficient, cloning also risks creating broken HIR (without properly recreating all the IDs and whatnot, in which case you might as well reconstruct the entire node without ever `Clone`-ing anything).
We detect *some* detrimental situations (based on the occurrence of `HirId`s, I believe?), but it's better to statically disallow it, IMO.
One of the examples that is fixed by this PR is `tcx.hir().fn_decl{,_by_hir_id}`, which was cloning an entire `hir::FnDecl` *every single time it was called*.
r? @petrochenkov cc @rust-lang/compiler
Support `cfg` and `cfg_attr` on generic parameters
`cfg` attributes are supported in all other positions where attributes are accepted at all.
They were previously prohibited in https://github.com/rust-lang/rust/pull/51283 because they weren't implemented correctly before that and were simply ignored.
Improve the explicit_outlives_requirements lint
* Don't use Strings to compare parameters
* Extend the lint to lifetime bounds
* Extend the lint to enums and unions
* Use the correct span for where clauses in tuple structs
* Try to early-out where possible
* Remove unnecessary bounds in rustc crates
This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
create a "provisional cache" to restore performance in the case of cycles
Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the *main* cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in #60846 -- I plan to add a perf.rust-lang.org regression test to track this.
Caveat: I've not run `x.py test` in full yet.
r? @pnkfelix
cc @arielb1
Fixes#60846
Change `...` to `..=` where applicable
This is mainly to fix#61816, but I decided to manually check a few thousand `...` throughout the code base to check for any other cases. I think I found a documentation bug in `src\libsyntax\ast.rs` where both `1..` and `1...` where mentioned. If there is internal support for both `1..` and `1..=` (that can exist before error handling gets to it), then I can add that back.
There were some other cases that look like `// struct Closure<'l0...'li, T0...Tj, CK, CS, U0...Uk> {`, `// <P0 as Trait<P1...Pn>>::Foo: 'a`, and `assert!(min <= max, "discriminant range is {}...{}", min, max);`, but I am not sure if I should change those.
There are a bunch of cases in the `/test/` directory that could be changed, but I presume I should just leave those be.
Remove some unnecessary symbol interner ops
* Don't gensym symbols that don't need to worry about colliding with other symbols
* Use symbol constants instead of interning string literals in a few places.
* Don't generate a module in `__register_diagnostic`
r? @petrochenkov
