about summary refs log tree commit diff
path: root/compiler/rustc_parse
AgeCommit message (Collapse)AuthorLines
2023-05-24Use `Option::is_some_and` and `Result::is_ok_and` in the compilerMaybe Waffle-7/+7
2023-05-20Rollup merge of #111708 - jyn514:delay-span-bug-msg, r=compiler-errorsDylan DPC-0/+1
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-18Rollup merge of #111054 - cjgillot:cfg-eval-recover, r=b-naberDylan DPC-1/+2
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-18Rollup merge of #111633 - nnethercote:avoid-ref-format, r=WaffleLapkinDylan DPC-2/+2
Avoid `&format("...")` calls in error message code. Some error message cleanups. Best reviewed one commit at a time. r? `@davidtwco`
2023-05-17Give a more useful location for where a span_bug was delayedjyn-0/+1
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-16Avoid `&format("...")` calls in error message code.Nicholas Nethercote-2/+2
Error message all end up passing into a function as an `impl Into<{D,Subd}iagnosticMessage>`. If an error message is creatd as `&format("...")` that means we allocate a string (in the `format!` call), then take a reference, and then clone (allocating again) the reference to produce the `{D,Subd}iagnosticMessage`, which is silly. This commit removes the leading `&` from a lot of these cases. This means the original `String` is moved into the `{D,Subd}iagnosticMessage`, avoiding the double allocations. This requires changing some function argument types from `&str` to `String` (when all arguments are `String`) or `impl Into<{D,Subd}iagnosticMessage>` (when some arguments are `String` and some are `&str`).
2023-05-15Recover `impl<T ?Sized>` correctlyMichael Goulet-0/+5
2023-05-15Rollup merge of #111531 - chenyukang:yukang-fix-111416-ice, r=compiler-errorsMatthias Krüger-0/+4
Fix ice caused by shorthand fields in NoFieldsForFnCall Fixes #111416
2023-05-13fmtyukang-6/+3
2023-05-13Fix ice caused by shorthand fields in NoFieldsForFnCallyukang-0/+7
2023-05-13improve error for `impl<..> impl Trait for Type`y21-4/+33
2023-05-13fix(parse): return unpected when current token is EOFbohan-1/+3
2023-05-09Rollup merge of #111120 - chenyukang:yukang-suggest-let, r=NilstriebDylan DPC-13/+48
Suggest let for possible binding with ty Origin from https://github.com/rust-lang/rust/pull/109128#discussion_r1179866137 r? `@Nilstrieb`
2023-05-09Rollup merge of #110694 - est31:builtin, r=petrochenkovDylan DPC-1/+93
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-09move sugg to derive session diagnosticyukang-9/+18
2023-05-08make it more accurate by parsing tyyukang-9/+19
2023-05-08suggest struct when we get colon in fileds in enumyukang-0/+9
2023-05-08code refactor and fix wrong suggestionyukang-24/+36
2023-05-08fix ice in suggestingyukang-7/+14
2023-05-08cleanupyukang-2/+1
2023-05-08Suggest let for possible binding with tyyukang-9/+17
2023-05-06Rollup merge of #111230 - zacklukem:eq-less-to-less-eq, r=compiler-errorsMatthias Krüger-1/+12
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-05Add feature gateest31-0/+1
2023-05-05Migrate offset_of from a macro to builtin # syntaxest31-1/+19
2023-05-05Add parsing for builtin # in expression and item contextest31-1/+74
2023-05-05add hint for =< as <=Zachary Mayhew-1/+12
2023-05-05Rollup merge of #108801 - fee1-dead-contrib:c-str, r=compiler-errorsDylan DPC-11/+75
Implement RFC 3348, `c"foo"` literals RFC: https://github.com/rust-lang/rfcs/pull/3348 Tracking issue: #105723
2023-05-04Rollup merge of #110791 - compiler-errors:negative-bounds, r=oli-obkDylan DPC-125/+59
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-03Restrict `From<S>` for `{D,Subd}iagnosticMessage`.Nicholas Nethercote-51/+47
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-02Implement negative boundsMichael Goulet-125/+59
2023-05-02make cook genericDeadbeef-37/+27
2023-05-02make it semantic errorDeadbeef-0/+3
2023-05-02try gating early, add non-ascii testDeadbeef-0/+1
2023-05-02refactor unescapeDeadbeef-8/+14
2023-05-02initial step towards implementing C string literalsDeadbeef-0/+64
2023-05-01Do not recover when parsing stmt in cfg-eval.Camille GILLOT-1/+2
2023-05-01soften the wording for removing type ascriptionyukang-12/+6
2023-05-01fix testsyukang-20/+5
2023-05-01fix parser sizeyukang-1/+1
2023-05-01clean up debug codeyukang-15/+1
2023-05-01Rip it outNilstrieb-192/+304
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-01Rollup merge of #110823 - compiler-errors:tweak-await-span, r=b-naberMatthias Krüger-3/+3
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-04-27Tweak await spanMichael Goulet-3/+3
2023-04-27Migrate trivially translatable `rustc_parse` diagnosticsclubby789-183/+375
2023-04-25Fix static string lintsclubby789-77/+149
2023-04-19Auto merge of #110407 - Nilstrieb:fluent-macro, r=davidtwcobors-1/+2
Add `rustc_fluent_macro` to decouple fluent from `rustc_macros` Fluent, with all the icu4x it brings in, takes quite some time to compile. `fluent_messages!` is only needed in further downstream rustc crates, but is blocking more upstream crates like `rustc_index`. By splitting it out, we allow `rustc_macros` to be compiled earlier, which speeds up `x check compiler` by about 5 seconds (and even more after the needless dependency on `serde_json` is removed from `rustc_data_structures`).
2023-04-18Add `rustc_fluent_macro` to decouple fluent from `rustc_macros`Nilstrieb-1/+2
Fluent, with all the icu4x it brings in, takes quite some time to compile. `fluent_messages!` is only needed in further downstream rustc crates, but is blocking more upstream crates like `rustc_index`. By splitting it out, we allow `rustc_macros` to be compiled earlier, which speeds up `x check compiler` by about 5 seconds (and even more after the needless dependency on `serde_json` is removed from `rustc_data_structures`).
2023-04-17Spelling - compilerJosh Soref-2/+2
* account * achieved * advising * always * ambiguous * analysis * annotations * appropriate * build * candidates * cascading * category * character * clarification * compound * conceptually * constituent * consts * convenience * corresponds * debruijn * debug * debugable * debuggable * deterministic * discriminant * display * documentation * doesn't * ellipsis * erroneous * evaluability * evaluate * evaluation * explicitly * fallible * fulfill * getting * has * highlighting * illustrative * imported * incompatible * infringing * initialized * into * intrinsic * introduced * javascript * liveness * metadata * monomorphization * nonexistent * nontrivial * obligation * obligations * offset * opaque * opportunities * opt-in * outlive * overlapping * paragraph * parentheses * poisson * precisely * predecessors * predicates * preexisting * propagated * really * reentrant * referent * responsibility * rustonomicon * shortcircuit * simplifiable * simplifications * specify * stabilized * structurally * suggestibility * translatable * transmuting * two * unclosed * uninhabited * visibility * volatile * workaround Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-17Rollup merge of #110404 - matthiaskrgr:mapmap, r=NilstriebMatthias Krüger-3/+3
fix clippy::toplevel_ref_arg and ::manual_map r? ``@Nilstrieb``
2023-04-16fix clippy::toplevel_ref_arg and ::manual_mapMatthias Krüger-3/+3