de-duplicate condition scoping logic between AST→HIR lowering and `ScopeTree` construction
There was some overlap between `rustc_ast_lowering::LoweringContext::lower_cond` and `rustc_hir_analysis::check::region::resolve_expr`, so I've removed the former and migrated its logic to the latter, with some simplifications.
Consequences:
- For `while` and `if` expressions' `let`-chains, this changes the `HirId`s for the `&&`s to properly correspond to their AST nodes. This is how guards were handled already.
- This makes match guards share previously-duplicated logic with `if`/`while` expressions. This will also be used by guard pattern[^1] guards.
- Aside from legacy syntax extensions (e.g. some builtin macros) that directly feed AST to the compiler, it's currently impossible to put attributes directly on `&&` operators in `let` chains[^2]. Nonetheless, attributes on `&&` operators in `let` chains in `if`/`while` expression conditions are no longer silently ignored and will be lowered.
- This no longer wraps conditions in `DropTemps`, so the HIR and THIR will be slightly smaller.
- `DesugaringKind::CondTemporary` is now gone. It's no longer applied to any spans, and all uses of it were dead since they were made to account for `if` and `while` being desugared to `match` on a boolean scrutinee.
- Should be a marginal perf improvement beyond that due to leveraging [`ScopeTree` construction](5e749eb66f/compiler/rustc_hir_analysis/src/check/region.rs (L312-L355))'s clever handling of `&&` and `||`:
- This removes some unnecessary terminating scopes that were placed around top-level `&&` and `||` operators in conditions. When lowered to MIR, logical operator chains don't create intermediate boolean temporaries, so there's no temporary to drop. The linked snippet handles wrapping the operands in terminating scopes as necessary, in case they create temporaries.
- The linked snippet takes care of letting `let` temporaries live and terminating other operands, so we don't need separate traversals of `&&` chains for that.
[^1]: rust-lang/rust#129967
[^2]: Case-by-case, here's my justification: `#[attr] e1 && e2` applies the attribute to `e1`. In `#[attr] (e1 && e2)` , the attribute is on the parentheses in the AST, plus it'd fail to parse if `e1` or `e2` contains a `let`. In `#[attr] expands_to_let_chain!()`, the attribute would already be ignored (rust-lang/rust#63221) and it'd fail to parse anyway; even if the expansion site is a condition, the expansion wouldn't be parsed with `Restrictions::ALLOW_LET`. If it *was* allowed, the notion of a "reparse context" from https://github.com/rust-lang/rust/issues/61733#issuecomment-509626449 would be necessary in order to make `let`-chains left-associative; multiple places in the compiler assume they are.
Port several trait/coherence-related attributes the new attribute system
Part of rust-lang/rust#131229
This ports:
- `#[const_trait]`
- `#[rustc_deny_explicit_impl]`
- `#[rustc_do_not_implement_via_object]`
- `#[rustc_coinductive]`
- `#[type_const]`
- `#[rustc_specialization_trait]`
- `#[rustc_unsafe_specialization_marker]`
- `#[marker]`
- `#[fundamental]`
- `#[rustc_paren_sugar]`
- `#[rustc_allow_incoherent_impl]`
- `#[rustc_coherence_is_core]`
This also changes `#[marker]` to error on duplicates instead of warning.
cc rust-lang/rust#142838, but I don't think it matters too much, since it's unstable.
r? ``@oli-obk``
compiler: rename BareFn to FnPtr
At some point "BareFn" was the chosen name for a "bare" function, without the niceties of `~fn`, `&fn`, or a few other ways of writing a function type. However, at some point the syntax for a "bare function" and any other function diverged even more. We started calling them what they are: function pointers, denoted by their own syntax.
However, we never changed the *internal* name for these, as this divergence was very gradual. Personally, I have repeatedly searched for "FnPtr" and gotten confused until I find the name is BareFn, only to forget this until the next time, since I don't routinely interact with the higher-level AST and HIR. But even tools that interact with these internal types only touch on them in a few places, making a migration easy enough. Let's use a more intuitive and obvious name, as this 12+ year old name has little to do with current Rust.
Fix some comments and related types and locals where it is obvious, e.g.
- bare_fn -> fn_ptr
- LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Remove `Symbol` from `Named` variant of `BoundRegionKind`/`LateParamRegionKind`
The `Symbol` is redundant, since we already store a `DefId` in the region variant. Instead, load the name via `item_name` when needed (which is almost always on the diagnostic path).
This introduces a `BoundRegionKind::NamedAnon` which is used for giving anonymous bound regions names, but which should only be used during pretty printing and error reporting.
compiler: Document and reduce `fn provide`s in hir crates
I found it hard to follow all these tiny micro-indirections. Much like you shouldn't pass around `&u32` if you can help it, you probably shouldn't use an indirection if the indirection overhead itself is literally bigger than the amount of data you are organizing. Generally a new `fn provide` amounts to around 3 LOC:
- the signature with opening brace
- the `rustc_middle::query::Providers` import
- an end brace
I am not even counting the cost in time and thought to go find the other `provide`, read it, understand, "Ah, yes, these functions", and then go to those. Thus I say we should collapse indirections of `provide` for modules that only export 1~2 queries. For higher-count indirections, I left them as-is, as I don't understand the crate well enough to judge their worth.
Then I dropped a pointer to the actual module of interest for all these instances of the same function. I think documenting them is important because the comment that it relates to the query system makes it obvious that they have **nothing** to do with the rest of the module's logic and I can carry on ignoring them. Actively doing so is another cognitive cost, but much more minimal.
There is also a small correctness issue in that all of these functions are technically mutating state. It's not a huge deal, but it's still easier to check all these mutations do not overlap if we have less instances of `fn provide` to check.
Many small indirections with 1-2 items actively hinders understanding.
Inlines various tiny submodule provides into
- hir_analysis::provide
- hir_analysis::check::provide
- hir_typeck::provide
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
Explicitly handle all nodes in `generics_of` when computing parent
If we, for example, forget to feed `generics_of` then it'll silently fall back to empty generics. Make this a bit more explicit.
Don't recompute `DisambiguatorState` for every RPITIT in trait definition
The `associated_type_for_impl_trait_in_trait` currently needs to rerun the `RPITVisitor` for every RPITIT to compute its disambiguator.
Instead of synthesizing all of the RPITITs def ids one at a time in different queries, just synthesize them inside of the `associated_types_for_impl_traits_in_associated_fn` query. There we can just share the same `DisambiguatorState` for all the RPITITs in one function signature.
r? ``````@Zoxc`````` or ``````@oli-obk`````` cc rust-lang/rust#140453
Start moving wf checking away from HIR
I'm trying to only access the HIR in the error path. My hope is that once we move significant portions of wfcheck off HIR that incremental will be able to cache wfcheck queries significantly better.
I think I am reaching a blocker because we normally need to provide good spans to `ObligationCause`, so that the trait solver can report good errors. In some cases I have been able to use bad spans and improve them depending on the `ObligationCauseCode` (by loading HIR in the case where we actually want to error). To scale that further we'll likely need to remove spans from the `ObligationCause` entirely (leaving it to some variants of `ObligationCauseCode` to have a span when they can't recompute the information later). Unsure this is the right approach, but we've already been using it. I will create an MCP about it, but that should not affect this PR, which is fairly limited in where it does those kind of tricks.
Especially b862d8828e is interesting here, because I think it improves spans in all cases
It's like `Symbol` but for byte strings. The interner is now used for
both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"`
you'll get a `Symbol` and a `ByteSymbol` with the same index and the
characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to
make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate
`ast::LitKind` in HIR. The latter change reduces peak memory by a
non-trivial amount on literal-heavy benchmarks such as `deep-vector` and
`tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some
changes so that they can handle normal strings and byte strings.
This change does slow down compilation of programs that use
`include_bytes!` on large files, because the contents of those files are
now interned (hashed). This makes `include_bytes!` more similar to
`include_str!`, though `include_bytes!` contents still aren't escaped,
and hashing is still much cheaper than escaping.
