Add suggestions when encountering chained comparisons
Ideally, we'd also prevent the type error, which is just extra noise, but that will require moving the error from the parser, and I think the suggestion makes things clear enough for now.
Fixes https://github.com/rust-lang/rust/issues/65659.
parser: reduce diversity in error handling mechanisms
Instead of having e.g. `span_err`, `fatal`, etc., we prefer to move towards uniformly using `struct_span_err` thus making it harder to emit fatal and/or unstructured diagnostics.
This PR also de-fatalizes some diagnostics.
r? @estebank
Refactor type & bounds parsing thoroughly
PR is based on https://github.com/rust-lang/rust/pull/67131 with first one from this PR being ` extract parse_ty_tuple_or_parens`.
Also fixes#67146.
r? @estebank
Make GATs less ICE-prone.
After this PR simple lifetime-generic associated types can now be used in a compiling program. There are two big limitations:
* #30472 has not been addressed in any way (see src/test/ui/generic-associated-types/iterable.rs)
* Using type- and const-generic associated types errors because bound types and constants aren't handled by trait solving.
* The errors are technically non-fatal, but they happen in a [part of the compiler](4abb0ad273/src/librustc_typeck/lib.rs (L298)) that fairly aggressively stops compiling on errors.
closes#47206closes#49362closes#62521closes#63300closes#64755closes#67089
* Make some run-pass or check-pass
* Use `#![allow(incomplete_features)]`
* Update FIXMEs now that some of the issues have been addressed
* Add regression tests
Merge `TraitItem` & `ImplItem into `AssocItem`
In this PR we:
- Merge `{Trait,Impl}Item{Kind?}` into `AssocItem{Kind?}` as discussed in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286.
- This is done by using the cover grammar of both forms.
- In particular, it requires that we syntactically allow (under `#[cfg(FALSE)]`):
- `default`ness on `trait` items,
- `impl` items without a body / definition (`const`, `type`, and `fn`),
- and associated `type`s in `impl`s with bounds, e.g., `type Foo: Ord;`.
- The syntactic restrictions are replaced by semantic ones in `ast_validation`.
- Move syntactic restrictions around C-variadic parameters from the parser into `ast_validation`:
- `fn`s in all contexts now syntactically allow `...`,
- `...` can occur anywhere in the list syntactically (`fn foo(..., x: usize) {}`),
- and `...` can be the sole parameter (`fn foo(...) {}`.
r? @petrochenkov
Refactor `parse_enum_item` to use `parse_delim_comma_seq`
Followup after https://github.com/rust-lang/rust/pull/66641
Some errors got more verbose but I think they make sense with the help message.
Rework raw ident suggestions
Use heuristics to determine whethersuggesting raw identifiers is
appropriate.
Account for raw identifiers when printing a path in a `use` suggestion.
Fix#66126.
