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`
I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`.
Turned out to be a more general problem as `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist.
This PR lowers `ptr::read(p)` to `copy *p` in MIR, which fortuitiously also improves the IR we give to LLVM for things like `mem::replace`.
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.
Implement round_ties_even
For tests, I just copied over the standard library's tests for this feature. It looks like the library uses an approximate equality check for most/all float tests, and I've replaced that check with our float equality check pattern.
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`.
Some comments may be formed like:
// This function takes a tuple `(Vec<String>,
// Box<[u8]>)` and transforms it into `Vec<u8>`.
where the "back-ticked" section wraps around.
Therefore, we can't make a single-line based
lint.
We also cannot make the lint paragraph based,
as it would otherwise complain about inline
code blocks:
/// ```
/// use super::Foo;
///
/// fn main() { Foo::new(); }
/// ```
For the future, one could introduce some checks
to treat code blocks specially, but such code
would make the check even more complicated.
Rollup of 9 pull requests
Successful merges:
- #104363 (Make `unused_allocation` lint against `Box::new` too)
- #106633 (Stabilize `nonzero_min_max`)
- #106844 (allow negative numeric literals in `concat!`)
- #108071 (Implement goal caching with the new solver)
- #108542 (Force parentheses around `match` expression in binary expression)
- #108690 (Place size limits on query keys and values)
- #108708 (Prevent overflow through Arc::downgrade)
- #108739 (Prevent the `start_bx` basic block in codegen from having two `Builder`s at the same time)
- #108806 (Querify register_tools and post-expansion early lints)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Querify register_tools and post-expansion early lints
The 2 extra queries correspond to code that happen before and after macro expansion, and don't need the resolver to exist.
Prevent the `start_bx` basic block in codegen from having two `Builder`s at the same time
Here, at the same time, there are two `start_llbb` builder, this should be unexpected.
Place size limits on query keys and values
This just prevents these from growing accidentally too large. I'm not sure if there's an easy way to also print the actual size too.
Implement goal caching with the new solver
Maybe it's wrong, idk. Opening mostly for first impressions before I go to sleep.
r? ``@lcnr,`` cc ``@cjgillot``
allow negative numeric literals in `concat!`
Fixes#106837
While *technically* negative numeric literals are implemented as unary operations, users can reasonably expect that negative literals are treated the same as positive literals.
