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.
This allows people to treat them like real links, such as right-click to
copy URL, and makes the line numbers in a scraped example work at all,
when before this commit was added, they had the clickable pointer cursor
but did not actually do anything when clicked.
Include both benchmarks and tests in the numbers given to `TeFiltered{,Out}`
Fixes#103794
`#[bench]` is broken on nightly without this, sadly. It apparently has no test coverage. In addition to manually testing, I've added a run-make smokecheck for this (which would have caught the issue), but it would be nice to have a better way to test, err, libtest. For now we should get this in ASAP IMO
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 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.
It's not clear why it was done, and apparently it's no longer necessary now.
Such additions are unpredictable for early doc link resolution and would force us to collect all doc links from all external traits.
rustdoc: add missing URL redirect
https://github.com/rust-lang/rust/pull/94753 missed some redirect settings, and one of the missing URL shows up in an error message. This PR adds those redirects.
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 }
}
```
All static files used by rustdoc are now stored in static.files/ and
include a hash of their contents. They no longer include the contents of
the --resource-suffix flag. This clarifies caching semantics. Anything
in static.files can use Cache-Control: immutable because any updates
will show up as a new URL.
Invocation-specific files like crates-NN.js, search-index-NN.js,
and sidebar-items-NN.js still get the resource suffix.
The --disable-minification flag is removed because it would vary the
output of static files based on invocation flags. Instead, for
rustdoc development purposes it's preferable to symlink static files
to a non-minified copy for quick iteration.
