Remove allow(rustc::potential_query_instability) in rustc_trait_selection
Related to https://github.com/rust-lang/rust/issues/84447
This PR needs to be benchmarked to check for regressions.
Previously, rustdoc would unconditionally report the version that *rustc* was compiled with.
That showed things like `nightly-2022-10-30`, which wasn't right, since this was a `dev` build compiled from source.
Fix it by changing `rustc_driver::version` to a macro expanded at invocation time.
Rollup of 7 pull requests
Successful merges:
- #100508 (avoid making substs of type aliases late bound when used as fn args)
- #101381 (Test that target feature mix up with homogeneous floats is sound)
- #103353 (Fix Access Violation when using lld & ThinLTO on windows-msvc)
- #103521 (Avoid possible infinite loop when next_point reaching the end of file)
- #103559 (first move on a nested span_label)
- #103778 (Update several crates for improved support of the new targets)
- #103827 (Properly remap and check for substs compatibility in `confirm_impl_trait_in_trait_candidate`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid possible infinite loop when next_point reaching the end of file
Fixes#103451
If we return a span with `lo` = `hi`, `span_to_snippet` will always get `Ok("")`, which may introduce infinite loop if we don't care.
This PR make `find_width_of_character_at_span` return `width` with 1, so that `span_to_snippet` will get an `Err`.
Fix Access Violation when using lld & ThinLTO on windows-msvc
Users report an AV at runtime of the compiled binary when using lld and ThinLTO on windows-msvc. The AV occurs when accessing a static value which is defined in one crate but used in another. Based on the disassembly of the cross-crate use, it appears that the use is not correctly linked with the definition and is instead assigned a garbage pointer value.
If we look at the symbol tables for each crates' obj file, we can see what is happening:
*lib.obj*:
```
COFF SYMBOL TABLE
...
00E 00000000 SECT2 notype External | _ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```
*bin.obj*:
```
COFF SYMBOL TABLE
...
010 00000000 UNDEF notype External | __imp__ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```
The use of the symbol has the "import" style symbol name but the declaration doesn't generate any symbol with the same name. As a result, linking the files generates a warning from lld:
> rust-lld: warning: bin.obj: locally defined symbol imported: reproducer::memrchr::FN::h612b61ca0e168901 (defined in lib.obj) [LNK4217]
and the symbol reference remains undefined at runtime leading to the AV.
To fix this, we just need to detect that we are performing ThinLTO (and thus, static linking) and omit the `dllimport` attribute on the extern item in LLVM IR.
Fixes#81408
avoid making substs of type aliases late bound when used as fn args
fixes#47511fixes#85533
(although I did not know theses issues existed when i was working on this 🙃)
currently `Alias<...>` is treated the same as `Struct<...>` when deciding if generics should be late bound or early bound but this is not correct as `Alias` might normalize to a projection which does not constrain the generics.
I think this needs more tests before merging
more explanation of PR [here](https://hackmd.io/v44a-QVjTIqqhK9uretyQg?view)
Hackmd inline for future readers:
---
This assumes reader is familiar with the concept of early/late bound lifetimes. There's a section on rustc-dev-guide if not (although i think some details are a bit out of date)
## problem & background
Not all lifetimes on a fn can be late bound:
```rust
fn foo<'a>() -> &'a ();
impl<'a> Fn<()> for FooFnDef {
type Output = &'a (); // uh oh unconstrained lifetime
}
```
so we make make them early bound
```rust
fn foo<'a>() -> &'a ();
impl<'a> Fn<()> for FooFnDef<'a> {// wow look at all that lifetimey
type Output = &'a ();
}
```
(Closures have the same constraint however it is not enforced leading to soundness bugs, [#84385](https://github.com/rust-lang/rust/pull/84385) implements this "downgrading late bound to early bound" for closures)
lifetimes on fn items are only late bound when they are "constrained" by the fn args:
```rust
fn foo<'a>(_: &'a ()) -> &'a ();
// late bound, not present on `FooFnItem`
// vv
impl<'a> Trait<(&'a (),)> for FooFnItem {
type Output = &'a ();
}
// projections do not constrain inputs
fn bar<'a, T: Trait>(_: <T as Trait<'a>>::Assoc) -> &'a (); // early bound
// vv
impl<'a, T: Trait> Fn<(<T as Trait<'a>>::Assoc,)> for BarFnItem<'a, T> {
type Output = &'a ();
}
```
current logic for determining if inputs "constrain" a lifetime works off of HIR so does not normalize aliases. It also assumes that any path with no self type constrains all its substs (i.e. `Foo<'a, u32>` has no self type but `T::Assoc` does). This falls apart for top level type aliases (see linked issues):
```rust
type Alias<'a, T> = <T as Trait<'a>>::Assoc;
// wow look its a path with no self type uwu
// i bet that constrains `'a` so it should be latebound
// vvvvvvvvvvv
fn foo<'a, T: Trait>(_: Alias<'a, T>) -> &'a ();
// `Alias` normalized to make things clearer
// vvvvvvvvvvvvvvvvvvvvvvv
impl<'a, T: Trait> Fn<(<T as Trait<'a>>::Assoc,)> for FooFnDef<T> {
type Output = &'a ();
// oh no `'a` isnt constrained wah wah waaaah *trumbone noises*
// i think, idk what musical instrument that is
}
```
## solution
The PR solves this by having the hir visitor that checks for lifetimes in constraining uses check if the path is a `DefKind::Alias`. If it is we ""normalize"" it by calling `type_of` and walking the returned type. This is a bit hacky as it requires a mapping between the substs on the path in hir, and the generics of the `type Alias<...>` which is on the ty layer.
Alternative solutions may involve calculating the "late boundness" of lifetimes after/during astconv rather than relying on hir at all. We already have code to determine whether a lifetime SHOULD be late bound or not as this is currently how the error for `fn foo<'a, T: Trait>(_: Alias<'a, T>) -> &'a ();` gets emitted.
It is probably not possible to do this right now, late boundness is used by `generics_of` and `gather_explicit_predicates_of` as we currently do not put late bound lifetimes in `Generics`. Although this seems sus to me as the long term goal is to make all generics late bound which would result in `generics_of(function)` being empty? [#103448](https://github.com/rust-lang/rust/pull/103448) places all lifetimes in `Generics` regardless of late boundness so that may be a good step towards making this possible.
Better error for HRTB error from generator interior
cc #100013
This is just a first pass at an error. It could be better, and shouldn't really be emitted in the first place. But this is better than what was being emitted before.
Remove an address comparison from the parser
Originally this check was added in #68985, as suggested by 940f65782c (r376850175). I don't think that this address check is a robust way of making parser more robust.
This code is also extensively tested by [`ui/parser/issues/issue-35813-postfix-after-cast.rs`](57d3c58ed6/src/test/ui/parser/issues/issue-35813-postfix-after-cast.rs).
_Replaces #103700_
r? `@compiler-errors`
Add split-debuginfo print option
This option prints all supported values for `-Csplit-debuginfo=..`, i.e. only stable ones on stable/beta and all of them on nightly/dev.
Motivated by 1.65.0 regression causing builds with the following entry in `Cargo.toml` to fail on Windows:
```toml
[profile.dev]
split-debuginfo = "unpacked"
```
See https://github.com/rust-lang/cargo/pull/11347 for details.
This will lead to closing https://github.com/rust-lang/rust/issues/103976.
selection failure: recompute applicable impls
The way we currently skip errors for ambiguous trait obligations seems pretty fragile so we get some duplicate errors because of this.
Removing this info from selection errors changes this system to be closer to my image of our new trait solver and is also making it far easier to change overflow errors to be non-fatal ✨
r? types cc `@estebank`
Make InferCtxtExt use a FxIndexMap
This should be faster, because the map is only being used to iterate,
which is supposed to be faster with the IndexMap
Make the user_computed_preds use an IndexMap
It is being used mostly for iteration, so the change shouldn't result in
a perf hit
Make the RegionDeps fields use an IndexMap
This change could be a perf hit. Both `larger` and `smaller` are used
for iteration, but they are also used for insertions.
Make types_without_default_bounds use an IndexMap
It uses extend, but it also iterates and removes items. Not sure if
this will be a perf hit.
Make InferTtxt.reported_trait_errors use an IndexMap
This change brought a lot of other changes. The map seems to have been
mostly used for iteration, so the performance shouldn't suffer.
Add FIXME to change ProvisionalEvaluationCache.map to use an IndexMap
Right now this results in a perf hit. IndexMap doesn't have
the `drain_filter` API, so in `on_completion` we now need to iterate two
times over the map.
resolve: More detailed effective visibility tracking for imports
Per-`DefId` tracking is not enough, due to glob imports in particular, which have a single `DefId` for the whole glob import item.
We need to track this stuff per every introduced name (`NameBinding`).
Also drop `extern` blocks from the effective visibility table, they are nominally private and it doesn't make sense to keep them there.
Later commits add some debug-only invariant checking and optimiaztions to mitigate regressions in https://github.com/rust-lang/rust/pull/103965#issuecomment-1304256445.
This is a bugfix and continuation of https://github.com/rust-lang/rust/pull/102026.
`CompiledModule` should not think a DWARF object was emitted when a
bitcode-only compilation has happened, this can confuse archive file
creation (which expects to create an archive containing non-existent dwo
files).
Signed-off-by: David Wood <david.wood@huawei.com>
fix debuginfo for windows_gnullvm_base.rs
These lines (including the FIXME comment) were added to windows_gnu_base.rs in cf2c492ef8 but windows_gnullvm_base.rs was not updated. This resulted in an error `LLVM ERROR: dwo only supported with ELF and Wasm` attempting to build on aarch64-pc-windows-gnullvm.
See also https://github.com/msys2/MINGW-packages/pull/13921#issuecomment-1304391707
/cc ```@mati865``` ```@davidtwco```
r? ```@davidtwco```
Remove `in_tail_expr` from FnCtxt
Cleans up yet another unneeded member from `FnCtxt`. The `in_tail_expr` condition wasn't even correct -- it was set for true while typechecking the whole fn body.
fix: lint against the functions `LintContext::{lookup_with_diagnostics,lookup,struct_span_lint,lint}`, `TyCtxt::struct_lint_node`, `LintLevelsBuilder::struct_lint`.
Normalize types when deducing closure signature from supertraits
Elaborated supertraits should be normalized, since there's no guarantee they don't contain projections 😅Fixes#104025
r? types
Mention const and lifetime parameters in error E0207
Error Index for E0207 must mention const and lifetime parameters. In addition, add code examples for these situations.
Fixes#80862
Remove #![allow(rustc::potential_query_instability)] from rustc_infer
Related to #84447
This PR probably needs to be benchmarked to check for regressions.
These lines (including the FIXME comment) were added to windows_gnu_base.rs in cf2c492ef8 but windows_gnullvm_base.rs was not updated. This resulted in an error `LLVM ERROR: dwo only supported with ELF and Wasm` attempting to build on aarch64-pc-windows-gnullvm.
Signed-off-by: Jeremy Drake <github@jdrake.com>
LLVM 16: Update RISCV data layout
The RISCV data layout was changed in 974e2e690b.
This updates all `riscv64*` targets, though I don't really know what the difference between the `gc` and `imac` ones is.
Passes `x test codegen` at LLVM head and with the currently bundled LLVM version. Without this patch, some tests fail with:
> error: internal compiler error: compiler/rustc_codegen_llvm/src/context.rs:192:13: data-layout for target `riscv64gc-unknown-none-elf`, `e-m:e-p:64:64-i64:64-i128:128-n64-S128`, differs from LLVM target's `riscv64` default layout, `e-m:e-p:64:64-i64:64-i128:128-n32:64-S128
Add type_array to BaseTypeMethods
Moved `type_array` function to `rustc_codegen_ssa::BaseTypeMethods` trait. This allows using normal `alloca` function to create arrays as suggested in https://github.com/rust-lang/rust/pull/104022.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Implement `std::marker::Tuple`, use it in `extern "rust-call"` and `Fn`-family traits
Implements rust-lang/compiler-team#537
I made a few opinionated decisions in this implementation, specifically:
1. Enforcing `extern "rust-call"` on fn items during wfcheck,
2. Enforcing this for all functions (not just ones that have bodies),
3. Gating this `Tuple` marker trait behind its own feature, instead of grouping it into (e.g.) `unboxed_closures`.
Still needing to be done:
1. Enforce that `extern "rust-call"` `fn`-ptrs are well-formed only if they have 1/2 args and the second one implements `Tuple`. (Doing this would fix ICE in #66696.)
2. Deny all explicit/user `impl`s of the `Tuple` trait, kinda like `Sized`.
3. Fixing `Tuple` trait built-in impl for chalk, so that chalkification tests are un-broken.
Open questions:
1. Does this need t-lang or t-libs signoff?
Fixes#99820
Moved type_array function to rustc_codegen_ssa::BaseTypeMethods trait.
This allows using normal alloca function to create arrays as suggested in
https://github.com/rust-lang/rust/pull/104022.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Rollup of 7 pull requests
Successful merges:
- #103012 (Suggest use .. to fill in the rest of the fields of Struct)
- #103851 (Fix json flag in bootstrap doc)
- #103990 (rustdoc: clean up `.logo-container` layout CSS)
- #104002 (fix a comment in UnsafeCell::new)
- #104014 (Migrate test-arrow to CSS variables)
- #104016 (Add internal descriptions to a few queries)
- #104035 (Add 'closure match' test to weird-exprs.rs.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rework applying closure requirements in borrowck
Previously the promoted closure constraints were registered under the category `ConstraintCategory::ClosureBounds` in `type_check::prove_closure_bounds()` and then mapped back their original category in `regions_infer::best_blame_constraint` using the complicated map `closure_bounds_mapping`.
Now we're registering promoted constraints under their original category and span earlier in `type_check::prove_closure_bounds`.
See commit messages.
Fixes#99245
[debuginfo] Make cpp-like debuginfo type names for slices and str consistent.
Before this PR, the compiler would emit the debuginfo name `slice$<T>` for all kinds of slices, regardless of whether they are behind a reference or not and regardless of the kind of reference. As a consequence, the types `Foo<&[T]>`, `Foo<[T]>`, and `Foo<&mut [T]>` would end up with the same type name `Foo<slice$<T> >` in debuginfo, making it impossible to disambiguate between them by name. Similarly, `&str` would get the name `str` in debuginfo, so the debuginfo name for `Foo<str>` and `Foo<&str>` would be the same. In contrast, `*const [bool]` and `*mut [bool]` would be `ptr_const$<slice$<bool> >` and `ptr_mut$<slice$<bool> >`, i.e. the encoding does not lose information about the type.
This PR removes all special handling for slices and `str`. The types `&[bool]`, `&mut [bool]`, and `&str` thus get the names `ref$<slice2$<bool> >`, `ref_mut$<slice2$<bool> >`, and `ref$<str$>` respectively -- as one would expect.
The new special name for slices is `slice2$` to differentiate it from the previous name `slice$`, which has different semantics. The same is true for `str` and `str$`. This kind of versioning already has a precedent with the case of `enum$` and `enum2$` and hopefully will make it easier to transition existing consumers of these names.
cc `@rust-lang/wg-debugging` `@vadimcn`
r? `@wesleywiser`
UPDATE: Here is a table to clarify the changes
| Rust type | DWARF name | C++-like name (before) | C++-like name (after) |
|-----------|------------|------------------------|------------------------|
| `[T]` | `[T]` | `slice$<T>` | `slice2$<T>` |
| `&[T]` | `&[T]` | `slice$<T>` | `ref$<slice2$<T> >` |
| `&mut [T]` | `&mut [T]` | `slice$<T>` | `ref_mut$<slice2$<T> >`|
| `str` | `str` | `str` | `str$` |
| `&str` | `&str` | `str` | `ref$<str$>` |
| `&mut str` | `&mut str` | `str` | `ref_mut$<str$>`|
| `*const [T]` | `*const [T]` | `ptr_const$<slice$<T> >` | `ptr_const$<slice2$<T> >` |
| `*mut [T]` | `*mut [T]` | `ptr_mut$<slice$<T> >` | `ptr_mut$<slice2$<T> >` |
As you can see, before the PR many types would end up with the same name, making it impossible to distinguish between them in NatVis or other places where types are matched or looked up by name. The DWARF version of names is not changed.
Remove `has_errors` from `FnCtxt`
It doesn't seem like this `has_errors` flag actually suppresses any errors (at least in the UI test suite) --- except for one test (`E0767.rs`), and I think that error really should be considered legitimate, since it has nothing to do with the error code and continues to exist after you fix the first error...
This flag was added by ```@eddyb``` in 6b3cc0b8c8, and it's likely that it was made redundant due to subsequent restructuring of the compiler.
It only affects block type-checking anyways, so its effect does seem limited these days anyway.
improve `filesearch::get_or_default_sysroot`
`fn get_or_default_sysroot` is now improved and used in `miri` and `clippy`, and tests are still passing as they should. So we no longer need to implement custom workarounds/hacks to find sysroot in tools like miri/clippy.
Resolves https://github.com/rust-lang/rust/issues/98832
re-opened from #103581
Spans are independent of the body being borrow-checked, so they don't
need remapping when promoting type-tests and they yield more specific
error spans inside bodies of closures/inline consts.
Don't use `ConstraintCategory::ClosureBounds`!
Set the category and the span for the promoted constraints to that of
the original constraint earlier than before.
This eliminates the need for `closure_bounds_mapping`.
LLVM 16: Switch to using MemoryEffects
This adapts the compiler to the changes required by 304f1d59ca.
AFAICT, `WriteOnly` isn't used by the compiler, all `ReadNone` uses were migrated and the remaining use of `ReadOnly` is only for function parameters.
To simplify the FFI, this PR uses an enum to represent `MemoryEffects` across the FFI boundary, which then gets mapped to the matching static factory method when constructing the attribute.
Fixes#103961.
`@rustbot` label +llvm-main
r? `@nikic`
Give a specific lint for unsafety not being inherited
In cases like
```rs
static mut FOO: u64 = 0;
fn main() {
unsafe {static BAR: u64 = FOO;}
}
```
and
```rs
fn foo() {
unsafe {
fn bar() {
unsafe_call();
}
}
}
```
Specifically inform the user that the unsafety is not inherited for the seperate enclosing items
Fixes#94077
r? compiler-errors
`@rustbot` label +A-diagnostics
minor changes to make method lookup diagnostic code easier to read
The end result of around 4 days of trying to understand this 1000+ line long function- a bunch of tiny nitpicks
r? `@compiler-errors`
asm: Work around LLVM bug on AArch64
Upstream issue: https://github.com/llvm/llvm-project/issues/58384
LLVM gets confused if we assign a 32-bit value to a 64-bit register, so pass the 32-bit register name to LLVM in that case.
Port `dead_code` lints to be translatable.
This adds an additional comma to lists with three or more items, to be consistent with list formatters like `icu4x`.
r? `@davidtwco`
Fix ICE when negative impl is collected during eager mono
```rust
trait Foo {
fn foo() {}
}
impl !Foo for () {}
```
This code will currently cause an ICE when mono collection mode is "eager" (with `-C link-dead-code=y` or `-Z print-mono-items=eager`.
Fix late-bound lifetime closure ICEs in HIR typeck and MIR borrowck
During HIR typeck, we need to teach astconv to treat late-bound regions within a closure body as free, fixing escaping bound vars ICEs in both of the issues below.
However, this then gets us to MIR borrowck, which itself needs to be taught how to instantiate free region vids for late-bound regions that come from items that _aren't_ the typeck root (for now, just closures).
Fixes#103771Fixes#103736
asm: Match clang behavior for inlateout fixed register operands
We have 2 options for representing LLVM constraints for `inlateout` operands on a fixed register (e.g. `r0`): `={r0},0` or `={r0},{r0}`.
This PR changes the behavior to the latter, which matches the behavior of Clang since https://reviews.llvm.org/D87279.
Add visit_fn_ret_ty to hir intravisit
I'm working on some RPITIT changes and I need to specialize `visit_fn_ret_ty` in my visitor impl. So I guess it's better to land it separately.
r? `@compiler-errors`
FIX - StrippingDebugInfoFailed typo
DELETE - unneeded FIXME comment
UPDATE - only declare the error with ExtractBundledLibsError as an enum and use the Diagnostic derive macro
It deals with eight cases: ints, floats, and the six quoted types
(char/byte/strings). For ints and floats we have an early return, and
the other six types fall through to the code at the end, which makes the
function hard to read.
This commit rearranges things to avoid the early returns.
There are three kinds of "byte" literals: byte literals, byte string
literals, and raw byte string literals. None are allowed to have
non-ASCII chars in them.
Two `EscapeError` variants exist for when that constraint is violated.
- `NonAsciiCharInByte`: used for byte literals and byte string literals.
- `NonAsciiCharInByteString`: used for raw byte string literals.
As a result, the messages for raw byte string literals use different
wording, without good reason. Also, byte string literals are incorrectly
described as "byte constants" in some error messages.
This commit eliminates `NonAsciiCharInByteString` so the three cases are
handled similarly, and described correctly. The `mode` is enough to
distinguish them.
Note: Some existing error messages mention "byte constants" and some
mention "byte literals". I went with the latter here, because it's a
more correct name, as used by the Reference.
Users report an AV at runtime of the compiled binary when using lld and
ThinLTO on windows-msvc. The AV occurs when accessing a static value
which is defined in one crate but used in another. Based on the
disassembly of the cross-crate use, it appears that the use is not
correctly linked with the definition and is instead assigned a garbage
pointer value.
If we look at the symbol tables for each crates' obj file, we can see
what is happening:
*lib.obj*:
```
COFF SYMBOL TABLE
...
00E 00000000 SECT2 notype External | _ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```
*bin.obj*:
```
COFF SYMBOL TABLE
...
010 00000000 UNDEF notype External | __imp__ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```
The use of the symbol has the "import" style symbol name but the
declaration doesn't generate any symbol with the same name. As a result,
linking the files generates a warning from lld:
> rust-lld: warning: bin.obj: locally defined symbol imported: reproducer::memrchr::FN::h612b61ca0e168901 (defined in lib.obj) [LNK4217]
and the symbol reference remains undefined at runtime leading to the AV.
To fix this, we just need to detect that we are performing ThinLTO (and
thus, static linking) and omit the `dllimport` attribute on the extern
item in LLVM IR.
Corresponding subsection in async book is not `07.05` not `07.06`.
The information on the linked page is the same so it may be reasonable to remove the whole sentence.
It's passed to numerous places where we just need an `is_byte` bool.
Passing the bool avoids the need for some assertions.
Also rename `is_bytes()` as `is_byte()`, to better match `Mode::Byte`,
`Mode::ByteStr`, and `Mode::RawByteStr`.
Fixed consistency of Apple simulator target's ABI
Currently there's a few Apple device simulator targets that are inconsistent since some set `target_abi = "sim"` (the correct thing to do) while a bunch of others don't set anything (`""`). Due to this its very hard to reliability check if some Rust code is running inside a simulator. This changes all of them to do the same thing and set `sim` as their `target_abi`.
The new way to identity a simulator during compilation is as simple as `cfg(all(target_vendor="apple", target_abi = "sim"))` or even `cfg(target_abi = "sim")` being less pedantic about it.
The issues with the current form (and inspiration for this) are also summarized in `@thomcc's` [Tweet](https://twitter.com/at_tcsc/status/1576685244702691328).
These have been bugging me for a while.
- `literal_text`: `src` is also used and is shorter and better.
- `first_char`: used even when "first" doesn't make sense; `c` is
shorter and better.
- `curr`: `c` is shorter and better.
- `unescaped_char`: `result` is also used and is shorter and better.
- `second_char`: these have a single use and can be elided.
Allow use of `-Clto=thin` with `-Ccodegen-units=1` in general
The current logic to ignore ThinLTO when `-Ccodegen-units=1` makes sense for local ThinLTO but even in this scenario, a user may still want (non-local) ThinLTO for the purpose of optimizing dependencies into the final crate which is being compiled with 1 CGU.
The previous behavior was even more confusing because if you were generating a binary (`--emit=link`), then you would get ThinLTO but if you asked for LLVM IR or bytecode, then it would silently change to using regular LTO.
With this change, we only override the defaults for local ThinLTO if you ask for a single output such as LLVM IR or bytecode and in all other cases honor the requested LTO setting.
r? `@michaelwoerister`
fix(generic_const_exprs): Fix predicate inheritance for children of opaque types
Fixes#99705
We currently have a special case to perform predicate inheritance when the const item is in the generics. I think we're also going to need this for opaque return types. When evaluating the predicates applied to the associated item, it'll inherit from its parent, the opaque type, which will never have predicates applied. This PR bypass the opaque typed parent and inherit predicates directly from the function itself.
For now, we only collect the small info for the `best_failure`, but
using this tracker, we can easily extend it in the future to track
things with more performance overhead.
We cannot retry cases where the macro failed with a parser error that
was emitted already, as that would cause us to emit the same error to
the user twice.
This moves out the matching part of expansion into a new function. This
function will try to match the macro and return an error if it failed to
match. A tracker can be used to get more information about the matching.
Reorder `walk_` functions in intravisit.rs
Reorder the `walk_` functions to match the order of the `visit_` methods. This is a follow up to https://github.com/rust-lang/rust/pull/103692.
Note that there are some oddballs. I put them where I thought made the most sense:
```diff
$ diff \
<(sed -n 's/^.*\<fn visit_\([^(]*\).*$/\1/;T;p' compiler/rustc_hir/src/intravisit.rs) \
<(sed -n 's/^.*\<fn walk_\([^<]*\).*$/\1/;T;p' compiler/rustc_hir/src/intravisit.rs)
1,5d0
< nested_item
< nested_trait_item
< nested_impl_item
< nested_foreign_item
< nested_body
9,10d3
< id
< name
20c13
< array_length
---
> array_len
30a24
> fn_ret_ty
31a26
> fn_kind
41c36
< variant_data
---
> struct_def
46c41
< infer
---
> inf
54d48
< attribute
```
Also, as some weak evidence that i did things correctly, I get the following before and after the change:
```sh
$ sort compiler/rustc_hir/src/intravisit.rs | openssl sha256
SHA256(stdin)= cac13d2545731ef442f318e2b4286490d7ac5494f4ad10c4cf4c5d4f50d21641
```
r? `@fee1-dead`
Gate some parser recovery behind the check
Mainly in `expr.rs`. `may_recover` doesn't do anything useful yet until I implement that on top of #103439.
r? `@compiler-errors`
Print valid `--print` requests if request is invalid
When someone makes a typo, it can be useful to see the valid options. This is also useful if someone wants to find out about all the options.
Add `multivalue` target feature to WASM target
This PR is similar to #99643 and #97808. It addresses #96472 for the `multivalue` target feature.
The problem I am trying to fix is to remove the following warning when compiling with `-C target-feature=+multivalue` for `--target=wasm32-unknown-unknown`.
```
warning: unknown feature specified for `-Ctarget-feature`: `multivalue`
|
= note: it is still passed through to the codegen backend
= note: consider filing a feature request
```
Change #[suggestion_*] attributes to use style="..."
As discussed [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20tool_only_span_suggestion), this changes `#[(multipart_)suggestion_{short,verbose,hidden}(...)]` attributes to plain `#[(multipart_)suggestion(...)]` attributes with a `style = "{short,verbose,hidden}"` parameter.
It also adds a new style, `tool-only`, that corresponds to `tool_only_span_suggestion`/`tool_only_multipart_suggestion` and causes the suggestion to not be shown in human-readable output at all.
Best reviewed commit-by-commit, there's a bit of noise in there.
cc #100717 `@compiler-errors`
r? `@davidtwco`
Track where diagnostics were created.
This implements the `-Ztrack-diagnostics` flag, which uses `#[track_caller]` to track where diagnostics are created. It is meant as a debugging tool much like `-Ztreat-err-as-bug`.
For example, the following code...
```rust
struct A;
struct B;
fn main(){
let _: A = B;
}
```
...now emits the following error message:
```
error[E0308]: mismatched types
--> src\main.rs:5:16
|
5 | let _: A = B;
| - ^ expected struct `A`, found struct `B`
| |
| expected due to this
-Ztrack-diagnostics: created at compiler\rustc_infer\src\infer\error_reporting\mod.rs:2275:31
```
resolve: Turn the binding from `#[macro_export]` into a proper `Import`
Continuation of https://github.com/rust-lang/rust/pull/91795.
```rust
#[macro_export]
macro_rules! m { /*...*/ }
```
is desugared to something like
```rust
macro_rules! m { /*...*/ } // Non-modularized macro_rules item
pub use m; // It's modularized reexport
```
This PR adjusts the internal representation to better match this model.
rustc_metadata: Encode even less doc comments
The fact that `def_id` is in the `tcx.privacy_access_levels(())` table is not very meaningful, especially after https://github.com/rust-lang/rust/pull/102026, `is_exported` (or `is_reachable` in the worst case) is what you need.
Follow up to https://github.com/rust-lang/rust/pull/98450.
r? `@GuillaumeGomez` `@lqd`
(almost) Always use `ObligationCtxt` when dealing with canonical queries
Hope this is a step in the right direction. cc rust-lang/types-team#50.
r? `@lcnr`
Fix E0433 No Typo Suggestions
Fixes#48676Fixes#87791Fixes#96625Fixes#95462Fixes#101637
Follows up PR #72923
Several open issues refer to the problem that E0433 does not suggest typos like other errors normally do. This fix augments the implementation of PR #72923.
**Background**
When the path of a function call, e.g. `Struct::foo()`, involves names that cannot be resolved, there are two errors that could be emitted by the compiler:
- If `Struct` is not found, it is ``E0433: failed to resolve: use of undeclared type `Struct` ``.
- If `foo` is not found in `Struct`, it is ``E0599: no function or associated item named `foo` found for struct `Struct` in the current scope``
When a name is used as a type, `e.g. fn foo() -> Struct`, and the name cannot be resolved, it is ``E0412: cannot find type `Struct` in this scope``.
Before #72923, `E0433` does not implement any suggestions, and the PR introduces suggestions for missing `use`s. When a resolution error occurs in the path of a function call, it tries to smart resolve just the type part of the path, e.g. `module::Struct` of a call to `module::Struct::foo()`. However, along with the suggestions, the smart-resolve function will report `E0412` since it only knows that it is a type that we cannot resolve instead of being a part of the path. So, the original implementation swap out `E0412` errors returned by the smart-resolve function with the real `E0433` error, but keeps the "missing `use`" suggestions to be reported to the programmer.
**Issue**
The current implementation only reports if there are "missing `use`" suggestions returned by the smart-resolve function; otherwise, it would fall back the normal reporting, which does not emit suggestions. But the smart-resolve function could also produce typo suggestions, which are omitted currently.
Also, it seems like that not all info has been swapped out when there are missing suggestions. The error message underlining the name in the snippet still says ``not found in this scope``, which is a `E0412` messages, if there are `use` suggestions, but says the normal `use of undeclared type` otherwise.
**Fixes**
This fix swaps out all fields in `Diagnostic` returned by the smart-resolve function except for `suggestions` with the current error, and merges the `suggestions` of the returned error and that of the current error together. If there are `use` suggestions, the error is saved to `use_injection` to be reported at the end; otherwise, the error is emitted immediately as `Resolver::report_error` does.
Some tests are updated to use the correct underlining error messages, and one additional test for typo suggestion is added to the test suite.
r? rust-lang/diagnostics
Rewrite implementation of `#[alloc_error_handler]`
The new implementation doesn't use weak lang items and instead changes `#[alloc_error_handler]` to an attribute macro just like `#[global_allocator]`.
The attribute will generate the `__rg_oom` function which is called by the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom` function is defined in any crate then the compiler shim will call `__rdl_oom` in the alloc crate which will simply panic.
This also fixes link errors with `-C link-dead-code` with `default_alloc_error_handler`: `__rg_oom` was previously defined in the alloc crate and would attempt to reference the `oom` lang item, even if it didn't exist. This worked as long as `__rg_oom` was excluded from linking since it was not called.
This is a prerequisite for the stabilization of `default_alloc_error_handler` (#102318).
interpret: move type_name implementation to an interpreter-independent helper file
This should avoid pinging rust-lang/miri each time that file changes, which is really not necessary.
r? `@oli-obk`
Reduce span of let else irrefutable_let_patterns warning
Huge spans aren't good for IDE users as they underline constructs that are possibly multiline.
Similar PR to #90761 which did the same for the `unused_macros` lint.
The new implementation doesn't use weak lang items and instead changes
`#[alloc_error_handler]` to an attribute macro just like
`#[global_allocator]`.
The attribute will generate the `__rg_oom` function which is called by
the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom`
function is defined in any crate then the compiler shim will call
`__rdl_oom` in the alloc crate which will simply panic.
This also fixes link errors with `-C link-dead-code` with
`default_alloc_error_handler`: `__rg_oom` was previously defined in the
alloc crate and would attempt to reference the `oom` lang item, even if
it didn't exist. This worked as long as `__rg_oom` was excluded from
linking since it was not called.
This is a prerequisite for the stabilization of
`default_alloc_error_handler` (#102318).
Before this PR, the compiler would emit the debuginfo name `slice$<T>`
for all kinds of slices, regardless of whether they are behind a
reference or not and regardless of the kind of reference. As a
consequence, the types `Foo<&[T]>`, `Foo<[T]>`, and `Foo<&mut [T]>`
would end up with the same type name `Foo<slice$<T> >` in debuginfo,
making it impossible to disambiguate between them by name. Similarly,
`&str` would get the name `str` in debuginfo, so the debuginfo name for
`Foo<str>` and `Foo<&str>` would be the same. In contrast,
`*const [bool]` and `*mut [bool]` would be `ptr_const$<slice$<bool> >`
and `ptr_mut$<slice$<bool> >`, i.e. the encoding does not lose
information about the type.
This PR removes all special handling for slices and `str`. The types
`&[bool]`, `&mut [bool]`, and `&str` thus get the names
`ref$<slice2$<bool> >`, `ref_mut$<slice2$<bool> >`, and
`ref$<str$>` respectively -- as one would expect.
Rollup of 8 pull requests
Successful merges:
- #97971 (Enable varargs support for calling conventions other than C or cdecl )
- #101428 (Add mir building test directory)
- #101944 (rustdoc: clean up `#toggle-all-docs`)
- #102101 (check lld version to choose correct option to disable multi-threading in tests)
- #102689 (Add a tier 3 target for the Sony PlayStation 1)
- #103746 (rustdoc: add support for incoherent impls on structs and traits)
- #103758 (Add regression test for reexports in search results)
- #103764 (All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`
Follow-up to #103428. That pr only partially fixed#94187. In some cases (like closures) `std::any::type_name` was still producing a different output when `-Zverbose` was enabled.
This pr fixes those cases and adds a new function `PrettyPrinter::should_print_verbose`. This function should always be used over `self.tcx().sess.verbose()` inside a `impl PrettyPrinter`.
Maybe closes#94187 now.
r? ``@compiler-errors``
Add a tier 3 target for the Sony PlayStation 1
This adds a tier 3 target, `mipsel-sony-psx`, for the Sony PlayStation 1. I've tested it pretty thoroughly with [this SDK](https://github.com/ayrtonm/psx-sdk-rs) I wrote for it.
From the [tier 3 target policy](https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-3-target-policy) (I've omitted the subpoints for brevity, but read over everything)
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I'd be the designated developer
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
The target name follows the conventions of the existing PSP target (`mipsel-sony-psp`) and uses `psx` following the convention of the broader [PlayStation homebrew community](https://psx-spx.consoledev.net/).
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
No legal issues with this target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
👍
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
The psx supports `core` and `alloc`, but will likely not support `std` anytime soon.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
This target has an SDK and a `cargo-psx` tool for formatting binaries as psx executables. Documentation and examples are provided in the [psx-sdk-rs README](https://github.com/ayrtonm/psx-sdk-rs#psx-sdk-rs), the SDK and cargo tool are both available through crates.io and docs.rs has [SDK documentation](https://docs.rs/psx/latest/psx/).
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
👍
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
No problem
Add mir building test directory
The first commit renames `mir-map.0` mir dumps to `built.after` dumps. I am happy to drop this commit if someone can explain the origin of the name.
The second commit moves a bunch of mir building tests into their own directory. I did my best to make sure that all of these tests are actually testing mir building, and not just incidentally using `built.after`
r? ``@oli-obk``
Enable varargs support for calling conventions other than C or cdecl
This patch makes it possible to use varargs for calling conventions,
which are either based on C (efiapi) or C is based on them (sysv64 and win64).
Also pinging ``@phlopsi,`` because he noticed first this oversight when writing a library for UEFI.
`codegen_switchint_terminator` already uses `br` instead of `switch`
when there is one normal target plus the `otherwise` target. But there's
another common case with two normal targets and an `otherwise` target
that points to an empty unreachable BB. This comes up a lot when
switching on the tags of enums that use niches.
The pattern looks like this:
```
bb1: ; preds = %bb6
%3 = load i8, ptr %_2, align 1, !range !9, !noundef !4
%4 = sub i8 %3, 2
%5 = icmp eq i8 %4, 0
%_6 = select i1 %5, i64 0, i64 1
switch i64 %_6, label %bb3 [
i64 0, label %bb4
i64 1, label %bb2
]
bb3: ; preds = %bb1
unreachable
```
This commit adds code to convert the `switch` to a `br`:
```
bb1: ; preds = %bb6
%3 = load i8, ptr %_2, align 1, !range !9, !noundef !4
%4 = sub i8 %3, 2
%5 = icmp eq i8 %4, 0
%_6 = select i1 %5, i64 0, i64 1
%6 = icmp eq i64 %_6, 0
br i1 %6, label %bb4, label %bb2
bb3: ; No predecessors!
unreachable
```
This has a surprisingly large effect on compile times, with reductions
of 5% on debug builds of some crates. The reduction is all due to LLVM
taking less time. Maybe LLVM is just much better at handling `br` than
`switch`.
The resulting code is still suboptimal.
- The `icmp`, `select`, `icmp` sequence is silly, converting an `i1` to an `i64`
and back to an `i1`. But with the current code structure it's hard to avoid,
and LLVM will easily clean it up, in opt builds at least.
- `bb3` is usually now truly dead code (though not always, so it can't
be removed universally).
Don't use usub.with.overflow intrinsic
The canonical form of a usub.with.overflow check in LLVM are separate sub + icmp instructions, rather than a usub.with.overflow intrinsic. Using usub.with.overflow will generally result in worse optimization potential.
The backend will attempt to form usub.with.overflow when it comes to actual instruction selection. This is not fully reliable, but I believe this is a better tradeoff than using the intrinsic in IR.
Fixes#103285.
rustdoc: Simplify modifications of effective visibility table
It is now obvious that rustdoc only calls `set_access_level` with foreign def ids and `AccessLevel::Public`.
The second commit makes one more step and separates effective visibilities coming from rustc from similar data collected by rustdoc for extern `DefId`s.
The original table is no longer modified and now only contains local def ids as populated by rustc.
cc https://github.com/rust-lang/rust/pull/102026 `@Bryanskiy`
Point only to the identifiers in the typo suggestions of shadowed names instead of the entire struct
Fixes#103358.
As discussed in the issue, the `Span` of the candidate `Ident` for a typo replacement is stored alongside its `Symbol` in `TypoSuggestion`. Then, the span of the identifier is what the "you might have meant to refer to" note is pointed at, rather than the entire struct definition.
Comments in #103111 and the issue both suggest that it is desirable to:
1. include names defined in the same crate as the typo,
2. ignore names defined elsewhere such as in `std`, _and_
3. include names introduced indirectly via `use`.
Since a name from another crate but introduced via `use` has non-local `def_id`, to achieve this, a suggestion is displayed if either the `def_id` of the suggested name is local, or the `span` of the suggested name is in the same file as the typo itself.
Some UI tests have also been modified to reflect this change.
r? `@cjgillot`
Allow `impl Fn() -> impl Trait` in return position
_This was originally proposed as part of #93082 which was [closed](https://github.com/rust-lang/rust/pull/93082#issuecomment-1027225715) due to allowing `impl Fn() -> impl Trait` in argument position._
This allows writing the following function signatures:
```rust
fn f0() -> impl Fn() -> impl Trait;
fn f3() -> &'static dyn Fn() -> impl Trait;
```
These signatures were already allowed for common traits and associated types, there is no reason why `Fn*` traits should be special in this regard.
`impl Trait` in both `f0` and `f3` means "new existential type", just like with `-> impl Iterator<Item = impl Trait>` and such.
Arrow in `impl Fn() ->` is right-associative and binds from right to left, it's tested by [this test](a819fecb8d/src/test/ui/impl-trait/impl_fn_associativity.rs).
There even is a test that `f0` compiles:
2f004d2d40/src/test/ui/impl-trait/nested_impl_trait.rs (L25-L28)
But it was changed in [PR 48084 (lines)](https://github.com/rust-lang/rust/pull/48084/files#diff-ccecca938872d65ffe8cd1c3ef1956e309fac83bcda547d8b16b89257e53a437R37) to test the opposite, probably unintentionally given [PR 48084 (lines)](https://github.com/rust-lang/rust/pull/48084/files#diff-5a02f1ed43debed1fd24f7aad72490064f795b9420f15d847bac822aa4621a1cR476-R477).
r? `@nikomatsakis`
----
This limitation is especially annoying with async code, since it forces one to write this:
```rust
trait AsyncFn3<A, B, C>: Fn(A, B, C) -> <Self as AsyncFn3<A, B, C>>::Future {
type Future: Future<Output = Self::Out>;
type Out;
}
impl<A, B, C, Fut, F> AsyncFn3<A, B, C> for F
where
F: Fn(A, B, C) -> Fut,
Fut: Future,
{
type Future = Fut;
type Out = Fut::Output;
}
fn async_closure() -> impl AsyncFn3<i32, i32, i32, Out = u32> {
|a, b, c| async move { (a + b + c) as u32 }
}
```
Instead of:
```rust
fn async_closure() -> impl Fn(i32, i32, i32) -> impl Future<Output = u32> {
|a, b, c| async move { (a + b + c) as u32 }
}
```
Accept `TyCtxt` instead of `TyCtxtAt` in `Ty::is_*` functions
Functions in answer:
- `Ty::is_freeze`
- `Ty::is_sized`
- `Ty::is_unpin`
- `Ty::is_copy_modulo_regions`
This allows to remove a lot of useless `.at(DUMMY_SP)`, making the code a bit nicer :3
r? `@compiler-errors`
Rename some `OwnerId` fields.
`@spastorino` noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of `def_id` for values of type `LocalDefId` is *very* widespread, so I left that alone.
r? `@compiler-errors`
filter candidates in pick probe for diagnostics
Fixes#103411, though also fine with closing this PR if my opinion (https://github.com/rust-lang/rust/issues/103411#issuecomment-1287900069) is shared that this doesn't need to be fixed.
```
~/rust3$ time rustc +nightly ~/test.rs 2>/dev/null
real 0m4.853s
user 0m4.837s
sys 0m0.016s
~/rust3$ time rustc +rust3 ~/test.rs 2>/dev/null
real 0m0.193s
user 0m0.169s
sys 0m0.024s
```
Also fixes#103427.
spastorino noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so
those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of
`def_id` for values of type `LocalDefId` is *very* widespread, so I left
that alone.
Note scope of TAIT more accurately
This maybe explains why the person was confused in #101897, since we say "same module" but really should've said "same impl".
r? ``@oli-obk``
Introduce UnordMap, UnordSet, and UnordBag (MCP 533)
This is the start of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
I followed `@eddyb's` suggestion of naming the collection types `Unord(Map/Set/Bag)` which is a bit easier to type than `Unordered(Map/Set/Bag)`
r? `@eddyb`
privacy: Rename "accessibility levels" to "effective visibilities"
And a couple of other naming and comment tweaks.
Related to https://github.com/rust-lang/rust/issues/48054
For `enum Level` I initially used naming `enum EffectiveVisibilityLevel`, but it was too long and inconvenient because it's used pretty often.
So I shortened it to just `Level`, if it needs to be used from some context where this name would be ambiguous, then it can be imported with renaming like `use rustc_middle::privacy::Level as EffVisLevel` or something.
Fix line numbers for MIR inlined code
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
Fixes#103068
Change reported_violations to use IndexSet
It is being used to iterate and to insert, without a lot of lookups
so hopefully it won't be a perf hit
Change MiniGraph.nodes to use IndexSet
It is being used to iterate and to insert, without performing lookups
so hopefully it won't be a perf hit
Change RegionConstraintData.givens to a FxIndexSet
This might result in a perf hit. Remove was being used in `givens`,
and `FxIndexSet` doesn't allow calling remove without losing the
fixed iteration order. So it was necessary to change remove to
`shift_remove`, but this method is slower.
Change OpaqueTypesVisitor to use stable sets and maps
This could also be a perf hit.
Make TraitObject visitor use a stable set
Emit a nicer error on `impl Self {`
currently it emits a "cycle detected error" but this PR makes it emit a more user friendly error specifically saying that `Self` is disallowed in that position. this is a pretty hacky fix so i dont expect this to be merged (I basically only made this PR because i wanted to see if CI passes)
r? ``@compiler-errors``
Remap early bound lifetimes in return-position `impl Trait` in traits too
Fixes part of #103457
r? ``@cjgillot,`` though feel free to reassign, just thought you'd have sufficient context to review.
Don't carry MIR location in `ConstraintCategory::CallArgument`
It turns out that `ConstraintCategory::CallArgument` cannot just carry a MIR location in it, since we may bubble them up to totally different MIR bodies.
So instead, revert the commit a6b5f95fb0, and instead just erase regions from the original `Option<Ty<'tcx>>` that it carried, so that it doesn't ICE with the changes in #103220.
Best reviewed in parts -- the first is just a revert, and the second is where the meaningful changes happen.
Fixes#103624
diagnostics: do not suggest static candidates as traits to import
If it's a static candidate, then it's already implemented. Do not suggest it a second time for implementing.
Partial fix for #102354
Add suggestions for unsafe impl error codes
Adds suggestions for users to add `unsafe` to trait impls that should be `unsafe`, and remove `unsafe` from trait impls that do not require `unsafe`
With the folllowing code:
```rust
struct Foo {}
struct Bar {}
trait Safe {}
unsafe trait Unsafe {}
impl Safe for Foo {} // ok
impl Unsafe for Foo {} // E0200
unsafe impl Safe for Bar {} // E0199
unsafe impl Unsafe for Bar {} // ok
// omitted empty main fn
```
The current rustc output is:
```
error[E0199]: implementing the trait `Safe` is not unsafe
--> e0200.rs:13:1
|
13 | unsafe impl Safe for Bar {} // E0199
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0200]: the trait `Unsafe` requires an `unsafe impl` declaration
--> e0200.rs:11:1
|
11 | impl Unsafe for Foo {} // E0200
| ^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0199, E0200.
For more information about an error, try `rustc --explain E0199`.
```
With this PR, the future rustc output would be:
```
error[E0199]: implementing the trait `Safe` is not unsafe
--> ../../temp/e0200.rs:13:1
|
13 | unsafe impl Safe for Bar {} // E0199
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: remove `unsafe` from this trait implementation
|
13 - unsafe impl Safe for Bar {} // E0199
13 + impl Safe for Bar {} // E0199
|
error[E0200]: the trait `Unsafe` requires an `unsafe impl` declaration
--> ../../temp/e0200.rs:11:1
|
11 | impl Unsafe for Foo {} // E0200
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: the trait `Unsafe` enforces invariants that the compiler can't check. Review the trait documentation and make sure this implementation upholds those invariants before adding the `unsafe` keyword
help: add `unsafe` to this trait implementation
|
11 | unsafe impl Unsafe for Foo {} // E0200
| ++++++
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0199, E0200.
For more information about an error, try `rustc --explain E0199`.
```
``@rustbot`` label +T-compiler +A-diagnostics +A-suggestion-diagnostics
Add flag to forbid recovery in the parser
To start the effort of fixing #103534, this adds a new flag to the parser, which forbids the parser from doing recovery, which it shouldn't do in macros.
This doesn't add any new checks for recoveries yet and is just here to bikeshed the names for the functions here before doing more.
r? `@compiler-errors`
rustc_metadata: Add struct and variant constructors to module children at encoding time
instead of decoding time.
Continuation of https://github.com/rust-lang/rust/pull/95899.
The last time it caused some ICEs from generator use, but not everything seems ok.
Clean up hidden type registration
work on https://github.com/rust-lang/rust/issues/101186
Actually passing down the relation and using it instead of `eq` for the hidden type comparison has *no* effect whatsoever and allows for no further improvements at the call sites. I decided the increased complexity was not worth it and thus did not include that change in this PR.
r? `@compiler-errors`
Rollup of 9 pull requests
Successful merges:
- #103035 (Even nicer errors from assert_unsafe_precondition)
- #103106 (Try to say that memory outside the AM is always exposed)
- #103475 (Make param index generation a bit more robust)
- #103525 (Move a wf-check into the site where the value is instantiated)
- #103564 (library: allow some unused things in Miri)
- #103586 (Process registered region obligation in `resolve_regions_with_wf_tys`)
- #103592 (rustdoc: remove redundant CSS selector `.notable-traits .notable`)
- #103593 (Remove an unused parser function (`Expr::returns`))
- #103611 (Add test for issue 103574)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `commit_if_ok` probe from NLL type relation
It was not really necessary to add the `commit_if_ok` in #100092 -- I added it to protect us against weird inference error messages due to recursive RPIT calls, but we are always on the error path when this happens anyways, and I can't come up with an example that makes this manifest.
Fixes#103599
r? `@oli-obk` since you reviewed #100092, feel free to re-roll.
🅱️📢 beta-nominating this since it's on beta (which forks in ~a week~ two days 😨) -- worst case we could revert the original PR on beta and land this on nightly, to give it some extra soak time...
The current logic to ignore ThinLTO when `-Ccodegen-units=1` makes sense
for local ThinLTO but even in this scenario, a user may still want
(non-local) ThinLTO for the purpose of optimizing dependencies into the
final crate which is being compiled with 1 CGU.
The previous behavior was even more confusing because if you were
generating a binary (`--emit=link`), then you would get ThinLTO but if
you asked for LLVM IR or bytecode, then it would silently change to
using regular LTO.
With this change, we only override the defaults for local ThinLTO if you
ask for a single output such as LLVM IR or bytecode and in all other
cases honor the requested LTO setting.
Diagnostic derives: allow specifying multiple alternative suggestions
This allows porting `span_suggestions()` to diagnostic structs.
Doesn't work for `multipart_suggestions()` because the rank would be reversed - the struct would specify multiple spans, each of which has multiple possible replacements, while `multipart_suggestions()` creates multiple possible replacements, each with multiple spans.
suggest type annotation for local statement initialed by ref expression
In a local statement with a type declaration, if a ref expression is used on the right side and not used on the left side, in addition to removing the `&` and `&mut` on the right side, we can add them on the left side alternatively
Fixes#102892
Add eval hack in `super_relate_consts` back
Partially reverts 01adb7e98d.
This extra eval call *still* needs to happen, for example, in `normalize_param_env_or_error` when a param-env predicate has an unnormalized constant, since the param-env candidates never get normalized during candidate assembly (everywhere else we can assume that they are normalized fully).
r? `@lcnr,` though I feel like I've assigned quite a few PRs to you in the last few days, so feel free to reassign to someone else familiar with this code if you're busy!
cc #103243 (fixes the issue, but don't want to auto-close that until a backport is performed).
Assert if inference vars are leaking from `InferCtxt::fully_resolve`
`InferCtxt::fully_resolve` shouldn't return unresolved inference vars without us at least being aware of it, so make it an assertion now. This should only happen in cases where we used to be returning `ReEmpty`...
cc `@jackh726`
Split phase change from `MirPass`
The main goal here is to simplify the pass manager logic. `MirPass` no longer contains the `phase_change` method, and `run_passes` instead accepts an `Option<PhaseChange>`. The hope is that this addresses the comments (and maybe perf regression) from #99102 .
r? `@oli-obk` cc `@RalfJung`
This allows writing the following function signatures:
```rust
fn f0() -> impl Fn() -> impl Trait;
fn f3() -> &'static dyn Fn() -> impl Trait;
```
These signatures were already allowed for common traits and associated
types, there is no reason why `Fn*` traits should be special in this
regard.
rustc: Use `unix_sigpipe` instead of `rustc_driver::set_sigpipe_handler`
This is the first (known) step towards starting to use `unix_sigpipe` in the wild. Eventually, `rustc_driver::set_sigpipe_handler` can be removed and all clients can use `unix_sigpipe` instead.
For now we just start using `unix_sigpipe` in one place: `rustc` itself.
It is easy to manually verify this change. If you remove `#[unix_sigpipe = "sig_dfl"]` and run `./x.py build` you will get an ICE when you do `./build/x86_64-unknown-linux-gnu/stage1/bin/rustc --help | false`. Add back `#[unix_sigpipe = "sig_dfl"]` and the ICE disappears again.
PR that added `set_sigpipe_handler`: https://github.com/rust-lang/rust/pull/49606
Tracking issue for `unix_sigpipe`: #97889
Not sure exactly how to label this PR. Going with T-libs for now since this is a T-libs feature.
````@rustdoc```` labels +T-libs
Support raw-dylib functions being used inside inlined functions
Fixes#102714
Issue Details:
When generating the import library for `raw-dylib` symbols, we currently only use the functions and variables declared within the current crate. This works fine if all crates are static libraries or `rlib`s as the generated import library will be contained in the static library or `rlib` itself, but if a dependency is a dynamic library AND the use of a `raw-dylib` function or variable is inlined or part of a generic instantiation then the current crate won't see its dependency's import library and so linking will fail.
Fix Details:
Instead, when we generate the import library for a `dylib` or `bin` crate, we will now generate it for the symbols both for the current crate and all upstream crates. We do this in two steps so that the import library for the current crate is passed into the linker first, thus it is preferred if there are any ambiguous symbols.
`TerminatorCodegenHelper` has three methods `llblock`, `llbb`, and
`lltarget`. They're all similar, but the names given no indication of
the differences.
This commit renames `lltarget` as `llbb_with_landing_pad`, and `llblock`
as `llbb_with_cleanup`. These aren't fantastic names, but at least it's
now clear that `llbb` is the lowest-level of the three and the other two
wrap it.
Ensure:
- builders always have a `bx` suffix;
- backend basic blocks always have an `llbb` suffix,
- paired builders and basic blocks have consistent prefixes.
Delay span bug when we can't map lifetimes back in `collect_trait_impl_trait_tys`
When a lifetime is late-bound in a trait signature, but early-bound in an impl signature, we already emit an error -- however, we also ICE in `collect_trait_impl_trait_tys`, so just delay a bug here.
Fixes#103407
Don't ICE when reporting borrowck errors involving regions from `anonymous_lifetime_in_impl_trait`
The issue here is that when we have:
```
trait Trait<'a> { .. }
fn foo(arg: impl Trait) { .. }
```
The anonymous lifetime `'_` that we generate for `arg: impl Trait` doesn't end up in the argument type (which is a param) but in a where-clause of the function, in a predicate whose self type is that param ty.
Fixes#101660
r? ``@cjgillot``
Only apply `ProceduralMasquerade` hack to older versions of `rental`
The latest version of `rental` (v0.5.6) contains a fix that allows it to
compile without relying on the pretty-print back-compat hack.
Hopefully, there are no longer any crates relying on the affected
versions of the (much less popular) `procedural-masquerade` crate. This
should allow us to target the pretty-print back-compat hack specifically
to older versions of `rental`, and specifically mention upgrading to
`rental` v0.5.6 in the lint message.
Sort tests at compile time, not at startup
Recently, another Miri user was trying to run `cargo miri test` on the crate `iced-x86` with `--features=code_asm,mvex`. This configuration has a startup time of ~18 minutes. That's ~18 minutes before any tests even start to run. The fact that this crate has over 26,000 tests and Miri is slow makes a lot of code which is otherwise a bit sloppy but fine into a huge runtime issue.
Sorting the tests when the test harness is created instead of at startup time knocks just under 4 minutes out of those ~18 minutes. I have ways to remove most of the rest of the startup time, but this change requires coordinating changes of both the compiler and libtest, so I'm sending it separately.
(except for doctests, because there is no compile-time harness)
Shorten the `lookup_line` code slightly
The `match` looks like it's exactly the same as `checked_sub(1)`, so we might as well see if perf says we can just do that to save a couple lines.
This patch makes it possible to use varargs for calling conventions,
which are either based on C (like efiapi) or C is based
on them (for example sysv64 and win64).
Pretty print lifetimes captured by RPIT
This specifically makes the output in #103409 change from:
```diff
error: `impl` item signature doesn't match `trait` item signature
--> $DIR/signature-mismatch.rs:15:5
|
LL | fn async_fn(&self, buff: &[u8]) -> impl Future<Output = Vec<u8>>;
| ----------------------------------------------------------------- expected `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
...
LL | fn async_fn<'a>(&self, buff: &'a [u8]) -> impl Future<Output = Vec<u8>> + 'a {
- | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>> + '2`
|
= note: expected `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
- found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>>`
+ found `fn(&'1 Struct, &'2 [u8]) -> impl Future<Output = Vec<u8>> + '2`
= help: the lifetime requirements from the `impl` do not correspond to the requirements in the `trait`
= help: verify the lifetime relationships in the `trait` and `impl` between the `self` argument, the other inputs and its output
error: aborting due to previous error
```
Along with the UI tests in this PR, which I think are all improvements!
r? `@oli-obk` though feel free to re-roll
Fix wrapped valid-range handling in ty_find_init_error
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
`ty_find_init_error` assumed that `lo > 0` means the type cannot contain a
zero.
Fix it to handle wrapping ranges.
This allows porting uses of span_suggestions() to diagnostic structs.
Doesn't work for multipart_suggestions() because the rank would be
reversed - the struct would specify multiple spans, each of which has
multiple possible replacements, while multipart_suggestions() creates
multiple possible replacements, each with multiple spans.
Enable LTO for rustc_driver.so
Alternative to https://github.com/rust-lang/rust/pull/97154
This enables LTO'ing dylibs behind a feature flag and uses this feature for compiling rustc_driver.so.
Rollup of 6 pull requests
Successful merges:
- #101293 (Recover when unclosed char literal is parsed as a lifetime in some positions)
- #101908 (Suggest let for assignment, and some code refactor)
- #103192 (rustdoc: Eliminate uses of `EarlyDocLinkResolver::all_traits`)
- #103226 (Check `needs_infer` before `needs_drop` during HIR generator analysis)
- #103249 (resolve: Revert "Set effective visibilities for imports more precisely")
- #103305 (Move some tests to more reasonable places)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
resolve: Revert "Set effective visibilities for imports more precisely"
In theory the change was correct, but in practice the use of import items in HIR is limited and hacky, and it expects that (effective) visibilities for all (up to) 3 IDs of the import are set to the value reflecting (effective) visibility of the whole syntactic `use` item rather than its individual components.
Fixes https://github.com/rust-lang/rust/issues/102352
r? `@oli-obk`
Check `needs_infer` before `needs_drop` during HIR generator analysis
This is kinda a revival of #103036, but with the understanding that after fallback, a generator-interior type will only have `needs_infer` true if there's an error that prevented int or float variable fallback to occur (modulo region variables, which are erased).
Therefore the best choice here is to delay a bug and skip the `needs_drop` call altogether.
r? `@lcnr` feel free to reassign though
Flatten diagnostic slug modules
This makes it easier to grep for the slugs in the code.
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error for more discussion about it.
This was mostly done with a few regexes and a bunch of manual work. This also exposes a pretty annoying inconsistency for the extra labels. Some of the extra labels are defined as additional properties in the fluent message (which makes them not prefixed with the crate name) and some of them are new fluent messages themselves (which makes them prefixed with the crate name). I don't know whether we want to clean this up at some point but it's useful to know.
r? `@davidtwco`
Change `unknown_lint` applicability to `MaybeIncorrect`
This small PR changes the applicability of `unknown_lint` to `MaybeIncorrect`, because the suggested lint might not be the correct one.
Here is one example where the current applicability causes a problem. Clippy has a set of internal lints guarded by a feature called `internal`. If the feature is not enabled, then the internal lints are "unknown." In that case, running `cargo clippy --fix ...` on `clippy_utils` causes lines such as the followig
26c96e3416/src/tools/clippy/clippy_utils/src/paths.rs (L51-L52)
to be changed to
```rust
#[expect(clippy::invalid_regex)] // internal lints do not know about all external crates
pub const FUTURES_IO_ASYNCREADEXT: [&str; 3] = ["futures_util", "io", "AsyncReadExt"];
```
which is not correct.
Delay ambiguity span bug in normalize query iff not rustdoc
Oli and I decided that the compiler debt of adding another usage of `tcx.sess.opts.actually_rustdoc` is fine, because we don't really want to add more complexity to the normalize query, and moving rustdoc to use fulfill normalization (`fully_normalize`, i.e. not use the normalize query) is unnecessary overhead given that it's skipping binders and stuff.
r? oli-obk
Fixes#102827Fixes#103181
Handle return-position `impl Trait` in traits properly in `register_hidden_type`
The bounds that we get by calling `bound_explicit_item_bounds` from an RPITIT have projections, not opaques, but when we're *registering* an opaque, we want to treat it like an opaque.
Coincidentally fixes#102688 as well, which makes sense, since that was failing because we were inferring an opaque type to be equal to itself (opaque cycle error => "cannot resolve opaque type").
Fixes#103352
r? ```@oli-obk```
Do not suggest trivially false const predicates
Pass through constness to `predicate_can_apply` and don't suggest other impls if it's satisfied but not const.
Fixes#103267
Introduce `subst_iter` and `subst_iter_copied` on `EarlyBinder`
Makes working with bounds lists a bit easier, which I seem to do a lot.
Specifically, means that we don't need to do `.transpose_iter().map(|(pred, _)| *pred)` every time we want to iterate through an `EarlyBinder<&'tcx [(Predicate, Span)]>` (and even then, still have to call `subst` later), which was a very awkward idiom imo.
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
ty_find_init_error assumed that `lo > 0` means the type cannot contain a
zero.
Fix it to handle wrapping ranges.
Add a test to cover this case.
Allow semicolon after closure within parentheses in macros
#88546 added some parsing logic that if we're parsing a closure, and we're within parentheses, and a semicolon follows, then we must be parsing something erroneous like: `f(|| a; b)`, so it replaces the closure body with an error expression. However, it's valid to parse those tokens if we're within a macro, as in #103222.
This is a bit unsatisfying fix. Is there a more robust way of checking that we're within a macro?
I would also be open to removing this "_It is likely that the closure body is a block but where the braces have been removed_" check altogether at the expense of more verbose errors, since it seems very suspicious in the first place...
Fixes#103222.
Slightly tweak comments wrt `lint_overflowing_range_endpoint`
From the review: https://github.com/rust-lang/rust/pull/101986#discussion_r975610611
It _seemed_ that the lint was not emitted when the `if` check failed, but _actually_ this happens already in a special case and the lint is emitted outside of this function, if this function doesn't. I've cleared up the code/comments a bit, so it's more obvious :)
r? ```@estebank```
Remove byte swap of valtree hash on big endian
This addresses problem reported in #103183. The code was originally introduced in e14b34c386. (see https://github.com/rust-lang/rust/pull/96591)
On big-endian environment, this operation sequence actually put the other half from 128-bit result, thus we got different hash result on LE and BE.
stop using `ty::UnevaluatedConst` directly
best reviewed commit by commit.
simplifies #99798 because we now don't have to expand `ty::UnevaluatedConst` to `ty::Const`.
I also remember some other places where using `ty::UnevaluatedConst` directly was annoying and caused issues, though I don't quite remember what they were rn '^^
r? `@oli-obk` cc `@JulianKnodt`
Get rid of native_library projection queries
They don't seem particularly useful as I don't expect native libraries to change frequently.
Maybe they do provide significant value of keeping incremental compilation green though, I'm not sure.
The latest version of `rental` (v0.5.6) contains a fix that allows it to
compile without relying on the pretty-print back-compat hack.
Hopefully, there are no longer any crates relying on the affected
versions of the (much less popular) `procedural-masquerade` crate. This
should allow us to target the pretty-print back-compat hack specifically
to older versions of `rental`, and specifically mention upgrading to
`rental` v0.5.6 in the lint message.
Introduce deduced parameter attributes, and use them for deducing `readonly` on indirect immutable freeze by-value function parameters.
Introduce deduced parameter attributes, and use them for deducing `readonly` on
indirect immutable freeze by-value function parameters.
Right now, `rustc` only examines function signatures and the platform ABI when
determining the LLVM attributes to apply to parameters. This results in missed
optimizations, because there are some attributes that can be determined via
analysis of the MIR making up the function body. In particular, `readonly`
could be applied to most indirectly-passed by-value function arguments
(specifically, those that are freeze and are observed not to be mutated), but
it currently is not.
This patch introduces the machinery that allows `rustc` to determine those
attributes. It consists of a query, `deduced_param_attrs`, that, when
evaluated, analyzes the MIR of the function to determine supplementary
attributes. The results of this query for each function are written into the
crate metadata so that the deduced parameter attributes can be applied to
cross-crate functions. In this patch, we simply check the parameter for
mutations to determine whether the `readonly` attribute should be applied to
parameters that are indirect immutable freeze by-value. More attributes could
conceivably be deduced in the future: `nocapture` and `noalias` come to mind.
Adding `readonly` to indirect function parameters where applicable enables some
potential optimizations in LLVM that are discussed in [issue 103103] and [PR
103070] around avoiding stack-to-stack memory copies that appear in functions
like `core::fmt::Write::write_fmt` and `core::panicking::assert_failed`. These
functions pass a large structure unchanged by value to a subfunction that also
doesn't mutate it. Since the structure in this case is passed as an indirect
parameter, it's a pointer from LLVM's perspective. As a result, the
intermediate copy of the structure that our codegen emits could be optimized
away by LLVM's MemCpyOptimizer if it knew that the pointer is `readonly
nocapture noalias` in both the caller and callee. We already pass `nocapture
noalias`, but we're missing `readonly`, as we can't determine whether a
by-value parameter is mutated by examining the signature in Rust. I didn't have
much success with having LLVM infer the `readonly` attribute, even with fat
LTO; it seems that deducing it at the MIR level is necessary.
No large benefits should be expected from this optimization *now*; LLVM needs
some changes (discussed in [PR 103070]) to more aggressively use the `noalias
nocapture readonly` combination in its alias analysis. I have some LLVM patches
for these optimizations and have had them looked over. With all the patches
applied locally, I enabled LLVM to remove all the `memcpy`s from the following
code:
```rust
fn main() {
println!("Hello {}", 3);
}
```
which is a significant codegen improvement over the status quo. I expect that if this optimization kicks in in multiple places even for such a simple program, then it will apply to Rust code all over the place.
[issue 103103]: https://github.com/rust-lang/rust/issues/103103
[PR 103070]: https://github.com/rust-lang/rust/pull/103070
make `order_dependent_trait_objects` show up in future-breakage reports
tried to change it to a hard error in #102474 but breaking the more than 1000 dependents of `traitobject` doesn't feel great 😅
This lint has existed since more than 3 years now and the way this is currently implemented is buggy and will break with #102472. imo we should upgrade it to also report for dependencies and maybe also backport this to beta. Then after maybe 2-3 stable versions I would like to finally convert this lint to a hard error.
Change process spawning to inherit the parent's signal mask by default
Previously, the signal mask was always reset when a child process is
started. This breaks tools like `nohup` which expect `SIGHUP` to be
blocked for all transitive processes.
With this change, the default behavior changes to inherit the signal mask.
This also changes the signal disposition for `SIGPIPE` to only be changed if the `#[unix_sigpipe]` attribute isn't set.
Remove more attributes from metadata
A lot of the attributes that are currently stored in the metadata aren't used at all. The biggest metadata usage comes from the doc attributes currently but they are needed by rustdoc so we only removed the ones that cannot be used in downstream crates (doc comments on private items).
r? `@ghost`
Rollup of 6 pull requests
Successful merges:
- #102287 (Elaborate supertrait bounds when triggering `unused_must_use` on `impl Trait`)
- #102922 (Filtering spans when emitting json)
- #103051 (translation: doc comments with derives, subdiagnostic-less enum variants, more derive use)
- #103111 (Account for hygiene in typo suggestions, and use them to point to shadowed names)
- #103260 (Fixup a few tests needing asm support)
- #103321 (rustdoc: improve appearance of source page navigation bar)
Failed merges:
- #103209 (Diagnostic derives: allow specifying multiple alternative suggestions)
r? `@ghost`
`@rustbot` modify labels: rollup
translation: doc comments with derives, subdiagnostic-less enum variants, more derive use
- Adds support for `doc` attributes in the diagnostic derives so that documentation comments don't result in the derive failing.
- Adds support for enum variants in the subdiagnostic derive to not actually correspond to an addition to a diagnostic.
- Made use of the derive in more places in the `rustc_ast_lowering`, `rustc_ast_passes`, `rustc_lint`, `rustc_session`, `rustc_infer` - taking advantage of recent additions like eager subdiagnostics, multispan suggestions, etc.
cc #100717
Elaborate supertrait bounds when triggering `unused_must_use` on `impl Trait`
Given `impl Trait`, if one of its supertraits has a `#[must_use]`, then trigger the lint. This means that, for example, `-> impl ExactSizeIterator` also triggers the `must_use` on `trait Iterator`, which fixes#102183.
This might need `@rust-lang/lang` sign-off, since it changes the behavior of the lint, so cc'ing them.
move hir typeck into separate crate
second part https://github.com/rust-lang/compiler-team/issues/529
I avoided pretty much anything that wasn't just a simple move + path adjustment. Left fixmes for methods which are at an odd place
r? `@compiler-errors`
indirect immutable freeze by-value function parameters.
Right now, `rustc` only examines function signatures and the platform ABI when
determining the LLVM attributes to apply to parameters. This results in missed
optimizations, because there are some attributes that can be determined via
analysis of the MIR making up the function body. In particular, `readonly`
could be applied to most indirectly-passed by-value function arguments
(specifically, those that are freeze and are observed not to be mutated), but
it currently is not.
This patch introduces the machinery that allows `rustc` to determine those
attributes. It consists of a query, `deduced_param_attrs`, that, when
evaluated, analyzes the MIR of the function to determine supplementary
attributes. The results of this query for each function are written into the
crate metadata so that the deduced parameter attributes can be applied to
cross-crate functions. In this patch, we simply check the parameter for
mutations to determine whether the `readonly` attribute should be applied to
parameters that are indirect immutable freeze by-value. More attributes could
conceivably be deduced in the future: `nocapture` and `noalias` come to mind.
Adding `readonly` to indirect function parameters where applicable enables some
potential optimizations in LLVM that are discussed in [issue 103103] and [PR
103070] around avoiding stack-to-stack memory copies that appear in functions
like `core::fmt::Write::write_fmt` and `core::panicking::assert_failed`. These
functions pass a large structure unchanged by value to a subfunction that also
doesn't mutate it. Since the structure in this case is passed as an indirect
parameter, it's a pointer from LLVM's perspective. As a result, the
intermediate copy of the structure that our codegen emits could be optimized
away by LLVM's MemCpyOptimizer if it knew that the pointer is `readonly
nocapture noalias` in both the caller and callee. We already pass `nocapture
noalias`, but we're missing `readonly`, as we can't determine whether a
by-value parameter is mutated by examining the signature in Rust. I didn't have
much success with having LLVM infer the `readonly` attribute, even with fat
LTO; it seems that deducing it at the MIR level is necessary.
No large benefits should be expected from this optimization *now*; LLVM needs
some changes (discussed in [PR 103070]) to more aggressively use the `noalias
nocapture readonly` combination in its alias analysis. I have some LLVM patches
for these optimizations and have had them looked over. With all the patches
applied locally, I enabled LLVM to remove all the `memcpy`s from the following
code:
```rust
fn main() {
println!("Hello {}", 3);
}
```
which is a significant codegen improvement over the status quo. I expect that
if this optimization kicks in in multiple places even for such a simple
program, then it will apply to Rust code all over the place.
[issue 103103]: https://github.com/rust-lang/rust/issues/103103
[PR 103070]: https://github.com/rust-lang/rust/pull/103070
Previously, the signal mask is always reset when a child process is
started. This breaks tools like `nohup` which expect `SIGHUP` to be
blocked.
With this change, the default behavior changes to inherit the signal mask.
This also changes the signal disposition for `SIGPIPE` to only be
changed if the `#[unix_sigpipe]` attribute isn't set.
interpret: remove an incorrect assertion
This fixes an ICE in Miri, [reported](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/SwitchInt.20with.20no.20targets.3F) by `@saethlin.` The faulty assertion was introduced by 432535da2b, when a previously correct assertion checking that the `otherwise` target exists got replaced by this assertion checking that at least one more target beyond `otherwise` exists.
Sadly we don't have a small reproducer so I don't think we can easily add a testcase.
linker: Fix weak lang item linking with combination windows-gnu + LLD + LTO
In https://github.com/rust-lang/rust/pull/100404 this logic was originally disabled for MSVC due to issues with LTO, but the same issues appear on windows-gnu with LLD because that LLD uses the same underlying logic as MSVC LLD, just with re-syntaxed command line options.
So this PR just disables it for LTO builds in general.
The canonical form of a usub.with.overflow check in LLVM are
separate sub + icmp instructions, rather than a usub.with.overflow
intrinsic. Using usub.with.overflow will generally result in worse
optimization potential.
The backend will attempt to form usub.with.overflow when it comes
to actual instruction selection. This is not fully reliable, but
I believe this is a better tradeoff than using the intrinsic in
IR.
Fixes#103285.
Fix the bug of next_point in source_map
There is a bug in `next_point`, the new span won't move to next position when be called in the first time.
For this reason, our current code is working like this:
1. When we really want to move to the next position, we called two times of `next_point`
2. Some code which use `next_point` actually done the same thing with `shrink_to_hi`
This fix make sure when `next_point` is called, span will move with the width at least 1, and also work correctly in the scenario of multiple bytes.
Ref: https://github.com/rust-lang/rust/pull/103140#discussion_r997710998
r? `@davidtwco`
Deny hashing ty/re/ct inference variables
cc `@cjgillot` and https://github.com/rust-lang/rust/pull/102695#issuecomment-1275706528
r? `@lcnr`
best reviewed one commit at a time, mostly because the second commit that fixes `ClosureOutlivesRequirement` is mostly noise because of losing its `<'tcx>` lifetime parameter.
Do anonymous lifetimes remapping correctly for nested rpits
Closes#103141
r? `@cjgillot` `@nikomatsakis`
This fixes a stable to stable regression that in my opinion is `P-critical` so, we probably want to backport it all the way up to stable.
Use already checked RHS ty for LHS deref suggestions
There's no reason to do the `check_lhs_assignable` and RHS `check_expr_with_hint` in that order, so invert them and use the typeck results to avoid exponential blowup on error.
Fixes#103219
Use Set instead of Vec in transitive_relation
Helps with #103195. It doesn't fix the underlying quadraticness but it makes it _a lot_ faster to an extent where even doubling the amount of nested references still takes less than two seconds (50s on nightly).
I want to see whether this causes regressions (because the vec was usually quite small) or improvements (as lookup for bigger sets is now much faster) in real code.
Let expressions on RHS shouldn't be terminating scopes
Fixes#100276.
Before this PR, we were unconditionally marking the RHS of short-circuiting binary expressions as a terminating scope.
In the case of a let chain where the `let` expression was on the RHS, this meant that temporaries within the `let` expr would only live until the end of the expression. Since this only affected the RHS, this led to surprising behavior ([example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d1b0a5d1f01882f9c89c2194a75eb19f)).
After this PR, we only mark the RHS as a terminating scope if it is not a `let` expression.
Standardize "use parentheses to call" suggestions between typeck and trait selection
1. Suggest calling constructors, since they're basically `FnDef`s but they have a different def kind and hir representation, so we were leaving them out.
2. Standardize the call suggestions between trait fulfillment errors and type mismatch. In the type mismatch suggestion, we suggest `/* Ty */` as the placeholder for an arg, and not the parameter's name, which is less helpful.
3. Use `predicate_must_hold_modulo_regions` instead of matching on `EvaluationResult` -- this might cause some suggestions to be filtered out, but we really shouldn't be suggesting a call if it "may" hold, only when it "must" hold.
4. Borrow some logic from `extract_callable_info` to generalize this suggestion to fn pointers, type parameters, and opaque types.
Fixes#102852
- Make the structure of the two variants more similar.
- Add some comments.
- Move various conditional `use` items inside the function that uses
them.
- Inline some closures.
The illumos linker does not support --strip-debug
When building and testing rust 1.64.0 on illumos, we saw a large number of failing tests associated with:
```
= note: ld: fatal: unrecognized option '--strip-debug'
ld: fatal: use the -z help option for usage information
collect2: error: ld returned 1 exit status
```
The illumos linker does not support the `--strip-debug` option (although it does support `--strip-all`).
Make diagnostic for unsatisfied `Termination` bounds more precise
Don't blindly emit a diagnostic claiming that “*`main` has an invalid return type*” if we encounter a type that should but doesn't implement `std::process::Termination` and isn't actually the return type of the program entry `main`.
Fixes#103052.
``@rustbot`` label A-diagnostics T-compiler T-libs
r? diagnostics
PR #98758 introduced code to avoid redundant assertions in derived code
like this:
```
let _: ::core::clone::AssertParamIsClone<u32>;
let _: ::core::clone::AssertParamIsClone<u32>;
```
But the predicate `is_simple_path` introduced as part of this failed to
account for generic arguments. Therefore the deriving code erroneously
considers types like `Option<bool>` and `Option<f32>` to be the same.
This commit fixes `is_simple_path`.
Fixes#103157.
Remove "execute" bit from lock file permissions
Previously, flock would set the "execute" bit on Rust lock files. That makes no sense.
This patch clears the "execute" bit on Rust lock files.
See issue #102531.
Rollup of 4 pull requests
Successful merges:
- #102454 (Suggest parentheses for possible range method calling)
- #102466 (only allow `ConstEquate` with `feature(gce)`)
- #102945 (Do not register placeholder `RegionOutlives` obligations when `considering_regions` is false)
- #103091 (rustdoc: remove unused HTML class `sidebar-title`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not register placeholder `RegionOutlives` obligations when `considering_regions` is false
**NOTE:** I'm kinda just putting this up for discussion. I'm not certain this is correct...?
This was introduced in [`608625d`](608625dae9 (diff-6e54b18681342ec725d75591dbf384ad08cd73df29db00485fe51b4e90f76ff7R361)).
Interestingly, we only check `data.has_placeholders()` for `RegionOutlives`, and not for `TypeOutlives`... why? For the record, that different treatment between `RegionOutlives` and `TypeOutlives` is why the fix "The compiling succeeds when all `'a : 'b` are replaced with `&'a () : 'b`" in #100689 _"works"_, but it seems like an implementation detail considering this.
Also, why do we care about placeholder regions being registered if `considering_regions` is false? It doesn't seem to affect any UI tests, for example.
r? `@lcnr`
Fixes#102899Fixes#100689
Sometimes it is convenient to return a subdiagnostic enum where one or
more of the variants don't add anything to the diagnostic.
Signed-off-by: David Wood <david.wood@huawei.com>
Documentation comments shouldn't affect the diagnostic derive in any
way, but explicit support has to be added for ignoring the `doc`
attribute.
Signed-off-by: David Wood <david.wood@huawei.com>
Rollup of 5 pull requests
Successful merges:
- #103087 (Documentation BTreeMap::append's behavior for already existing keys)
- #103089 (Mark derived StructuralEq as automatically derived.)
- #103102 (Clarify the possible return values of `len_utf16`)
- #103109 (PhantomData: inline a macro that is used only once)
- #103120 (rustdoc: Do not expect `doc(primitive)` modules to always exist)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix subst issues with return-position `impl Trait` in trait
1. Fix an issue where we were rebase impl substs onto trait method substs, instead of trait substs
2. Fix an issue where early-bound regions aren't being mapped correctly for RPITIT hidden types
Fixes#102301Fixes#102310Fixes#102334Fixes#102918
Fix missing explanation of where the borrowed reference is used when the same borrow occurs multiple times due to loop iterations
Fix#99824.
Problem of the issue:
If a borrow occurs in a loop, the borrowed reference could be invalidated at the same place at next iteration of the loop. When this happens, the point where the borrow occurs is the same as the intervening point that might invalidate the reference in the loop. This causes a problem for the current code finding the point where the resulting reference is used, so that the explanation of the cause will be missing. As the second point of "explain all errors in terms of three points" (see [leveraging intuition framing errors in terms of points"](https://rust-lang.github.io/rfcs/2094-nll.html#leveraging-intuition-framing-errors-in-terms-of-points), this explanation is very helpful for user to understand the error.
In the current implementation, the searching region for finding the location where the borrowed reference is used is limited to between the place where the borrow occurs and the place where the reference is invalidated. If those two places happen to be the same, which indicates that the borrow and invalidation occur at the same place in a loop, the search will fail.
One solution to the problem is when these two places are the same, find the terminator of the loop, and then use the location of the loop terminator instead of the location of the borrow for the region to find the place where the borrowed reference is used.
pretty: fix to print some lifetimes on HIR pretty-print
HIR pretty-printer doesn't seem to print some lifetimes in types. This PR fixes that.
Closes https://github.com/rust-lang/rust/issues/85089
We have 2 options for representing LLVM constraints for `inlateout`
operands on a fixed register (e.g. `r0`): `={r0},0` or `={r0},{r0}`.
This PR changes the behavior to the latter, which matches the behavior
of Clang since https://reviews.llvm.org/D87279.
Get rid of `rustc_query_description!`
**I am not entirely sure whether this is an improvement and would like to get your feedback on it.**
Helps with #96524.
Queries can provide an arbitrary expression for their description and their caching behavior. Before, these expressions where stored in a `rustc_query_description` macro emitted by the `rustc_queries` macro, and then used in `rustc_query_impl` to fill out the methods for the `QueryDescription` trait.
Instead, we now emit two new modules from `rustc_queries` containing the functions with the expressions. `rustc_query_impl` calls these functions now instead of invoking the macro.
Since we are now defining some of the functions in `rustc_middle::query`, we now need all the imports for the key types mthere as well.
r? `@cjgillot`
Rollup of 6 pull requests
Successful merges:
- #102773 (Use semaphores for thread parking on Apple platforms)
- #102884 (resolve: Some cleanup, asserts and tests for lifetime ribs)
- #102954 (Add missing checks for `doc(cfg_hide(...))`)
- #102998 (Drop temporaries created in a condition, even if it's a let chain)
- #103003 (Fix `suggest_floating_point_literal` ICE)
- #103041 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Drop temporaries created in a condition, even if it's a let chain
Fixes#100513.
During the lowering from AST to HIR we wrap expressions acting as conditions in a `DropTemps` expression so that any temporaries created in the condition are dropped after the condition is executed. Effectively this means we transform
```rust
if Some(1).is_some() { .. }
```
into (roughly)
```rust
if { let _t = Some(1).is_some(); _t } { .. }
```
so that if we create any temporaries, they're lifted into the new scope surrounding the condition, so for example something along the lines of
```rust
if { let temp = Some(1); let _t = temp.is_some(); _t }.
```
Before this PR, if the condition contained any let expressions we would not introduce that new scope, instead leaving the condition alone. This meant that in a let-chain like
```rust
if get_drop("first").is_some() && let None = get_drop("last") {
println!("second");
} else { .. }
```
the temporary created for `get_drop("first")` would be lifted into the _surrounding block_, which caused it to be dropped after the execution of the entire `if` expression.
After this PR, we wrap everything but the `let` expression in terminating scopes. The upside to this solution is that it's minimally invasive, but the downside is that in the worst case, an expression with `let` exprs interspersed like
```rust
if get_drop("first").is_some()
&& let Some(_a) = get_drop("fifth")
&& get_drop("second").is_some()
&& let Some(_b) = get_drop("fourth") { .. }
```
gets _multiple_ new scopes, roughly
```rust
if { let _t = get_drop("first").is_some(); _t }
&& let Some(_a) = get_drop("fifth")
&& { let _t = get_drop("second").is_some(); _t }
&& let Some(_b) = get_drop("fourth") { .. }
```
so instead of all of the temporaries being dropped at the end of the entire condition, they will be dropped right after they're evaluated (before the subsequent `let` expr). So while I'd say the drop behavior around let-chains is _less_ surprising after this PR, it still might not exactly match what people might expect.
For tests, I've just extended the drop order tests added in #100526. I'm not sure if that's the best way to go about it, though, so suggestions are welcome.
Add missing checks for `doc(cfg_hide(...))`
Part of #43781.
The `doc(cfg_hide(...))` attribute can only be used at the crate level and takes a list of attributes as argument.
r? ```@Manishearth```
Make `dyn*` casts into a coercion, allow `dyn*` upcasting
I know that `dyn*` is likely not going to be a feature exposed to surface Rust, but this makes it slightly more ergonomic to write tests for these types anyways. ... and this was just fun to implement anyways.
1. Make `dyn*` into a coercion instead of a cast
2. Enable `dyn*` upcasting since we basically get it for free
3. Simplify some of the cast checking code since we're using the coercion path now
r? `@eholk` but feel free to reassign
cc `@nikomatsakis` and `@tmandry` who might care about making `dyn*` casts into a coercion
Correctly handle path stability for 'use tree' items
PR #95956 started checking the stability of path segments.
However, this was not applied to 'use tree' items
(e.g. 'use some::path::{ItemOne, ItemTwo}') due to the way
that we desugar these items in HIR lowering.
This PR modifies 'use tree' lowering to preserve resolution
information, which is needed by stability checking.
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
