This allows lints and other diagnostics to refer to items
by a unique ID instead of relying on whacky path
resolution schemes that may break when items are
relocated.
resolve: Block expansion of a derive container until all its derives are resolved
So, it turns out there's one more reason to block expansion of a `#[derive]` container until all the derives inside it are resolved, beside `Copy` (https://github.com/rust-lang/rust/pull/63248).
The set of derive helper attributes registered by derives in the container also has to be known before the derives themselves are expanded, otherwise it may be too late (see https://github.com/rust-lang/rust/pull/63468#issuecomment-524550872 and the `#[stable_hasher]`-related test failures in https://github.com/rust-lang/rust/pull/63468).
So, we stop our attempts to unblock the container earlier, as soon as the `Copy` status is known, and just block until all its derives are resolved.
After all the derives are resolved we immediately go and process their helper attributes in the item, without delaying it until expansion of the individual derives.
Unblocks https://github.com/rust-lang/rust/pull/63468
r? @matthewjasper (as a reviewer of https://github.com/rust-lang/rust/pull/63248)
cc @c410-f3r
Resolve some small issues related to #63580
This resolves some feedback left on #63580 after it was merged:
- Adds documentation to `mir::Static` and `mir::StaticKind`
- Simplifies `maybe_get_optimized_mir()` and `maybe_get_promoted_mir()`
cc @bjorn3 @RalfJung
Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.
Serialize additional data for procedural macros
Split off from #62855
This PR serializes the declaration `Span` and attributes for all
procedural macros. This allows Rustdoc to properly render doc comments
and source links when performing inlinig procedural macros across crates
Split off from #62855
This PR deerializes the declaration `Span` and attributes for all
procedural macros from their underlying function definitions.
This allows Rustdoc to properly render doc comments
and source links when inlining procedural macros across crates
Most `Ident`s are serialized as `InternedString`s the exceptions are:
* Reexports
* Attributes
* Idents in macro definitions
Using gensyms helped reexports emulate hygiene. However, the actual item
wouldn't have a gensymmed name so would be usable cross-crate. So
removing this case until we have proper cross-crate hygiene seems
sensible.
Codegen attributes (`inline`, `export_name`) are resolved by their
`Symbol`. This meant that opaque macro-expanded codegen attributes could
cause linker errors. This prevented making built-in derives hygienic.
A couple of comment fixes.
This change fixes a couple of comments in the compiler code.
The first change was discussed with @eddyb. This one confused me because I thought only *public* defs were in the table (not so).
The second was a typo I noticed yesterday.
OK to go in?
Now that procedural macros no longer link transitively to libsyntax,
this shouldn't be needed any more! This commit is an experiment in
removing all dynamic libraries from rustc except for librustc_driver
itself. Let's see how far we can get with that!
The (almost) culmination of HirIdification
It's finally over.
This PR removes old `FIXME`s and renames some functions so that the `HirId` variant has the shorter name.
All that remains (and rightfully so) is stuff in `resolve`, `save_analysis` and (as far as I can tell) in a few places where we can't replace `NodeId` with `HirId`.
Implement another internal lints
cc #49509
This adds ~~two~~ one internal lint~~s~~:
1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc #59669
2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in #49509~~
~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~
TODO (not directly relevant for review):
- [ ] https://github.com/rust-lang/rust/pull/59316#discussion_r280186517 (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) 🤔 cc @eddyb)
- [x] https://github.com/rust-lang/rust/pull/61735#discussion_r292389870
- [x] Check explicitly for the `{declare,impl}_lint_pass!` macros
r? @oli-obk
