summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser/expr.rs
AgeCommit message (Collapse)AuthorLines
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
2023-02-24Replace parse_[sth]_expr with parse_expr_[sth] function namesest31-118/+118
This resolves an inconsistency in naming style for functions on the parser, between functions parsing specific kinds of items and those for expressions, favoring the parse_item_[sth] style used by functions for items. There are multiple advantages of that style: * functions of both categories are collected in the same place in the rustdoc output. * it helps with autocompletion, as you can narrow down your search for a function to those about expressions. * it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. std::collections::hash_map::Entry The disadvantage is that it doesn't "read like a sentence" any more, but I think the advantages weigh more greatly. This change was mostly application of this command: sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs Plus very minor fixes outside of rustc_parse, and an invocation of x fmt.
2023-02-21Use `ThinVec` in a few more AST types.Nicholas Nethercote-2/+2
2023-02-21Use `ThinVec` in `ast::ExprKind::Match`.Nicholas Nethercote-1/+1
2023-02-21Use `ThinVec` in `ast::Block`.Nicholas Nethercote-2/+2
2023-02-21Use `ThinVec` in various AST types.Nicholas Nethercote-5/+6
This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
2023-02-21Use `ThinVec` in `ast::Generics` and related types.Nicholas Nethercote-1/+1
2023-02-06Migrate `rustc_parse` to derive diagnosticsclubby789-1/+2
2023-02-05Recover from missing expression in for loopObei Sideg-0/+15
2023-02-05rustc_parse: remove huge error importsest31-98/+88
2023-02-03Rollup merge of #107551 - fee1-dead-contrib:rm_const_fnmut_helper, r=oli-obkMichael Goulet-1/+1
Replace `ConstFnMutClosure` with const closures Also fixes a parser bug. cc `@oli-obk` for compiler changes
2023-02-03Rollup merge of #107544 - nnethercote:improve-TokenCursor, r=petrochenkovDylan DPC-1/+1
Improve `TokenCursor`. Some small improvements, for things that were bugging me. Best reviewed one commit at a time. r? ``@petrochenkov``
2023-02-03Remove `TokenCursorFrame`.Nicholas Nethercote-1/+1
The motivation here is to eliminate the `Option<(Delimiter, DelimSpan)>`, which is `None` for the outermost token stream and `Some` for all other token streams. We are already treating the innermost frame specially -- this is the `frame` vs `stack` distinction in `TokenCursor`. We can push that further so that `frame` only contains the cursor, and `stack` elements contain the delimiters for their children. When we are in the outermost token stream `stack` is empty, so there are no stored delimiters, which is what we want because the outermost token stream *has* no delimiters. This change also shrinks `TokenCursor`, which shrinks `Parser` and `LazyAttrTokenStreamImpl`, which is nice.
2023-02-02Improve diagnostic for missing space in range patternclubby789-0/+8
2023-02-01Make "use latest edition" subdiagnostic translatableXiretza-11/+12
2023-02-01Convert rustc_parse::parser::pat::Expected to enumXiretza-2/+2
This is required in order to support translatable diagnostics.