[pull] master from rust-lang:master #12
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Mark-Simulacrum
force-pushed
the
master
branch
from
47c0792 to
999ac5f
Compare
Revert "Rollup merge of #136127 - WaffleLapkin:dyn_ptr_unwrap_cast, r=compiler-errors" ...not permanently tho. Just until we can land something like #138542, which will fix the underlying perf issues (#136127 (comment)). I just don't want this to land on beta and have people rely on this behavior if it'll need some reworking for it to be implemented performantly. r? `@WaffleLapkin` or reassign -- sorry for reverting ur pr! i'm working on getting it re-landed soon :>
Prefer built-in sized impls (and only sized impls) for rigid types always
This PR changes the confirmation of `Sized` obligations to unconditionally prefer the built-in impl, even if it has nested obligations. This also changes all other built-in impls (namely, `Copy`/`Clone`/`DiscriminantKind`/`Pointee`) to *not* prefer built-in impls over param-env impls. This aligns the old solver with the behavior of the new solver.
---
In the old solver, we register many builtin candidates with the `BuiltinCandidate { has_nested: bool }` candidate kind. The precedence this candidate takes over other candidates is based on the `has_nested` field. We only prefer builtin impls over param-env candidates if `has_nested` is `false`
https://github.com/rust-lang/rust/blob/2b4694a69804f89ff9d47d1a427f72c876f7f44c/compiler/rustc_trait_selection/src/traits/select/mod.rs#L1804-L1866
Preferring param-env candidates when the builtin candidate has nested obligations *still* ends up leading to detrimental inference guidance, like:
```rust
fn hello<T>() where (T,): Sized {
let x: (_,) = Default::default();
// ^^ The `Sized` obligation on the variable infers `_ = T`.
let x: (i32,) = x;
// We error here, both a type mismatch and also b/c `T: Default` doesn't hold.
}
```
Therefore this PR adjusts the candidate precedence of `Sized` obligations by making them a distinct candidate kind and unconditionally preferring them over all other candidate kinds.
Special-casing `Sized` this way is necessary as there are a lot of traits with a `Sized` super-trait bound, so a `&'a str: From<T>` where-bound results in an elaborated `&'a str: Sized` bound. People tend to not add explicit where-clauses which overlap with builtin impls, so this tends to not be an issue for other traits.
We don't know of any tests/crates which need preference for other builtin traits. As this causes builtin impls to diverge from user-written impls we would like to minimize the affected traits. Otherwise e.g. moving impls for tuples to std by using variadic generics would be a breaking change. For other builtin impls it's also easier for the preference of builtin impls over where-bounds to result in issues.
---
There are two ways preferring builtin impls over where-bounds can be incorrect and undesirable:
- applying the builtin impl results in undesirable region constraints. E.g. if only `MyType<'static>` implements `Copy` then a goal like `(MyType<'a>,): Copy` would require `'a == 'static` so we must not prefer it over a `(MyType<'a>,): Copy` where-bound
- this is mostly not an issue for `Sized` as all `Sized` impls are builtin and don't add any region constraints not already required for the type to be well-formed
- however, even with `Sized` this is still an issue if a nested goal also gets proven via a where-bound: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=30377da5b8a88f654884ab4ebc72f52b)
- if the builtin impl has associated types, we should not prefer it over where-bounds when normalizing that associated type. This can result in normalization adding more region constraints than just proving trait bounds. #133044
- not an issue for `Sized` as it doesn't have associated types.
r? lcnr
Fix closure recovery for missing block when return type is specified Firstly, fix the `is_array_like_block` condition to make sure we're actually recovering a mistyped *block* rather than some other delimited expression. This fixes #138748. Secondly, split out the recovery of missing braces on a closure body into a separate recovery. Right now, the suggestion `"you might have meant to write this as part of a block"` originates from `suggest_fixes_misparsed_for_loop_head`, which feels kinda brittle and coincidental since AFAICT that recovery wasn't ever really intended to fix this. We also can make this `MachineApplicable` in this case. Fixes #138748 r? `@fmease` or reassign if you're busy/don't wanna review this
Emit `unused_attributes` for `#[inline]` on exported functions I saw someone post a code sample that contained these two attributes, which immediately made me suspicious. My suspicions were confirmed when I did a small test and checked the compiler source code to confirm that in these cases, `#[inline]` is indeed ignored (because you can't exactly `LocalCopy`an unmangled symbol since that would lead to duplicate symbols, and doing a mix of an unmangled `GloballyShared` and mangled `LocalCopy` instantiation is too complicated for our current instatiation mode logic, which I don't want to change right now). So instead, emit the usual unused attribute lint with a message saying that the attribute is ignored in this position. I think this is not 100% true, since I expect LLVM `inlinehint` to still be applied to such a function, but that's not why people use this attribute, they use it for the `LocalCopy` instantiation mode, where it doesn't work. r? saethlin as the instantiation guy Procedurally, I think this should be fine to merge without any lang involvement, as this only does a very minor extension to an existing lint.
Encode synthetic by-move coroutine body with a different `DefPathData`
See the included test. In the first revision rpass1, we have an async closure `{closure#0}` which has a coroutine as a child `{closure#0}::{closure#0}`. We synthesize a by-move coroutine body, which is `{closure#0}::{closure#1}` which depends on the mir_built query, which depends on the typeck query.
In the second revision rpass2, we've replaced the coroutine-closure by a closure with two children closure. Notably, the def path of the second child closure is the same as the synthetic def id from the last revision: `{closure#0}::{closure#1}`. When type-checking this closure, we end up trying to compute its def_span, which tries to fetch it from the incremental cache; this will try to force the dependencies from the last run, which ends up forcing the mir_built query, which ends up forcing the typeck query, which ends up with a query cycle.
The problem here is that we really should never have used the same `DefPathData` for the synthetic by-move coroutine body, since it's not a closure. Changing the `DefPathData` will mean that we can see that the def ids are distinct, which means we won't try to look up the closure's def span from the incremental cache, which will properly skip replaying the node's dependencies and avoid a query cycle.
Fixes #139142
Remove mention of `exhaustive_patterns` from `never` docs
The example shows an exhaustive match:
```rust
#![feature(exhaustive_patterns)]
use std::str::FromStr;
let Ok(s) = String::from_str("hello");
```
But #119612 moved this functionality to `#
Rollup of 6 pull requests Successful merges: - #138176 (Prefer built-in sized impls (and only sized impls) for rigid types always) - #138749 (Fix closure recovery for missing block when return type is specified) - #138842 (Emit `unused_attributes` for `#[inline]` on exported functions) - #139153 (Encode synthetic by-move coroutine body with a different `DefPathData`) - #139157 (Remove mention of `exhaustive_patterns` from `never` docs) - #139167 (Remove Amanieu from the libs review rotation) r? `@ghost` `@rustbot` modify labels: rollup
We also have to remove the LLVM argument in cast-target-abi.rs for LLVM 21. I'm not really sure what the best approach here is since that test already uses revisions. We could also fork the test into a copy for LLVM 19-20 and another for LLVM 21, but what I did for now was drop the lint-abort-on-error flag to LLVM figuring that some coverage was better than none, but I'm happy to change this if that was a bad direction. The above also applies for ffi-out-of-bounds-loads.rs. r? dianqk @rustbot label llvm-main
It makes it clearer that the symbol is unused and doesn't matter.
To use one `kw::Empty` instead of two. It's a little more direct this way, and avoids `kw::Empty` being used for both "no string" and "empty string".
This is part of the implementation of `#[doc(keyword = "match")]` attributes used by `std` to provide documentation for keywords. `is_doc_keyword` currently does a crude keyword range test that's intended to catch all keywords but misses `kw::Yeet`. This commit changes it to use `Symbol` methods, including the new `is_weak` method (required for `union`). `Symbol` methods are much less prone to falling out of date if new keywords are added.
By changing two of the fields to use `Option<Ident>` instead of `Ident`. As a result, `None` now means "no identifier", which is much clearer than using an empty identifier.
Fix `armv7-sony-vita-newlibeabihf` LLVM target triple It was previously normalized by LLVM to `thumbv7a-vita-unknown-eabihf` (can be seen with `clang -target thumbv7a-vita-eabihf -v`), which seems wrong, as Vita is the OS name. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. CC target maintainers ``@nikarh,`` ``@pheki`` and ``@ZetaNumbers.`` r? jieyouxu
rustc_resolve: Test the order that preludes are resolved This test is exhaustive. See attached truth table:  Companion PR to rust-lang/reference#1765.
The future and ctor fields aren't actually used, and the way they are extracted is obviously wrong – swapping the order of the items in the source code will give wrong results. Instead, store just the LocalDefId of the impl, which is enough for the only use of this data.
Folder experiment: Monomorphize region resolver **NOTE:** This is one of a series of perf experiments that I've come up with while sick in bed. I'm assigning them to lqd b/c you're a good reviewer and you'll hopefully be awake when these experiments finish, lol. r? lqd This is actually two tweaks to the `RegionFolder`, monomorphizing its callback and accounting for flags to avoid folding unnecessarily.
It uses `Br` prefixes which are inappropriate and appear to have been incorrectly copy/pasted from the `Debug` impl for `BoundRegionKind`.
Rename `is_like_osx` to `is_like_darwin` Replace `is_like_osx` with `is_like_darwin`, which more closely describes reality (OS X is the pre-2016 name for macOS, and is by now quite outdated; Darwin is the overall name for the OS underlying Apple's macOS, iOS, etc.). ``@rustbot`` label O-apple r? compiler
…02, r=joboet Remove creation of duplicate `AnonPipe` The `File` is unwrapped to a `Handle` into an `AnonPipe`, and then that `AnonPipe` was unwrapped to a `Handle` into another `AnonPipe`. The second operation is entirely redundant.
Deduplicate some `rustc_middle` function bodies by calling the `rustc_type_ir` equivalent Maybe in the future we can use method delegation, but I'd rather avoid that for now (I don't even know if it can do that already)
compiletest: Encapsulate all of the code that touches libtest Compiletest currently relies on unstable libtest APIs in order to actually execute tests. That's unfortunate, but removing the dependency isn't trivial. However, we can make a small step towards removing the libtest dependency by encapsulating the libtest interactions into a single dedicated module. That makes it easier to see what parts of libtest are actually used. --- As a side-effect of moving the `test_opts` function into that dedicated module, this PR also ends up allowing `--fail-fast` to be passed on the command line, instead of requiring an environment variable. --- There is still (at least) one other aspect of the libtest dependency that this PR does not address, namely the fact that we rely on libtest's output capture (via unstable std APIs) to capture the output that we print during individual tests. I hope to do something about that at some point. r? jieyouxu
Add helper function for checking LLD usage to `run-make-support` Extracted out of #138645, should be a simple refactoring. r? ``@jieyouxu``
Pass correct param-env to `error_implies` Duplicated comment from the test: In the error reporting code, when reporting fulfillment errors for goals A and B, we try to see if elaborating A will result in another goal that can equate with B. That would signal that B is "implied by" A, allowing us to skip reporting it, which is beneficial for cutting down on the number of diagnostics we report. In the new trait solver especially, but even in the old trait solver through things like defining opaque type usages, this `can_equate` call was not properly taking the param-env of the goals, resulting in nested obligations that had empty param-envs. If one of these nested obligations was a `ConstParamHasTy` goal, then we would ICE, since those goals are particularly strict about the param-env they're evaluated in. This is morally a fix for <#139314>, but that repro uses details about how defining usages in the `check_opaque_well_formed` code can spring out of type equality, and will likely stop failing soon coincidentally once we start using `PostBorrowck` mode in that check. Instead, we use lazy normalization to end up generating an alias-eq goal whose nested goals woul trigger the ICE instead, since this is a lot more stable. Fixes #139314 r? ``@oli-obk`` or reassign
Add a mailmap entry for myself
…r-errors adt_destructor: sanity-check returned item Fixes #139278
Rollup of 8 pull requests Successful merges: - #138949 (Rename `is_like_osx` to `is_like_darwin`) - #139295 (Remove creation of duplicate `AnonPipe`) - #139313 (Deduplicate some `rustc_middle` function bodies by calling the `rustc_type_ir` equivalent) - #139317 (compiletest: Encapsulate all of the code that touches libtest) - #139322 (Add helper function for checking LLD usage to `run-make-support`) - #139335 (Pass correct param-env to `error_implies`) - #139342 (Add a mailmap entry for myself) - #139349 (adt_destructor: sanity-check returned item) r? `@ghost` `@rustbot` modify labels: rollup
Run coretests and alloctests with cg_clif in CI Part of rust-lang/rustc_codegen_cranelift#1290
…r_of_i686-pc-windows-gnu, r=workingjubilee Demote i686-pc-windows-gnu to Tier 2 In accordance with [RFC 3771](rust-lang/rfcs#3771). FCP has been completed. tracking issue #138422 I also added a stub doc page for the target and renamed the windows-gnullvm page for consistency.
…oli-obk add `TypingMode::Borrowck` Shares the first commit with #138499, doesn't really matter which PR to land first 😊 😁 Introduces `TypingMode::Borrowck` which unlike `TypingMode::Analysis`, uses the hidden type computed by HIR typeck as the initial value of opaques instead of an unconstrained infer var. This is a part of rust-lang/types-team#129. Using this new `TypingMode` is unfortunately a breaking change for now, see tests/ui/impl-trait/non-defining-uses/as-projection-term.rs. Using an inference variable as the initial value results in non-defining uses in the defining scope. We therefore only enable it if with `-Znext-solver=globally` or `-Ztyping-mode-borrowck` To do that the PR contains the following changes: - `TypeckResults::concrete_opaque_type` are already mapped to the definition of the opaque type - writeback now checks that the non-lifetime parameters of the opaque are universal - for this, `fn check_opaque_type_parameter_valid` is moved from `rustc_borrowck` to `rustc_trait_selection` - we add a new `query type_of_opaque_hir_typeck` which, using the same visitors as MIR typeck, attempts to merge the hidden types from HIR typeck from all defining scopes - done by adding a `DefiningScopeKind` flag to toggle between using borrowck and HIR typeck - the visitors stop checking that the MIR type matches the HIR type. This is trivial as the HIR type are now used as the initial hidden types of the opaque. This check is useful as a safeguard when not using `TypingMode::Borrowck`, but adding it to the new structure is annoying and it's not soundness critical, so I intend to not add it back. - add a `TypingMode::Borrowck` which behaves just like `TypingMode::Analysis` except when normalizing opaque types - it uses `type_of_opaque_hir_typeck(opaque)` as the initial value after replacing its regions with new inference vars - it uses structural lookup in the new solver fixes #112201, fixes #132335, fixes #137751 r? `@compiler-errors` `@oli-obk`
…tSelf, r=BoxyUwU Remove `rustc_middle::ty::util::ExplicitSelf`. It's an old (2017 or earlier) type that describes a `self` receiver. It's only used in `rustc_hir_analysis` for two error messages, and much of the complexity isn't used. I suspect it used to be used for more things. This commit removes it, and moves a greatly simplified version of the `determine` method into `rustc_hir_analysis`, renamed as `get_self_string`. The big comment on the method is removed because it no longer seems relevant. r? `@BoxyUwU`
…mease Fix 2024 edition doctest panic output Fixes #137970. The problem was that the output was actually displayed by rustc itself because we're exiting with `Result<(), String>`, and the display is really not great. So instead, we get the output, we print it and then we return an `ExitCode`. r? ````@aDotInTheVoid````
unstable book: document tait Documents the type alias impl trait feature. Rendered:    because you are deeply involved in this I'll r you but feel free to reroll r? `@oli-obk`
…ochenkov AsyncDestructor: replace fields with impl_did The future and ctor fields aren't actually used, and the way they are extracted is obviously wrong – swapping the order of the items in the source code will give wrong results. Instead, store just the LocalDefId of the impl, which is enough for the only use of this data.
Fix `Debug` impl for `LateParamRegionKind`. It uses `Br` prefixes which are inappropriate and appear to have been incorrectly copy/pasted from the `Debug` impl for `BoundRegionKind`. r? `@BoxyUwU`
ToSocketAddrs: fix typo It's "a function", never "an function". I noticed the same typo somewhere in the compiler sources so figured I'd fix it there as well.
Use the span of the whole bound when the diagnostic talks about a bound While it makes sense that the host predicate only points to the `~const` part, as whether the actual trait bound is satisfied is checked separately, the user facing diagnostic is talking about the entire trait bound, at which point it makes more sense to just highlight the entire bound r? `@compiler-errors` or `@fee1-dead`
Use target-agnostic LLD flags in bootstrap for `use-lld` [Before](#135001), I hardcoded LLD flags that pretty much only worked on GNU. The right way is to use `-Zlinker-features` instead though. I *think* that this should also make this work on Windows mingw, and thus `@petrochenkov's` workaround is no longer necessary. Fixes: #139372 Closes: #139375 r? `@lqd`
Add `compiletest` adhoc_group for `r? compiletest` r? `@Kobzol` (or bootstrap/compiler)
Rollup of 9 pull requests Successful merges: - #139041 (Remove `rustc_middle::ty::util::ExplicitSelf`.) - #139328 (Fix 2024 edition doctest panic output) - #139339 (unstable book: document tait) - #139348 (AsyncDestructor: replace fields with impl_did) - #139353 (Fix `Debug` impl for `LateParamRegionKind`.) - #139366 (ToSocketAddrs: fix typo) - #139374 (Use the span of the whole bound when the diagnostic talks about a bound) - #139378 (Use target-agnostic LLD flags in bootstrap for `use-lld`) - #139384 (Add `compiletest` adhoc_group for `r? compiletest`) r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )