about summary refs log tree commit diff
path: root/compiler/rustc_ast/src
AgeCommit message (Collapse)AuthorLines
2021-06-28Auto merge of #85909 - cjgillot:alloc-kind-query, r=Aaron1011bors-1/+1
Make allocator_kind a query. Part of #85153 r? `@Aaron1011`
2021-06-25Auto merge of #86599 - Amanieu:asm_raw, r=nagisabors-0/+1
Add a "raw" option for asm! which ignores format string specifiers This is useful when including raw assembly snippets using `include_str!`.
2021-06-24Add a "raw" option for asm! which ignores format string specifiersAmanieu d'Antras-0/+1
2021-06-20Make allocator_kind a query.Camille GILLOT-1/+1
2021-06-17Use `AttrVec` for `Arm`, `FieldDef`, and `Variant`Yuki Okushi-6/+6
2021-06-10Add support for using qualified paths with structs in expression and patternRyan Levick-11/+25
position.
2021-06-09Fix ICE when `main` is declared in an `extern` blockasquared31415-0/+1
2021-06-06Auto merge of #84995 - petrochenkov:tcollect, r=Aaron1011bors-1/+2
parser: Ensure that all nonterminals have tokens after parsing `parse_nonterminal` should always result in something with tokens. This requirement wasn't satisfied in two cases: - `stmt` nonterminal with expression statements (e.g. `0`, or `{}`, or `path + 1`) because `fn parse_stmt_without_recovery` forgot to propagate `force_collect` in some cases. - `expr` nonterminal with expressions with built-in attributes (e.g. `#[allow(warnings)] 0`) due to an incorrect optimization in `fn parse_expr_force_collect`, it assumed that all expressions starting with `#` have their tokens collected during parsing, but that's not true if all the attributes on that expression are built-in and inert. (Discovered when trying to implement eager `cfg` expansion for all attributes https://github.com/rust-lang/rust/pull/83824#issuecomment-817317170.) r? `@Aaron1011`
2021-06-06parser: Ensure that all nonterminals have tokens after parsingVadim Petrochenkov-1/+2
2021-06-06Rollup merge of #86043 - klensy:attr-clone, r=jyn514Yuki Okushi-3/+2
don't clone attrs
2021-06-01Revert "Reduce the amount of untracked state in TyCtxt"Camille Gillot-1/+1
2021-05-31Remove unused feature gatesbjorn3-2/+0
2021-05-30don't clone attrsklensy-3/+2
2021-05-30Make allocator_kind a query.Camille GILLOT-1/+1
2021-05-26Specialize implementationsJacob Pratt-0/+2
Implementations in stdlib are now optimized as they were before.
2021-05-24remove cfg(bootstrap)Pietro Albini-3/+1
2021-05-22stabilize const_fn_unsizeRalf Jung-1/+1
2021-05-16Implement Anonymous{Struct, Union} in the ASTjedel1043-0/+10
Add unnamed_fields feature gate and gate unnamed fields on parsing
2021-05-13Add support for const operands and options to global_asm!Amanieu d'Antras-62/+49
On x86, the default syntax is also switched to Intel to match asm!
2021-05-12Add more precise span informations to generic typesGiacomo Stevanato-1/+1
2021-04-28Auto merge of #83386 - mark-i-m:stabilize-pat2015, r=nikomatsakisbors-15/+8
Stabilize `:pat_param` and remove `:pat2021` Blocked on #83384 cc `@rust-lang/lang` #79278 If I understand `@nikomatsakis` in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873, another FCP is not needed. r? `@nikomatsakis`
2021-04-27remove pat2021mark-10/+3
2021-04-24Auto merge of #84310 - RalfJung:const-fn-feature-flags, r=oli-obkbors-1/+2
further split up const_fn feature flag This continues the work on splitting up `const_fn` into separate feature flags: * `const_fn_trait_bound` for `const fn` with trait bounds * `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here) I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more. `@oli-obk` are you currently able to do reviews?
2021-04-20Auto merge of #84334 - klensy:typo-compiler, r=jyn514bors-2/+2
fix few typos in comments
2021-04-19fix few typosklensy-2/+2
2021-04-18fix feature use in rustc libsRalf Jung-1/+2
2021-04-15rename pat2015 to pat_parammark-7/+7
2021-04-11Implement token-based handling of attributes during expansionAaron Hill-20/+305
This PR modifies the macro expansion infrastructure to handle attributes in a fully token-based manner. As a result: * Derives macros no longer lose spans when their input is modified by eager cfg-expansion. This is accomplished by performing eager cfg-expansion on the token stream that we pass to the derive proc-macro * Inner attributes now preserve spans in all cases, including when we have multiple inner attributes in a row. This is accomplished through the following changes: * New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced. These are very similar to a normal `TokenTree`, but they also track the position of attributes and attribute targets within the stream. They are built when we collect tokens during parsing. An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when we invoke a macro. * Token capturing and `LazyTokenStream` are modified to work with `AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which is created during the parsing of a nested AST node to make the 'outer' AST node aware of the attributes and attribute target stored deeper in the token stream. * When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`), we tokenize and reparse our target, capturing additional information about the locations of `#[cfg]` and `#[cfg_attr]` attributes at any depth within the target. This is a performance optimization, allowing us to perform less work in the typical case where captured tokens never have eager cfg-expansion run.
2021-04-11Match against attribute name when validating attributesTomasz Miąsko-0/+1
Extract attribute name once and match it against symbols that are being validated, instead of using `Session::check_name` for each symbol individually. Assume that all validated attributes are used, instead of marking them as such, since the attribute check should be exhaustive.
2021-04-08Rollup merge of #83980 - pierwill:fix-compiler-librustc-names, r=davidtwcoDylan DPC-2/+2
Fix outdated crate names in compiler docs Changes `librustc_X` to `rustc_X`, only in documentation comments. Plain code comments are left unchanged.
2021-04-08Fix outdated crate names in compiler docspierwill-2/+2
Changes `librustc_X` to `rustc_X`, only in documentation comments. Plain code comments are left unchanged. Also fix incorrect file paths.
2021-04-07Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkovDylan DPC-3/+5
Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See #83169 for more background. The syntax for `const` operands is still the same as before: `const <expr>`. Fixes #83169 Because the implementation is heavily based on inline consts, we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
2021-04-06Use AnonConst for asm! constantsAmanieu d'Antras-3/+5
2021-04-05Fix typo in TokenStream documentationGuillaume Gomez-1/+1
2021-04-04Add notesJubilee Young-1/+4
2021-03-27Remove (lots of) dead codeJoshua Nelson-123/+1
Found with https://github.com/est31/warnalyzer. Dubious changes: - Is anyone else using rustc_apfloat? I feel weird completely deleting x87 support. - Maybe some of the dead code in rustc_data_structures, in case someone wants to use it in the future? - Don't change rustc_serialize I plan to scrap most of the json module in the near future (see https://github.com/rust-lang/compiler-team/issues/418) and fixing the tests needed more work than I expected. TODO: check if any of the comments on the deleted code should be kept.
2021-03-26Use iter::zip in compiler/Josh Stone-1/+2
2021-03-23Rollup merge of #83384 - mark-i-m:rename-pat2018, r=joshtriplettYuki Okushi-7/+7
rename :pat2018 -> :pat2015 as requested by T-lang on zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873 No functional changes here... just renaming. r? `@nikomatsakis`
2021-03-22rename :pat2018 -> :pat215mark-7/+7
2021-03-19stabilize or_patternsmark-1/+1
2021-03-18Auto merge of #82868 - petrochenkov:bto, r=estebankbors-1/+1
Report missing cases of `bare_trait_objects` Fixes https://github.com/rust-lang/rust/issues/65371
2021-03-18hir: Preserve used syntax in `TyKind::TraitObject`Vadim Petrochenkov-1/+1
2021-03-18Rollup merge of #83216 - jyn514:register-tool, r=petrochenkovDylan DPC-4/+0
Allow registering tool lints with `register_tool` Previously, there was no way to add a custom tool prefix, even if the tool itself had registered a lint: ```rust #![feature(register_tool)] #![register_tool(xyz)] #![warn(xyz::my_lint)] ``` ``` $ rustc unknown-lint.rs --crate-type lib error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint` --> unknown-lint.rs:3:9 | 3 | #![warn(xyz::my_lint)] | ^^^ ``` This allows opting-in to lints from other tools using `register_tool`. cc https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, ``@chorman0773`` r? ``@petrochenkov``
2021-03-18Rollup merge of #83168 - Aaron1011:lint-procedural-masquerade, r=petrochenkovDylan DPC-27/+0
Extend `proc_macro_back_compat` lint to `procedural-masquerade` We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-17Auto merge of #83188 - petrochenkov:field, r=lcnrbors-56/+66
ast/hir: Rename field-related structures I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent. - `StructField` -> `FieldDef` ("field definition") - `Field` -> `ExprField` ("expression field", not "field expression") - `FieldPat` -> `PatField` ("pattern field", not "field pattern") Various visiting and other methods working with the fields are renamed correspondingly too. The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
2021-03-16Allow registering tool lints with `register_tool`Joshua Nelson-4/+0
Previously, there was no way to add a custom tool prefix, even if the tool itself had registered a lint: ``` #![feature(register_tool)] #![register_tool(xyz)] #![warn(xyz::my_lint)] ``` ``` $ rustc unknown-lint.rs --crate-type lib error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint` --> unknown-lint.rs:3:9 | 3 | #![warn(xyz::my_lint)] | ^^^ ``` This allows opting-in to lints from other tools using `register_tool`.
2021-03-16ast: Reduce size of `ExprKind` by boxing fields of `ExprKind::Struct`Vadim Petrochenkov-8/+16
2021-03-16ast/hir: Rename field-related structuresVadim Petrochenkov-50/+52
StructField -> FieldDef ("field definition") Field -> ExprField ("expression field", not "field expression") FieldPat -> PatField ("pattern field", not "field pattern") Also rename visiting and other methods working on them.
2021-03-15Extend `proc_macro_back_compat` lint to `procedural-masquerade`Aaron Hill-27/+0
We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-15More precise spans for HIR pathsVadim Petrochenkov-0/+8
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 22:42:35 +0000