about summary refs log tree commit diff
path: root/src/libsyntax/ext/expand.rs
AgeCommit message (Collapse)AuthorLines
2018-07-21Gate `format_args_nll` behind feature flagEsteban Küber-0/+1
2018-07-19rustc: Fix two custom attributes with custom deriveAlex Crichton-0/+17
This commit fixes an issue where multiple custom attributes could not be fed into a custom derive in some situations with the `use_extern_macros` feature enabled. The problem was that the macro expander didn't consider that it was making progress when we were deducing that attributes should be lumped in with custom derive invocations. The fix applied here was to track in the expander if our attribute is changing (getting stashed away elsewhere and replaced with a new invocation). If it is swapped then it's considered progress, otherwise behavior should remain the same. Closes #52525
2018-07-16rustc: Stabilize much of the `proc_macro` featureAlex Crichton-4/+4
This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros, custom derives, with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature, such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR, once landed, will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
2018-07-14Functions introducing procedural macros reserve a slot in the macro ↵Vadim Petrochenkov-1/+1
namespace as well
2018-07-10Deny bare trait objects in in src/libsyntaxljedrz-1/+1
2018-06-30Fortify dummy span checkingVadim Petrochenkov-1/+1
2018-06-30hygiene: Implement transparent marksVadim Petrochenkov-1/+1
2018-06-30expansion: Give names to some fields of `SyntaxExtension`Vadim Petrochenkov-5/+5
2018-06-28Auto merge of #50997 - michaelwoerister:pre-analyze-filemaps, r=Mark-Simulacrumbors-2/+4
Make FileMap::{lines, multibyte_chars, non_narrow_chars} non-mutable. This PR removes most of the interior mutability from `FileMap`, which should be beneficial, especially in a multithreaded setting. This is achieved by initializing the state in question when the filemap is constructed instead of during lexing. Hopefully this doesn't degrade performance. cc @wesleywiser
2018-06-27Remove the now redundant CodeMap::new_filemap_with_lines() method.Michael Woerister-2/+4
2018-06-27Implement `#[macro_export(local_inner_macros)]`Vadim Petrochenkov-1/+9
2018-06-23hygiene: Merge `NameAndSpan` into `ExpnInfo`Vadim Petrochenkov-41/+31
2018-06-23hygiene: Do not reset expansion info for `quote!`Vadim Petrochenkov-2/+2
2018-06-23expansion: Add some commentsVadim Petrochenkov-2/+14
2018-06-23expansion: Improve searchability for `AstFragments` methodsVadim Petrochenkov-44/+60
2018-06-23expansion: Rename `Expansion` to `AstFragment`Vadim Petrochenkov-150/+159
2018-06-23expansion: Remove unnecessary override from `impl Folder for Marker`Vadim Petrochenkov-5/+0
2018-06-02Deny #[cfg] and #[cfg_attr] on generic parameters.kennytm-0/+5
2018-05-28Auto merge of #50724 - zackmdavis:applicability_rush, r=Manishearthbors-2/+6
add suggestion applicabilities to librustc and libsyntax A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means). r? @Manishearth cc @killercup @estebank
2018-05-26Add `Ident::as_str` helperVadim Petrochenkov-2/+2
2018-05-20suggestion applicabilities for libsyntax and librustc, run-rustfix testsZack M. Davis-2/+6
Consider this a down payment on #50723. To recap, an `Applicability` enum was recently (#50204) added, to convey to Rustfix and other tools whether we think it's OK for them to blindly apply the suggestion, or whether to prompt a human for guidance (because the suggestion might contain placeholders that we can't infer, or because we think it has a sufficiently high probability of being wrong even though it's— presumably—right often enough to be worth emitting in the first place). When a suggestion is marked as `MaybeIncorrect`, we try to use comments to indicate precisely why (although there are a few places where we just say `// speculative` because the present author's subjective judgement balked at the idea that the suggestion has no false positives). The `run-rustfix` directive is opporunistically set on some relevant UI tests (and a couple tests that were in the `test/ui/suggestions` directory, even if the suggestions didn't originate in librustc or libsyntax). This is less trivial than it sounds, because a surprising number of test files aren't equipped to be tested as fixed even when they contain successfully fixable errors, because, e.g., there are more, not-directly-related errors after fixing. Some test files need an attribute or underscore to avoid unused warnings tripping up the "fixed code is still producing diagnostics" check despite the fixes being correct; this is an interesting contrast-to/inconsistency-with the behavior of UI tests (which secretly pass `-A unused`), a behavior which we probably ought to resolve one way or the other (filed issue #50926). A few suggestion labels are reworded (e.g., to avoid phrasing it as a question, which which is discouraged by the style guidelines listed in `.span_suggestion`'s doc-comment).
2018-05-20Auto merge of #50820 - alexcrichton:no-modules, r=petrochenkovbors-5/+55
rustc: Disallow modules and macros in expansions This commit feature gates generating modules and macro definitions in procedural macro expansions. Custom derive is exempt from this check as it would be a large retroactive breaking change (#50587). It's hoped that we can hopefully stem the bleeding to figure out a better solution here before opening up the floodgates. The restriction here is specifically targeted at surprising hygiene results [1] that result in non-"copy/paste" behavior. Hygiene and procedural macros is intended to be avoided as much as possible for Macros 1.2 by saying everything is "as if you copy/pasted the code", but modules and macros are sort of weird exceptions to this rule that aren't fully fleshed out. [1]: https://github.com/rust-lang/rust/issues/50504#issuecomment-387734625 cc #50504
2018-05-18rustc: Disallow modules and macros in expansionsAlex Crichton-5/+55
This commit feature gates generating modules and macro definitions in procedural macro expansions. Custom derive is exempt from this check as it would be a large retroactive breaking change (#50587). It's hoped that we can hopefully stem the bleeding to figure out a better solution here before opening up the floodgates. The restriction here is specifically targeted at surprising hygiene results [1] that result in non-"copy/paste" behavior. Hygiene and procedural macros is intended to be avoided as much as possible for Macros 1.2 by saying everything is "as if you copy/pasted the code", but modules and macros are sort of weird exceptions to this rule that aren't fully fleshed out. [1]: https://github.com/rust-lang/rust/issues/50504#issuecomment-387734625 cc #50504
2018-05-17Pass crate editions to macro expansions, update testsVadim Petrochenkov-11/+15
2018-05-17Add edition to expansion infoVadim Petrochenkov-1/+6
2018-05-02make it compile againflip1995-1/+1
2018-05-02Gate tool_attributes featureSeiichi Uchida-1/+5
2018-05-02Allow Path for name of MetaItemSeiichi Uchida-1/+1
2018-04-30Auto merge of #50092 - abonander:issue-49934, r=petrochenkovbors-11/+57
Warn on pointless #[derive] in more places This fixes the regression in #49934 and ensures that unused `#[derive]` invocations on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. There is a separate warning hardcoded for `#[derive]` on macro invocations since linting (even the early-lint pass) occurs after expansion. This also adds regression tests for some nodes that were already warning properly. closes #49934
2018-04-29Warn on pointless `#[derive]` in more placesAustin Bonander-11/+57
This fixes the regression in #49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly. closes #49934
2018-04-20rustc: Tweak custom attribute capabilitiesAlex Crichton-1/+74
This commit starts to lay some groundwork for the stabilization of custom attribute invocations and general procedural macros. It applies a number of changes discussed on [internals] as well as a [recent issue][issue], namely: * The path used to specify a custom attribute must be of length one and cannot be a global path. This'll help future-proof us against any ambiguities and give us more time to settle the precise syntax. In the meantime though a bare identifier can be used and imported to invoke a custom attribute macro. A new feature gate, `proc_macro_path_invoc`, was added to gate multi-segment paths and absolute paths. * The set of items which can be annotated by a custom procedural attribute has been restricted. Statements, expressions, and modules are disallowed behind two new feature gates: `proc_macro_expr` and `proc_macro_mod`. * The input to procedural macro attributes has been restricted and adjusted. Today an invocation like `#[foo(bar)]` will receive `(bar)` as the input token stream, but after this PR it will only receive `bar` (the delimiters were removed). Invocations like `#[foo]` are still allowed and will be invoked in the same way as `#[foo()]`. This is a **breaking change** for all nightly users as the syntax coming in to procedural macros will be tweaked slightly. * Procedural macros (`foo!()` style) can only be expanded to item-like items by default. A separate feature gate, `proc_macro_non_items`, is required to expand to items like expressions, statements, etc. Closes #50038 [internals]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252 [issue]: https://github.com/rust-lang/rust/issues/50038
2018-04-06Use `Ident` instead of `Name` in `MetaItem`Vadim Petrochenkov-8/+9
2018-04-06Use `Span::apply_mark` where possibleVadim Petrochenkov-1/+1
2018-04-06Rename `PathSegment::identifier` to `ident`Vadim Petrochenkov-4/+4
2018-04-06Use `Span` instead of `SyntaxContext` in `Ident`Vadim Petrochenkov-1/+1
2018-04-03expand macro invocations in `extern {}` blocksAustin Bonander-0/+58
2018-04-02Expand attribute macros on statements and expressions.Austin Bonander-19/+70
Retains the `stmt_expr_attributes` feature requirement for attributes on expressions. closes #41475 cc #38356
2018-03-17Rename `Span::empty` to `Span::shrink_to_lo`, add `Span::shrink_to_hi`Vadim Petrochenkov-1/+1
2018-03-16Auto merge of #48524 - abonander:check-macro-stability, r=petrochenkovbors-16/+40
check stability of macro invocations I haven't implemented tests yet but this should be a pretty solid prototype. I think as-implemented it will also stability-check macro invocations in the same crate, dunno if we want that or not. I don't know if we want this to go through `rustc::middle::stability` or not, considering the information there wouldn't be available at the time of macro expansion (even for external crates, right?). r? @nrc closes #34079 cc @petrochenkov @durka @jseyfried #38356
2018-03-13Fix ICE on malformed plugin attributesMichael Lamparski-2/+4
2018-03-07check stability of macro invocationsAustin Bonander-16/+40
2018-03-02Replace Rc with Lrc for shared dataJohn Kåre Alsaker-5/+5
2018-02-18Replace dummy spans with empty spansSeiichi Uchida-1/+1
2018-02-18Change ast::Visibility to Spanned typeSeiichi Uchida-3/+6
2018-01-26Do not capture stderr in the compiler. Instead just panic silently for fatal ↵John Kåre Alsaker-1/+1
errors
2017-12-26Do not expand a derive invocation when derive is not allowedSeiichi Uchida-79/+91
1. Change the return type of `expand_invoc()` and its subroutines to `Option<Expansion>` from `Expansion`. 2. Return `None` when expanding a derive invocation if the item cannot have derive on it (in `expand_derive_invoc()`).
2017-12-22Rollup merge of #46858 - QuietMisdreavus:external-doc-error, r=estebankkennytm-7/+11
tweaks and fixes for doc(include) This PR makes a handful of changes around `#[doc(include="file.md")]` (https://github.com/rust-lang/rust/issues/44732): * Turns errors when loading files into full errors. This matches the original RFC text. * Makes the `missing_docs` lint check for `#[doc(include="file.md")]` as well as regular `#[doc="text"]` attributes. * Loads files included by `#[doc(include="file.md")]` into dep-info, mirroring the behavior of `include_str!()` and friends. * Adds or modifies tests to check for all of these.
2017-12-19Implement non-mod.rs mod statementsTaylor Cramer-3/+7
2017-12-19add files loaded through doc(include) into dep-infoQuietMisdreavus-0/+4
2017-12-19turn errors with external docs into actual errorsQuietMisdreavus-7/+7
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 01:11:18 +0000