Let qpath contain NtTy: `<$:ty as $:ty>::…`
Example:
```rust
macro_rules! m {
(<$type:ty as $trait:ty>::$name:ident) => {
<$type as $trait>::$name
};
}
fn main() {
let _: m!(<str as ToOwned>::Owned);
}
```
Previous behavior:
```console
error: expected identifier, found `ToOwned`
--> src/main.rs:3:19
|
3 | <$type as $trait>::$name
| ^^^^^^ expected identifier
...
8 | let _: m!(<str as ToOwned>::Owned);
| ---------------------------
| |
| this macro call doesn't expand to a type
| in this macro invocation
```
The <code>expected identifier, found \`ToOwned\`</code> error is particularly silly. I think it should be fine to accept this code as long as $trait is of the form `TyKind::Path(None, path)`; if it is any other kind of `NtTy`, we'll keep the same behavior as before.
ProjectionPredicate should be able to handle both associated types and consts so this adds the
first step of that. It mainly just pipes types all the way down, not entirely sure how to handle
consts, but hopefully that'll come with time.
check_mistyped_turbofish_with_multiple_type_params was previously
expecting type arguments between angle brackets, which is not right, as
we can also see const expressions. We now use generic argument parser
instead of type parser.
Test with one, two, and three generic arguments added to check
consistentcy between
1. check_no_chained_comparison: Called after parsing a nested binop
application like `x < A > ...` where angle brackets are interpreted as
binary operators and `A` is an expression.
2. check_mistyped_turbofish_with_multiple_type_params: called by
`parse_full_stmt` when we expect to see a semicolon after parsing an
expression but don't see it.
(In `T2<1, 2>::C;`, the expression is `T2 < 1`)
- Adds optional default values to const generic parameters in the AST
and HIR
- Parses these optional default values
- Adds a `const_generics_defaults` feature gate
Takayuki Maeda