Don't leak sysroot crates through dependencies
Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates.
Should fix https://github.com/rust-lang/rust/issues/147966
There are two rustc_hash crates in the sysroot when building miri and
there is no way to disambiguate between the two. Instead use the
re-exports of it in the rustc_data_structures crate.
Add `Steal::risky_hack_borrow_mut`
I'm working on a rustc driver (Creusot) which needs to modify the MIR read by two queries, `mir_borrowck` and `check_liveness`, in different ways for each query. Both of these queries use `mir_promoted` to read the MIR, which is immutable (until it is stolen).
This adds an escape hatch so rustc drivers can mutate MIR for specific queries. And this removes `get_mut` which is unused and also unusable now that there's no way to get a `&mut Steal` from the rustc API.
Another approach may be to override the queries to modify the MIR after having read it from `mir_promoted`. However the implementation of queries is largely hidden, so I can't just copy their code to then modify it. A solution would be to parameterize the queries with callbacks which get instantiated with `mir_promoted` by default, but that seems more involved and ad hoc. That's why I'm proposing this smaller change instead.
It's common to import dependencies from the sysroot via `extern crate`
rather than use an explicit cargo dependency, when it's necessary to use
the same dependency version as used by rustc itself. However, this is
dangerous for crates.io crates, since rustc may not pull in the
dependency on some targets, or may pull in multiple versions. In both
cases, the `extern crate` fails to resolve.
To address this, re-export all such dependencies from the appropriate
`rustc_*` crates, and use this alias from crates which would otherwise
need to use `extern crate`.
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
Add new self-profiling event to cheaply aggregate query cache hit counts
Self-profile can record various types of things, some of them are not enabled, like query cache hits. Rustc currently records cache hits as "instant" measureme events, which records the thread ID, current timestamp, and constructs an individual event for each such cache hit. This is incredibly expensive, in a small hello world benchmark that just depends on serde, it makes compilation with nightly go from ~3s (with `-Zself-profile`) to ~15s (with `-Zself-profile -Zself-profile-events=default,query-cache-hit`).
We'd like to add query cache hits to rustc-perf (https://github.com/rust-lang/rustc-perf/pull/2168), but there we only need the actualy cache hit counts, not the timestamp/thread ID metadata associated with it.
This PR adds a new `query-cache-hit-count` event. Instead of generating individual instant events, it simply aggregates cache hit counts per *query invocation* (so a combination of a query and its arguments, if I understand it correctly) using an atomic counter. At the end of the compilation session, these counts are then dumped to the self-profile log using integer events (in a similar fashion as how we record artifact sizes). I suppose that we could dedup the query invocations in rustc directly, but I don't think it's really required. In local experiments with the hello world + serde case, the query invocation records generated ~30 KiB more data in the self-profile, which was ~10% increase in this case.
With this PR, the overhead of `-Zself-profile` seems to be the same as before, at least on my machine, so I also enabled query cache hit counts by default when self profiling is enabled.
We should also modify `analyzeme`, specifically [this](https://github.com/rust-lang/measureme/blob/master/analyzeme/src/analysis.rs#L139), and make it load the integer events with query cache hit counts. I can do that as a follow-up, it's not required to be done in sync with this PR, and it doesn't require changes in rustc.
CC `@cjgillot`
r? `@oli-obk`
bors
Andrew Zhogin
bendn
bjorn3
Stuart Cook
Zachary S
Li-yao Xia
Matthias Krüger
Diggory Blake
zhetaicheleba
Ralf Jung
lcnr
Camille Gillot
Jakub Beránek
Scott McMurray
Jana Dönszelmann
klensy
Josh Stone