Revert "Rollup merge of #129343 - estebank:time-version, r=jieyouxu"
This reverts commit 26f75a65d7, reversing
changes made to 2572e0e8c9.
Imports are modified to fix merge conflicts and remove unused ones.
Enable non-leaf Frame Pointers for Arm64 Windows
Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers>:
> The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack.
I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.
Use span before macro expansion in lint for-loops-over-falibles
Fixes#140747
I think there are going to be a lot of cases where macros are expanded in the compiler resulting in span offsets, and I'd like to know how that's typically handled. Does it have to be handled specially every time?
All uses have been removed. And it's nonsensical: an identifier by
definition has at least one char.
The commits adds an is-non-empty assertion to `Ident::new` to enforce
this, and converts some `Ident` constructions to use `Ident::new`.
Adding the assertion requires making `Ident::new` and
`Ident::with_dummy_span` non-const, which is no great loss.
The commit amends a couple of places that do path splitting to ensure no
empty identifiers are created.
Fix linking statics on Arm64EC
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).
Fixes#138541
---
try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided
Since #136458, we began filtering out associated types with `Self: Sized` bounds when constructing the list of associated type bounds to put into our `dyn Trait` types. For example, given:
```rust
trait Trait {
type Assoc where Self: Sized;
}
```
After #136458, even if a user writes `dyn Trait<Assoc = ()>`, the lowered ty would have an empty projection list, and thus be equivalent to `dyn Trait`. However, this has the side effect of no longer constraining any types in the RHS of `Assoc = ...`, not implying any WF implied bounds, and not requiring that they hold when unsizing.
After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list.
This results in `dyn Trait` types that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. between `dyn Trait` and `dyn Trait<Assoc = ()>`. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before #136458.
We may want to begin to ignore thse bounds in the future by bumping `unused_associated_type_bounds` to an FCW. I don't want to tangle that up into the fix that was originally intended in #136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future.
Fixes#140645
r? lcnr
[win][arm64] Disable MSVC Linker 'Arm Hazard' warning
While trying to get the aarch64-msvc build working correctly (#140136), I observed the following test failure:
From <https://github.com/rust-lang/rust/pull/140136#issuecomment-2848179657>
```
= note: main.main.d17f5fbe6225cf88-cgu.0.rcgu.o : fatal error LNK1322: cannot avoid potential ARM hazard (Cortex-A53 MPCore processor bug #843419) in section 0x57; please consider using compiler option /Gy if it was not used
```
This is warning of a code sequence that triggers a bug in Cortex-A53 processors: <https://developer.arm.com/documentation/epm048406/latest>
However, since Windows 10 isn't supported on the Cortex-A53, this warning is not required, so it can be suppressed using the undocumented `/arm64hazardfree` flag.
Add `DefPathData::OpaqueLifetime` to avoid conflicts for remapped opaque lifetimes
This adds `DefPathData::OpaqueLifetime` to ensure the def paths for remapped opaque lifetimes remain unique.
Fixes https://github.com/rust-lang/rust/issues/140731.
r? ``@oli-obk``
detect additional uses of opaques after writeback
Based on #140607. It's a lot harder to encounter in practice than I though 😅😁 I've still added it with the expectation that somebody will encounter it at some point.
Also modifies the `EvalCtxt` to use the same impl to detect newly added opaque types.
r? ``@compiler-errors``
Better error message for late/early lifetime param mismatch
Rework the way we report early-/late-bound lifetime param mismatches to equate the trait and impl signatures using region variables, so that we can detect when a late-bound param is present in the signature in place of an early-bound param, or vice versa.
The diagnostic is a bit more technical, but it's more obviously clear to see what the problem is, even if it's not great at explaining how to fix it. I think this could be improved further, but I still think it's much better than what exists today.
Note to reviewer(s): I'd appreciate if we didn't bikeshed *too* much about this verbiage, b/c I hope it's clear that the old message sucked a lot. I'm happy to file bugs for interested new contributors to improve the messaging further.
Edit(fmease): Fixes https://github.com/rust-lang/rust/issues/33624.
Only prefer param-env candidates if they remain non-global after norm
Introduce `CandidateSource::GlobalParamEnv`, and dynamically compute the `CandidateSource` based on whether the predicate contains params *post-normalization*.
This code needs some cleanup and documentation. I'm just putting this up for review.
cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/179
r? lcnr
allow deref patterns to participate in exhaustiveness analysis
Per [this proposal](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Exhaustiveness), this PR allows deref patterns to participate in exhaustiveness analysis. Currently all deref patterns enforce `DerefPure` bounds on their scrutinees, so this assumes all patterns it's analyzing are well-behaved. This also doesn't support [mixed exhaustiveness](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Mixed-exhaustiveness), and instead emits an error if deref patterns are used together with normal constructors. I think mixed exhaustiveness would be nice to have (especially if we eventually want to support arbitrary `Deref` impls[^1]), but it'd require more work to get reasonable diagnostics[^2].
Tracking issue for deref patterns: #87121
r? `@Nadrieril`
[^1]: Regardless of whether we support limited exhaustiveness checking for untrusted `Deref` or always require other arms to be exhaustive, I think it'd be useful to allow mixed matching for user-defined smart pointers. And it'd be strange if it worked there but not for `Cow`.
[^2]: I think listing out witnesses of non-exhaustiveness can be confusing when they're not necessarily disjoint, and when you only need to cover some of them, so we'd probably want special formatting and/or explanatory subdiagnostics. And if it's implemented similarly to unions, we'd probably also want some way of merging witnesses; the way witnesses for unions can appear duplicated is pretty unfortunate. I'm not sure yet how the diagnostics should look, especially for deeply nested patterns.
Don't crash on error codes passed to `--explain` which exceed our internal limit of 9999
removed panic in case where we do `--explain > 9999` and added check for it
now error looks like this instead of ICE
```
$ rustc.exe --explain E10000
error: E10000 is not a valid error code
```
fixes#140647
r? `@fmease`
Parser: Recover error from named params while parse_path
Fixes#140169
I added test to the first commit and the second added the code and changes to test.
r? `@petrochenkov`
Separate dataflow analysis and results
`Analysis` gets put into `Results` with `EntryStates`, by `iterate_to_fixpoint`. This has two problems:
- `Results` is passed various places where only `Analysis` is needed.
- `EntryStates` is passed around mutably everywhere even though it is immutable.
This commit mostly separates `Analysis` from `Results` and fixes these two problems.
r? `@davidtwco`
Use thread local dep graph encoding
This adds thread local encoding of dep graph nodes. Each thread has a `MemEncoder` that gets flushed to the global `FileEncoder` when it exceeds 64 kB. Each thread also has a local cache of dep indices. This means there can now be empty gaps in `SerializedDepGraph`.
Indices are marked green and also allocated by the new atomic operation `DepNodeColorMap::try_mark_green` as the encoder lock is removed.
fix typo in autorefs lint doc example
The documentation is talking about other way using only raw pointers, but the example was use `std::slice::from_raw_parts_mut` which also create a reference. `std::ptr::slice_from_raw_parts_mut` should be used instead, and it also highlights the benefit of raw pointer manipulation compared to dereference, as the function doesn't need to be unsafe anymore.
Moreover, [`unsafe_op_in_unsafe_fn`](https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-op-in-unsafe-fn.html) warning has been enabled since Edition 2024, so I've updated the examples to use unsafe blocks.
