about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser/expr.rs
AgeCommit message (Collapse)AuthorLines
2023-07-30Rollup merge of #114256 - Urgau:fix-issue-114180, r=WaffleLapkinMatthias Krüger-1/+1
Fix invalid suggestion for mismatched types in closure arguments This PR fixes the invalid suggestion for mismatched types in closure arguments. The invalid suggestion came from a wrongly created span in the parser for closure arguments that don't have a type specified. Specifically, the span in this case was the last token span, but in the case of tuples, the span represented the last parenthesis instead of the whole tuple, which is fixed by taking the more accurate span of the pattern. There is one unfortunate downside of this fix, it worsens even more the diagnostic for mismatched types in closure args without an explicit type. This happens because there is no correct span for implied inferred type. I tried also fixing this but it's a rabbit hole. Fixes https://github.com/rust-lang/rust/issues/114180
2023-07-30Fix invalid suggestion for mismatched types in closure argumentsUrgau-1/+1
The invalid suggestion came from a wrongly created span in `rustc_parse' for closure arguments that didn't have a type specified. Specifically, the span in this case was the last token span, but in the case of tuples, the span represented the last parenthesis instead of the whole tuple, which is fixed by taking the more accurate span of the pattern.
2023-07-30inline format!() args up to and including rustc_middleMatthias Krüger-2/+2
2023-07-24Optimize format usageYuri Astrakhan-1/+1
Per #112156, using `&` in `format!` may cause a small perf delay, so I tried to clean up one module at a time format usage. This PR includes a few removals of the ref in format (they do compile locally without the ref), as well as a few format inlining for consistency.
2023-07-22Support interpolated block for try and asyncMichael Goulet-4/+10
2023-07-19Make it clearer that edition functions are >=, not ==Michael Goulet-5/+5
2023-06-27Rollup merge of #112978 - compiler-errors:bad-block-sugg, r=davidtwcoMatthias Krüger-0/+4
Add suggestion for bad block fragment error Makes it a bit clearer how to fix this parser restriction
2023-06-27Rollup merge of #112518 - chenyukang:yukang-fix-112458, r=davidtwcoMatthias Krüger-2/+8
Detect actual span for getting unexpected token from parsing macros Fixes #112458
2023-06-23Add suggestion for bad block fragment errorMichael Goulet-0/+4
2023-06-19Syntatically accept `become` expressionsMaybe Waffle-0/+12
2023-06-15Handle interpolated literal errorsMichael Goulet-6/+3
2023-06-11Detect actual span for getting unexpected token from parsing macrosyukang-2/+8
2023-06-09Move parse_seq_to_before_end closure to own functionest31-43/+37
2023-06-08Support float-like tuple indices in offset_of!()est31-2/+45
The tokenizer gives us whole float literal tokens, we have to split them up in order to be able to create field access from them.
2023-06-08Move float breaking out of Parser::parse_expr_tuple_field_access_floatest31-22/+53
Purely a refactor in preparation of using it in offset_of!() parsing
2023-05-24Use `Option::is_some_and` and `Result::is_ok_and` in the compilerMaybe Waffle-4/+4
2023-05-13fmtyukang-6/+3
2023-05-13Fix ice caused by shorthand fields in NoFieldsForFnCallyukang-0/+7
2023-05-09Rollup merge of #110694 - est31:builtin, r=petrochenkovDylan DPC-0/+61
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-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-0/+42
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-0/+1
Implement RFC 3348, `c"foo"` literals RFC: https://github.com/rust-lang/rfcs/pull/3348 Tracking issue: #105723
2023-05-03Restrict `From<S>` for `{D,Subd}iagnosticMessage`.Nicholas Nethercote-2/+2
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-02try gating early, add non-ascii testDeadbeef-0/+1
2023-05-01fix testsyukang-14/+1
2023-05-01Rip it outNilstrieb-69/+36
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-2/+2
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-2/+2
2023-04-27Migrate trivially translatable `rustc_parse` diagnosticsclubby789-8/+4
2023-04-10Fix typos in compilerDaniPopes-1/+1
2023-03-27Rollup merge of #109354 - Swatinem:rm-closureid, r=compiler-errorsGuillaume Gomez-1/+1
Remove the `NodeId` of `ast::ExprKind::Async` This is a followup to https://github.com/rust-lang/rust/pull/104833#pullrequestreview-1314537416. In my original attempt, I was using `LoweringContext::expr`, which was not correct as it creates a fresh `DefId`. It now uses the correct `DefId` for the wrapping `Expr`, and also makes forwarding `#[track_caller]` attributes more explicit.
2023-03-21Refactor `handle_missing_lit`.Nicholas Nethercote-14/+8
2023-03-19Remove the `NodeId` of `ast::ExprKind::Async`Arpad Borsos-1/+1
2023-03-13Auto merge of #108471 - clubby789:unbox-the-syntax, r=Nilstrieb,est31bors-3/+21
Remove `box_syntax` r? `@Nilstrieb` This removes the feature `box_syntax`, which allows the use of `box <expr>` to create a Box, and finalises removing use of the feature from the compiler. `box_patterns` (allowing the use of `box <pat>` in a pattern) is unaffected. It also removes `ast::ExprKind::Box` - the only way to create a 'box' expression now is with the rustc-internal `#[rustc_box]` attribute. As a temporary measure to help users move away, `box <expr>` now parses the inner expression, and emits a `MachineApplicable` lint to replace it with `Box::new` Closes #49733
2023-03-12Add recovery for use of removed `box` syntaxclubby789-0/+28
2023-03-12Remove `box_syntax` from AST and use in toolsclubby789-10/+0
2023-03-11Gate const closures even when they appear in macrosMichael Goulet-1/+1
2023-03-04Rollup merge of #108715 - chenyukang:yukang/cleanup-parser-delims, ↵Matthias Krüger-13/+0
r=compiler-errors Remove unclosed_delims from parser After landing https://github.com/rust-lang/rust/pull/108297 we could remove `unclosed_delims` from the parser now.
2023-03-03Remove unclosed_delims from parseryukang-13/+0
2023-03-03check if snippet is `)`Takayuki Maeda-2/+7
2023-03-01recover from for-else and while-elsey21-0/+22
2023-03-01Rollup merge of #108496 - nx2k3:issue-108495-dec, r=WaffleLapkinMatthias Krüger-0/+12
fix #108495, postfix decrement and prefix decrement has no warning Fixes #108495
2023-02-28micro fmt changesMaybe Waffle-1/+1
2023-02-27handle only postfix decrementnx2k3-24/+4
2023-02-27check double negationnx2k3-3/+10
2023-02-26fix some commentsnx2k3-3/+3
2023-02-26fix #108495, postfix decrement and prefix decrement has no warningnx2k3-4/+29