| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
bootstrap: more consistent use of `...` when citing configuration snippets
|
|
Fix `tests/rustdoc-json` triagebot message path
r? ```@aDotInTheVoid```
|
|
add signed ints to unn- transmutes to ensure feature parity
i forgot a few cases https://github.com/rust-lang/rust-clippy/pull/14703/#pullrequestreview-2824194994
adds
- char -> i32
- i32 -> char
- float -> size ()
- size -> float
- i32 -> float
``@rustbot`` label L-unnecessary_transmutes
|
|
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?
|
|
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
|
|
Rollup of 8 pull requests
Successful merges:
- #140095 (Eliminate `word_and_empty` methods.)
- #140341 (Clarify black_box warning a bit)
- #140684 (Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided)
- #140707 (Structurally normalize in range pattern checking in HIR typeck)
- #140716 (Improve `-Zremap-path-scope` tests with dependency)
- #140800 (Make `rustdoc-tempdir-removal` run-make tests work on other platforms than linux)
- #140802 (Add release notes for 1.87.0)
- #140811 (Enable triagebot note functionality for rust-lang/rust)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Enable triagebot note functionality for rust-lang/rust
Docs: <https://forge.rust-lang.org/triagebot/note.html>.
r? `@Urgau`
|
|
Add release notes for 1.87.0
Originally drafted in #140133
cc `@rust-lang/release`
r? `@pietroalbani` as you're running the release
|
|
Make `rustdoc-tempdir-removal` run-make tests work on other platforms than linux
Follow-up of #140706.
r? `@jieyouxu`
|
|
Improve `-Zremap-path-scope` tests with dependency
This PR greatly improves our coverage of `-Zremap-path-scope` for diagnostic paths and macros with dependencies.
r? `@jieyouxu` (since we talked about it)
try-job: x86_64-msvc-1
|
|
Structurally normalize in range pattern checking in HIR typeck
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/200
r? lcnr
|
|
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
|
|
Clarify black_box warning a bit
Trying to bring the docs on black_box more in line with the advice that we have discussed in Zulip.
https://github.com/rust-lang/rust/pull/140341#issuecomment-2832592382
|
|
Eliminate `word_and_empty` methods.
To remove the last remaining `Ident::empty` uses.
r? `@jdonszelmann`
|
|
Do not deny warnings in "fast" try builds
When we do the classic ``@bors` try` build without specifying `try-job` in the PR description, we want to get a compiler toolchain for perf./crater/local experimentation as fast as possible. We don't run any tests in that case, so it seems reasonable to also ignore warnings.
Fixes: https://github.com/rust-lang/rust/issues/140753
r? `@jieyouxu`
try-job: dist-x86_64-linux
|
|
|
|
|
|
|
|
See <https://forge.rust-lang.org/triagebot/note.html>.
|
|
Rollup of 5 pull requests
Successful merges:
- #140736 (trait selection: check `&` before suggest remove deref)
- #140755 ([win][arm64] Disable various DebugInfo tests that don't work on Arm64 Windows)
- #140756 ([arm64] Pointer auth test should link with C static library statically)
- #140758 ([win][arm64] Disable MSVC Linker 'Arm Hazard' warning)
- #140759 ([win][arm64] Disable std::fs tests that require symlinks)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
And note that the same limitation applies to all LLVM-based compilers
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
|
|
|
|
[win][arm64] Disable std::fs tests that require symlinks
While trying to get the aarch64-msvc build working correctly (#140136), various tests in `std::fs` were failing as the Arm64 Windows runner image we are using does not have Developer Mode enabled, thus it cannot create symlinks.
I've [filed a request to get Developer Mode enabled](https://github.com/actions/partner-runner-images/issues/94), but in the meantime I've disabled the relevant tests on Arm64 Windows.
|
|
[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.
|
|
[arm64] Pointer auth test should link with C static library statically
While trying to get the aarch64-msvc build working correctly (#140136), the `pointer-auth-link-with-c` test was failing.
The pointer auth test builds its C library statically:
https://github.com/rust-lang/rust/blob/3ef8e64ce9f72ee8d600d55bc43b36eed069b252/tests/run-make/pointer-auth-link-with-c/rmake.rs#L15
However, the Rust code did not indicate the link kind, so it defaulted to dynamic which then fails on Windows.
|
|
[win][arm64] Disable various DebugInfo tests that don't work on Arm64 Windows
While trying to get the aarch64-msvc build working correctly (#140136), various DebugInfo related tests were failing.
I've added comments to each test to indicate why it is disabled and linked to appropriate bugs.
* `tests/debuginfo/step-into-match.rs`: Stepping at the end of a function on goes to the callsite, not the instruction after it.
* `tests/debuginfo/type-names.rs`: Arm64 Windows cdb doesn't support JavaScript extensions. Followed up with the Microsoft Debugger Tools team to fix this.
* `tests/ui/runtime/backtrace-debuginfo.rs`: Backtraces are truncated due to #140489
|
|
trait selection: check `&` before suggest remove deref
FIxes #140166
r? compiler
|
|
make it possible to run in-tree rustfmt with `x run rustfmt`
Currently, there is no way to run in-tree `rustfmt` using `x fmt` or `x test tidy` commands. This PR implements `rustfmt` on `x run`, which allows bootstrap to run the in-tree `rustfmt`.
Fixes #140723
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 9 pull requests
Successful merges:
- #140260 (Only prefer param-env candidates if they remain non-global after norm)
- #140523 (Better error message for late/early lifetime param mismatch)
- #140579 (Remove estebank from automated review assignment)
- #140641 (detect additional uses of opaques after writeback)
- #140711 (Do not discard constraints on overflow if there was candidate ambiguity)
- #140762 (rustdoc-json: Remove newlines from attributes)
- #140764 (style: Never break within a nullary function call `func()` or a unit literal `()`)
- #140769 (Add `DefPathData::OpaqueLifetime` to avoid conflicts for remapped opaque lifetimes)
- #140773 (triagebot: Better message for changes to `tests/rustdoc-json`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
triagebot: Better message for changes to `tests/rustdoc-json`
Followup to #140689 / #140606
Adds a message to changes to `tests/rustdoc-json`, instead of just pinging me. Hopefully this makes the significance of these tests clearer to people who otherwise wouldn't have context, so hopefully we can avoid that happening again. It's annoyingly hard to know how well this works, because the real test is seeing if it doesn't get ignored.
Predrag has [kindly offered](https://github.com/rust-lang/rust/issues/140689#issuecomment-2855602664) to also get pinged here.
cc ``@jyn514`` ``@obi1kenobi``
r? ``@GuillaumeGomez``
|
|
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``
|
|
style: Never break within a nullary function call `func()` or a unit literal `()`
Implements https://github.com/rust-lang/style-team/issues/210
|
|
rustdoc-json: Remove newlines from attributes
Fixes #140689
Not sure if this needs to bump `FORMAT_VERSION` or not.
r? ``@GuillaumeGomez``
cc ``@obi1kenobi``
|
|
Do not discard constraints on overflow if there was candidate ambiguity
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/201.
There's a pretty chunky justification in the test.
r? lcnr
|
|
detect additional uses of opaques after writeback
Based on #140607. It's a lot harder to encounter in practice than I though :sweat_smile: :grin: 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``
|
|
Remove estebank from automated review assignment
First of all, Esteban thanks for all the reviews 💙
I think you've been quite busy IRL recently, so I'm proposing to remove you from the *automated* review assignment to prevent randomly rolling compiler PRs to you until you have more availability. If this is just temporary, please close this PR!
This is [just a way to improve our fairness when assigning reviews, trying to find a balance between leaving time to Rust contributors review on their terms and availability and avoid having PRs waiting for too long](https://github.com/rust-lang/compiler-team/issues/856).
> [!NOTE]
>
> This only prevents randomly-rolled compiler PRs from being auto assigned to you, it does not prevent explicit `r?` assignments.
**Please feel free to re-add yourself back to the active review rotation once you have more availability (if you feel like it).**
- If you want, it's also possible to only opt-out of the *general* compiler review rotation (`r? compiler`) but keep e.g. `r? diagnostics` rolls.
r? compiler_leads
|
