Add all remaining `DefKind`s.
r? @eddyb or @Centril
~~I'm not sure if this is what you were thinking of. There are also a few places where I'm not sure what the correct choice is because I don't fully understand the meaning of some variants.~~
~~In general, it feels a bit odd to add some of these as `DefKind`s (e.g. `Arm`) because they don't feel like definitions. Are there things that it makes sense not to add?~~
Entirely remove `DUMMY_HIR_ID`
Some helpers functions have been introduced to deal with (buggy) cases
where either a `NodeId` or a `DefId` do not have a corresponding `HirId`.
Those cases are tracked in issue #71104.
Some helpers functions have been introduced to deal with (buggy) cases
where either a `NodeId` or a `DefId` do not have a corresponding `HirId`.
Those cases are tracked in issue #71104.
Improve async-await/generator obligation errors in some cases
Fixes#68112.
This change is best read one commit at a time (I add a test at the beginning and update it in each change after).
The `test2` function is a case I found while writing the test that we don't handle with this code yet. I don't attempt to fix it in this PR, but it's a good candidate for future work.
r? @davidtwco, @nikomatsakis
Replace "rc"/"arc" lang items with Rc/Arc diagnostic items.
`Rc`/`Arc` should have no special semantics, so it seems appropriate for them to not be lang items.
r? @matthewjasper
Rename asm! to llvm_asm!
As per https://github.com/rust-lang/rfcs/pull/2843, this PR renames `asm!` to `llvm_asm!`. It also renames the compiler's internal `InlineAsm` data structures to `LlvmInlineAsm` in preparation for the new `asm!` functionality specified in https://github.com/rust-lang/rfcs/pull/2850.
This PR doesn't actually deprecate `asm!` yet, it just makes it redirect to `llvm_asm!`. This is necessary because we first need to update the submodules (in particular stdarch) to use `llvm_asm!`.
Decouple `rustc_hir::print` into `rustc_hir_pretty`
High level summary:
- The HIR pretty printer, `rustc_hir::print` is moved into a new crate `rustc_hir_pretty`.
- `rustc_ast_pretty` and `rustc_errors` are dropped as `rustc_hir` dependencies.
- The dependence on HIR pretty is generally reduced, leaving `rustc_save_analysis`, `rustdoc`, `rustc_metadata`, and `rustc_driver` as the remaining clients.
The main goal here is to reduce `rustc_hir`'s dependencies and its size such that it can start and finish earlier, thereby working towards https://github.com/rust-lang/rust/issues/65031.
r? @Zoxc
Tweak output for invalid negative impl errors
Follow up to #69722. Tweak negative impl errors emitted in the HIR:
```
error[E0192]: invalid negative impl
--> $DIR/E0192.rs:9:6
|
LL | impl !Trait for Foo { }
| ^^^^^^
|
= note: negative impls are only allowed for auto traits, like `Send` and `Sync`
```
Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
r? @Zoxc
resolve/hygiene: `macro_rules` are not "legacy"
The "modern" vs "legacy" naming was introduced by jseyfried during initial implementation of macros 2.0.
At this point it's clear that `macro_rules` are not going anywhere and won't be deprecated in the near future.
So this PR changes the naming "legacy" (when it implies "macro_rules") to "macro_rules".
This should also help people reading this code because it's wasn't obvious that "legacy" actually meant "macro_rules" in these contexts.
The most contentious renaming here is probably
```
fn modern -> fn normalize_to_macros_2_0
fn modern_and_legacy -> fn normalize_to_macro_rules
```
Other alternatives that I could think of are `normalize_to_opaque`/`normalize_to_semitransparent`, or `strip_non_opaque`/`strip_transparent`, but they seemed less intuitive.
The documentation to these functions can be found in `symbol.rs`.
r? @matthewjasper
Change "method" to "associated function"
r? @matthewjasper
cc @Centril @eddyb #67742
I'm opening this mostly as a test to see what the diagnostic changes would be. It seems that this makes them somewhat more verbose, and I'm not sure it's worth it...
The relevant changes are the last two commits (it is rebased on top of #67742)
