| Age | Commit message (Collapse) | Author | Lines |
|---|
|
self-profiling: Add events for metadata loading (plus a small dep-tracking optimization)
This PR
- adds self-profiling events related to loading things from crate metadata
- makes the compiler cache the `DepNodeIndex` of upstream crates, so that they don't have to be looked up over and over.
The commits are best reviewed in isolation.
Self-profiling tracking issue: https://github.com/rust-lang/rust/issues/58967
r? @Mark-Simulacrum
cc @wesleywiser
|
|
Improve message when attempting to instantiate tuple structs with private fields
Fixes #58017, fixes #39703.
```
error[E0603]: tuple struct `Error` is private
--> main.rs:22:16
|
2 | pub struct Error(usize, pub usize, usize);
| ----- ----- field is private
| |
| field is private
...
22 | let x = a::Error(3, 1, 2);
| ^^^^^
|
= note: a tuple struct constructor is private if any of its fields is private
```
|
|
|
|
|
|
and table lookups on each access of crate metadata.
|
|
|
|
metadata: Some crate loading cleanup
So, my goal was to fix caching of loaded crates which is broken and causes ICEs like #56935 or #64450.
While investigating I found that the code is pretty messy and likes to confuse various things that look similar but are actually different.
This PR does some initial cleanup in that area, I hope to get to the caching itself a bit later.
|
|
It duplicates `CrateRoot::name`
|
|
It was only used for retreiving edition, which was a bug.
In case of dual proc macros the edition should be taken from the target crate version, like any other metadata.
|
|
|
|
|
|
reserve `impl<T> From<!> for T`
this is necessary for never-type stabilization.
cc #57012 #35121
I think we wanted a crater run for this @nikomatsakis?
r? @nikomatsakis
|
|
Rustdoc render async function re-export
Closes #63710
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
This ensures that we match the order used by proc macro metadata
serialization.
Fixes #64251
|
|
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
|
|
|
|
Since both functions are always unwrapped, don't wrap the return value
in an `Option`.
|
|
Cleanup: Consistently use `Param` instead of `Arg` #62426
Fixes #62426
|
|
|
|
Fix caching of loaded proc macros
|
|
|
|
resolved
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
|
|
The implementations were wrong and unused.
|
|
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.
|
|
`Ident` has had a full span rather than just a `SyntaxContext` for a long time now.
|
|
For consistency with `ExpnId::root`.
Also introduce a helper `Span::with_root_ctxt` for creating spans with `SyntaxContext::root()` context
|
|
Cleanup syntax::attr
Mostly removing needless arguments to constructors
r? @petrochenkov
|
|
|
|
|
|
|
|
syntax: Factor out common fields from `SyntaxExtension` variants
And some other related cleanups.
Continuation of https://github.com/rust-lang/rust/pull/61606.
This will also help to unblock https://github.com/rust-lang/rust/pull/61877.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
