Previously a `Symbol` was stored there, but this ended up causing hash
collisions in situations that otherwise shouldn't have a hash collision. Only
the symbol's string value was hashed, but it was possible for distinct symbols
to have the same string value, fooling various calcuations into thinking that
these paths *didn't* need disambiguating data when in fact they did!
By storing `InternedString` instead we're hopefully triggering all the exising
logic to disambiguate paths with same-name `Symbol` but actually distinct
locations.
This commit primarily removes the `stability` field from `TyCtxt` as well as its
internal mutable state, instead using a query to build the stability index as
well as primarily using queries for other related lookups.
Like previous commits the calculation of the stability index is wrapped in a
`with_ignore` node to avoid regressing the current tests, and otherwise this
commit also introduces #44232 but somewhat intentionally so.
This commit moves the calculation of the `LanguageItems` structure into a
query rather than being calculated before the `TyCtxt` exists, with the eventual
end goal of removing some `CrateStore` methods.
This commit started by moving methods from `CrateStore` to queries, but it ended
up necessitating some deeper refactorings to move more items in general to
queries.
Before this commit the *resolver* would walk over the AST and process foreign
modules (`extern { .. }` blocks) and collect `#[link]` annotations. It would
then also process the command line `-l` directives and such. This information
was then stored as precalculated lists in the `CrateStore` object for iterating
over later.
After this, commit, however, this pass no longer happens during resolution but
now instead happens through queries. A query for the linked libraries of a crate
will crawl the crate for `extern` blocks and then process the linkage
annotations at that time.
Compact display of static lib dependencies
Fixes#33173
Instead of displaying one dependency per line, I've changed the format to display them all in one line.
As a bonus they're in format of linker flags (`-lfoo`), so the output can be copy&pasted if one is actually going to link as suggested.
Profile queries
This PR implements the "profile queries" debugging feature described here:
https://github.com/rust-lang-nursery/rust-forge/blob/master/profile-queries.md
In particular, it implements the debugging flag `-Z profile-queries`
FYI: This PR is my second attempt at pushing these changes. My original PR required a rebase; I have now done that rebase manually, after messing up with git's "interactive" rebase support. The original (now closed/cancelled) PR is this one: https://github.com/rust-lang/rust/issues/43156
r? @nikomatsakis
This feature allows targets to opt in to full support of the crt-static
feature. Currently, crt-static is allowed on all targets, even those
that really can't or really shouldn't support it. This works because it
is very loose in the specification of its effects. Changing the behavior
of crt-static to be more strict in how it chooses libraries and links
executables would likely cause compilation to fail on these platforms.
To avoid breaking existing uses of crt-static, whitelist targets that
support the new, stricter behavior. For all other targets, this changes
crt-static from being "mostly a no-op" to "explicitly a no-op".
Added two fixmes: The `SimplifyBranches` pass cannot stay where it is,
and `BorrowckMir` should be a query, not a pass. But I am going to
leave those changes to a future PR.
One can either use `-Z borrowck-mir` or add the `#[rustc_mir_borrowck]` attribute
to opt into MIR based borrow checking.
Note that regardless of whether one opts in or not, AST-based borrow
check will still run as well. The errors emitted from AST-based
borrow check will include a "(Ast)" suffix in their error message,
while the errors emitted from MIR-based borrow check will include a
"(Mir)" suffix.
post-rebase: removed check for intra-statement mutual conflict;
replaced with assertion checking that at most one borrow is generated
per statement.
post-rebase: removed dead code: `IdxSet::pairs` and supporting stuff.
Use hir::ItemLocalId as keys in TypeckTables.
This PR makes `TypeckTables` use `ItemLocalId` instead of `NodeId` as key. This is needed for incremental compilation -- for stable hashing and for being able to persist and reload these tables. The PR implements the most important part of https://github.com/rust-lang/rust/issues/40303.
Some notes on the implementation:
* The PR adds the `HirId` to HIR nodes where needed (`Expr`, `Local`, `Block`, `Pat`) which obviates the need to store a `NodeId -> HirId` mapping in crate metadata. Thanks @eddyb for the suggestion! In the future the `HirId` should completely replace the `NodeId` in HIR nodes.
* Before something is read or stored in one of the various `TypeckTables` subtables, the entry's key is validated via the new `TypeckTables::validate_hir_id()` method. This makes sure that we are not mixing information from different items in a single table.
That last part could be made a bit nicer by either (a) new-typing the table-key and making `validate_hir_id()` the only way to convert a `HirId` to the new-typed key, or (b) just encapsulate sub-table access a little better. This PR, however, contents itself with not making things significantly worse.
Also, there's quite a bit of switching around between `NodeId`, `HirId`, and `DefIndex`. These conversions are cheap except for `HirId -> NodeId`, so if the valued reviewer finds such an instance in a performance critical place, please let me know.
Ideally we convert more and more code from `NodeId` to `HirId` in the future so that there are no more `NodeId`s after HIR lowering anywhere. Then the amount of switching should be minimal again.
r? @eddyb, maybe?
Cleanup for "Support compiling rustc without LLVM (try 2)"
This includes a small patch to allow running tests without llvm. Also check if you are not trying to compile a dylib.
cc #42932
r? @alexcrichton
