Check that a query has not completed and is not executing before starting it
This fixes a race in the query system where we only checked if the query was currently executing, but not if it was already completed, causing queries to re-execute.
r? `@cjgillot`
Ensure value is on the on-disk cache before returning from `ensure()`.
The current logic for `ensure()` a query just checks that the node is green in the dependency graph.
However, a lot of places use `ensure()` to prevent the query from being called later. This is the case before stealing a query result.
If the query is actually green but the value is not available in the on-disk cache, `ensure` would return, but a subsequent call to the full query would run the code, and attempt to read from a stolen value.
This PR conforms the query system to the usage by checking whether the queried value is loadable from disk before returning.
Sadly, I can't manage to craft a proper test...
Should fix all instances of "attempted to read from stolen value".
Rollup of 9 pull requests
Successful merges:
- #108726 (tidy: enforce comment blocks to have an even number of backticks)
- #108797 (Allow binary files to go through the `FileLoader`)
- #108841 (Add suggestion to diagnostic when user has array but trait wants slice. (rebased))
- #108984 (bootstrap: document tidy)
- #109013 (Give proper error message when tcx wasn't passed to decoder)
- #109017 (remove duplicated calls to sort_string)
- #109018 (Expand on the allocator comment in `rustc-main`)
- #109028 (Add eslint checks for rustdoc-js tester)
- #109034 (Commit some tests for the new solver + lazy norm)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Commit some tests for the new solver + lazy norm
Also consolidate `typeck/lazy-norm` into `traits/new-solver`, since it's not really useful to maintain a distinction, like when a test really is due to "lazy norm" or "the new solver" (usually both!)
Give proper error message when tcx wasn't passed to decoder
I hit this yesterday and found it very confusing, even though the solution to the problem is very simple.
bootstrap: document tidy
Enable documentation of tidy, as suggested in #106803. Jyn mentioned they should probably be added to `doc.rust-lang.org`, how should that be done?
Add suggestion to diagnostic when user has array but trait wants slice. (rebased)
Rebase of #91314, except for change to multipart suggestion
Resolves#90528
r? ``@compiler-errors`` since you requested the multipart suggestion
Allow binary files to go through the `FileLoader`
I'd like for `include_bytes!` to go through the `FileLoader` in an out-of-tree `rustc_driver` wrapper, and I can't find a reason it's not already done. It seems like most folks providing a custom `FileLoader` would want this too, so I added it.
I can solve my problem in other ways if there's a strong reason not to do it, but it seems simple and harmless.
tidy: enforce comment blocks to have an even number of backticks
After PR #108694, most unmatched backticks in `compiler/` comments have been eliminated. This PR adds a tidy lint to ensure no new unmatched backticks are added, and either addresses the lint in the remaining instances it found, or allows it.
Very often, backtick containing sections wrap around lines, for example:
```Rust
// This function takes a tuple `(Vec<String>,
// Box<[u8]>)` and transforms it into `Vec<u8>`.
```
The lint is implemented to work on top of blocks, counting each line with a `//` into a block, and counting if there are an odd or even number of backticks in the entire block, instead of looking at just a single line.
Avoid unnecessary hashing
I noticed some stable hashing being done in a non-incremental build. It turns out that some of this is necessary to compute the crate hash, but some of it is not. Removing the unnecessary hashing is a perf win.
r? `@cjgillot`
This approach depends on CSE to not have any branches or selects when the guessed offset is correct -- which it always will be right now -- but to also be *sound* (just less efficient) if the layout algorithms change such that the guess is incorrect.
Simplify message paths
This makes it easier to open the messages file. Right now I have to first click on the `locales` dir to open it, and then on the `en-US.ftl` file. `Cargo.toml` and `build.rs` files are also in the top level, and I think there should not be more than one file, so a directory isn't really needed. The [chosen strategy for pontoon adoption](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/pontoon.20and.20next.20steps) is out of tree. Even if this descision is changed in the future, the `messages.ftl` approach is also compatible with non-english translations living in-tree, as long as the non-english translations don't live in the `compiler/rustc_foo/` directories but in different ones. That would also be helpful for grepability purposes.
The commit was the result of automated changes:
```
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
```
r? `@davidtwco`
Instead of maintaining parallel buffers for both HTML and non-HTML output,
follow the idiom from the rest of format.rs that f.alternate() == true means
textual output. Also, add an argument to control line wrapping explicitly.
This allows the caller to render once with textual output and no line wrapping,
to decide whether line wrapping should be applied in the final HTML output.
Also, remove some format! and " ".repeat calls, and remove a dependency on
calling `String::replace` to switch from newlines to spaces.
This coincidentally fixes some minor bugs where the old code was undercounting
the number of characters for a declaration in text mode.
This makes it easier to open the messages file while developing on features.
The commit was the result of automatted changes:
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
Move dep graph methods to DepGraphData to avoid branches and `unwrap`s
This moves methods from `DepGraph` to `DepGraphData` which makes the code a bit cleaner since the dep graph is unconditionally available. It also changes `try_execute_query` to only branch on dep graph availability once, removing unnecessary branches and `unwrap`s.
This is based on https://github.com/rust-lang/rust/pull/108134 and https://github.com/rust-lang/rust/pull/108167.
Performance impact of just the last commit:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.7354s</td><td align="right">1.7242s</td><td align="right"> -0.64%</td></tr><tr><td>🟣 <b>clap</b>:check:initial</td><td align="right">2.0813s</td><td align="right">2.0687s</td><td align="right"> -0.61%</td></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.4554s</td><td align="right">0.4550s</td><td align="right"> -0.09%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2528s</td><td align="right">0.2521s</td><td align="right"> -0.27%</td></tr><tr><td>🟣 <b>hyper</b>:check:initial</td><td align="right">0.3222s</td><td align="right">0.3214s</td><td align="right"> -0.25%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.1339s</td><td align="right">0.1333s</td><td align="right"> -0.38%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9484s</td><td align="right">0.9455s</td><td align="right"> -0.30%</td></tr><tr><td>🟣 <b>regex</b>:check:initial</td><td align="right">1.1805s</td><td align="right">1.1727s</td><td align="right"> -0.66%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.3305s</td><td align="right">0.3307s</td><td align="right"> 0.08%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.5453s</td><td align="right">1.5374s</td><td align="right"> -0.51%</td></tr><tr><td>🟣 <b>syn</b>:check:initial</td><td align="right">1.9230s</td><td align="right">1.9206s</td><td align="right"> -0.12%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.6340s</td><td align="right">0.6333s</td><td align="right"> -0.11%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">5.8623s</td><td align="right">5.8536s</td><td align="right"> -0.15%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:initial</td><td align="right">7.2873s</td><td align="right">7.2786s</td><td align="right"> -0.12%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:unchanged</td><td align="right">1.8378s</td><td align="right">1.8478s</td><td align="right"> 0.54%</td></tr><tr><td>Total</td><td align="right">26.5300s</td><td align="right">26.4750s</td><td align="right"> -0.21%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9976s</td><td align="right"> -0.24%</td></tr></table>
r? `@cjgillot`
Unlike `Arc`, `Rc` doesn't have the same race condition to avoid, but
maintaining an equivalent API still makes it easier to work with both
`Rc` and `Arc`.
