about summary refs log tree commit diff
path: root/compiler/rustc_expand/src
AgeCommit message (Collapse)AuthorLines
2021-03-22rename :pat2018 -> :pat215mark-3/+3
2021-03-19stabilize or_patternsmark-3/+3
2021-03-19Extend `proc_macro_back_compat` lint to `js-sys`Aaron Hill-4/+30
With this PR, we now lint for all cases where we perform some kind of proc-macro back-compat hack. The `js-sys` had an internal fix made to properly handle `None`-delimited groups, so we need to manually check the version in the filename. As a result, we no longer apply the back-compat hack to cases where the version number is missing file the file path. This should not affect any users of the `crates.io` crate.
2021-03-18Extend `proc_macro_back_compat` lint to `actix-web`Aaron Hill-17/+29
Unlike the other cases of this lint, there's no simple way to detect if an old version of the relevant crate (`syn`) is in use. The `actix-web` crate only depends on `pin-project` v1.0.0, so checking the version of `actix-web` does not guarantee that a new enough version of `pin-project` (and therefore `syn`) is in use. Instead, we rely on the fact that virtually all of the regressed crates are pinned to a pre-1.0 version of `pin-project`. When this is the case, bumping the `actix-web` dependency will pull in the *latest* version of `pin-project`, which has an explicit dependency on a newer v dependency on a newer version of `syn`. The lint message tells users to update `actix-web`, since that's what they're most likely to have control over. We could potentially tell them to run `cargo update -p syn`, but I think it's more straightforward to suggest an explicit change to the `Cargo.toml` The `actori-web` fork had its last commit over a year ago, and appears to just be a renamed fork of `actix-web`. Therefore, I've removed the `actori-web` check entirely - any crates that actually get broken can simply update `syn` themselves.
2021-03-18Rollup merge of #83168 - Aaron1011:lint-procedural-masquerade, r=petrochenkovDylan DPC-2/+43
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-16ast: Reduce size of `ExprKind` by boxing fields of `ExprKind::Struct`Vadim Petrochenkov-1/+4
2021-03-16ast/hir: Rename field-related structuresVadim Petrochenkov-80/+80
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-2/+43
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-14Introduce `proc_macro_back_compat` lint, and emit for `time-macros-impl`Aaron Hill-4/+66
Now that future-incompat-report support has landed in nightly Cargo, we can start to make progress towards removing the various proc-macro back-compat hacks that have accumulated in the compiler. This PR introduces a new lint `proc_macro_back_compat`, which results in a future-incompat-report entry being generated. All proc-macro back-compat warnings will be grouped under this lint. Note that this lint will never actually become a hard error - instead, we will remove the special cases for various macros, which will cause older versions of those crates to emit some other error. I've added code to fire this lint for the `time-macros-impl` case. This is the easiest case out of all of our current back-compat hacks - the crate was renamed to `time-macros`, so seeing a filename with `time-macros-impl` guarantees that an older version of the parent `time` crate is in use. When Cargo's future-incompat-report feature gets stabilized, affected users will start to see future-incompat warnings when they build their crates.
2021-03-14expand: Resolve and expand inner attributes on out-of-line modulesVadim Petrochenkov-26/+52
2021-03-12Auto merge of #82422 - petrochenkov:allunst, r=oli-obkbors-2/+3
expand: Do not allocate `Lrc` for `allow_internal_unstable` list unless necessary This allocation is done for any macro defined in the current crate, or used from a different crate. EDIT: This also removes an `Lrc` increment from each *use* of such macro, which may be more significant. Noticed when reviewing https://github.com/rust-lang/rust/pull/82367. This probably doesn't matter, but let's do a perf run.
2021-03-08Rollup merge of #82682 - petrochenkov:cfgeval, r=Aaron1011Dylan DPC-171/+22
Implement built-in attribute macro `#[cfg_eval]` + some refactoring This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in https://github.com/rust-lang/rust/pull/79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes. The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input). The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items. `cfg_eval` was the first name suggested in https://github.com/rust-lang/rust/pull/79078, but other alternatives are also possible, e.g. `cfg_expand`. ```rust #[cfg_eval] #[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]` struct S { #[cfg(FALSE)] field: u8, } ``` Tracking issue: https://github.com/rust-lang/rust/issues/82679
2021-03-08Rollup merge of #82415 - petrochenkov:modin3, r=davidtwcoDylan DPC-265/+254
expand: Refactor module loading This is an accompanying PR to https://github.com/rust-lang/rust/pull/82399, but they can be landed independently. See individual commits for more details. Anyone should be able to review this equally well because all people actually familiar with this code left the project.
2021-03-07Move full configuration logic from `rustc_expand` to `rustc_builtin_macros`Vadim Petrochenkov-169/+6
This logic is applicable to two specific macros and not to the expansion infrastructure in general.
2021-03-06rustc_ast: Replace `AstLike::finalize_tokens` with a getter `tokens_mut`Vadim Petrochenkov-2/+16
2021-03-05Auto merge of #71481 - estebank:inherit-stability, r=nikomatsakisbors-3/+9
Inherit `#[stable(..)]` annotations in enum variants and fields from its item Lint changes for #65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.
2021-03-05expand: Introduce enum for module loading errors and make module loading ↵Vadim Petrochenkov-87/+86
speculative
2021-03-05expand: Share some code between inline and out-of-line module treatmentVadim Petrochenkov-18/+18
2021-03-05expand: Align some code with the PR fixing inner attributes on out-of-line ↵Vadim Petrochenkov-6/+13
modules
2021-03-05rustc_interface: Hide some hacky details of early linting from expandVadim Petrochenkov-9/+11
2021-03-05expand: Some more consistent naming in module loadingVadim Petrochenkov-55/+57
2021-03-05expand: Less path cloning during module loadingVadim Petrochenkov-37/+51
2021-03-05expand: Determine module directory path directly instead of relying on spanVadim Petrochenkov-8/+3
2021-03-05expand: Move module file path stack from global session to expansion dataVadim Petrochenkov-51/+64
Also don't push the paths on the stack directly in `fn parse_external_mod`, return them instead.
2021-03-05expand: Remove obsolete `DirectoryOwnership::UnownedViaMod`Vadim Petrochenkov-52/+9
This ownership kind is only constructed in the case of path attributes like `#[path = ".."]` without a file name segment, which always represent some kind of directories and will produce and error on attempt to parse them as a module file.
2021-02-27Combine HasAttrs and HasTokens into AstLikeAaron Hill-14/+32
When token-based attribute handling is implemeneted in #80689, we will need to access tokens from `HasAttrs` (to perform cfg-stripping), and we will to access attributes from `HasTokens` (to construct a `PreexpTokenStream`). This PR merges the `HasAttrs` and `HasTokens` traits into a new `AstLike` trait. The previous `HasAttrs` impls from `Vec<Attribute>` and `AttrVec` are removed - they aren't attribute targets, so the impls never really made sense.
2021-02-23expand: Do not allocate `Lrc` for `allow_internal_unstable` list unless ↵Vadim Petrochenkov-2/+3
necessary
2021-02-23expand: Preserve order of inert attributes during expansionVadim Petrochenkov-9/+14
2021-02-21remove redundant wrapping of return types of allow_internal_unstable() and ↵Matthias Krüger-2/+2
rustc_allow_const_fn_unstable()
2021-02-18ast: Keep expansion status for out-of-line module itemsVadim Petrochenkov-58/+59
Also remove `ast::Mod` which is mostly redundant now
2021-02-18ast: Stop using `Mod` in `Crate`Vadim Petrochenkov-32/+21
Crate root is sufficiently different from `mod` items, at least at syntactic level. Also remove customization point for "`mod` item or crate root" from AST visitors.
2021-02-17Rollup merge of #81869 - mark-i-m:leading-vert, r=petrochenkovDylan DPC-2/+4
Simplify pattern grammar, improve or-pattern diagnostics This implements the change under FCP in https://github.com/rust-lang/rust/issues/81415. It allows nested or-patterns to contain a leading `|`, simplifying the [grammar for patterns](https://github.com/rust-lang/reference/pull/957/files?short_path=cc629f1#diff-cc629f15712821139bc706c63b3845ab59a008e2a998e08ffad42e3aebcbcbe2). Along the way, we also improve the diagnostics around a few specially-handled cases, such as using `||` instead of `|`, using or-patterns in fn params, including the leading `|` in the pattern span, etc. r? `@petrochenkov`
2021-02-15Simplify pattern grammar by allowing nested leading vertmark-2/+4
Along the way, we also implement a handful of diagnostics improvements and fixes, particularly with respect to the special handling of `||` in place of `|` and when there are leading verts in function params, which don't allow top-level or-patterns anyway.
2021-02-15Rollup merge of #82129 - est31:master, r=jyn514Jonas Schievink-1/+0
Remove redundant bool_to_option feature gate
2021-02-15Remove redundant bool_to_option feature gateest31-1/+0
2021-02-14expand: Remove redundant calls to configureVadim Petrochenkov-21/+3
Starting from https://github.com/rust-lang/rust/pull/63468 cfg attributes on variants, fields, fn params etc. are processed together with other attributes (via `configure!`).
2021-02-14expand: Remove obsolete `ExpansionConfig::keep_macs`Vadim Petrochenkov-12/+2
Maybe it was used before the introduction of placeholders, but now it has no effect.
2021-02-11Add test for "const stability on macro"Esteban Küber-2/+5
2021-02-10Tweak stability attribute diagnostic outputEsteban Küber-3/+6
2021-02-09add method to construct def site path as a vec of identsSkgland-0/+4
like std_path but used dummy span for all path elements and does not perpend kw:DollarCrate
2021-02-07Address review commentsVadim Petrochenkov-0/+3
2021-02-07expand/resolve: Turn `#[derive]` into a regular macro attributeVadim Petrochenkov-342/+135
2021-01-31Improve handling of spans around macro result parse errorsAaron Hill-1/+3
Fixes #81543 After we expand a macro, we try to parse the resulting tokens as a AST node. This commit makes several improvements to how we handle spans when an error occurs: * Only ovewrite the original `Span` if it's a dummy span. This preserves a more-specific span if one is available. * Use `self.prev_token` instead of `self.token` when emitting an error message after encountering EOF, since an EOF token always has a dummy span * Make `SourceMap::next_point` leave dummy spans unused. A dummy span does not have a logical 'next point', since it's a zero-length span. Re-using the span span preserves its 'dummy-ness' for other checks
2021-01-28Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lintAaron Hill-1/+13
cc #79813 This PR adds an allow-by-default future-compatibility lint `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a macro body is ignored due to the macro being used in expression position: ```rust macro_rules! foo { () => { true; // WARN } } fn main() { let val = match true { true => false, _ => foo!() }; } ``` The lint takes its level from the macro call site, and can be allowed for a particular macro by adding `#[allow(semicolon_in_expressions_from_macros)]`. The lint is set to warn for all internal rustc crates (when being built by a stage1 compiler). After the next beta bump, we can enable the lint for the bootstrap compiler as well.
2021-01-28Rollup merge of #81284 - jyn514:impl-times, r=wesleywiserYuki Okushi-3/+5
Make `-Z time-passes` less noisy - Add the module name to `pre_AST_expansion_passes` and don't make it a verbose event (since it normally doesn't take very long, and it's emitted many times) - Don't make the following rustdoc events verbose; they're emitted many times. + build_extern_trait_impl + build_local_trait_impl + build_primitive_trait_impl + get_auto_trait_impls + get_blanket_trait_impls - Remove the `get_auto_trait_and_blanket_synthetic_impls` rustdoc event; it's wholly covered by get_{auto,blanket}_trait_impls and not very useful. I found this while working on https://github.com/rust-lang/rust/pull/81275 but it's independent of those changes.
2021-01-23Make `-Z time-passes` less noisyJoshua Nelson-3/+5
- Add the module name to `pre_AST_expansion_passes` and don't make it a verbose event (since it normally doesn't take very long, and it's emitted many times) - Don't make the following rustdoc events verbose; they're emitted many times. + build_extern_trait_impl + build_local_trait_impl + build_primitive_trait_impl + get_auto_trait_impls + get_blanket_trait_impls - Remove `get_auto_trait_and_blanket_synthetic_impls`; it's wholly covered by get_{auto,blanket}_trait_impls and not very useful.
2021-01-20Force token collection to run when parsing nonterminalsAaron Hill-5/+7
Fixes #81007 Previously, we would fail to collect tokens in the proper place when only builtin attributes were present. As a result, we would end up with attribute tokens in the collected `TokenStream`, leading to duplication when we attempted to prepend the attributes from the AST node. We now explicitly track when token collection must be performed due to nomterminal parsing.
2021-01-17Remove dead codeRyan Levick-29/+1
2021-01-14Use Option::map_or instead of `.map(..).unwrap_or(..)`LingMan-6/+6
2021-01-12Auto merge of #80499 - matthiaskrgr:red_clos, r=estebankbors-1/+1
remove redundant closures (clippy::redundant_closure)
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 02:01:57 +0000