This reverts commit 3acb505ee5
(PR #101833).
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.
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`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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.
cc `@fmease` `@aDotInTheVoid`
r? `@notriddle`
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.
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.
compiletest: Refactor test rustcflags
Refactoring `host-rustcflags` and `target-rustcflags` from `Option<String>` to `Vec<String>`
Ref: #102438
r? `@Mark-Simulacrum`
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.
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`.
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.
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.
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.
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
