Commit Graph

1061 Commits

Author SHA1 Message Date
bors
70e04bd88d Auto merge of #111748 - nnethercote:Cow-DiagnosticMessage, r=WaffleLapkin
Use `Cow` in `{D,Subd}iagnosticMessage`.

Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most compelling change ever, but it might be worth merging.

This requires changing the `impl<'a> From<&'a str>` impls to `impl From<&'static str>`, which involves a bunch of knock-on changes that require/result in call sites being a little more precise about exactly what kind of string they use to create errors, and not just `&str`. This will result in fewer unnecessary allocations, though this will not have any notable perf effects given that these are error paths.

Note that I was lazy within Clippy, using `to_string` in a few places to preserve the existing string imprecision. I could have used `impl Into<{D,Subd}iagnosticMessage>` in various places as is done in the compiler, but that would have required changes to *many* call sites (mostly changing `&format("...")` to `format!("...")`) which didn't seem worthwhile.

r? `@WaffleLapkin`
2023-05-29 07:10:44 +00:00
Nicholas Nethercote
781111ef35 Use Cow in {D,Subd}iagnosticMessage.
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most
compelling change ever, but it might be worth merging.

This requires changing the `impl<'a> From<&'a str>` impls to `impl
From<&'static str>`, which involves a bunch of knock-on changes that
require/result in call sites being a little more precise about exactly
what kind of string they use to create errors, and not just `&str`. This
will result in fewer unnecessary allocations, though this will not have
any notable perf effects given that these are error paths.

Note that I was lazy within Clippy, using `to_string` in a few places to
preserve the existing string imprecision. I could have used `impl
Into<{D,Subd}iagnosticMessage>` in various places as is done in the
compiler, but that would have required changes to *many* call sites
(mostly changing `&format("...")` to `format!("...")`) which didn't seem
worthwhile.
2023-05-29 09:23:43 +10:00
许杰友 Jieyou Xu (Joe)
41f5a30690
Recover upon encountering mistyped Const in const param def 2023-05-28 16:55:21 +08:00
Matthias Krüger
97fae38bf9
Rollup merge of #111181 - bvanjoi:fix-issue-111148, r=davidtwco
fix(parse): return unpected when current token is EOF

close https://github.com/rust-lang/rust/issues/111148

#111148 panic occurred because [FatalError.raise()](https://github.com/bvanjoi/rust/blob/master/compiler/rustc_parse/src/parser/mod.rs#LL540C3-L540C3) was encountered which caused by `Eof` and `Pound`(the last token) had same span, when parsing `#` in `fn a<<i<Y<w<>#`.

<img width="825" alt="image" src="https://user-images.githubusercontent.com/30187863/236612589-9e2c6a0b-18cd-408c-b636-c12a51cbcf1c.png">

There are a few ways to solve this problem:

- Change the action assign for [self.last_unexpected_token_span](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/diagnostics.rs#L592), for example, if current token is `Eof`, then return Error directly.
- Avoid triggering the `FatalError` when the current token is `Eof`.

I have chosen the second option because executing `expected_one_of_not_found` when the token is `Eof` but not in `ediable` seems reasonable.
2023-05-27 20:40:28 +02:00
Maybe Waffle
307799a711 Use is_some_and/is_ok_and in less obvious spots 2023-05-24 14:33:43 +00:00
Maybe Waffle
fb0f74a8c9 Use Option::is_some_and and Result::is_ok_and in the compiler 2023-05-24 14:20:41 +00:00
Dylan DPC
35bef062c7
Rollup merge of #111708 - jyn514:delay-span-bug-msg, r=compiler-errors
Give a more useful location for where a span_bug was delayed

Before:
```
   = note: delayed at    0: <rustc_errors::HandlerInner>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1335:29
              1: <rustc_errors::Handler>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1124:9
...
```

After:
```
   = note: delayed at compiler/rustc_parse/src/parser/diagnostics.rs:2158:28
              0: <rustc_errors::HandlerInner>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1335:29
              1: <rustc_errors::Handler>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1124:9
...
```

This both makes the relevant frame easier to find without having to dig through diagnostic internals, and avoids the weird-looking formatting for the first frame.

Found while working on https://github.com/rust-lang/rust/issues/111529.
2023-05-20 12:21:00 +05:30
Dylan DPC
ee26abdafb
Rollup merge of #111054 - cjgillot:cfg-eval-recover, r=b-naber
Do not recover when parsing stmt in cfg-eval.

`parse_stmt` does recovery on its own. When parsing the statement fails, we always get `Ok(None)` instead of an `Err` variant with the diagnostic that we can emit.

To avoid this behaviour, we need to opt-out of recovery for cfg_eval.

Fixes https://github.com/rust-lang/rust/issues/105228
2023-05-18 17:37:08 +05:30
jyn
e6a7fdedd7 Give a more useful location for where a span_bug was delayed
Before:
```
   = note: delayed at    0: <rustc_errors::HandlerInner>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1335:29
              1: <rustc_errors::Handler>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1124:9
...
```

After:
```
   = note: delayed at compiler/rustc_parse/src/parser/diagnostics.rs:2158:28
              0: <rustc_errors::HandlerInner>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1335:29
              1: <rustc_errors::Handler>::emit_diagnostic
                        at ./compiler/rustc_errors/src/lib.rs:1124:9
```

This both makes the relevant frame easier to find without having to dig
through diagnostic internals, and avoids the weird-looking formatting
for the first frame.
2023-05-17 23:15:22 -05:00
Michael Goulet
a5763ff8d3 Recover impl<T ?Sized> correctly 2023-05-15 17:14:59 +00:00
Matthias Krüger
7a1f3e7a88
Rollup merge of #111531 - chenyukang:yukang-fix-111416-ice, r=compiler-errors
Fix ice caused by shorthand fields in NoFieldsForFnCall

Fixes #111416
2023-05-15 10:58:39 +02:00
yukang
83789b8b06 fmt 2023-05-13 19:40:17 +08:00
yukang
ce6cfc37d0 Fix ice caused by shorthand fields in NoFieldsForFnCall 2023-05-13 18:06:16 +08:00
y21
7fe83345ef improve error for impl<..> impl Trait for Type 2023-05-13 10:51:21 +02:00
bohan
272dc5a6d5 fix(parse): return unpected when current token is EOF 2023-05-13 00:33:27 +08:00
Dylan DPC
8c51701b8a
Rollup merge of #111120 - chenyukang:yukang-suggest-let, r=Nilstrieb
Suggest let for possible binding with ty

Origin from https://github.com/rust-lang/rust/pull/109128#discussion_r1179866137

r? `@Nilstrieb`
2023-05-09 12:33:46 +05:30
Dylan DPC
dbd090c655
Rollup merge of #110694 - est31:builtin, r=petrochenkov
Implement builtin # syntax and use it for offset_of!(...)

Add `builtin #` syntax to the parser, as well as a generic infrastructure to support both item and expression position builtin syntaxes. The PR also uses this infrastructure for the implementation of the `offset_of!` macro, added by #106934.

cc `@petrochenkov` `@DrMeepster`

cc #110680 `builtin #` tracking issue
cc #106655 `offset_of!` tracking issue
2023-05-09 12:33:45 +05:30
yukang
4d219d0666 move sugg to derive session diagnostic 2023-05-09 11:51:04 +08:00
yukang
0e8703da3e make it more accurate by parsing ty 2023-05-08 15:07:36 +08:00
yukang
6b76588222 suggest struct when we get colon in fileds in enum 2023-05-08 14:58:09 +08:00
yukang
5e94b5faf1 code refactor and fix wrong suggestion 2023-05-08 14:56:36 +08:00
yukang
a7fc32ceaf fix ice in suggesting 2023-05-08 11:16:17 +08:00
yukang
20e6e6a493 cleanup 2023-05-08 10:56:20 +08:00
yukang
0bb43c63c3 Suggest let for possible binding with ty 2023-05-08 10:56:20 +08:00
Matthias Krüger
83b29ec743
Rollup merge of #111230 - zacklukem:eq-less-to-less-eq, r=compiler-errors
add hint for =< as <=

Adds a compiler hint for when `=<` is typed instead of `<=`

Example hint:
```rust
fn foo() {
    if 1 =< 3 {
        println!("Hello, World!");
    }
}
```
```
error: expected type, found `3`
 --> main.rs:2:13
  |
2 |     if 1 =< 3 {
  |          -- ^ expected type
  |          |
  |          help: did you mean: `<=`
```

This PR only emits the suggestion if there is no space between the `=` and `<`.  This hopefully narrows the scope of when this error is emitted, however this still allows this error to be emitted in cases such as this:
```
error: expected expression, found `;`
 --> main.rs:2:18
  |
2 |     if 1 =< [i32;; 3]>::hello() {
  |          --      ^ expected expression
  |          |
  |          help: did you mean: `<=`
```

Which could be a good reason not to merge since I haven't been able to think of any other ways of narrowing the scope of this diagnostic.

closes #111128
2023-05-06 13:30:05 +02:00
est31
83b4df4e61 Add feature gate 2023-05-05 21:44:48 +02:00
est31
5eb29c7f49 Migrate offset_of from a macro to builtin # syntax 2023-05-05 21:44:13 +02:00
est31
59ecbd2cea Add parsing for builtin # in expression and item context 2023-05-05 21:44:13 +02:00
Zachary Mayhew
a183ac6f90
add hint for =< as <= 2023-05-05 11:17:14 -04:00
Dylan DPC
4891f02cff
Rollup merge of #108801 - fee1-dead-contrib:c-str, r=compiler-errors
Implement RFC 3348, `c"foo"` literals

RFC: https://github.com/rust-lang/rfcs/pull/3348
Tracking issue: #105723
2023-05-05 18:40:33 +05:30
Dylan DPC
80df4ab403
Rollup merge of #110791 - compiler-errors:negative-bounds, r=oli-obk
Implement negative bounds for internal testing purposes

Implements partial support the `!` negative polarity on trait bounds. This is incomplete, but should allow us to at least be able to play with the feature.

Not even gonna consider them as a public-facing feature, but I'm implementing them because would've been nice to have in UI tests, for example in #110671.
2023-05-04 00:17:23 +05:30
Nicholas Nethercote
6b62f37402 Restrict From<S> for {D,Subd}iagnosticMessage.
Currently a `{D,Subd}iagnosticMessage` can be created from any type that
impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static,
str>`, which are reasonable. It also includes `&String`, which is pretty
weird, and results in many places making unnecessary allocations for
patterns like this:
```
self.fatal(&format!(...))
```
This creates a string with `format!`, takes a reference, passes the
reference to `fatal`, which does an `into()`, which clones the
reference, doing a second allocation. Two allocations for a single
string, bleh.

This commit changes the `From` impls so that you can only create a
`{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static,
str>`. This requires changing all the places that currently create one
from a `&String`. Most of these are of the `&format!(...)` form
described above; each one removes an unnecessary static `&`, plus an
allocation when executed. There are also a few places where the existing
use of `&String` was more reasonable; these now just use `clone()` at
the call site.

As well as making the code nicer and more efficient, this is a step
towards possibly using `Cow<'static, str>` in
`{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing
the `From<&'a str>` impls to `From<&'static str>`, which is doable, but
I'm not yet sure if it's worthwhile.
2023-05-03 08:44:39 +10:00
Michael Goulet
6e01e910cb Implement negative bounds 2023-05-02 22:36:24 +00:00
Deadbeef
bf3ca5979e try gating early, add non-ascii test 2023-05-02 10:32:08 +00:00
Camille GILLOT
d56ce8e199 Do not recover when parsing stmt in cfg-eval. 2023-05-01 08:51:47 +00:00
yukang
5d1796a608 soften the wording for removing type ascription 2023-05-01 16:37:00 +08:00
yukang
f54489978d fix tests 2023-05-01 16:15:17 +08:00
yukang
a4453c20ca fix parser size 2023-05-01 16:15:17 +08:00
yukang
1b08eaca20 clean up debug code 2023-05-01 16:15:17 +08:00
Nilstrieb
c63b6a437e Rip it out
My type ascription
Oh rip it out
Ah
If you think we live too much then
You can sacrifice diagnostics
Don't mix your garbage
Into my syntax
So many weird hacks keep diagnostics alive
Yet I don't even step outside
So many bad diagnostics keep tyasc alive
Yet tyasc doesn't even bother to survive!
2023-05-01 16:15:13 +08:00
Matthias Krüger
1b262b8b56
Rollup merge of #110823 - compiler-errors:tweak-await-span, r=b-naber
Tweak await span to not contain dot

Fixes a discrepancy between method calls and await expressions where the latter are desugared to have a span that *contains* the dot (i.e. `.await`) but method call identifiers don't contain the dot. This leads to weird suggestions suggestions in borrowck -- see linked issue.

Fixes #110761

This mostly touches a bunch of tests to tighten their `await` span.
2023-05-01 01:09:47 +02:00
Michael Goulet
f0fc4f9acf Tweak await span 2023-04-27 17:18:11 +00:00
clubby789
1ce9d7254e Migrate trivially translatable rustc_parse diagnostics 2023-04-27 01:53:06 +01:00
clubby789
0138513635 Fix static string lints 2023-04-25 18:59:55 +01:00
Matthias Krüger
1795bf8222
Rollup merge of #110404 - matthiaskrgr:mapmap, r=Nilstrieb
fix clippy::toplevel_ref_arg and ::manual_map

r? ``@Nilstrieb``
2023-04-17 08:09:40 +02:00
Matthias Krüger
543f8bc38c fix clippy::toplevel_ref_arg and ::manual_map 2023-04-16 13:28:13 +02:00
Matthias Krüger
bcc15bba95 use matches! macro in more places 2023-04-16 12:08:30 +02:00
Matthias Krüger
1077d574cf remove redundant clones 2023-04-15 18:04:51 +02:00
Matthias Krüger
a34bcd70b2
Rollup merge of #110203 - compiler-errors:rtn-dots, r=eholk
Remove `..` from return type notation

`@nikomatsakis` and I decided that using `..` in the return-type notation syntax is probably overkill.

r? `@eholk` since you reviewed the last one

Since this is piggybacking now totally off of a pre-existing syntax (parenthesized generics), let me know if you need any explanation of the logic here, since it's a bit more complicated now.
2023-04-12 20:56:22 +02:00
Michael Goulet
24cbf81b85 Remove .. from return type notation 2023-04-10 22:19:46 +00:00