Rustup #12632
Merged
Rustup #12632
Conversation
This file contains hidden or 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
…es was ignored Fixes: rust-lang#11481 changelog: Fix `allow-one-hash-in-raw-strings` option of [`needless_raw_string_hashes`] was ignored
…thod call
```
error[E0283]: type annotations needed
--> $DIR/into-inference-needs-type.rs:12:10
|
LL | .into()?;
| ^^^^
|
= note: cannot satisfy `_: From<...>`
= note: required for `FilterMap<...>` to implement `Into<_>`
help: try using a fully qualified path to specify the expected types
|
LL ~ let list = <FilterMap<Map<std::slice::Iter<'_, &str>, _>, _> as Into<T>>::into(vec
LL | .iter()
LL | .map(|s| s.strip_prefix("t"))
LL ~ .filter_map(Option::Some))?;
|
```
Fix #122569.
Split an item bounds and an item's super predicates This is the moral equivalent of #107614, but instead for predicates this applies to **item bounds**. This PR splits out the item bounds (i.e. *all* predicates that are assumed to hold for the alias) from the item *super predicates*, which are the subset of item bounds which share the same self type as the alias. ## Why? Much like #107614, there are places in the compiler where we *only* care about super-predicates, and considering predicates that possibly don't have anything to do with the alias is problematic. This includes things like closure signature inference (which is at its core searching for `Self: Fn(..)` style bounds), but also lints like `#[must_use]`, error reporting for aliases, computing type outlives predicates. Even in cases where considering all of the `item_bounds` doesn't lead to bugs, unnecessarily considering irrelevant bounds does lead to a regression (#121121) due to doing extra work in the solver. ## Example 1 - Trait Aliases This is best explored via an example: ``` type TAIT<T> = impl TraitAlias<T>; trait TraitAlias<T> = A + B where T: C; ``` The item bounds list for `Tait<T>` will include: * `Tait<T>: A` * `Tait<T>: B` * `T: C` While `item_super_predicates` query will include just the first two predicates. Side-note: You may wonder why `T: C` is included in the item bounds for `TAIT`? This is because when we elaborate `TraitAlias<T>`, we will also elaborate all the predicates on the trait. ## Example 2 - Associated Type Bounds ``` type TAIT<T> = impl Iterator<Item: A>; ``` The `item_bounds` list for `TAIT<T>` will include: * `Tait<T>: Iterator` * `<Tait<T> as Iterator>::Item: A` But the `item_super_predicates` will just include the first bound, since that's the only bound that is relevant to the *alias* itself. ## So what This leads to some diagnostics duplication just like #107614, but none of it will be user-facing. We only see it in the UI test suite because we explicitly disable diagnostic deduplication. Regarding naming, I went with `super_predicates` kind of arbitrarily; this can easily be changed, but I'd consider better names as long as we don't block this PR in perpetuity.
Replace closures with `_` when suggesting fully qualified path for method call
```
error[E0283]: type annotations needed
--> $DIR/into-inference-needs-type.rs:12:10
|
LL | .into()?;
| ^^^^
|
= note: cannot satisfy `_: From<...>`
= note: required for `FilterMap<...>` to implement `Into<_>`
help: try using a fully qualified path to specify the expected types
|
LL ~ let list = <FilterMap<Map<std::slice::Iter<'_, &str>, _>, _> as Into<T>>::into(vec
LL | .iter()
LL | .map(|s| s.strip_prefix("t"))
LL ~ .filter_map(Option::Some))?;
|
```
Fix #122569.
Stop using `box PAT` syntax for deref patterns, as it's misleading and also causes their semantics being tangled up.
This includes updating astconv-related items and a few local variables.
Several (doc) comments were super outdated or didn't provide enough context. Some doc comments shoved everything in a single paragraph without respecting the fact that the first paragraph should be a single sentence because rustdoc treats these as item descriptions / synopses on module pages.
Experimental feature postfix match This has a basic experimental implementation for the RFC postfix match (rust-lang/rfcs#3295, #121618). [Liaison is](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Postfix.20Match.20Liaison/near/423301844) ```@scottmcm``` with the lang team's [experimental feature gate process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md). This feature has had an RFC for a while, and there has been discussion on it for a while. It would probably be valuable to see it out in the field rather than continue discussing it. This feature also allows to see how popular postfix expressions like this are for the postfix macros RFC, as those will take more time to implement. It is entirely implemented in the parser, so it should be relatively easy to remove if needed. This PR is split in to 5 commits to ease review. 1. The implementation of the feature & gating. 2. Add a MatchKind field, fix uses, fix pretty. 3. Basic rustfmt impl, as rustfmt crashes upon seeing this syntax without a fix. 4. Add new MatchSource to HIR for Clippy & other HIR consumers
Rollup of 9 pull requests Successful merges: - #121619 (Experimental feature postfix match) - #122370 (Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`) - #122537 (interpret/allocation: fix aliasing issue in interpreter and refactor getters a bit) - #122542 (coverage: Clean up marker statements that aren't needed later) - #122800 (Add `NonNull::<[T]>::is_empty`.) - #122820 (Stop using `<DefId as Ord>` in various diagnostic situations) - #122847 (Suggest `RUST_MIN_STACK` workaround on overflow) - #122855 (Fix Itanium mangling usizes) - #122863 (add more ice tests ) r? `@ghost` `@rustbot` modify labels: rollup
Note that the caller chooses a type for type param
```
error[E0308]: mismatched types
--> $DIR/return-impl-trait.rs:23:5
|
LL | fn other_bounds<T>() -> T
| - -
| | |
| | expected `T` because of return type
| | help: consider using an impl return type: `impl Trait`
| expected this type parameter
...
LL | ()
| ^^ expected type parameter `T`, found `()`
|
= note: expected type parameter `T`
found unit type `()`
= note: the caller chooses the type of T which can be different from ()
```
Tried to see if "expected this type parameter" can be replaced, but that goes all the way to `rustc_infer` so seems not worth the effort and can affect other diagnostics.
Revives #112088 and #104755.
Split out `PredicatePolarity` from `ImplPolarity` Because having to deal with a third `Reservation` level in all the trait solver code is kind of weird. r? `@lcnr` or `@oli-obk`
Rollup of 8 pull requests Successful merges: - #114009 (compiler: allow transmute of ZST arrays with generics) - #122195 (Note that the caller chooses a type for type param) - #122651 (Suggest `_` for missing generic arguments in turbofish) - #122784 (Add `tag_for_variant` query) - #122839 (Split out `PredicatePolarity` from `ImplPolarity`) - #122873 (Merge my contributor emails into one using mailmap) - #122885 (Adjust better spastorino membership to triagebot's adhoc_groups) - #122888 (add a couple more tests) r? `@ghost` `@rustbot` modify labels: rollup
…t,saethlin Replace visibility test with reachability test in dead code detection Fixes rust-lang/rust#119545 Also included is a fix for an error now flagged by the lint
Rename `hir::Local` into `hir::LetStmt` Follow-up of #122776. As discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Improve.20naming.20of.20.60ExprKind.3A.3ALet.60.3F). I made this change into a separate PR because I'm less sure about this change as is. For example, we have `visit_local` and `LocalSource` items. Is it fine to keep these two as is (I supposed it is but I prefer to ask) or not? Having `Node::Local(LetStmt)` makes things more explicit but is it going too far? r? ```@oli-obk```
These macros and functions are not intrinsics, after all.
refactor check_{lang,library}_ub: use a single intrinsic
This enacts the plan I laid out [here](rust-lang/rust#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library.
This makes it easier to do something like rust-lang/rust#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time.
The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics.
r? `@saethlin`
It turns out there is a bit of a circular dependency - I cannot add anything to `core` because Clippy fails, and I can't actually add correct Clippy implementations without new implementations from `core`. Change some of the Clippy stubs from `unimplemented!` to success values and leave a FIXME in their place to mitigate this. Fixes <rust-lang/rust#122587>
…r=oli-obk Rename `Inherited` -> `TypeckRootCtxt` `Inherited` is a confusing name. Rename it to `TypeckRootCtxt`. I don't think this needs a type MCP or anything since it's not nearly as pervasive as `FnCtxt` , for example. r? `@lcnr` `@oli-obk`
rename ptr::from_exposed_addr -> ptr::with_exposed_provenance As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/To.20expose.20or.20not.20to.20expose/near/427757066). The old name, `from_exposed_addr`, makes little sense as it's not the address that is exposed, it's the provenance. (`ptr.expose_addr()` stays unchanged as we haven't found a better option yet. The intended interpretation is "expose the provenance and return the address".) The new name nicely matches `ptr::without_provenance`.
rustbot
added
the
S-waiting-on-review
|
@bors r+ |
bors
added a commit
that referenced
this pull request
Apr 4, 2024
Rustup r? `@ghost` changelog: none
|
💔 Test failed - checks-action_test |
|
@bors r+ |
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
1 similar comment
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
|
👀 Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request. |
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.
r? @ghost
changelog: none