| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Eliminate `word_and_empty` methods.
To remove the last remaining `Ident::empty` uses.
r? `@jdonszelmann`
|
|
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
|
|
[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
|
|
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.
|
|
Rollup of 8 pull requests
Successful merges:
- #140234 (Separate dataflow analysis and results)
- #140614 (Correct warning message in restricted visibility)
- #140671 (Parser: Recover error from named params while parse_path)
- #140700 (Don't crash on error codes passed to `--explain` which exceed our internal limit of 9999 )
- #140706 ([rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed)
- #140734 (Fix regression from #140393 for espidf / horizon / nuttx / vita)
- #140741 (add armv5te-unknown-linux-gnueabi target maintainer)
- #140745 (run-make-support: set rustc dylib path for cargo wrapper)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
lifetimes
|
|
borrowck nested items in dead code
fixes https://github.com/rust-lang/rust/issues/140583
r? `@compiler-errors`
|
|
`()`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
with ambiguity
|
|
|
|
r=jieyouxu
run-make-support: set rustc dylib path for cargo wrapper
Some run-make tests invoke Cargo via run_make_support::cargo(), but fail to execute correctly when rustc is built without rpath. In these setups, runtime loading of rustc’s shared libraries fails unless the appropriate dynamic library path is set manually.
This commit updates the cargo() wrapper to call set_host_compiler_dylib_path(), aligning its behavior with the existing rustc() wrapper: https://github.com/rust-lang/rust/blob/f76c7367c6363d33ddb5a93b5de0d158b2d827f6/src/tools/run-make-support/src/external_deps/rustc.rs#L39-L43
This ensures that Cargo invocations during tests inherit the necessary dylib paths, avoiding errors related to missing shared libraries in rpath-less builds.
Fixes part of #140738
|
|
r=jieyouxu
add armv5te-unknown-linux-gnueabi target maintainer
My employer is interested in having this target maintained and we already have some tests in our CI running for it.
armv5te-unknown-linux-gnueabi can be ticket off in #113739.
|
|
Fix regression from #140393 for espidf / horizon / nuttx / vita
#140393 introduced changes to the layout of the `std::sys::process` code.
As a result, the Tier 3 ESP-IDF (and I suspect Horizon, Nuttx and Vita targets as well) no longer build.
A `pub use unsupported::output` is all that was missing - for the above OSes specifically. This explicit `pub use` is now necessary, because #140393 moved the `output` function to module-level, where it was previously part of `Command` and was thus re-exported automatically, as part of the `imp::Command` re-export further down the file containing the one-liner fix.
Note that - with the change introduced by #140393 - we **can't** anymore just do an unconditional `pub use imp::output` as this function simply does not exist anymore anywhere else but in the `unsupported` module.
r? `@joboet`
|
|
r=notriddle
[rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed
Fixes #139899.
The bug was due to the fact that if any doctest fails for any reason, we call `exit` (or it's called inside `libtest` if not edition 2024), meaning that `TempDir`'s destructor isn't called, and therefore the temporary folder isn't cleaned up.
Took me a while to figure out how to reproduce but finally I was able to reproduce the bug with:
`````rust
#![doc(test(attr(deny(warnings))))]
//! ```
//! let a = 12;
//! ```
`````
And then I ensured that panicking doctests were cleaned up as well:
`````rust
//! ```
//! panic!();
//! ```
`````
And finally I checked if it was fixed for merged doctests too (`--edition 2024`).
To make this work, I needed to add a new public function in `libtest` too which would call a function once all tests have been run.
So only issue is: I have absolutely no idea how we can add a regression test for this fix. If anyone has an idea...
r? `@notriddle`
|
|
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`
|
|
Correct warning message in restricted visibility
Fixes #131220
|
|
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`
|
|
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
