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.
`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.
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.
Allow out of order dep graph node encoding
This allows out of order dep graph node encoding by also encoding the index instead of using the file node order as the index.
`MemEncoder` is also brought back to life and used for encoding.
Both of these are done to enable thread-local encoding of dep graph nodes.
This is based on https://github.com/rust-lang/rust/pull/139636.
Daria Sukhonina