Commit Graph

359 Commits

Author SHA1 Message Date
Guillaume Gomez
d3e042dc4e
Rollup merge of #124749 - RossSmyth:stable_range, r=davidtwco
Stabilize exclusive_range_pattern (v2)

This PR is identical to #124459, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F).

r? ghost

Original PR description:

---

Stabilization report: https://github.com/rust-lang/rust/issues/37854#issuecomment-1842398130
FCP: https://github.com/rust-lang/rust/issues/37854#issuecomment-1872520294

Stabilization was blocked by a lint that was merged here: #118879

Documentation PR is here: rust-lang/reference#1484

`@rustbot` label +F-exclusive_range_pattern +T-lang
2024-05-05 16:42:48 +02:00
Urgau
d4e26fbb53 compiletest: add enable-by-default check-cfg 2024-05-04 11:30:38 +02:00
Ross Smyth
6967d1c0fc Stabilize exclusive_range 2024-05-02 19:42:31 -04:00
Lieselotte
b52e4bd997
Fix substitution parts having a shifted underline in some cases 2024-04-25 13:09:13 +02:00
Gary Guo
cfee72aa24 Fix tests and bless 2024-04-24 13:12:33 +01:00
Matthias Krüger
57dad1d75e
Rollup merge of #124099 - voidc:disallow-ambiguous-expr-attrs, r=davidtwco
Disallow ambiguous attributes on expressions

This implements the suggestion in [#15701](https://github.com/rust-lang/rust/issues/15701#issuecomment-2033124217) to disallow ambiguous outer attributes on expressions. This should resolve one of the concerns blocking the stabilization of `stmt_expr_attributes`.
2024-04-23 12:10:26 +02:00
Matthias Krüger
5800e2a6f9
Rollup merge of #124200 - scrabsha:sasha/->, r=compiler-errors,fmease
Improve handling of expr->field errors

The current message for "`->` used for field access" is the following:

```rust
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `->`
 --> src/main.rs:2:6
  |
2 |     a->b;
  |      ^^ expected one of 8 possible tokens
```

([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7f8b6f4433aa7866124123575456f54e))

This PR tries to address this by adding a dedicated error message and recovery. The proposed error message is:

```
error: `->` used for field access or method call
 --> ./tiny_test.rs:2:6
  |
2 |     a->b;
  |      ^^ help: try using `.` instead
  |
  = help: the `.` operator will dereference the value if needed
```

(feel free to bikeshed it as much as necessary)
2024-04-23 06:24:57 +02:00
Sasha Pourcelot
98332c108b Improve handling of expr->field errors
The current message for "`->` used for field access" is the following:

```rust
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `->`
 --> src/main.rs:2:6
  |
2 |     a->b;
  |      ^^ expected one of 8 possible tokens
```

(playground link[1])

This PR tries to address this by adding a dedicated error message and recovery. The proposed error message is:

```
error: `->` used for field access or method call
 --> ./tiny_test.rs:2:6
  |
2 |     a->b;
  |      ^^ help: try using `.` instead
  |
  = help: the `.` operator will dereference the value if needed
```

(feel free to bikeshed it as much as necessary)

[1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7f8b6f4433aa7866124123575456f54e

Signed-off-by: Sasha Pourcelot <sasha.pourcelot@protonmail.com>
2024-04-22 17:47:35 +02:00
Caio
3aaa3941fd Move some tests 2024-04-21 15:43:43 -03:00
Dominik Stolz
5af861cf7b Disallow ambiguous attributes on expressions 2024-04-18 20:42:19 +02:00
Matthias Krüger
e4c8672571
Rollup merge of #123847 - eggyal:issue-123844, r=fmease
Suppress `let else` suggestion for uninitialized refutable `let`s

Fixes #123844

r? `@CAD97`
2024-04-12 21:46:59 +02:00
Alan Egerton
ddcfb94b84
Suppress erroneous suggestion
The suggestion to use `let else` with an uninitialized refutable `let`
statement was erroneous: `let else` cannot be used with deferred
initialization.
2024-04-12 17:45:15 +01:00
Matthias Krüger
15a8b490ea
Rollup merge of #123841 - Kohei316:remove_qualifier_sugg, r=wesleywiser
Improve diagnostic by suggesting to remove visibility qualifier

Resolves #123529
This PR improve diagnostic by suggesting to remove visibility qualifier.
2024-04-12 17:41:35 +02:00
morine0122
ac1bee6493 Improve diagnostic by suggesting to remove visibility qualifier 2024-04-12 12:59:40 +09:00
Urgau
3ba0139c66 Remove useless configs in tests
Since they are never set and don't have impact on the test.

Or for the cfg-panic tests are already tested with check-cfg.
2024-04-07 01:16:45 +02:00
Urgau
c4a97d9407 Unify all the always-false cfgs under the FALSE cfg 2024-04-07 01:16:45 +02:00
Arthur Carcano
109daa2d4b Fix diagnostic for qualifier in extern block
Closes: https://github.com/rust-lang/rust/issues/123306
2024-04-04 11:58:38 +02:00
Matthias Krüger
ff8cdc9e14
Rollup merge of #122120 - fmease:sugg-assoc-ty-bound-on-eq-bound, r=compiler-errors
Suggest associated type bounds on problematic associated equality bounds

Fixes #105056. TL;DR: Suggest `Trait<Ty: Bound>` on `Trait<Ty = Bound>` in Rust >=2021.

~~Blocked on #122055 (stabilization of `associated_type_bounds`), I'd say.~~ (merged)
2024-03-26 21:23:47 +01:00
Matthias Krüger
e9ec44251c
Rollup merge of #122910 - compiler-errors:unit-struct-in-path-pat-only, r=petrochenkov
Validate that we're only matching on unit struct for path pattern

Resolution doesn't validate that we only really take `CtorKind::Unit` in path patterns, since all it sees is `Res::SelfCtor(def_id)`. Check this instead during pattern typeck.

r? petrochenkov

Fixes #122809
2024-03-25 17:05:33 +01:00
Matthias Krüger
1164c2725e
Rollup merge of #122217 - estebank:issue-119685, r=fmease
Handle str literals written with `'` lexed as lifetime

Given `'hello world'` and `'1 str', provide a structured suggestion for a valid string literal:

```
error[E0762]: unterminated character literal
  --> $DIR/lex-bad-str-literal-as-char-3.rs:2:26
   |
LL |     println!('hello world');
   |                          ^^^^
   |
help: if you meant to write a `str` literal, use double quotes
   |
LL |     println!("hello world");
   |              ~           ~
```
```
error[E0762]: unterminated character literal
  --> $DIR/lex-bad-str-literal-as-char-1.rs:2:20
   |
LL |     println!('1 + 1');
   |                    ^^^^
   |
help: if you meant to write a `str` literal, use double quotes
   |
LL |     println!("1 + 1");
   |              ~     ~
```

Fix #119685.
2024-03-24 01:05:51 +01:00
Michael Goulet
08235b1603 Validate that we're only matching on unit struct for path pattern 2024-03-22 20:53:42 -04:00
León Orell Valerian Liehr
3879acbec0
Suggest assoc ty bound on lifetime in eq constraint 2024-03-23 00:17:30 +01:00
Matthias Krüger
2171243b2b add test for #105210 assertion failure self.lines.iter().all(|r| !r.iter().any(|sc| sc.chr == \'\\t\')) with edition 2021
Fixes #105210
2024-03-22 17:25:57 +01:00
Nicholas Nethercote
8ac16c6193 Rewrite parse_meta_item.
It can't use `maybe_whole`, but it can match `maybe_whole` more closely.

Also add a test for a case that wasn't previously covered.
2024-03-21 10:16:09 +11:00
Matthias Krüger
65618908ef
Rollup merge of #122717 - workingjubilee:handle-call-call-call-call-calling-me-maybe, r=compiler-errors
Ensure stack before parsing dot-or-call

There are many cases where, due to codegen or a massively unruly codebase, a deeply nested `call(call(call(call(call(call(call(call(call(f())))))))))` can happen. This is a spot where it would be good to grow our stack, so that we can survive to tell the programmer their code is dubiously written.

Closes https://github.com/rust-lang/rust/issues/122715
2024-03-19 18:03:52 +01:00
Jubilee Young
cdeb170fc2 Ensure stack before parsing dot-or-call
There are many cases where, due to codegen or a massively unruly codebase,
a deeply nested call(call(call(call(call(call(call(call(call(f())))))))))
can happen. This is a spot where it would be good to grow our stack, so that
we can survive to tell the programmer their code is dubiously written.
2024-03-18 21:35:18 -07:00
bors
21d94a3d2c Auto merge of #122055 - compiler-errors:stabilize-atb, r=oli-obk
Stabilize associated type bounds (RFC 2289)

This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses.

### What are we stabilizing?

We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation.

In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info).

Associated type bounds are stabilized in four positions:
* **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`.
* **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See #112573/#112629.
* **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`.
* **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound.

The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in #120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds.

### How does this differ from the RFC?

Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular:
* It does *not* desugar to anonymous associated items in associated type item bounds.
* It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds.

This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in #120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example:
* Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: https://github.com/rust-lang/rust/pull/120752#issuecomment-1979412531.
* Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types.

This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See #120719.

### Implementation history:

Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out--
* #57428
* #108063
* #110512
* #112629
* #120719
* #120584

Closes #52662

[RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html
2024-03-19 00:04:09 +00:00
Esteban Küber
6c31f6ce12 Provide structured suggestion for #![feature(foo)]
```
error: `S2<'_>` is forbidden as the type of a const generic parameter
  --> $DIR/lifetime-in-const-param.rs:5:23
   |
LL | struct S<'a, const N: S2>(&'a ());
   |                       ^^
   |
   = note: the only supported types are integers, `bool` and `char`
help: add `#![feature(adt_const_params)]` to the crate attributes to enable more complex and user defined types
   |
LL + #![feature(adt_const_params)]
   |
```

Fix #55941.
2024-03-18 16:08:58 +00:00
Esteban Küber
999a0dc300 review comment: str -> string in messages 2024-03-17 23:35:18 +00:00
Esteban Küber
4a10b01f95 Use shorter span for existing ' -> " structured suggestion 2024-03-17 23:35:18 +00:00
Trevor Gross
2529bf2650 Remove unneeded f16 and f128 parser tests
Superceded by feature gate tests.
2024-03-14 13:32:54 -04:00
Daniel Sedlak
eab1f30c29 Fix ICE in diagnostics for parenthesized type arguments 2024-03-12 21:32:21 +01:00
Jubilee
05ff86c389
Rollup merge of #122152 - wutchzone:120892, r=fmease
Improve diagnostics for parenthesized type arguments

Fixes #120892

r? fmease
2024-03-11 09:29:35 -07:00
Daniel Sedlak
58f6aaa710 Improve diagnostics for parenthesized type arguments 2024-03-09 22:15:50 +01:00
Matthias Krüger
985befe036
Rollup merge of #122160 - jieyouxu:eager-translate-help-use-latest-edition, r=cjgillot
Eagerly translate `HelpUseLatestEdition` in parser diagnostics

Fixes #122130.

This makes me suspicious of these other two usage of  `add_to_diagnostic()`. Would they *also* crash? I haven't attempted to construct test cases for them.

```
compiler/rustc_parse/src/parser/expr.rs
3453:            errors::HelpUseLatestEdition::new().add_to_diagnostic(e);

compiler/rustc_hir_typeck/src/expr.rs
2603:            HelpUseLatestEdition::new().add_to_diagnostic(&mut err);
```

This also seems like a footgun?
2024-03-09 16:21:16 +01:00
Michael Goulet
c63f3feb0f Stabilize associated type bounds 2024-03-08 20:56:25 +00:00
许杰友 Jieyou Xu (Joe)
4663fbb2cb
Eagerly translate HelpUseLatestEdition in parser diagnostics 2024-03-07 23:03:42 +00:00
Guillaume Gomez
2e3bde2bc4
Rollup merge of #122004 - fmease:astvalidator-min-fix, r=compiler-errors
AST validation: Improve handling of inherent impls nested within functions and anon consts

Minimal fix for issue #121607 extracted from PR #120698 for ease of backporting and since I'd like to improve PR #120698 in such a way that it makes AST validator truly robust against such sort of regressions (AST validator is generally *beyond* footgun-y atm). The current version of PR #120698 sort of does that already but there's still room for improvement.

Fixes #89342.
Fixes [after beta-backport] #121607.
Partially addresses #119924 (#120698 aims to fully fix it).

---

### Explainer

The last commit of PR #119505 regressed issue #121607.

Previously we would reject visibilities on associated items with `visibility_not_permitted` if we were in a trait (by checking the parameter `ctxt` of `visit_assoc_item` which was 100% accurate) or if we were in a trait impl (by checking a flag called `in_trait_impl` tracked in `AstValidator` which was/is only accurate if the visitor methods correctly updated it which isn't actually the case giving rise to the old open issue #89342).

In PR #119505, I moved even more state into the `AstValidator` by generalizing the flag `in_trait_impl` to `trait_or_trait_impl` to be able to report more precise diagnostics (modeling *Trait | TraitImpl*). However since we/I didn't update `trait_or_trait_impl` in all places to reflect reality (similar to us not updating `in_trait_impl` before), this lead to https://github.com/rust-lang/rust/issues/121607#issuecomment-1963084636 getting wrongfully rejected. Since PR #119505 we reject visibilities if the “globally tracked” (wrt. to `AstValidator`) `outer_trait_or_trait_impl` is `Some`.

Crucially, when visiting an inherent impl, I never reset `outer_trait_or_trait_impl` back to `None` leading us to believe that `bar` in the stack [`trait Foo` > `fn foo` > `impl Bar` > `pub fn bar`] (from the MCVE) was an inherent associated item (we saw `trait Foo` but not `impl Bar` before it).

The old open issue #89342 is caused by the aforementioned issue of us never updating `in_trait_impl` prior to my PR #119505 / `outer_trait_or_trait` after my PR. Stack: [`impl Default for Foo` > `{` > `impl Foo` > `pub const X`] (we only saw `impl Default for Foo` but not the `impl Foo` before it).

---

This PR is only meant to be a *hot fix*. I plan on completely *rewriting* `AstValidator` from the ground up to not rely on “globally tracked” state like this or at least make it close to impossible to forget updating it when descending into nested items (etc.). Other visitors do a way better job at that (e.g. AST lowering). I actually plan on experimenting with moving more and more logic from `AstValidator` into the AST lowering pass/stage/visitor to follow the [Parse, don't validate](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) “pattern”.

---

r? `@compiler-errors`
2024-03-07 18:32:47 +01:00
Guillaume Gomez
9bda4e47c7
Rollup merge of #122115 - clubby789:cancel-recoverr, r=compiler-errors
Cancel parsing ever made during recovery

Fixes #122112

It would be nice if diagnostics from recovery were automatically cancelled... 🤔
2024-03-07 15:07:08 +01:00
Oli Scherer
8206cffc48 Merge check_mod_impl_wf and check_mod_type_wf 2024-03-07 06:27:09 +00:00
clubby789
8e45d0fe49 Cancel parsing ever made during recovery 2024-03-06 21:59:03 +00:00
León Orell Valerian Liehr
7d428db605
AST validation: Improve handling of inherent impls nested within functions and anon consts 2024-03-05 00:12:15 +01:00
bors
4cdd20584c Auto merge of #121657 - estebank:issue-119665, r=davidtwco
Detect more cases of `=` to `:` typo

When a `Local` is fully parsed, but not followed by a `;`, keep the `:` span arround and mention it. If the type could continue being parsed as an expression, suggest replacing the `:` with a `=`.

```
error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.`
 --> file.rs:2:32
  |
2 |     let _: std::env::temp_dir().join("foo");
  |          -                     ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=`
  |          |
  |          while parsing the type for `_`
  |          help: use `=` if you meant to assign
```

Fix #119665.
2024-03-02 05:03:46 +00:00
bors
6cbf0926d5 Auto merge of #121728 - tgross35:f16-f128-step1-ty-updates, r=compiler-errors
Add stubs in IR and ABI for `f16` and `f128`

This is the very first step toward the changes in https://github.com/rust-lang/rust/pull/114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary.

These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`.

The next steps will probably be AST support with parsing and the feature gate.

r? `@compiler-errors`
cc `@Nilstrieb` suggested breaking the PR up in https://github.com/rust-lang/rust/pull/120645#issuecomment-1925900572
2024-03-01 03:36:11 +00:00
Esteban Küber
bde2dfb127 Detect more cases of = to : typo
When a `Local` is fully parsed, but not followed by a `;`, keep the `:` span
arround and mention it. If the type could continue being parsed as an
expression, suggest replacing the `:` with a `=`.

```
error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.`
 --> file.rs:2:32
  |
2 |     let _: std::env::temp_dir().join("foo");
  |          -                     ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=`
  |          |
  |          while parsing the type for `_`
  |          help: use `=` if you meant to assign
```

Fix #119665.
2024-03-01 02:03:00 +00:00
Trevor Gross
406790e9d1 Add a basic test for f16 and f128 2024-02-28 12:58:32 -05:00
Nicholas Nethercote
840c8d3243 Use LitKind::Err for floats with unsupported bases.
This slightly changes error messages in `float-field.rs`, but nothing of
real importance.
2024-02-28 20:59:32 +11:00
Nicholas Nethercote
79766098a4 Reformat float-field.rs test.
- Put every literal in its own braces, rather than just some of them,
  for maximal error recovery.
- Add a blank line between every case, for readability.
2024-02-28 20:59:32 +11:00
Lieselotte
1658ca082a
Properly emit expected ; on #[attr] expr 2024-02-26 21:47:10 +01:00
Esteban Küber
28c028737d Deduplicate some logic and reword output 2024-02-22 18:05:28 +00:00