Remove `..` from return type notation
`@nikomatsakis` and I decided that using `..` in the return-type notation syntax is probably overkill.
r? `@eholk` since you reviewed the last one
Since this is piggybacking now totally off of a pre-existing syntax (parenthesized generics), let me know if you need any explanation of the logic here, since it's a bit more complicated now.
Avoid a few locks
We can use atomics or datastructures tuned for specific access patterns instead of locks. This may be an improvement for parallel rustc, but it's mostly a cleanup making various datastructures only usable in the way they are used right now (append data, never mutate), instead of having a general purpose lock.
Remove the `NodeId` of `ast::ExprKind::Async`
This is a followup to https://github.com/rust-lang/rust/pull/104833#pullrequestreview-1314537416.
In my original attempt, I was using `LoweringContext::expr`, which was not correct as it creates a fresh `DefId`.
It now uses the correct `DefId` for the wrapping `Expr`, and also makes forwarding `#[track_caller]` attributes more explicit.
Remove `box_syntax`
r? `@Nilstrieb`
This removes the feature `box_syntax`, which allows the use of `box <expr>` to create a Box, and finalises removing use of the feature from the compiler. `box_patterns` (allowing the use of `box <pat>` in a pattern) is unaffected.
It also removes `ast::ExprKind::Box` - the only way to create a 'box' expression now is with the rustc-internal `#[rustc_box]` attribute.
As a temporary measure to help users move away, `box <expr>` now parses the inner expression, and emits a `MachineApplicable` lint to replace it with `Box::new`
Closes#49733
Replace parse_[sth]_expr with parse_expr_[sth] function names
This resolves an inconsistency in naming style for functions on the parser, where:
* functions parsing specific kinds of items are named `parse_item_[sth]` and
* functions parsing specific kinds of *expressions* are named `parse_[sth]_expr`
favoring the style used by functions for items. There are multiple advantages of that style:
* functions of both categories are collected in the same place in the [rustdoc output](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html).
* it helps with autocompletion, as you can narrow down your search for a function to those about expressions.
* it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. `std::collections::hash_map::Entry`.
The disadvantage is that it doesn't "read like a sentence" any more. But I think the advantages weigh more greatly.
This change was mostly application of this command:
```
sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs
```
Plus very minor fixes outside of `rustc_parse`, and an invocation of `x fmt`.
