Commit Graph

338 Commits

Author SHA1 Message Date
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
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
Esteban Küber
e1e4da2b0a Make confusable suggestions verbose 2024-02-22 18:04:55 +00:00
Michael Goulet
9c8b107955 Support async trait bounds in macros 2024-02-20 16:09:09 +00:00
Vadim Petrochenkov
9f8d05f29f macro_rules: Preserve all metavariable spans in a global side table 2024-02-18 11:19:24 +03:00
许杰友 Jieyou Xu (Joe)
ec2cc761bc
[AUTO-GENERATED] Migrate ui tests from // to //@ directives 2024-02-16 20:02:50 +00:00
bors
cbddf31863 Auto merge of #121142 - GuillaumeGomez:rollup-5qmksjw, r=GuillaumeGomez
Rollup of 8 pull requests

Successful merges:

 - #120449 (Document requirements for unsized {Rc,Arc}::from_raw)
 - #120505 (Fix BTreeMap's Cursor::remove_{next,prev})
 - #120672 (std::thread update freebsd stack guard handling.)
 - #121088 (Implicitly enable evex512 if avx512 is enabled)
 - #121104 (Ignore unsized types when trying to determine the size of the original type)
 - #121107 (Fix msg for verbose suggestions with confusable capitalization)
 - #121113 (Continue compilation even if inherent impl checks fail)
 - #121120 (Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-02-15 17:00:55 +00:00
Guillaume Gomez
e878439d39
Rollup merge of #121113 - oli-obk:track_errors10, r=compiler-errors
Continue compilation even if inherent impl checks fail

We should not be hiding errors behind unrelated errors
2024-02-15 14:33:02 +01:00
Guillaume Gomez
3c8705402a
Rollup merge of #121107 - estebank:capitalization-suggestion, r=michaelwoerister
Fix msg for verbose suggestions with confusable capitalization

When encountering a verbose/multipart suggestion that has changes that are only caused by different capitalization of ASCII letters that have little differenciation, expand the message to highlight that fact (like we already do for inline suggestions).

The logic to do this was already present, but implemented incorrectly.
2024-02-15 14:33:02 +01:00
bors
fa9f77ff35 Auto merge of #120931 - chenyukang:yukang-cleanup-hashmap, r=michaelwoerister
Clean up potential_query_instability with FxIndexMap and UnordMap

From https://github.com/rust-lang/rust/pull/120485#issuecomment-1916437191

r? `@michaelwoerister`
2024-02-15 12:36:37 +00:00
Oli Scherer
c1bb352c8b Continue compilation even if inherent impl checks fail 2024-02-14 21:04:51 +00:00
Esteban Küber
8d4d572e4d Fix msg for verbose suggestions with confusable capitalization
When encountering a verbose/multipart suggestion that has changes
that are only caused by different capitalization of ASCII letters that have
little differenciation, expand the message to highlight that fact (like we
already do for inline suggestions).

The logic to do this was already present, but implemented incorrectly.
2024-02-14 20:15:13 +00:00
bors
ee9c7c940c Auto merge of #120847 - oli-obk:track_errors9, r=compiler-errors
Continue compilation after check_mod_type_wf errors

The ICEs fixed here were probably reachable through const eval gymnastics before, but now they are easily reachable without that, too.

The new errors are often bugfixes, where useful errors were missing, because they were reported after the early abort. In other cases sometimes they are just duplication of already emitted errors, which won't be user-visible due to deduplication.

fixes https://github.com/rust-lang/rust/issues/120860
2024-02-14 18:32:19 +00:00
Oli Scherer
5f6390f947 Continue compilation after check_mod_type_wf errors 2024-02-14 11:00:30 +00:00
yukang
3f27e4b3ea clean up potential_query_instability with FxIndexMap and UnordMap 2024-02-14 18:36:37 +08:00
trevyn
29fd82b24e Be less confident when dyn suggestion is not checked for object safety 2024-02-09 20:47:50 -08:00
Oli Scherer
eab2adb660 Continue to borrowck even if there were previous errors 2024-02-08 08:10:43 +00:00
r0cky
c7519d42c2 Update tests 2024-02-07 10:42:01 +08:00
Matthias Krüger
ed27148812
Rollup merge of #116284 - RalfJung:no-nan-match, r=cjgillot
make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern

These arms would never be hit anyway, so the pattern makes little sense. We have had a future-compat lint against float matches in general for a *long* time, so I hope we can get away with immediately making this a hard error.

This is part of implementing https://github.com/rust-lang/rfcs/pull/3535.

Closes https://github.com/rust-lang/rust/issues/41620 by removing the lint.

https://github.com/rust-lang/reference/pull/1456 updates the reference to match.
2024-02-05 11:07:26 +01:00
bors
4d87c4ad62 Auto merge of #120649 - matthiaskrgr:rollup-ek80j61, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #119759 (Add FileCheck annotations to dataflow-const-prop tests)
 - #120323 (On E0277 be clearer about implicit `Sized` bounds on type params and assoc types)
 - #120473 (Only suggest removal of `as_*` and `to_` conversion methods on E0308)
 - #120540 (add test for try-block-in-match-arm)
 - #120547 (`#![feature(inline_const_pat)]` is no longer incomplete)
 - #120552 (Correctly check `never_type` feature gating)
 - #120555 (put pnkfelix (me) back on the review queue.)
 - #120556 (Improve the diagnostics for unused generic parameters)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-02-04 22:55:40 +00:00
Matthias Krüger
7fa99bfb71
Rollup merge of #120556 - fmease:improve-unused-generic-param-diags, r=oli-obk
Improve the diagnostics for unused generic parameters

* Don't emit two errors (namely E0091 *and* E0392) for unused type parameters on *lazy* type aliases
* Fix the diagnostic help message of E0392 for *lazy* type aliases: Don't talk about the “fields” of lazy type aliases (use the term “body” instead) and don't suggest `PhantomData` for them, it doesn't make much sense
* Consolidate the diagnostics for E0091 (unused type parameters in type aliases) and E0392 (unused generic parameters due to bivariance) and make it translatable
  * Still keep the error codes distinct (for now)
  * Naturally leads to better diagnostics for E0091

r? ```@oli-obk``` (to ballast your review load :P) or compiler
2024-02-04 19:42:12 +01:00
Matthias Krüger
7d516c57df
Rollup merge of #120531 - oli-obk:track_errors7, r=estebank
Remove a bunch of `has_errors` checks that have no meaningful or the wrong effect

r? `@nnethercote`
2024-02-03 22:25:16 +01:00
León Orell Valerian Liehr
02320b502d
Improve the diagnostics for unused generic parameters 2024-02-01 16:18:03 +01:00