No StableHasherResult everywhere
This removes the generic parameter on `StableHasher`, instead moving it to the call to `finish`. This has the side-effect of making all `HashStable` impls nicer, since we no longer need the verbose `<W: StableHasherResult>` that previously existed -- often forcing line wrapping.
This is done for two reasons:
* we should avoid false "generic" dependency on the result of StableHasher
* we don't need to codegen two/three copies of all the HashStable impls when they're transitively used to produce a fingerprint, u64, or u128. I haven't measured, but this might actually make our artifacts somewhat smaller too.
* Easier to understand/read/write code -- the result of the stable hasher is irrelevant when writing a hash impl.
added more context for duplicate lang item errors (fixes#60561)
Some more information about #60561 -- these errors are pretty common when one works in restrictive environments with `no_std` or customized `std`, but they don't provide much context for debugging, as any transitive dependency could have brought in `std` crate. With that, currently, one needs to use something like `cargo tree` and investigate transitive dependencies one by one.
It'll be more helpful to know at least the crate that uses `std` (which `cargo tree` doesn't show) to pin down this investigation when debugging.
I'm not sure what the best way to get this context is inside rustc internals (I'm new to them). I found that `all_crate_nums` query returns the crates in some dependency order, so printing out the name of the preceding crate seems to do the trick. But I welcome suggestions if this can be done in a better way.
Where possible, the error message includes the name of the crate
that brought in the crate with duplicate lang items (which
helps with debugging). This information is passed on from cstore
using the `extern_crate` query.
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
This commit addresses #64319 by removing the `dylib` crate type from the
list of crate type that exports generic symbols. The bug in #64319
arises because a `dylib` crate type was trying to export a symbol in an
uptream crate but it miscalculated the symbol name of the uptream
symbol. This isn't really necessary, though, since `dylib` crates aren't
that heavily used, so we can just conservatively say that the `dylib`
crate type never exports generic symbols, forcibly removing them from
the exported symbol lists if were to otherwise find them.
The fix here happens in two places:
* First is in the `local_crate_exports_generics` method, indicating that
it's now `false` for the `Dylib` crate type. Only rlibs actually
export generics at this point.
* Next is when we load exported symbols from upstream crate. If, for our
compilation session, the crate may be included from a dynamic library,
then its generic symbols are removed. When the crate was linked into a
dynamic library its symbols weren't exported, so we can't consider
them a candidate to link against.
Overally this should avoid situations where we incorrectly calculate the
upstream symbol names in the face of differnet `share_generics` options,
ultimately...
Closes#64319
This commit converts a field of `Session`, `dependency_formats`, into a
query of `TyCtxt`. This information then also needed to be threaded
through to other remaining portions of the linker, but it's relatively
straightforward. The only change here is that instead of
`HashMap<CrateType, T>` the data structure changed to `Vec<(CrateType,
T)>` to make it easier to deal with in queries.
Avoid more `Symbol`-to-string operations
These commits avoid various `Symbol`-to-string conversions, by doing more operations directly on `Symbol`s. This requires adding a few more static `Symbol`s to the binary.
r? @petrochenkov
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
