Dylan DPC [Mon, 31 Oct 2022 09:22:57 +0000 (14:52 +0530)]
Rollup merge of #103766 - lukas-code:error-in-core, r=Dylan-DPC
Add tracking issue to `error_in_core`
This was merged in https://github.com/rust-lang/rust/pull/99917 without a tracking issue, so I'm creating one now: https://github.com/rust-lang/rust/issues/103765
The changes in this commit caused several bugs/incompatibilities (https://github.com/rust-lang/rust/pull/101833#issuecomment-1270191721, https://github.com/rust-lang/rust/issues/102560). For now we're reverting this commit and will re-land it alongside fixes for those bugs.
bors [Mon, 31 Oct 2022 03:40:22 +0000 (03:40 +0000)]
Auto merge of #103787 - notriddle:rollup-q1vmxsb, r=notriddle
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`)
Michael Howell [Mon, 31 Oct 2022 02:31:40 +0000 (19:31 -0700)]
Rollup merge of #103764 - SarthakSingh31:issue-94187-2, r=compiler-errors
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`.
Michael Howell [Mon, 31 Oct 2022 02:31:38 +0000 (19:31 -0700)]
Rollup merge of #102689 - ayrtonm:master, r=cjgillot
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.
:+1:
> 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.
:+1:
> 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.
Michael Howell [Mon, 31 Oct 2022 02:31:37 +0000 (19:31 -0700)]
Rollup merge of #101944 - notriddle:notriddle/toggle-all-docs, r=jsha,GuillaumeGomez
rustdoc: clean up `#toggle-all-docs`
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`.
Michael Howell [Mon, 31 Oct 2022 02:31:37 +0000 (19:31 -0700)]
Rollup merge of #101428 - JakobDegen:build-tests, r=oli-obk
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`
bors [Mon, 31 Oct 2022 00:40:32 +0000 (00:40 +0000)]
Auto merge of #103331 - nnethercote:convert-switch-to-br, r=scottmcm
Use `br` instead of `switch` in more cases.
`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.
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).
`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.
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).
bors [Sun, 30 Oct 2022 17:45:04 +0000 (17:45 +0000)]
Auto merge of #103299 - nikic:usub-overflow, r=wesleywiser
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.
bors [Sun, 30 Oct 2022 14:13:42 +0000 (14:13 +0000)]
Auto merge of #103295 - ishitatsuyuki:ninja, r=cuviper
ci: Bring back ninja for dist builders
The primary reason for this is that make can result in a substantial under utilization of parallelism (noticed while testing on a workstation), mostly due to the submake structure preventing good dependency tracking and scheduling.
In f758c7b2a78 (Debian 6 doesn't have ninja, so use make for the dist builds) llvm.ninja was disabled due to lack of distro package. This is no longer the case with the CentOS 7 base, so bring ninja back for a performance boost.
bors [Sun, 30 Oct 2022 10:52:04 +0000 (10:52 +0000)]
Auto merge of #103010 - petrochenkov:effvisdoc, r=GuillaumeGomez
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`
bors [Sun, 30 Oct 2022 08:09:59 +0000 (08:09 +0000)]
Auto merge of #103755 - Dylan-DPC:rollup-dl2hups, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #93582 (Allow `impl Fn() -> impl Trait` in return position)
- #103560 (Point only to the identifiers in the typo suggestions of shadowed names instead of the entire struct)
- #103588 (rustdoc: add missing URL redirect)
- #103689 (Do fewer passes and generally be more efficient when filtering tests)
- #103740 (rustdoc: remove unnecessary CSS `.search-results { padding-bottom }`)
Dylan DPC [Sun, 30 Oct 2022 06:20:27 +0000 (11:50 +0530)]
Rollup merge of #103689 - saethlin:libtest-startup, r=thomcc
Do fewer passes and generally be more efficient when filtering tests
Follow-on of the work I started with this PR: https://github.com/rust-lang/rust/pull/99939
Basically, the startup code for libtest is really inefficient, but that's not usually a problem because it is distributed in release and workloads are small. But under Miri which can be 100x slower than a debug build, these inefficiencies explode.
Most of the diff here is making test filtering single-pass. There are a few other small optimizations as well, but they are more straightforward.
With this PR, the startup time of the `iced` tests with `--features=code_asm,mvex` drops from 17 to 2 minutes (I think Miri has gotten slower under this workload since #99939). The easiest way to try this out is to set `MIRI_LIB_SRC` to a checkout of this branch when running `cargo +nightly miri test --features=code_asm,mvex`.
Dylan DPC [Sun, 30 Oct 2022 06:20:27 +0000 (11:50 +0530)]
Rollup merge of #103588 - weihanglo:rustdoc/url-redirect, r=notriddle
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.
Dylan DPC [Sun, 30 Oct 2022 06:20:26 +0000 (11:50 +0530)]
Rollup merge of #103560 - zbyrn:issue-103358-fix, r=cjgillot
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.
Dylan DPC [Sun, 30 Oct 2022 06:20:26 +0000 (11:50 +0530)]
Rollup merge of #93582 - WaffleLapkin:rpitirpit, r=compiler-errors
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](https://github.com/WaffleLapkin/rust/blob/a819fecb8dea438fc70488ddec30a61e52942672/src/test/ui/impl-trait/impl_fn_associativity.rs).
There even is a test that `f0` compiles:
https://github.com/rust-lang/rust/blob/2f004d2d401682e553af3984ebd9a3976885e752/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 }
}
```
bors [Sun, 30 Oct 2022 02:26:41 +0000 (02:26 +0000)]
Auto merge of #103745 - matthiaskrgr:rollup-hipjva8, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #100006 (Make `core::mem::copy` const)
- #102659 (1.65.0 release notes)
- #103124 (Add tests for autoderef on block tail)
- #103253 (rustdoc: add test case for masked blanket impl)
- #103715 (use consistent terminology)
- #103722 (Fix z-indexes of code example feature and cleanup its CSS)
- #103726 (Avoid unnecessary `&str` to `String` conversions)
- #103737 (rustdoc: use CSS margin/padding shorthand when all are being set)
This PR fixes it by reducing the value of value under the one used for `.popover` (it could be completely removed but then it wouldn't be displayed as nicely).
There was also a lot of duplicated CSS so I merged the rules.
The changes in this commit caused several bugs or at least
incompatibilies. For now we're reverting this commit and will re-land it
alongside fixes for those bugs.
bors [Sat, 29 Oct 2022 14:14:08 +0000 (14:14 +0000)]
Auto merge of #103727 - GuillaumeGomez:rollup-hfyxccr, r=GuillaumeGomez
Rollup of 8 pull requests
Successful merges:
- #102634 (compiletest: Refactor test rustcflags)
- #102721 (Prevent foreign Rust exceptions from being caught)
- #103415 (filter candidates in pick probe for diagnostics)
- #103618 (Rename some `OwnerId` fields.)
- #103625 (Accept `TyCtxt` instead of `TyCtxtAt` in `Ty::is_*` functions)
- #103653 (Add missing impl blocks for item reexported from private mod in JSON output)
- #103699 (Emit proper error when casting to `dyn*`)
- #103719 (fix typo in `try_reserve` method from `HashMap` and `HashSet`)
Guillaume Gomez [Sat, 29 Oct 2022 12:18:05 +0000 (14:18 +0200)]
Rollup merge of #103719 - joseluis:fix-typos-try-reserve, r=the8472
fix typo in `try_reserve` method from `HashMap` and `HashSet`
Currently refers to the `reserve` method, instead of `try_reserve`. Other collections like [Vec](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.try_reserve) & [VecDeque](https://doc.rust-lang.org/std/collections/vec_deque/struct.VecDeque.html#method.try_reserve) shows it well.
Guillaume Gomez [Sat, 29 Oct 2022 12:18:04 +0000 (14:18 +0200)]
Rollup merge of #103653 - GuillaumeGomez:missing-impl-private-json, r=notriddle
Add missing impl blocks for item reexported from private mod in JSON output
Fixes #102583.
Since we don't inline for the JSON output, the impl blocks from private modules are not present when we generate the output. To go around this limitation, in case the impl block doesn't have `#[doc(hidden)]` and is implementing a public item, we don't strip it.
Guillaume Gomez [Sat, 29 Oct 2022 12:18:03 +0000 (14:18 +0200)]
Rollup merge of #103618 - nnethercote:rename-OwnerId-fields, 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.
Guillaume Gomez [Sat, 29 Oct 2022 12:18:02 +0000 (14:18 +0200)]
Rollup merge of #103415 - compiler-errors:tiny-perf-increase-on-diagnostic, r=TaKO8Ki
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
Guillaume Gomez [Sat, 29 Oct 2022 12:18:02 +0000 (14:18 +0200)]
Rollup merge of #102721 - nbdd0121:panic, r=Amanieu
Prevent foreign Rust exceptions from being caught
Fix #102715
Use the address of a static variable (which is guaranteed to be unique per copy of std) to tell apart if a Rust exception comes from local or foreign Rust code, and abort for the latter.
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.
bors [Sat, 29 Oct 2022 09:00:14 +0000 (09:00 +0000)]
Auto merge of #2631 - RalfJung:futex-wait-no-isolate, r=RalfJung
Support timeouts with monotonic clocks even when isolation is enabled
With the deterministic monotonic clock support we now have, we can allow some synchronization primitives with timeouts even under isolation:
- Linux futex waiting (when set to the monotonic clock)
- pthread_cond_timedwait (when set to the monotonic clock)
- Windows WaitOnAddress
Unfortunately none of these exist on macOS -- the standard library always uses the system clock for timeouts on macOS, so that will still require `-Zmiri-disable-isolation`.
This wrapper DIV was originally added in 89e1fb322321c05497caa01372ceb7d5b57fa680, when it allowed the search bar's size to be calculated without using `calc()`. This `width` hack can be removed using flexbox.
bors [Sat, 29 Oct 2022 03:08:59 +0000 (03:08 +0000)]
Auto merge of #102233 - petrochenkov:effvis, r=jackh726
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.
bors [Fri, 28 Oct 2022 23:27:33 +0000 (23:27 +0000)]
Auto merge of #102737 - RalfJung:poll_fn_pin, r=Mark-Simulacrum
poll_fn and Unpin: fix pinning
See [IRLO](https://internals.rust-lang.org/t/surprising-soundness-trouble-around-pollfn/17484) for details: currently `poll_fn` is very subtle to use, since it does not pin the closure, so creating a `Pin::get_unchcked(&mut capture)` inside the closure is unsound. This leads to actual miscompilations with `futures::join!`.
IMO the proper fix is to pin the closure when the future is pinned, which is achieved by changing the `Unpin` implementation. This is a breaking change though. 1.64.0 was *just* released, so maybe this is still okay?
The alternative would be to add some strong comments to the docs saying that closure captures are *not pinned* and doing `Pin::get_unchecked` on them is unsound.
bors [Fri, 28 Oct 2022 20:19:28 +0000 (20:19 +0000)]
Auto merge of #2630 - RalfJung:windows-parking, r=RalfJung
Implement thread parking for Windows
Cc https://github.com/rust-lang/miri/issues/2628
Based on code by `@DrMeepster.` However I adjusted `WakeByAddressSingle`: I don't think the futex value is compared *again* after the thread is woken up. I see nothing in the Windows docs indicating such a comparison, and the Linux futex does not behave like that either. So we only check the value before sleeping, same as on Linux.
bors [Fri, 28 Oct 2022 16:27:56 +0000 (16:27 +0000)]
Auto merge of #103071 - wesleywiser:fix_inlined_line_numbers, r=davidtwco
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.
projects / rust.git / log