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
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.
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`
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`
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`
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.
Make `unused_allocation` lint against `Box::new` too
Previously it only linted against `box` syntax, which likely won't ever be stabilized, which is pretty useless. Even now I'm not sure if it's a meaningful lint, but it's at least something 🤷
This means that code like the following will be linted against:
```rust
Box::new([1, 2, 3]).len();
f(&Box::new(1)); // where f : &i32 -> ()
```
The lint works by checking if a `Box::new` (or `box`) expression has an a borrow adjustment, meaning that the code that first stores the box in a variable won't be linted against:
```rust
let boxed = Box::new([1, 2, 3]); // no lint
boxed.len();
```
Before, it said "global_allocator does nothing". Now it gives you
suggestions for what to do if you want to change the global allocator
(which is likely the main reason you'd be reading the comment).
Directly construct Inherited in typeck.
Using `InheritedBuilder` + a closure does not seem necessary any more.
+ a few opportunistic simplifications to typeck entry point.
Honor current target when checking conditional compilation values
This is fixed by simply using the currently registered target in the current session. We need to use it because of target json that are not by design included in the rustc list of targets.
Fixes https://github.com/rust-lang/rust/issues/108941
Add note when matching token with nonterminal
The current error message is _really_ confusing. The implementation is slightly hacky, but not that much more hacky than all this nonterminal stuff..
r? ``@petrochenkov``
Rollup of 9 pull requests
Successful merges:
- #106921 (Add documentation about the memory layout of `Cell`)
- #108828 (Emit alias-eq when equating numeric var and projection)
- #108834 (Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type)
- #108900 (fix(lexer): print whitespace warning for \x0c)
- #108930 (feat: implement better error for manual impl of `Fn*` traits)
- #108937 (improve readability of winnowing)
- #108947 (Don't even try to combine consts with incompatible types)
- #108976 (Update triagebot rust-analyzer team mention)
- #108983 (Forbid `#[target_feature]` on safe default implementations)
Failed merges:
- #108950 (Directly construct Inherited in typeck.)
r? `@ghost`
`@rustbot` modify labels: rollup
Add more license annotations
This PR updates the `.reuse/dep5` file to include more accurate licensing data for everything in the repository (*excluding* submodules and dependencies). Some decisions were made in this PR:
* The standard copyright attribution for files maintained by us is "The Rust Project Developers (see https://thanks.rust-lang.org)", to avoid having to maintain an in-tree `AUTHORS` file.
* For files that have specific licensing terms, we added the terms to the `.reuse/dep5` rather than adding SPDX comments in the files themselves.
* REUSE picks up any comment/text line with `Copyright` on it, so I had to sprinkle around `REUSE-IgnoreStart` and `REUSE-IgnoreEnd` comments.
The rendered `COPYRIGHT` file is available at https://gist.github.com/pietroalbini/efb81103f69596d39758114f3f6a8688.
r? `@pnkfelix`
Remove an extraneous include
SymbolWrapper.cpp doesn't use std::optional or llvm::Optional, so this patch removes the extraneous include. Note that llvm/ADT/Optional.h has been deprecated upstream. This patch ensures that SymbolWrapper.cpp continues to compile even after the upcoming removal of Optional.h.
Add `--no-undefined-version` link flag and fix associated breakage
LLVM upstream sets `--no-undefined-version` by default in lld: https://reviews.llvm.org/D135402.
Due to a bug in how version scripts are generated, this breaks the `dylib` output type for most crates. See https://github.com/rust-lang/rust/issues/105967#issuecomment-1428671533 for details.
This PR adds the flag to gcc flavor linkers in anticipation of this LLVM change rolling in, and patches `rustc` to not attempt to export `__rust_*` allocator symbols when they weren't generated.
Fixes#105967
Stabilize movbe target feature
Almost all "old" x86 target features are stable. As far as I can tell, these are the last two unstable features in the `x86-64-v2` or `x86-64-v3` microarchitecture levels, so I'm not sure if it was an oversight or if they're still unstable for a reason (see #106323 for `f16c`).
Note that this only stabilizes the target features, and not the intrinsics.
cc ```@Amanieu```
r? ```@rust-lang/lang```
Relax ordering rules for `asm!` operands
The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order:
- Template strings
- Positional operands
- Named operands
- Explicit register operands
- `clobber_abi`
- `options`
This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows:
- Template strings must still come before all other operands.
- Positional operands must still come before named and explicit register operands.
- Named and explicit register operands can be freely mixed.
- `options` and `clobber_abi` can appear in any position after the template strings.
r? ```````@joshtriplett```````
Don't even try to combine consts with incompatible types
~I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a `ConstArgHasType` predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.~
1. Use the `type_of` for a parameter in `try_eval_lit_or_param`, instead of the "expected" type from a `WithOptConstParam` def id.
2. Don't combine consts that have incompatible types.
Fixes#108781
feat: implement better error for manual impl of `Fn*` traits
Fixes#39259
cc `@estebank` (you gave me some advice in the linked issue, would you like to review?)
