Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

subtree-push nightly-2025-04-02 #6531

Merged
merged 38 commits into from
Apr 2, 2025

Conversation

ytmimi
Copy link
Contributor

@ytmimi ytmimi commented Apr 2, 2025

Bumping the toolchain version as part of a git subtree push

current toolchain (nightly-2025-01-02):

  • 1.85.0-nightly (45d11e51b 2025-01-01)

latest toolchain (nightly-2025-04-02):

  • 1.88.0-nightly (e2014e876 2025-04-01)

jieyouxu and others added 30 commits January 7, 2025 20:49
Only treat plain literal patterns as short

See rust-lang/rust#134228 (comment) and rust-lang/rust#134228 (comment) for context. We never wanted to treat const blocks and paths as short, only plain literals.

I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting
`BinOpToken` is badly named, because it only covers the assignable
binary ops and excludes comparisons and `&&`/`||`. Its use in
`ast::TokenKind` does allow a small amount of code sharing, but it's a
clumsy factoring.

This commit removes `ast::TokenKind::BinOp{,Eq}`, replacing each one
with 10 individual variants. This makes `ast::TokenKind` more similar to
`rustc_lexer::TokenKind`, which has individual variants for all
operators.

Although the number of lines of code increases, the number of chars
decreases due to the frequent use of shorter names like `token::Plus`
instead of `token::BinOp(BinOpToken::Plus)`.
For consistency with `rustc_lexer::TokenKind::Bang`, and because other
`ast::TokenKind` variants generally have syntactic names instead of
semantic names (e.g. `Star` and `DotDot` instead of `Mul` and `Range`).
Implement `#[cfg]` in `where` clauses

This PR implements #115590, which supports `#[cfg]` attributes in `where` clauses.

The biggest change is, that it adds `AttrsVec` and  `NodeId` to the `ast::WherePredicate` and `HirId` to the `hir::WherePredicate`.
Rollup of 12 pull requests

Successful merges:

 - #135767 (Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies)
 - #137852 (Remove layouting dead code for non-array SIMD types.)
 - #137863 (Fix pretty printing of unsafe binders)
 - #137882 (do not build additional stage on compiler paths)
 - #137894 (Revert "store ScalarPair via memset when one side is undef and the other side can be memset")
 - #137902 (Make `ast::TokenKind` more like `lexer::TokenKind`)
 - #137921 (Subtree update of `rust-analyzer`)
 - #137922 (A few cleanups after the removal of `cfg(not(parallel))`)
 - #137939 (fix order on shl impl)
 - #137946 (Fix docker run-local docs)
 - #137955 (Always allow rustdoc-json tests to contain long lines)
 - #137958 (triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search)

r? `@ghost`
`@rustbot` modify labels: rollup
…matsakis

Ergonomic ref counting

This is an experimental first version of ergonomic ref counting.

This first version implements most of the RFC but doesn't implement any of the optimizations. This was left for following iterations.

RFC: rust-lang/rfcs#3680
Tracking issue: rust-lang/rust#132290
Project goal: rust-lang/rust-project-goals#107

r? ```@nikomatsakis```
This involved fixing the span when parsing .yield
They're dodgy, covering all the keywords, including weak ones, and
edition-specific ones without considering the edition. They have a
single use in rustfmt. This commit changes that use to
`is_reserved_ident`, which is a much more widely used alternative and is
good enough, judging by the lack of effect on the test suite.
Since `{ ident: ident }` is a parse error, these fields are dead.
Visitors track whether an assoc item is in a trait impl or an inherent impl

`AssocCtxt::Impl` now contains an `of_trait` field. This allows ast lowering and nameres to not have to track whether we're in a trait impl or an inherent impl.
Zalathar and others added 8 commits March 26, 2025 19:40
…mpiler-errors

Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax

**Disclaimer**: This PR is intended to mostly clean up code as opposed to bringing about behavioral changes. Therefore it doesn't aim to address any of the 'FIXME: remove after a month [dated: 2023-05-02]: "type ascription syntax has been removed, see issue [#]101728"'.

---

By commit:

1. Removes truly dead code:
   * Since 1.71 (#109128) `let _ = { f: x };` is a syntax error as opposed to a semantic error which allows the parse-time diagnostic (suggestion) "*struct literal body without path // you might have forgotten […]*" to kick in.
   * The analysis-time diagnostic (suggestion) from <=1.70 "*cannot find value \`f\` in this scope // you might have forgotten […]*" is therefore no longer reachable.
2. Updates `is_certainly_not_a_block` to be in line with the current grammar:
   * The seq. `{ ident:` is definitely not the start of a block. Before the removal of ty ascr, `{ ident: ty_start` would begin a block expr.
   * This shouldn't make more code compile IINM, it should *ultimately* only affect diagnostics.
   * For example, `if T { f: () } {}` will now be interpreted as an `if` with struct lit `T { f: () }` as its *condition* (which is banned in the parser anyway) as opposed to just `T` (with the *consequent* being `f : ()` which is also invalid (since 1.71)). The diagnostics are almost the same because we have two separate parse recovery procedures + diagnostics: `StructLiteralNeedingParens` (*invalid struct lit*) before and `StructLiteralNotAllowedHere` (*struct lits aren't allowed here*) now, as you can see from the diff.
   * (As an aside, even before this PR, fn `maybe_suggest_struct_literal` should've just used the much older & clearer `StructLiteralNotAllowedHere`)
   * NB: This does sadly regress the compiler output for `tests/ui/parser/type-ascription-in-pattern.rs` but that can be fixed in follow-up PRs. It's not super important IMO and a natural consequence.
3. Removes code that's become dead due to the prior commit.
   * Basically reverts #106620 + #112475 (without regressing rustc's output!).
   * Now the older & more robust parse recovery procedure (cc `StructLiteralNotAllowedHere`) takes care of the cases the removed code used to handle.
   * This automatically fixes the suggestions for \[[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=7e2030163b11ee96d17adc3325b01780)\]:
     * `if Ty::<i32> { f: K }.m() {}`: `if Ty::<i32> { SomeStruct { f: K } }.m() {}` (broken) → ` if (Ty::<i32> { f: K }).m() {}`
     * `if <T as Trait>::Out { f: K::<> }.m() {}`: `if <T as Trait>(::Out { f: K::<> }).m() {}` (broken) → `if (<T as Trait>::Out { f: K::<> }).m() {}`
4. Merge and simplify UI tests pertaining to this issue, so it's easier to add more regression tests like for the two cases mentioned above.
5. Merge UI tests and add the two regression tests.

Best reviewed commit by commit (on request I'll partially squash after approval).
Instead of putting the item inside it, just pass the ident and
visibility (the only things needed) alongside it where necessary.

This helps with the next commit, which will move the ident's location.
Specifically, it gets rid of the `match visitor_kind` in
`rewrite_type_alias`.
`FmtVisitor::visit_mac` has an `Option<Ident>` arg which is always
either `None` or `Some(kw::Empty)`, because `ItemKind::MacCall` always
has an empty ident. This value is passed through various functions until
it reaches `rewrite_macro_name`, which treats `None` and
`Some(kw::Empty)` the same.

In other words, the argument is useless. This commit removes it. There
is no change in behaviour. The commit also changes a few `symbol::Ident`
occurrences to `Ident` in `macros.rs`; `Symbol` is imported in that file
so `Ident` might as well be, too.

(This is a good example of why it's a bad idea for `Itemt` to have an
`ident` field when various item kinds don't have an identifier. It's
easy to get confused when "empty identifier" is used to mean "no
identifier". This will be fixed in a subsequent commit.)
`ast::Item` has an `ident` field.

- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
  `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
  `Trait`, `TraitAlias`, `MacroDef`, `Delegation`.

- It's always empty for these item kinds: `Use`, `ForeignMod`,
  `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`.

There is a similar story for `AssocItemKind` and `ForeignItemKind`.

Some sites that handle items check for an empty ident, some don't. This
is a very C-like way of doing things, but this is Rust, we have sum
types, we can do this properly and never forget to check for the
exceptional case and never YOLO possibly empty identifiers (or possibly
dummy spans) around and hope that things will work out.

The commit is large but it's mostly obvious plumbing work. Some notable
things.

- `ast::Item` got 8 bytes bigger. This could be avoided by boxing the
  fields within some of the `ast::ItemKind` variants (specifically:
  `Struct`, `Union`, `Enum`). I might do that in a follow-up; this
  commit is big enough already.

- For the visitors: `FnKind` no longer needs an `ident` field because
  the `Fn` within how has one.

- In the parser, the `ItemInfo` typedef is no longer needed. It was used
  in various places to return an `Ident` alongside an `ItemKind`, but
  now the `Ident` (if present) is within the `ItemKind`.

- In a few places I renamed identifier variables called `name` (or
  `foo_name`) as `ident` (or `foo_ident`), to better match the type, and
  because `name` is normally used for `Symbol`s. It's confusing to see
  something like `foo_name.name`.
remove `feature(inline_const_pat)`

Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.

With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:

- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.

There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
  - causes inline const patterns to be different than inline const exprs
  - prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
  - region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }`  instead. We then only evaluate them after borrowck
  - difference between `const { 1 }`  and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
  - do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
  - should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now

I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.

`const { .. }`-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920.

r? types

cc `@rust-lang/types` `@rust-lang/lang` #76001
Bumping the toolchain version as part of a git subtree push

current toolchain (nightly-2025-01-02):
  - 1.85.0-nightly (45d11e51b 2025-01-01)

latest toolchain (nightly-2025-04-02):
  - 1.88.0-nightly (e2014e876 2025-04-01)
@ytmimi
Copy link
Contributor Author

ytmimi commented Apr 2, 2025

Diff Check Job

Edit: Check Failed ❌

@ytmimi
Copy link
Contributor Author

ytmimi commented Apr 2, 2025

Diff Check failures in more detail:

Feature: #![feature(where_clause_attrs)]

         #[cfg = b]
         /* block comment after the attribute */
         U: TraitB,
-        #[cfg = a] // short
+        #[cfg = a]
+        // short
         U: TraitA,
-        #[cfg = b] /* short */ U: TraitB;
+        #[cfg = b]
+        /* short */
+        U: TraitB;

Bugfix: Do not yeet unsafe<> from type

-fn empty() -> unsafe<> () {}
+fn empty() -> () {}

Feature: #![feature(pin_ergonomics)]

-fn f(x: &pin  const i32) {}
-fn g<'a>(x: &  'a pin const  i32) {}
-fn h<'a>(x: &  'a pin  
-mut i32) {}
-fn i(x: &pin      mut  i32) {}
+fn f(x: &pin const i32) {}
+fn g<'a>(x: &'a pin const i32) {}
+fn h<'a>(x: &'a pin mut i32) {}
+fn i(x: &pin mut i32) {}

Parse Error: src/tools/rust-analyzer/crates/parser/test_data/parser/inline/ok/record_pat_field_list.rs

  • Not sure which commit lead to the code no longer parsing.

rustfmt 1.8.0-nightly (f371e16 2025-04-01) produces this diff:

 fn foo() {
     let S {} = ();
     let S { f, ref mut g } = ();
-    let S { h: _, ..} = ();
-    let S { h: _, } = ();
-    let S { #[cfg(any())] .. } = ();
+    let S { h: _, .. } = ();
+    let S { h: _ } = ();
+    let S { .. } = ();
 }

This PR's rustfmt can't parse the code:

error: expected identifier, found `..`
 --> <stdin>:6:27
  |
6 |     let S { #[cfg(any())] .. } = ();
  |         -                 ^^ expected identifier
  |         |
  |         while parsing the fields for this pattern

Parse Error: src/tools/rust-analyzer/crates/parser/test_data/parser/inline/ok/const_block_pat.rs

  • Not sure which commit lead to the code no longer parsing.

rustfmt 1.8.0-nightly (f371e16 2025-04-01) produces this diff:

 fn main() {
     let const { 15 } = ();
-    let const { foo(); bar() } = ();
+    let const {
+        foo();
+        bar()
+    } = ();
 
     match 42 {
-        const { 0 } .. const { 1 } => (),
-        .. const { 0 } => (),
-        const { 2 } .. => (),
+        const { 0 }..const { 1 } => (),
+        ..const { 0 } => (),
+        const { 2 }.. => (),
     }

This PR's rustfmt can't parse the code:

error: `inline_const_pat` has been removed
 --> <stdin>:2:15
  |
2 |     let const { 15 } = ();
  |               ^^^^^^
  |
  = help: use a named `const`-item or an `if`-guard instead

@ytmimi
Copy link
Contributor Author

ytmimi commented Apr 2, 2025

Given that the Diff-Check failed because of unstable feature, bug fixes implemented in the r-l/r tree, and code that no longer compiles we should be good to go here.

@ytmimi ytmimi merged commit e3f0a53 into rust-lang:master Apr 2, 2025
26 checks passed
@ytmimi ytmimi deleted the subtree-push-nightly-2025-04-02 branch April 2, 2025 04:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.