[RFC 2011] Optimize non-consuming operators
Tracking issue: https://github.com/rust-lang/rust/issues/44838
Fifth step of https://github.com/rust-lang/rust/pull/96496
The most non-invasive approach that will probably have very little to no performance impact.
## Current behaviour
Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.
```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`
if !(
{ ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
panic!( ... );
}
```
As such, some overhead is likely to occur (Specially with very large chains of conditions).
## New behaviour for non-consuming operators
When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition.
```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`
if !( a > 1 && b < 100 ) {
{ ***try capture `a`*** }
{ ***try capture `b`*** }
panic!( ... );
}
```
So the possible impact on the runtime execution time will be diminished.
r? ````@oli-obk````
Remove `MAX_SUGGESTION_HIGHLIGHT_LINES`
After #97798 the `MAX_SUGGESTION_HIGHLIGHT_LINES` constant doesn't really make sense since we always show full suggestions. This PR removes last usages of the constant and the constant itself.
r? ``@flip1995`` (this mostly does changes in clippy)
Only keep a single query for well-formed checking
There are currently 3 queries to perform wf checks on different item-likes. This complexity is not required.
This PR replaces the query by:
- one query per item;
- one query to invoke it for a whole module.
This allows to remove HIR `ParItemLikeVisitor`.
interpret: refactor allocation info query
We now have an infallible function that also tells us which kind of allocation we are talking about.
Also we do longer have to distinguish between data and function allocations for liveness.
This will help us to avoid "catching" `InterpError`s in Miri.
r? `@oli-obk`
Fix rustdoc argument error
Fixes#88756.
It's a take over of #88831. I cherry-picked the commits, fixed the merge conflict and the failing test.
cc `@inashivb` `@jyn514`
r? `@notriddle`
catch unwind in parallel mode during wfcheck
Update #75760
When performing wfcheck, from the test results, the parallel mode will stop all checks when an `item`'s check failed, (e.g. the first ui test failure raised from [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs#L249))while the serial mode will output each `item`'s check result via `catch_unwind`. This leads to inconsistencies in the final output of the two mode.
In my local environment, this modification prevents the following ui tests from failing when set `parallel-compiler = true` in `config.toml`:
```
[ui] src/test\ui\associated-types\defaults-cyclic-fail-1.rs
[ui] src/test\ui\associated-types\defaults-cyclic-fail-2.rs
[ui] src/test\ui\associated-types\hr-associated-type-bound-2.rs
[ui] src/test\ui\associated-types\impl-wf-cycle-1.rs
[ui] src/test\ui\associated-types\impl-wf-cycle-2.rs
[ui] src/test\ui\issues\issue-20413.rs
[ui] src/test\ui\parallel_test\defaults-cyclic-fail-para.rs
```
Check ADT field is well-formed before checking it is sized
Fixes#96810.
There is one diagnostics regression, in [`src/test/ui/generic-associated-types/bugs/issue-80626.stderr`](https://github.com/rust-lang/rust/pull/97780/files#diff-53795946378e78a0af23a10277c628ff79091c18090fdc385801ee70c1ba6963). I am not super concerned about it, since it's GAT related.
We _could_ fix it, possibly by using the `FieldSized` obligation cause code instead of `BuiltinDerivedObligation`. But that would require changing `Sized` trait confirmation and the `adt_sized_constraint` query.
We now have an infallible function that also tells us which kind of allocation we are talking about.
Also we do longer have to distinguish between data and function allocations for liveness.
rustc_target: Add convenience functions for adding linker arguments
They ensure that lld and non-lld linker flavors get the same set of arguments.
The second commit also adds some tests checking for linker argument inconsistencies, and tweaks some arguments to fix those inconsistencies.
proc_macro/bridge: cache static spans in proc_macro's client thread-local state
This is the second part of https://github.com/rust-lang/rust/pull/86822, split off as requested in https://github.com/rust-lang/rust/pull/86822#pullrequestreview-1008655452. This patch removes the RPC calls required for the very common operations of `Span::call_site()`, `Span::def_site()` and `Span::mixed_site()`.
Some notes:
This part is one of the ones I don't love as a final solution from a design standpoint, because I don't like how the spans are serialized immediately at macro invocation. I think a more elegant solution might've been to reserve special IDs for `call_site`, `def_site`, and `mixed_site` at compile time (either starting at 1 or from `u32::MAX`) and making reading a Span handle automatically map these IDs to the relevant values, rather than doing extra serialization.
This would also have an advantage for potential future work to allow `proc_macro` to operate more independently from the compiler (e.g. to reduce the necessity of `proc-macro2`), as methods like `Span::call_site()` could be made to function without access to the compiler backend.
That was unfortunately tricky to do at the time, as this was the first part I wrote of the patches. After the later part (#98188, #98189), the other uses of `InternedStore` are removed meaning that a custom serialization strategy for `Span` is easier to implement.
If we want to go that path, we'll still need the majority of the work to split the bridge object and introduce the `Context` trait for free methods, and it will be easier to do after `Span` is the only user of `InternedStore` (after #98189).
macros: use typed identifiers in diag and subdiag derive
Using typed identifiers instead of strings with the Fluent identifiers in the diagnostic and subdiagnostic derives - this enables the diagnostic derive to benefit from the compile-time validation that comes with typed identifiers, namely that use of a non-existent Fluent identifier will not compile.
r? `````@oli-obk`````
make const_err show up in future breakage reports
As tracked in https://github.com/rust-lang/rust/issues/71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since https://github.com/rust-lang/rust/pull/80394 (landed more than a year ago). Some CTFE errors are already hard errors since https://github.com/rust-lang/rust/pull/86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.
Cc `````@rust-lang/wg-const-eval`````
Work around llvm 12's memory ordering restrictions.
Older llvm has the pre-C++17 restriction on success and failure memory ordering, requiring the former to be at least as strong as the latter. So, for llvm 12, this upgrades the success ordering to a stronger one if necessary.
See https://github.com/rust-lang/rust/issues/68464
Suggest defining variable as mutable on `&mut _` type mismatch in pats
Suggest writing `mut a` where `&mut a` was written but a non-ref type provided.
Since we still don't have "apply either one of the suggestions but not both" kind of thing, the interaction with the suggestion of removing `&[mut]` or moving it to the type is weird, and idk how to make it better..
r? ``@compiler-errors``
Reverse folder hierarchy
#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
r? ````@jackh726````
