about summary refs log tree commit diff
path: root/compiler/rustc_ast/src/util
AgeCommit message (Collapse)AuthorLines
2023-12-19Plumb awaitness of for loopsEric Holk-3/+11
2023-12-17Rollup merge of #118880 - GearsDatapacks:issue-118859-fix, r=compiler-errorsMatthias Krüger-3/+32
More expressions correctly are marked to end with curly braces Fixes #118859, and replaces the mentioned match statement with an exhaustive list, so that this code doesn't get overlooked in the future
2023-12-14Change expr_trailing_brace to an exhaustive match to force new expression ↵GearsDatapacks-3/+32
kinds to specify whether they contain a brace Add inline const and other possible curly brace expressions to expr_trailing_brace Add tests for `}` before `else` in `let...else` error Change to explicit cases for expressions with optional values when being checked for trailing braces Add tests for more complex cases of `}` before `else` in `let..else` statement Move other possible `}` cases into separate arm and add FIXME for future reference
2023-12-13Unify single-char and multi-char `CStrUnit::Char` handling.Nicholas Nethercote-1/+0
The two cases are equivalent. C string literals aren't common so there is no performance need here.
2023-12-13Don't rebuild raw strings when unescaping.Nicholas Nethercote-43/+30
Raw strings don't have escape sequences, so for them "unescaping" just means checking for invalid chars like bare CR. Which means there is no need to rebuild them one char or byte at a time while escaping, because the unescaped version will be the same. This commit removes that rebuilding. Also, the commit changes things so that "unescaping" is unconditional for raw strings and raw byte strings. That's simpler and they're rare enough that the perf effect is negligible.
2023-10-27Add gen blocks to ast and do some broken ast loweringOli Scherer-3/+3
2023-09-11Move let expression checking to parsingMatthew Jasper-1/+1
There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-08-04Improve spans for indexing expressionsNilstrieb-1/+1
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
2023-07-23more clippy::style fixes:Matthias Krüger-1/+1
get_first single_char_add_str unnecessary_mut_passed manual_map manual_is_ascii_check
2023-06-19Syntatically accept `become` expressionsMaybe Waffle-1/+3
2023-05-24Use `Option::is_some_and` and `Result::is_ok_and` in the compilerMaybe Waffle-2/+1
2023-05-05Rollup merge of #108801 - fee1-dead-contrib:c-str, r=compiler-errorsDylan DPC-1/+62
Implement RFC 3348, `c"foo"` literals RFC: https://github.com/rust-lang/rfcs/pull/3348 Tracking issue: #105723
2023-05-02make it semantic errorDeadbeef-0/+2
2023-05-02fix TODO commentsDeadbeef-2/+8
2023-05-02update and add a few testsDeadbeef-2/+2
2023-05-02initial step towards implementing C string literalsDeadbeef-1/+54
2023-05-01Rip it outNilstrieb-14/+9
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-04-27Tweak await spanMichael Goulet-1/+1
2023-04-21offset_ofDrMeepster-1/+3
2023-03-14Remove box expressions from HIRclubby789-3/+1
2023-03-12Remove `box_syntax` from AST and use in toolsclubby789-1/+0
2023-03-03Match unmatched backticks in comments in compiler/est31-1/+1
2023-01-30Replace enum `==`s with `match`es where it makes senseMaybe Waffle-16/+17
2023-01-28Rollup merge of #107194 - ↵Yuki Okushi-1/+1
xfix:remove-slice-internals-dependency-in-rustc-ast, r=Nilstrieb Remove dependency on slice_internals feature in rustc_ast This reduces dependency on unstable features by the compiler.
2023-01-26Auto merge of #106745 - m-ou-se:format-args-ast, r=oli-obkbors-1/+3
Move format_args!() into AST (and expand it during AST lowering) Implements https://github.com/rust-lang/compiler-team/issues/541 This moves FormatArgs from rustc_builtin_macros to rustc_ast_lowering. For now, the end result is the same. But this allows for future changes to do smarter things with format_args!(). It also allows Clippy to directly access the ast::FormatArgs, making things a lot easier. This change turns the format args types into lang items. The builtin macro used to refer to them by their path. After this change, the path is no longer relevant, making it easier to make changes in `core`. This updates clippy to use the new language items, but this doesn't yet make clippy use the ast::FormatArgs structure that's now available. That should be done after this is merged.
2023-01-22Remove dependency on slice_internals feature in rustc_astKonrad Borowski-1/+1
2023-01-17Remove double spaces after dots in commentsMaybe Waffle-1/+1
2023-01-12Expand format_args!() in rust_ast_lowering.Mara Bos-1/+3
2023-01-05Fix `uninlined_format_args` for some compiler cratesnils-3/+3
Convert all the crates that have had their diagnostic migration completed (except save_analysis because that will be deleted soon and apfloat because of the licensing problem).
2023-01-02Print correct base for too-large literalsclubby789-2/+2
Also update tests
2022-12-20rustc: Remove needless lifetimesJeremy Stucki-1/+1
2022-12-12Auto merge of #105160 - nnethercote:rm-Lit-token_lit, r=petrochenkovbors-48/+94
Remove `token::Lit` from `ast::MetaItemLit`. Currently `ast::MetaItemLit` represents the literal kind twice. This PR removes that redundancy. Best reviewed one commit at a time. r? `@petrochenkov`
2022-12-05Remove `LitKind::synthesize_token_lit`.Nicholas Nethercote-39/+44
It has a single call site in the HIR pretty printer, where the resulting token lit is immediately converted to a string. This commit replaces `LitKind::synthesize_token_lit` with a `Display` impl for `LitKind`, which can be used by the HIR pretty printer.
2022-12-05Remove `ExtCtxt::expr_lit`.Nicholas Nethercote-11/+23
2022-12-04Rollup merge of #105142 - nbdd0121:inline_const, r=petrochenkovMatthias Krüger-0/+1
Make inline const block `ExprWithBlock` Fix https://github.com/rust-lang/rust/pull/104087#issuecomment-1324190817 `@rustbot` label: +T-lang +F-inline_const
2022-12-02Remove `token::Lit` from `ast::MetaItemLit`.Nicholas Nethercote-2/+25
`token::Lit` contains a `kind` field that indicates what kind of literal it is. `ast::MetaItemLit` currently wraps a `token::Lit` but also has its own `kind` field. This means that `ast::MetaItemLit` encodes the literal kind in two different ways. This commit changes `ast::MetaItemLit` so it no longer wraps `token::Lit`. It now contains the `symbol` and `suffix` fields from `token::Lit`, but not the `kind` field, eliminating the redundancy.
2022-12-02Add `StrStyle` to `ast::LitKind::ByteStr`.Nicholas Nethercote-5/+11
This is required to distinguish between cooked and raw byte string literals in an `ast::LitKind`, without referring to an adjacent `token::Lit`. It's a prerequisite for the next commit.
2022-12-02Rename `LitKind::to_token_lit` as `LitKind::synthesize_token_lit`.Nicholas Nethercote-2/+2
This makes it clearer that it's not a lossless conversion, which I find helpful.
2022-12-01Make inline const block `ExprWithBlock`Gary Guo-0/+1
2022-12-01Remove useless borrows and derefsMaybe Waffle-11/+11
2022-11-29Avoid more `MetaItem`-to-`Attribute` conversions.Nicholas Nethercote-9/+0
There is code for converting `Attribute` (syntactic) to `MetaItem` (semantic). There is also code for the reverse direction. The reverse direction isn't really necessary; it's currently only used when generating attributes, e.g. in `derive` code. This commit adds some new functions for creating `Attributes`s directly, without involving `MetaItem`s: `mk_attr_word`, `mk_attr_name_value_str`, `mk_attr_nested_word`, and `ExtCtxt::attr_{word,name_value_str,nested_word}`. These new methods replace the old functions for creating `Attribute`s: `mk_attr_inner`, `mk_attr_outer`, and `ExtCtxt::attribute`. Those functions took `MetaItem`s as input, and relied on many other functions that created `MetaItems`, which are also removed: `mk_name_value_item`, `mk_list_item`, `mk_word_item`, `mk_nested_word_item`, `{MetaItem,MetaItemKind,NestedMetaItem}::token_trees`, `MetaItemKind::attr_args`, `MetaItemLit::{from_lit_kind,to_token}`, `ExtCtxt::meta_word`. Overall this cuts more than 100 lines of code and makes thing simpler.
2022-11-29Inline and remove `MetaItemLit::from_lit_kind`.Nicholas Nethercote-7/+0
It has a single call site.
2022-11-28Rename `ast::Lit` as `ast::MetaItemLit`.Nicholas Nethercote-12/+12
2022-11-28Remove `Lit::from_included_bytes`.Nicholas Nethercote-8/+0
`Lit::from_included_bytes` calls `Lit::from_lit_kind`, but the two call sites only need the resulting `token::Lit`, not the full `ast::Lit`. This commit changes those call sites to use `LitKind::to_token_lit`, which means `from_included_bytes` can be removed.
2022-11-21Remove `ref` patterns from `rustc_ast`Maybe Waffle-11/+11
Also use if let chains in one case.
2022-11-17Box `ExprKind::{Closure,MethodCall}`, and `QSelf` in expressions, types, and ↵Nicholas Nethercote-2/+4
patterns.
2022-11-16Use `token::Lit` in `ast::ExprKind::Lit`.Nicholas Nethercote-22/+5
Instead of `ast::Lit`. Literal lowering now happens at two different times. Expression literals are lowered when HIR is crated. Attribute literals are lowered during parsing. This commit changes the language very slightly. Some programs that used to not compile now will compile. This is because some invalid literals that are removed by `cfg` or attribute macros will no longer trigger errors. See this comment for more details: https://github.com/rust-lang/rust/pull/102944#issuecomment-1277476773
2022-11-11Introduce `ExprKind::IncludedBytes`clubby789-0/+8
2022-11-11Auto merge of #99918 - WaffleLapkin:fnFnfun, r=estebankbors-0/+6
Recover wrong-cased keywords that start items (_this pr was inspired by [this tweet](https://twitter.com/Azumanga/status/1552982326409367561)_) r? `@estebank` We've talked a bit about this recovery, but I just wanted to make sure that this is the right approach :) For now I've only added the case insensitive recovery to `use`s, since most other items like `impl` blocks, modules, functions can start with multiple keywords which complicates the matter.
2022-11-05Remove `unescape_byte_literal`.Nicholas Nethercote-18/+11
It's easy to just use `unescape_literal` + `byte_from_char`.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 13:02:32 +0000