| Age | Commit message (Collapse) | Author | Lines |
|---|
|
chore: move more ui tests
r? `@jieyouxu`
|
|
|
|
|
|
the size of `AsyncStruct`'s destructor depends on whether the configured
panic strategy is 'unwind' or 'abort' so factor that into the test using
conditional compilation
fixes rust-lang/rust#140939
|
|
Rollup of 3 pull requests
Successful merges:
- #140397 (Add T-compiler backports Zulip notifications)
- #140851 (Warn when `#[export_name]` is used with generic functions)
- #140862 (Enable non-leaf Frame Pointers for Arm64EC Windows)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=oli-obk
Async drop fix for async_drop_in_place<T> layout for unspecified T
Fix for https://github.com/rust-lang/rust/issues/140423.
Layout of `async_drop_in_place<T>::{closure}` is calculated for unspecified T from dataflow_const_prop `try_make_constant`.
`@oli-obk,` do you think, it may be a better solution to add check like `if !args[0].is_fully_specialized() { return None; }` in `fn async_drop_coroutine_layout`?
And could you, pls, recommend, how to implement `is_fully_specialized()` in a most simple way?
|
|
Warn when `#[export_name]` is used with generic functions
Fixes #140742
|
|
Partially stabilize LoongArch target features
Stabilization PR for the LoongArch target features. This PR stabilizes some of the target features tracked by #44839.
Specifically, this PR stabilizes the following target features:
* f
* d
* frecipe
* lasx
* lbt
* lsx
* lvz
Docs PR: https://github.com/rust-lang/reference/pull/1707
r? `@Amanieu`
|
|
Make t letter looks like lowercase rather than uppercase
randomly noticed that, took opportunity to fix :D
it was looks like "RusT" now fixed to "Rust"
r? `@jieyouxu`
before
<img src="https://github.com/user-attachments/assets/1ff19891-2e7b-4633-897d-2b2635aff9c6" width="65%" />
now
<img src="https://github.com/user-attachments/assets/d577a2af-6755-411b-8050-2556f0f12e75" width="65%" />
|
|
r=petrochenkov
Prefer to suggest stable candidates rather than unstable ones
Fixes #140240
The logic is to replace unstable suggestions if we meet a new stable one, and do nothing if any other situation. In old logic, we just use the first candidate we meet as the suggestion for the same items.
E.g., `std::range::legacy::Range` vs `std::ops::Range`, `legacy` in the former is unstable, we prefer to suggest use the latter.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #129334 (Implement (part of) ACP 429: add `DerefMut` to `Lazy[Cell/Lock]`)
- #139562 (rustdoc: add a handle that makes sidebar resizing more obvious)
- #140151 (remove intrinsics::drop_in_place)
- #140660 (remove 'unordered' atomic intrinsics)
- #140783 (Update documentation of OnceLock::get_or_init.)
- #140789 (Update hermit-abi to 0.5.1)
- #140879 (1.87.0 release notes: remove nonsensical `~` operator)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=Mark-Simulacrum
remove intrinsics::drop_in_place
This was only ever accidentally stable, and has been marked as deprecated since Rust 1.52, released almost 4 years ago. We've removed the old serialization `derive`s, maybe we can remove this one as well?
As suggested by ``@jhpratt,`` let's see what crater says for this one.
|
|
Merge typeck loop with static/const item eval loop
r? `@ghost`
Let's try a small one first. Doing this in general has some bad cache coherence issues because the query caches are laid out in `Vec<QueryResult>` lists per query where each index refers to a `DefId` in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
|
|
|
|
Improved error message for top-level or-patterns
I was confused by "top-level or-patterns are not allowed in `let` bindings" error, because it sounded like or-patterns were completely unsupported.
This error has an auto-fix suggestion that shows otherwise, but the auto-fix isn't always visible in IDEs.
I've changed the wording to be consistent with "`Fn` bounds require arguments in parentheses", and it doesn't sound like a dead-end any more.
|
|
Add regression test for 125877
close: #125877
https://github.com/rust-lang/rust/issues/125877#issuecomment-2143704586 has been resolved https://github.com/rust-lang/rust/pull/128171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bump version number to 1.89.0
Part of the release process. This PR must not be rolled up.
Closes #129461.
r? `@ghost`
|
|
Revert "Rollup merge of #129343 - estebank:time-version, r=jieyouxu"
This reverts commit 26f75a65d70773e4520634b9f6599ddf08c499e6, reversing
changes made to 2572e0e8c9d5d671eccb1d5791e55c929c4720f4.
Imports are modified to fix merge conflicts and remove unused ones.
|
|
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?
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
|
|
[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
|
|
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``
|
|
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
|
|
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
|
|
lifetimes
|
|
borrowck nested items in dead code
fixes https://github.com/rust-lang/rust/issues/140583
r? `@compiler-errors`
|
