Revert `QueryStackFrame` split
PR rust-lang/rust#138672 fixed a query cycle OOM reported in rust-lang/rust#124901. The fix involved delaying computation of some query stack frame elements and was very complex. It involved the addition of two new types, the addition of a generic `I` parameter to eleven(!) other types, a `PhantomData` field, and even required an unsafe transmute of a closure. [This comment](https://github.com/rust-lang/rust/issues/124901#issuecomment-2104852065) had suggested a much simpler fix, but it was ignored. The PR also failed to add a test case.
This PR adds a test case, reverts the complex fix, applies the simpler fix, and does a few other minor cleanups.
r? @oli-obk
PR #138672 introduced a complex and invasive split of `QueryStackFrame`
to avoid a query cycle. This commit reverts that change because there is
a much simpler change that fixes the problem, which will be in the next
commit.
Also hash spans inside the same file as relative (V2)
Hashes spans relatively to their parent, even if they are not contained inside their parent.
Fixes https://github.com/rust-lang/rust/issues/150400
Closes https://github.com/rust-lang/rust/pull/143882, as this is a successor PR
This PR is very closely based on that PR with a few minor changes, so to give proper credit I made @cjgillot coauthor of the commit.
Add `unnormalized_source_len` field to track the byte length
of source files before normalization (the original length).
`unnormalized_source_len` is for writing the correct file length
to dep-info for `-Zchecksum-hash-algorithm`
Reword unstable fingerprints ICE to ask for reproduction
When the unstable fingerprints error was added, Rust was on fire, and we needed a quick way for people to sort of understand what's going on, follow the tracking issue, and leave some information without overwhelming the issue tracker and focusing on getting their code working.
This is what motivated the previous message. It called this a "known issue", provided help on how to fix it, and only secondarily asked for a bug report.
This is no longer true. These days incremental compilation is fairly solid and these issues are supposed to be rare, we expect *none* of them to exist (but obviously know that's not true). As such, it's time to reword this message.
Recently someone mentioned how they didn't bother reporting this issue because it said that it was a "known issue", and I only got awareness of their problem because they complained about all the rustc-ice files hanging around their directories (https://github.com/rust-lang/rust/issues/147825#issuecomment-3417297842). This is not at all what we want, we want reports from people, ideally with a reproduction.
To get this, I reworded the error. It now explicitly asks for a reproduction (and explaining what that means) and no longer calls it a "known issue". It also does not link to the tracking issue anymore, because I don't think this tracking issue is useful. It should probably be closed.
I still mention the workaround, but explicitly call it a "workaround". People should report a reproduction and only *then* use the workaround.
When the unstable finterprint error was added, Rust was on fire, and we
needed a quick way for people to sort of understand what's going on,
follow the tracking issue, and leave some information without
overwhelming the issue tracker and focusing on getting their code
working.
This is what motivated the previous message. It called this a "known
issue", provided help on how to fix it, and only secondarily asked for a
bug report.
This is no longer true. These days incremental compilation is fairly
solid and these issues are supposed to be rare, we expect *none* of them
to exist (but obviously know that's not true). As such, it's time to
reword this message.
Recently someone mentioned how they didn't bother reporting this issue
because it said that it was a "known issue", and I only got awareness of
their problem because they complained about all the rustc-ice files
hanging around their directories. This is not at all what we want, we
want reports from people, ideally with a reproduction.
To get this, I reworded the error. It now explicitly asks for a
reproduction (and explaining what that means) and no longer calls it a
"known issue". It also does not link to the tracking issue anymore,
because I don't think this tracking issue is useful. It should probably
be closed.
I still mention the workaround, but explicitly call it a "workaround".
People should report a reproduction and only *then* use the workaround.
Prefer to use repeat_n over repeat().take()
More from https://github.com/rust-lang/rust/pull/147464, but batch processed with `ast-grep` to find and replace.
second commit add notes for library: affaf532f9
r? ``@RalfJung``
`INLINE_CAPACITY` has two different uses:
- It dictates the inline capacity of `EdgesVec::edges`, which is a
`SmallVec`.
- It dictates when `TaskDeps` switches from a linear scan lookup to a
hashset lookup to determine if an edge has been seen before.
These two uses are in the same part of the code, but they're
fundamentally separate and don't need to use the same constant.
This commit separates the two uses, and adds some helpful comments,
making the code clearer. It also changes the value used for the
linear/hashset threshold from 8 to 16, which gives slightly better perf.
There are only two places that create a `TaskDeps`. One constructs it
manually, the other uses `default`. It's weird that `default()` uses a
capacity of 128.
This commit just gets rid of `default` and introduces `new` so that
both construction sites can be equivalent.
It uses a different implementation depending on whether the compiler
front-end is running single-threaded or multi-threaded. The two
implementations are equivalent and I think the multi-threaded one
expresses the intent more clearly, and I imagine the perf is similar. So
this commit removes the single-threaded code.
The most common `get` case is green. This commit changes `get` to use
use `if`/`else` instead of match, so that getting green requires one
comparison instead of two.
Currently it's binary, either `Green` or `Red`. But it's almost always
used within an `Option`. So it's a bit neater, and possibly slightly
faster, to make it tri-value with `Unknown` as a first-class variant.
a more general version of https://github.com/rust-lang/rust/pull/146080.
after a bit of hacking in [`fluent.rs`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_fluent_macro/src/fluent.rs), i discovered that i'm not the only one that is bad at following guidelines 😅. this pr lowercases the first letter of all the error messages in the codebase.
(i did not change things that are traditionally uppercased such as _MIR_, _ABI_ or _C_)
i think it's reasonable to run a `@bors try` so all the test suite is checked, as i cannot run some of the tests on my machine. i double checked (and replaced manually) all the old error messages, but better be safe than sorry.
in the future i will try to add a check in `x test tidy` that errors if an error message starts with an uppercase letter.
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
Bringing `rustc_rayon_core` in tree as `rustc_thread_pool`
This PR moves [`rustc_rayon_core`](5fadf44/rayon-core) from commit `5fadf44` as suggested in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Bringing.20.60rustc_rayon_core.60.20in.20tree). I tried to split the work into separate commits so it is easy to review. The first commit is a simple copy and paste from the fork, and subsequent changes were made to use the new crate and to ensure the new crate complies with different format and lint expectations.
**Call-out:** I was also wondering if I need to make any further changes to accommodate licensing requirements.
r? oli-obk
Use thread local dep graph encoding
This adds thread local encoding of dep graph nodes. Each thread has a `MemEncoder` that gets flushed to the global `FileEncoder` when it exceeds 64 kB. Each thread also has a local cache of dep indices. This means there can now be empty gaps in `SerializedDepGraph`.
Indices are marked green and also allocated by the new atomic operation `DepNodeColorMap::try_mark_green` as the encoder lock is removed.
