Create a single value cache for the () query key
Since queries using `()` as the key can only store a single value, specialize for that case.
This looks like a minor performance improvement:
<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.8477s</td><td align="right">1.8415s</td><td align="right"> -0.33%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2666s</td><td align="right">0.2655s</td><td align="right"> -0.40%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">6.3943s</td><td align="right">6.3686s</td><td align="right"> -0.40%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.6413s</td><td align="right">1.6345s</td><td align="right"> -0.42%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">1.0337s</td><td align="right">1.0313s</td><td align="right"> -0.24%</td></tr><tr><td>Total</td><td align="right">11.1836s</td><td align="right">11.1414s</td><td align="right"> -0.38%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9964s</td><td align="right"> -0.36%</td></tr></table>
Use associated items of `char` instead of freestanding items in `core::char`
The associated functions and constants on `char` have been stable since 1.52 and the freestanding items have soft-deprecated since 1.62 (https://github.com/rust-lang/rust/pull/95566). This PR ~~marks them as "deprecated in future", similar to the integer and floating point modules (`core::{i32, f32}` etc)~~ replaces all uses of `core::char::*` with `char::*` to prepare for future deprecation of `core::char::*`.
Enable new rlib in non stable cases
If bundled static library uses cfg (unstable) or whole-archive (wasn't supported) bundled libs are packed even without packed_bundled_libs.
r? `@petrochenkov`
Resolve documentation links in rustc and store the results in metadata
This PR implements MCP https://github.com/rust-lang/compiler-team/issues/584.
Doc links are now resolved in rustc and stored into metadata, so rustdoc simply retrieves them through a query (local or extern),
Code that is no longer used is removed, and some code that no longer needs to be public is privatized.
The removed code includes resolver cloning, so this PR fixes https://github.com/rust-lang/rust/issues/83761.
Rollup of 9 pull requests
Successful merges:
- #105019 (Add parentheses properly for borrowing suggestion)
- #106001 (Stop at the first `NULL` argument when iterating `argv`)
- #107098 (Suggest function call on pattern type mismatch)
- #107490 (rustdoc: remove inconsistently-present sidebar tooltips)
- #107855 (Add a couple random projection tests for new solver)
- #107857 (Add ui test for implementation on projection)
- #107878 (Clarify `new_size` for realloc means bytes)
- #107888 (revert #107074, add regression test)
- #107900 (Zero the `REPARSE_MOUNTPOINT_DATA_BUFFER` header)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Implement `deferred_projection_equality` for erica solver
Somewhat of a revival of #96912. When relating projections now emit an `AliasEq` obligation instead of attempting to determine equality of projections that may not be as normalized as possible (i.e. because of lazy norm, or just containing inference variables that prevent us from resolving an impl). Only do this when the new solver is enabled
Mir-Opt for copying enums with large discrepancies
I have been meaning to make this for quite a while, based off of this [hackmd](https://hackmd.io/`@ft4bxUsFT5CEUBmRKYHr7w/rJM8BBPzD).`
I'm not sure where to put this opt now that I've made it, so I'd appreciate suggestions on that!
It's also one long chain of statements, not sure if there's a more friendly format to make it.
r? `@tmiasko`
I would `r` oli but he's on leave so he suggested I `r` tmiasko or wesleywiser.
avoid duplicating the RUSTC_LOG env var name
We also have the env var name here:
c40919b7a7/compiler/rustc_driver_impl/src/lib.rs (L1247-L1251)
Redundantly having this name twice doesn't seem great. Looks like `rustc_log::init_rustc_env_logger` is dead code anyway.
r? `@oli-obk`
Avoid exposing type parameters and implementation details sourced from macro expansions
Fixes#107745.
~~I would like to **request some guidance** for this issue, because I don't think this is a good fix (a band-aid at best).~~
### The Problem
The code
```rust
fn main() {
println!("{:?}", []);
}
```
gets desugared into (`rustc +nightly --edition=2018 issue-107745.rs -Z unpretty=hir`):
```rust
#[prelude_import]
use std::prelude::rust_2018::*;
#[macro_use]
extern crate std;
fn main() {
{
::std::io::_print(<#[lang = "format_arguments"]>::new_v1(&["",
"\n"], &[<#[lang = "format_argument"]>::new_debug(&[])]));
};
}
```
so the diagnostics code tries to be as specific and helpful as possible, and I think it finds that `[]` needs a type parameter and so does `new_debug`. But since `[]` doesn't have an origin for the type parameter definition, it points to `new_debug` instead and leaks the internal implementation detail since all `[]` has is an type inference variable.
### ~~The Bad Fix~~
~~This PR currently tries to fix the problem by bypassing the generated function `<#[lang = "format_argument"]>::new_debug` to avoid its generic parameter (I think it is auto-generated from the argument `[_; 0]`?) from getting collected as an `InsertableGenericArg`. This is problematic because it also prevents the help from getting displayed.~~
~~I think this fix is not ideal and hard-codes the format generated code pattern, but I can't think of a better fix. I have tried asking on Zulip but no responses there yet.~~
Fix implied outlives bounds logic for projections
The logic here is subtly wrong. I put a bit of an explanation in a767d7b5165cea8ee5cbe494a4a636c50ef67c9c.
TL;DR: we register outlives predicates to be proved, because wf code normalizes projections (from the unnormalized types) to type variables. This causes us to register those as constraints instead of implied. This was "fine", because we later added that implied bound in the normalized type, and delayed registering constraints. When I went to cleanup `free_region_relations` to *not* delay adding constraints, this bug was uncovered.
cc. `@aliemjay` because this caused your test failure in #99832 (I only realized as I was writing this)
r? `@nikomatsakis`
Implement some tweaks in the new solver
I've been testing the new solver on some small codebases, and these are a few small changes I've needed to make.
The most "controversial" here is implementing `trait_candidate_should_be_dropped_in_favor_of`, which I just implemented to always return false. This surprisingly allows some code to compile, without us having to actually decide on any semantics yet.
r? `@rust-lang/initiative-trait-system-refactor`
Terminals supporting the OSC8 Hyperlink Extension can support inline
anchors where the text is user defineable but clicking on it opens a
browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
There is a type `QueryCtxt`, which impls the trait `QueryContext`.
Confusingly, there is another type `QueryContext`. The latter is (like
`TyCtxt`) just a pointer to a `GlobalContext`. It's not used much, e.g.
its `impl` block has a single method.
This commit removes `QueryContext`, replacing its use with direct
`GlobalCtxt` use.
correctly update goals in the cache
we may want to actually write the response for our goal into the provisional or global cache instead of simply using the result from the last iteration '^^
r? ```@rust-lang/initiative-trait-system-refactor```
Extend `BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE`.
To temporarily allow a `str` field in a packed struct using `derive`, along with `[u8]`.
r? ``@RalfJung``
This is somewhat important because LLVM enables the pass based on
target architecture, but support by the target OS also matters.
For example, XRay attributes are processed by codegen for macOS
targets, but Apple linker fails to process relocations in XRay
data sections, so the feature as a whole is not supported there
for the time being.
Specify where XRay is supported. I only test ARM64 and x86_64, but hey
those others should work too, right? LLVM documentation says that MIPS
and PPC are also supported, but I don't have the hardware, so I won't
pretend. Naturally, more targets can be added later with more testing.
Add the attributes to functions according to the settings.
"xray-always" overrides "xray-never", and they both override
"xray-ignore-loops" and "xray-instruction-threshold", but we'll
let lints deal with warnings about silly attribute combinations.
Recognize all bells and whistles that LLVM's XRay pass is capable of.
The always/never settings are a bit dumb without attributes but they're
still there. The default instruction count is chosen by the compiler,
not LLVM pass. We'll do it later.
Rename `replace_bound_vars_with_*` to `instantiate_binder_with_*`
Mentioning "binder" rather than "bound vars", imo, makes it clearer that we're doing something to the binder as a whole.
Also, "instantiate" is the verb that I'm always reaching for when I'm looking for these functions, and the name that we use in the new solver anyways.
r? types
Make `derive_const` derive properly const-if-const impls
Fixes#107774Fixes#107666
Also fixes rendering of const-if-const bounds in pretty printing.
r? ```@oli-obk``` or ```@fee1-dead```
Change `arena_cache` to not alter the declared query result
This makes the return types a bit clearer, limiting `arena_cache`'s effect to just the computation side. It also makes it easier to potentially remove `arena_cache`.
r? ```@cjgillot```
Treat Drop as a rmw operation
Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place.
In order for this change to be correct, we need to guarantee that
1. A dropped value won't be used again
2. Places that appear in a drop won't be used again before a
subsequent initialization.
We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having:
* (1) as there is no way of reaching the old value. drop-elaboration
will also remove any uninitialized drop.
* (2) as the place can't be named following the end of the scope.
However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.
From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from https://github.com/rust-lang/compiler-team/issues/558.
See also https://github.com/rust-lang/rust/pull/104488#discussion_r1085556010
Remove astconv usage in diagnostic
Fixes#107775
Location of the test sucks, I know, but I needed to put it somewhere 😓
The issue here is that the root cause of the issue has nothing to do with what's being tested, so I couldn't really give it a better name. Oh well.
Rename `PointerSized` to `PointerLike`
The old name was unnecessarily vague. This PR renames a nightly language feature that I added, so I don't think it needs any additional approval, though anyone can feel free to speak up if you dislike the rename.
It's still unsatisfying that we don't the user which of {size, alignment} is wrong, but this trait really is just a stepping stone for a more generalized mechanism to create `dyn*`, just meant for nightly testing, so I don't think it really deserves additional diagnostic machinery for now.
Fixes#107696, cc ``@RalfJung``
r? ``@eholk``
Rollup of 8 pull requests
Successful merges:
- #100599 (Add compiler error E0523 long description and test)
- #107471 (rustdoc: do not include empty default-settings tag in HTML)
- #107555 (Modify existing bounds if they exist)
- #107662 (Turn projections into copies in CopyProp.)
- #107695 (Add test for Future inflating arg size to 3x )
- #107700 (Run the tools builder on all PRs)
- #107706 (Mark 'atomic_mut_ptr' methods const)
- #107709 (Fix problem noticed in PR106859 with char -> u8 suggestion)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
llvm-16: Use Triple.h from new header location.
LLVM 16 has moved Triple.h from ADT and into TargetParser.
LLVM [landed a commit](62c7f035b4) this morning moving the header. This change should make rustc continue to build against LLVM main.
Fix problem noticed in PR106859 with char -> u8 suggestion
HN reader `@ayosec` noticed that my #106859 a few weeks back, malfunctions if you have a Unicode escape, the code suggested b'\u{0}' if you tried to use '\u{0}' where a byte should be, when of course b'\u{0}' is not a byte literal, regardless of the codepoint you can't write Unicode escapes in a byte literal at all.
My proposed fix here just checks that the "character" you wrote is fewer than 5 bytes, thus allowing \x7F and similar escapes but conveniently forbidding even the smallest Unicode escape \u{0} before offering the suggestion as before.
I have provided an updated test which includes examples which do and don't work because of this additional rule.
Split fn_ctxt/adjust_fulfillment_errors from fn_ctxt/checks
This is a follow-up from #106477, addressing a small number of the `FIXME`s that were added, by moving some functions into the new(er) `adjust_fulfillment_errors` module.
More cleanup is possible for this file (and I'll hopefully get around to doing some of that soon) but the very first thing is to just move these functions out.
There should be no "real" changes in this PR, besides minor adjustments to imports and the functions being transferred.
Turn projections into copies in CopyProp.
The current implementation can leave behind projections that are moved out several times.
This PR widens the check to turn such moves into copies: a move out of a projection of a copy is equivalent to a copy of the original projection.
Modify existing bounds if they exist
Fixes#107335.
This implementation is kinda gross but I don't really see a better way to do it.
This primarily does two things: Modifies `suggest_constraining_type_param` to accept a new parameter that indicates a span to be replaced instead of added, if presented, and limit the additive suggestions to either suggest a new bound on an existing bound (see newly added unit test) or add the generics argument if a generics argument wasn't found.
The former change is required to retain the capability to add an entirely new bounds if it was entirely omitted.
r? ``@compiler-errors``
Fix suggestions rendering when the diff span is multiline
Fixes#92741
cc `@estebank`
I think, I finally fixed. I still want to go back and try to clean up the code a bit. I'm open to suggestions.
Some examples of the new suggestions:
```
help: consider removing the borrow
|
2 - &
|
```
```
help: consider removing the borrow
|
2 - &
3 - mut
|
```
```
help: consider removing the borrow
|
2 - &
3 - mut if true { true } else { false }
2 + if true { true } else { false }
|
```
Should we add a test to ensure this behavior doesn't disappear in the future?
There is a distinction between running this on wasm and i686, even though they should be
identical. This technically is not _incorrect_, it's just an unexpected difference, which is
worth investigating, but not for correctness.
Since we're changing a bunch of stuff, necessary to remove some codegen tests
which look for specific things. Also attempting to restart a test which timed out, maybe due to
fastly failing?
make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias
See https://github.com/rust-lang/unsafe-code-guidelines/issues/381 and [this LLVM discussion](https://discourse.llvm.org/t/interaction-of-noalias-and-dereferenceable/66979). The exact semantics of how `noalias` and `dereferenceable` interact are unclear, and `@comex` found a case of LLVM actually exploiting that ambiguity for optimizations. I think for now we should treat LLVM `dereferenceable` as implying a "fake read" to happen immediately at the top of the function (standing in for the spurious reads that LLVM might introduce), and that fake read is subject to all the usual `noalias` restrictions. This means we cannot put `dereferenceable` on `&mut !Unpin` references as those references can alias with other references that are being read and written inside the function (e.g. for self-referential generators), meaning the fake read introduces aliasing conflicts with those other accesses.
For `&` this is already not a problem due to https://github.com/rust-lang/rust/pull/98017 which removed the `dereferenceable` attribute for other reasons.
Regular `&mut Unpin` references are unaffected, so I hope the impact of this is going to be tiny.
The first commit does some refactoring of the `PointerKind` enum since I found the old code very confusing each time I had to touch it. It doesn't change behavior.
Fixes https://github.com/rust-lang/miri/issues/2714
EDIT: Turns out our `Box<!Unpin>` treatment was incorrect, too, so the PR also fixes that now (in codegen and Miri): we do not put `noalias` on these boxes any more.
interpret: move discriminant reading and writing to separate file
This is quite different from the otherwise fairly general read and write functions in place.rs and operand.rs, and also it's nice to have these two functions close together as they are basically inverses of each other.
Sort Generator `print-type-sizes` according to their yield points
Especially when trying to diagnose runaway future sizes, it might be more intuitive to sort the variants according to the control flow (aka their yield points) rather than the size of the variants.
Refine error spans for "The trait bound `T: Trait` is not satisfied" when passing literal structs/tuples
This PR adds a new heuristic which refines the error span reported for "`T: Trait` is not satisfied" errors, by "drilling down" into individual fields of structs/enums/tuples to point to the "problematic" value.
Here's a self-contained example of the difference in error span:
```rs
struct Burrito<Filling> {
filling: Filling,
}
impl <Filling: Delicious> Delicious for Burrito<Filling> {}
fn eat_delicious_food<Food: Delicious>(food: Food) {}
fn will_type_error() {
eat_delicious_food(Burrito { filling: Kale });
// ^~~~~~~~~~~~~~~~~~~~~~~~~ (before) The trait bound `Kale: Delicious` is not satisfied
// ^~~~ (after) The trait bound `Kale: Delicious` is not satisfied
}
```
(kale is fine, this is just a silly food-based example)
Before this PR, the error span is identified as the entire argument to the generic function `eat_delicious_food`. However, since only `Kale` is the "problematic" part, we can point at it specifically. In particular, the primary error message itself mentions the missing `Kale: Delicious` trait bound, so it's much clearer if this part is called out explicitly.
---
The _existing_ heuristic tries to label the right function argument in `point_at_arg_if_possible`. It goes something like this:
- Look at the broken base trait `Food: Delicious` and find which generics it mentions (in this case, only `Food`)
- Look at the parameter type definitions and find which of them mention `Filling` (in this case, only `food`)
- If there is exactly one relevant parameter, label the corresponding argument with the error span, instead of the entire call
This PR extends this heuristic by further refining the resulting expression span in the new `point_at_specific_expr_if_possible` function. For each `impl` in the (broken) chain, we apply the following strategy:
The strategy to determine this span involves connecting information about our generic `impl`
with information about our (struct) type and the (struct) literal expression:
- Find the `impl` (`impl <Filling: Delicious> Delicious for Burrito<Filling>`)
that links our obligation (`Kale: Delicious`) with the parent obligation (`Burrito<Kale>: Delicious`)
- Find the "original" predicate constraint in the impl (`Filling: Delicious`) which produced our obligation.
- Find all of the generics that are mentioned in the predicate (`Filling`).
- Examine the `Self` type in the `impl`, and see which of its type argument(s) mention any of those generics.
- Examing the definition for the `Self` type, and identify (for each of its variants) if there's a unique field
which uses those generic arguments.
- If there is a unique field mentioning the "blameable" arguments, use that field for the error span.
Before we do any of this logic, we recursively call `point_at_specific_expr_if_possible` on the parent
obligation. Hence we refine the `expr` "outwards-in" and bail at the first kind of expression/impl we don't recognize.
This function returns a `Result<&Expr, &Expr>` - either way, it returns the `Expr` whose span should be
reported as an error. If it is `Ok`, then it means it refined successfull. If it is `Err`, then it may be
only a partial success - but it cannot be refined even further.
---
I added a new test file which exercises this new behavior. A few existing tests were affected, since their error spans are now different. In one case, this leads to a different code suggestion for the autofix - although the new suggestion isn't _wrong_, it is different from what used to be.
This change doesn't create any new errors or remove any existing ones, it just adjusts the spans where they're presented.
---
Some considerations: right now, this check occurs in addition to some similar logic in `adjust_fulfillment_error_for_expr_obligation` function, which tidies up various kinds of error spans (not just trait-fulfillment error). It's possible that this new code would be better integrated into that function (or another one) - but I haven't looked into this yet.
Although this code only occurs when there's a type error, it's definitely not as efficient as possible. In particular, there are definitely some cases where it degrades to quadratic performance (e.g. for a trait `impl` with 100+ generic parameters or 100 levels deep nesting of generic types). I'm not sure if these are realistic enough to worry about optimizing yet.
There's also still a lot of repetition in some of the logic, where the behavior for different types (namely, `struct` vs `enum` variant) is _similar_ but not the same.
---
I think the biggest win here is better targeting for tuples; in particular, if you're using tuples + traits to express variadic-like functions, the compiler can't tell you which part of a tuple has the wrong type, since the span will cover the entire argument. This change allows the individual field in the tuple to be highlighted, as in this example:
```
// NEW
LL | want(Wrapper { value: (3, q) });
| ---- ^ the trait `T3` is not implemented for `Q`
// OLD
LL | want(Wrapper { value: (3, q) });
| ---- ^~~~~~~~~~~~~~~~~~~~~~~~~ the trait `T3` is not implemented for `Q`
```
Especially with large tuples, the existing error spans are not very effective at quickly narrowing down the source of the problem.
Rollup of 5 pull requests
Successful merges:
- #107553 (Suggest std::ptr::null if literal 0 is given to a raw pointer function argument)
- #107580 (Recover from lifetimes with default lifetimes in generic args)
- #107669 (rustdoc: combine duplicate rules in ayu CSS)
- #107685 (Suggest adding a return type for async functions)
- #107687 (Adapt SROA MIR opt for aggregated MIR)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Adapt SROA MIR opt for aggregated MIR
The pass was broken by https://github.com/rust-lang/rust/pull/107267.
This PR extends it to replace:
```
x = Struct { 0: a, 1: b }
y = move? x
```
by assignment between locals
```
x_0 = a
x_1 = b
y_0 = move? x_0
y_1 = move? x_1
```
The improved pass runs to fixpoint, so we can flatten nested field accesses.
Suggest std::ptr::null if literal 0 is given to a raw pointer function argument
Implementation feels a little sus (we're parsing the span for a `0`) but it seems to fall in line the string-expected-found-char condition right above this check, so I think it's fine.
Feedback appreciated on help text? I think it's consistent but it does sound a little awkward maybe?
Fixes#107517
Adds the extended error documentation for E0523 to indicate that the
error is no longer produced by the compiler.
Update the E0464 documentation to include example code that produces the
error.
Remove the error message E0523 from the compiler and replace it with an
internal compiler error.
The code that consumes PointerKind (`adjust_for_rust_scalar` in rustc_ty_utils)
ended up using PointerKind variants to talk about Rust reference types (& and
&mut) anyway, making the old code structure quite confusing: one always had to
keep in mind which PointerKind corresponds to which type. So this changes
PointerKind to directly reflect the type.
This does not change behavior.
don't point at nonexisting code beyond EOF when warning about delims
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? `@compiler-errors`
Especially when trying to diagnose runaway future sizes, it might be
more intuitive to sort the variants according to the control flow
(aka their yield points) rather than the size of the variants.
Change wording from "nullable" to "default".
Introduce a trait `IsDefault` for detecting values that are encoded as zeros or not encoded at all.
Add panics to impossible cases.
Some other minor cleanups.
Less import overhead for errors
This removes huge (3+ lines) import lists found in files that had their error reporting migrated. These lists are bad for developer workflows as adding, removing, or editing a single error's name might cause a chain reaction that bloats the git diff. As the error struct names are long, the likelihood of such chain reactions is high.
Follows the suggestion by `@Nilstrieb` in the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/massive.20use.20statements) to replace the `use errors::{FooErr, BarErr};` with `use errors;` and then changing to `errors::FooErr` on the usage sites.
I have used sed to do most of the changes, i.e. something like:
```
sed -i -E 's/(create_err|create_feature_err|emit_err|create_note|emit_fatal|emit_warning)\(([[:alnum:]]+|[A-Z][[:alnum:]:]*)( \{|\))/\1(errors::\2\3/' path/to/file.rs
```
& then I manually fixed the errors that occured. Most manual changes were required in `compiler/rustc_parse/src/parser/expr.rs`.
r? `@compiler-errors`
Move code in `rustc_driver` out to a new `rustc_driver_impl` crate to allow pipelining
That adds a `rustc_shared` library which contains all the rustc library crates in a single dylib. It takes over this role from `rustc_driver`. This is done so that `rustc_driver` can be compiled in parallel with other crates. `rustc_shared` is intentionally left empty so it only does linking.
An alternative could be to move the code currently in `rustc_driver` into a new crate to avoid changing the name of the distributed library.
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing.
This would cause the debug assertion ice to trigger.
I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :(
But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? @compiler-errors
Retry opening proc-macro DLLs a few times on Windows.
On Windows, the compiler [sometimes](https://users.rust-lang.org/t/error-loadlibraryexw-failed/77603) fails with the message `error: LoadLibraryExW failed` when trying to load a proc-macro crate. The error seems to occur intermittently, similar to https://github.com/rust-lang/rust/issues/86929, however, it seems to be almost impossible to reproduce outside of CI environments and thus very hard to debug. The fact that the error only occurs intermittently makes me think that this is a timing related issue.
This PR is an attempt to mitigate the issue by letting the compiler retry a few times when encountering this specific error (which resolved the issue described in https://github.com/rust-lang/rust/issues/86929).
Fix suggestion for coercing Option<&String> to Option<&str>
Fixes#107604
This also makes the diagnostic `MachineApplicable`, and runs `rustfix` to check we're not producing incorrect code.
``@rustbot`` label +A-diagnostics
Don't cause a cycle when formatting query description that references a FnDef
When a function returns `-> _`, we use typeck to compute what the resulting type of the body _should_ be. If we call another query inside of typeck and hit a cycle error, we attempt to report the cycle error which requires us to compute all of the query descriptions for the stack.
However, if one of the queries in that cycle has a query description that references this function as a FnDef type, we'll cause a *second* cycle error from within the cycle error reporting code, since rendering a FnDef requires us to compute its signature. This causes an unwrap to ICE, since during the *second* cycle reporting code, we try to look for a job that isn't in the active jobs list.
We can avoid this by using `with_no_queries!` when computing these query descriptions.
Fixes#107089
The only drawback is that the rendering of opaque types in cycles regresses a bit :| I'm open to alternate suggestions about how we may handle this...
Emit warnings on unused parens in index expressions
Fixes: #96606.
I am not sure what the best term for "index expression" is. Is there a better term we could use?
Don't generate unecessary `&&self.field` in deriving Debug
Since unsized fields may only be the last one in a struct, we only need to generate a double reference (`&&self.field`) for the final one.
cc `@nnethercote`
ast: Optimize list and value extraction primitives for attributes
It's not necessary to convert the whole attribute into a meta item to extract something specific.
Suggest `{var:?}` when finding `{?:var}` in inline format strings
Link to issue: https://github.com/rust-lang/rust/issues/106572
This is my first PR to this project, so hopefully I can get some good pointers with me from the first PR.
Currently my idea was to test out whether or not this is the correct solution to this issue and then hopefully expand upon the idea to not only work for Debug formatting but for all of them. If this is a valid solution, I will create a new issue to give a better error message to a broader range of wrong-order formatting.
