Move THIR printing to rustc_mir_build.
https://github.com/rust-lang/rust/pull/107451 increased the compilation time of `rustc_middle` by 10% = 3s.
As https://github.com/rust-lang/rust/pull/107006 adds quite a lot of code to rustc_middle, I suspect it to be the cause.
This PR moves the THIR printing code to `rustc_mir_build`, where the query provider lives, in order to benefit from higher parallelism when compiling rustc.
MIR-Validate StorageLive.
`StorageLive` statements on a local which already has storage is banned by miri.
This check is easy enough, and can detect bugs in MIR opts.
Unify validity checks into a single query
Previously, there were two queries to check whether a type allows the 0x01 or zeroed bitpattern.
I am planning on adding a further initness to check in #100423, truly uninit for MaybeUninit, which would make this three queries. This seems overkill for such a small feature, so this PR unifies them into one.
I am not entirely happy with the naming and key type and open for improvements.
r? oli-obk
Don't project specializable RPITIT projection
This effective rejects specialization + RPITIT/AFIT (usages of `impl Trait` in traits) because the implementation is significantly complicated over making regular "default" trait method bodies work.
I have another PR that experimentally fixes all this, but the code may not be worth investing in.
Emit the enum discriminant separately for the Encodable macro
This changes the `Encodable` proc macro to first emit the discriminant with a separate `match` statement, then emit the fields. LLVM can optimize down the first `match` to just a read of the enum discriminant. This avoids generating a `emit_usize` call per variant and enums with no fields now optimize down to just a single `emit_usize` call.
The no variant case is special cased to avoid warnings about unreachable code.
<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:unchanged</td><td align="right">0.4676s</td><td align="right">0.4640s</td><td align="right"> -0.78%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.1348s</td><td align="right">0.1338s</td><td align="right"> -0.75%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.3370s</td><td align="right">0.3352s</td><td align="right"> -0.54%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.6326s</td><td align="right">0.6281s</td><td align="right"> -0.71%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:unchanged</td><td align="right">1.8561s</td><td align="right">1.8589s</td><td align="right"> 0.15%</td></tr><tr><td>Total</td><td align="right">3.4282s</td><td align="right">3.4200s</td><td align="right"> -0.24%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9947s</td><td align="right"> -0.53%</td></tr></table>
Upgrade to ena-0.14.1.
It avoids some inlining within its `inlined_probe_value` function, which seems to result in better codegen for the very large `process_obligations` function within rustc. It might also help with reducing the bimodal perf results we see for the `keccak` and `cranelift-codegen-0.82.1` benchmarks.
r? `@ghost`
Remove `from` lang item
It was probably a leftover from the old `?` desugaring but anyways, it's unused now except for clippy, which can just use a diagnostics item.
statically guarantee that current error codes are documented
Closes#61137 (that's right!)
Pretty simple refactor (often just a change from `Result<Option<&str>>` to `Result<&str>`)
r? `@GuillaumeGomez` (could you specially look at 53044158eff0d64673a6100f701c57b484232aca? I believe you wrote that in the first place, just want to make sure you're happy with the change)
rustc_infer: Consolidate obligation elaboration de-duplication
# Explanation
The obligations `Elaborator` is doing de-duplication of obligations in 3 different locations. 1 off which has a comment.
This PR consolidates the functionality and comment to a single function.
Replace parse_[sth]_expr with parse_expr_[sth] function names
This resolves an inconsistency in naming style for functions on the parser, where:
* functions parsing specific kinds of items are named `parse_item_[sth]` and
* functions parsing specific kinds of *expressions* are named `parse_[sth]_expr`
favoring the style used by functions for items. There are multiple advantages of that style:
* functions of both categories are collected in the same place in the [rustdoc output](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html).
* it helps with autocompletion, as you can narrow down your search for a function to those about expressions.
* it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. `std::collections::hash_map::Entry`.
The disadvantage is that it doesn't "read like a sentence" any more. But I think the advantages weigh more greatly.
This change was mostly application of this command:
```
sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs
```
Plus very minor fixes outside of `rustc_parse`, and an invocation of `x fmt`.
Add `ErrorGuaranteed` to `hir::{Expr,Ty}Kind::Err` variants
First step in making the `Err` variants of `ExprKind` and `TyKind` require an `ErrorGuaranteed` during parsing. Making the corresponding AST versions require `ErrorGuaranteed` is a bit harder, whereas it was pretty easy to do this for HIR, so let's do that first.
The only weird thing about this PR is that `ErrorGuaranteed` is moved to `rustc_span`. This is *certainly* not the right place to put it, but `rustc_hir` cannot depend on `rustc_error` because the latter already depends on the former. Should I just pull out some of the error machinery from `rustc_error` into an even more minimal crate that `rustc_hir` can depend on? Advice would be appreciated.
Treat `str` as containing `[u8]` for auto trait purposes
Wanted to gauge ``@rust-lang/lang`` and ``@rust-lang/types`` teams' thoughts on treating `str` as "containing" a `[u8]` slice for auto-trait purposes.
``@dtolnay`` brought this up in https://github.com/rust-lang/rust/issues/13231#issuecomment-1399386472 as a blocker for future `str` type librarification, and I think it's both a valid concern and very easy to fix. I'm interested in actually doing that `str` type librarification (#107939), but this probably should be considered in the mean time regardless of that PR.
r? types for the impl, though this definitely needs an FCP.
Rollup of 8 pull requests
Successful merges:
- #107062 (Do some cleanup of doc/index.md)
- #107890 (Lint against `Iterator::map` receiving a callable that returns `()`)
- #108431 (Add regression test for #107918)
- #108432 (test: drop unused deps)
- #108436 (make "proc macro panicked" translatable)
- #108444 (docs/test: add UI test and docs for `E0476`)
- #108449 (Do not lint ineffective unstable trait impl for unresolved trait)
- #108456 (Complete migrating `ast_passes` to derive diagnostics)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
docs/test: add UI test and docs for `E0476`
Final undocumented error code. Not entirely sure about wording in the docs.
Part of https://github.com/rust-lang/rust/issues/61137.
r? ```@compiler-errors```
cc ```@compiler-errors```
Implement -Zlink-directives=yes/no
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives.
This is another way to address issue # #70093, which is currently addressed by `-Zlink-native-libraries` (implemented in #70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used.
Being able to control this on a crate-by-crate basis should make it much easier to apply when needed.
I'm not sure if we need both mechanisms, but we can decide that later.
cc `@pcwalton` `@cramertj`
[breaking change] Remove a rustdoc back compat warning
This warning was introduced in https://github.com/rust-lang/rust/pull/62855 for users who use `rustdoc` directly on proc macro crates (instead of using `cargo doc`) without passing `--crate-type proc-macro` (which `cargo doc` passed automatically).
Wrap missing provider message correctly
Fixes#108429
```
error: internal compiler error: compiler/rustc_middle/src/ty/query.rs:441:1: `tcx.trigger_delay_span_bug(DefId(0:3 ~ test[78c5]::main))` is not supported for local crate;
hint: Queries can be either made to the local crate, or the external crate. This error means you tried to use it for one that's not supported.
If that's not the case, trigger_delay_span_bug was likely never assigned to a provider function.
thread 'rustc' panicked at 'Box<dyn Any>', /home/ec2-user/rust3/compiler/rustc_errors/src/lib.rs:1651:9
stack backtrace:
0: 0x7f51870926d7 - std::backtrace_rs::backtrace::libunwind::trace::hb0876bb39e7adf0d
at /home/ec2-user/rust3/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x7f51870926d7 - std::backtrace_rs::backtrace::trace_unsynchronized::h1bcab1313827007b
at /home/ec2-user/rust3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7f5187077e07 - std::sys_common::backtrace::_print_fmt::h262d2a62279fa102
at /home/ec2-user/rust3/library/std/src/sys_common/backtrace.rs:65:5
```
