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.
update Miri
I had to use a hacked version of josh to create this, so let's be careful with merging this and maybe wait a bit to see if the josh issue becomes more clear. But the history looks good to me, we are not adding duplicates of rustc commits that were previously mirrored to Miri.
Also I want to add some cross-testing of Miri in x.py.
Before this commit, compiletest would add `-L path/to/aux` at the end of
the rustc flags, even after the custom ones set with the compile-flags
header comment. This made it impossible to check how rustc would behave
when a flag requiring an argument was passed without the argument,
because the argument would become `-L`.
This PR fixes that by adding the `-L path/to/aux` before the arguments
defined in compile-flags, at least for UI tests. Other test suites might
either be fixed as well by this change, or still present the old
behavior.
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.
rustdoc: Use `unix_sigpipe` instead of `rustc_driver::set_sigpipe_handler`
Do what was already done for `rustc` in #102587, namely start using `unix_sigpipe` instead of `rustc_driver::set_sigpipe_handler`.
After this has been merged, we can completely remove `rustc_driver::set_sigpipe_handler`.
PR that added `set_sigpipe_handler`: https://github.com/rust-lang/rust/pull/49606
Tracking issue for `unix_sigpipe`: #97889
Verification of this change
---------------------------
1. Remove `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE
1. Add back `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE fixed
``@rustbot`` labels +T-rustdoc
rustdoc: remove redundant CSS `a.test-arrow:hover`
In 4b402dbe69, when this rule was added, it was overriding a rule that made all links in docblock get an underline when hovered. This became redundant when, after reordering the rules, 7585632052 changed the pro-underline rule to exclude the test-arrow link anyway.
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``
Start using `unix_sigpipe` instead of
`rustc_driver::set_sigpipe_handler`.
After this has been merged, we can completely remove
`rustc_driver::set_sigpipe_handler`.
Verification of this change
---------------------------
1. Remove `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE
1. Add back `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE fixed
In 4b402dbe69, when this rule was added, it
was overriding a rule that made all links in docblock get an underline when
hovered. This became redundant when, after reordering the rules,
7585632052 changed the pro-underline rule to
exclude the test-arrow link anyway.
This change converts the element from an `<a>` link to a button. It's
pretty much directly trading slightly more CSS for slightly less HTML, and
it's also semantically correct (so you don't get a broken "bookmark" option
when you right click on it).
While doing this, I also got rid of the unnecessary `class="inner"`
attribute on the inner span. There was a style targeting
`.collapse-toggle > .inner`, but no CSS ever targeted the
`#toggle-all-docs > .inner`.
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)
