about summary refs log tree commit diff
path: root/src/libproc_macro/lib.rs
AgeCommit message (Collapse)AuthorLines
2018-10-01Span::def_site() is now at #54724Alex Crichton-1/+1
2018-10-01The `proc_macro_raw_ident` feature is now at #54723Alex Crichton-1/+1
2018-10-01The `proc_macro_quote` feature now lives at #54722Alex Crichton-2/+2
2018-09-27Bump to 1.31.0 and bootstrap from 1.30 betaJosh Stone-1/+1
2018-09-19Make 'proc_macro::MultiSpan' public.Sergio Benitez-1/+1
2018-09-13Add multispan support to proc-macro diagnostics.Sergio Benitez-2/+2
Also updates the issue number for 'proc_macro_diagnostic'.
2018-09-12Auto merge of #53793 - toidiu:ak-stabalize, r=nikomatsakisbors-1/+0
stabilize outlives requirements https://github.com/rust-lang/rust/issues/44493 r? @nikomatsakis
2018-09-11stabalize infer outlives requirements (RFC 2093).toidiu-1/+0
Co-authored-by: nikomatsakis
2018-09-09Remove documentation about proc_macro being bare-bonesDavid Tolnay-7/+0
2018-09-08Track distinct spans for open and close delimiterDavid Tolnay-24/+10
2018-09-02proc_macro::Group::span_open and span_closeDavid Tolnay-1/+42
Before this addition, every delimited group like (...) [...] {...} has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation: mod m { type T = } error: expected type, found `}` --> src/main.rs:3:1 | 3 | } | ^ On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above. This commit adds group.span_open() and group.span_close() which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro.
2018-08-24check that adding infer-outlives requirement to all crates worksNiko Matsakis-0/+1
2018-08-21Rollup merge of #53496 - matthiaskrgr:codespell_08_2018, r=varkorkennytm-1/+1
Fix typos found by codespell.
2018-08-19fix tidy errorsDonato Sciarra-1/+1
2018-08-19mv codemap() source_map()Donato Sciarra-1/+1
2018-08-19mv filemap source_fileDonato Sciarra-4/+4
2018-08-19mv FileMap SourceFileDonato Sciarra-3/+3
2018-08-19Fix typos found by codespell.Matthias Krüger-1/+1
2018-08-16Auto merge of #53433 - kennytm:rollup, r=kennytmbors-0/+1
Rollup of 10 pull requests Successful merges: - #52946 (Documented impl From on line 367 of libserialize/json.rs) - #53234 (Remove Travis shutdown debug scripts, and remove CI-specific DNS settings) - #53313 (Two small improvements) - #53360 (Addressed #51602) - #53364 (Warn if the user tries to use GATs) - #53373 (Tweak unclosed delimiter parser error) - #53377 (std: Use target_pointer_width for BACKTRACE_ELF_SIZE) - #53395 (Use #[non_exhaustive] on internal enums) - #53399 (Tidy: ignore non-Markdown files when linting for the Unstable Book) - #53412 (syntax_ext: remove leftover span_err_if_not_stage0 macro.)
2018-08-16Auto merge of #53304 - dtolnay:extend, r=dtolnaybors-0/+14
TokenStream::extend Two new insta-stable impls in libproc_macro: ```rust impl Extend<TokenTree> for TokenStream impl Extend<TokenStream> for TokenStream ``` `proc_macro::TokenStream` already implements `FromIterator<TokenTree>` and `FromIterator<TokenStream>` so I elected to support the same input types for `Extend`. **This commit reduces compile time of Serde derives by 60% (takes less than half as long to compile)** as measured by building our test suite: ```console $ git clone https://github.com/serde-rs/serde $ cd serde/test_suite $ cargo check --tests --features proc-macro2/nightly $ rm -f ../target/debug/deps/libtest_*.rmeta $ time cargo check --tests --features proc-macro2/nightly Before: 20.8 seconds After: 8.6 seconds ``` r? @alexcrichton
2018-08-15Make proc_macro Level #[non_exhaustive]varkor-0/+1
2018-08-12TokenStream::extendDavid Tolnay-0/+14
2018-08-09[nll] libproc_macro: enable feature(nll) for bootstrapmemoryruins-0/+1
2018-07-25Deny bare_trait_objects globallyTatsuyuki Ishi-1/+0
2018-07-20proc_macro: avoid exposing internal details in formatting impls.Eduard-Mihai Burtescu-7/+37
2018-07-20proc_macro: move some implementation details to a rustc module.Eduard-Mihai Burtescu-246/+21
2018-07-20proc_macro: don't expose compiler-internal FileName in public API.Eduard-Mihai Burtescu-16/+7
2018-07-20proc_macro: clean up the implementation of quasi-quoting.Eduard-Mihai Burtescu-10/+4
2018-07-20proc_macro: don't try to reflect literals in quasi-quoting.Eduard-Mihai Burtescu-1/+1
2018-07-16rustc: Stabilize much of the `proc_macro` featureAlex Crichton-100/+122
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-14Clarify how the quote macro is loadedManish Goregaokar-0/+2
2018-07-12Deny bare trait objects in the rest of rustljedrz-0/+1
2018-07-08hygiene: Decouple transparencies from expansion IDsVadim Petrochenkov-12/+7
2018-06-30Address commentsVadim Petrochenkov-1/+4
2018-06-30Fortify dummy span checkingVadim Petrochenkov-3/+1
2018-06-30proc-macro: Use transparent marks for call-site hygieneVadim Petrochenkov-34/+54
2018-06-01Update recursion limitsJohn Kåre Alsaker-0/+2
2018-05-26Auto merge of #51072 - petrochenkov:ifield, r=eddybbors-3/+3
Use `Ident`s for fields in HIR Continuation of https://github.com/rust-lang/rust/pull/49718, part of https://github.com/rust-lang/rust/issues/49300
2018-05-26Add `Ident::as_str` helperVadim Petrochenkov-3/+3
2018-05-25Rename TokenStream::empty to TokenStream::newDavid Tolnay-1/+1
There is no precedent for the `empty` name -- we do not have `Vec::empty` or `HashMap::empty` etc.
2018-05-17Fix rebaseVadim Petrochenkov-1/+1
2018-05-16Fix stability annotations for already stable bits of proc macro API 1.1Vadim Petrochenkov-5/+5
Remove unnecessary proc-macro-related `feature`s
2018-05-15Represent lifetimes as two joint tokens in proc macrosVadim Petrochenkov-16/+18
2018-05-15Address feedback, remove remaining review comments, add some more docsVadim Petrochenkov-52/+29
2018-05-15proc_macro: Validate inputs to `Punct::new` and `Ident::new`Vadim Petrochenkov-17/+22
2018-05-15proc_macro: Properly support raw identifiersVadim Petrochenkov-14/+13
2018-05-15TokenTree: Op -> Punct, Term -> IdentVadim Petrochenkov-86/+70
2018-05-15Extend documentation and add review commentsVadim Petrochenkov-38/+152
2018-05-10Auto merge of #49823 - Zoxc:term-str, r=alexcrichtonbors-2/+3
Remove usages of Term::as_str and mark it for removal Returning references to rustc internal data structures is a bad idea since their lifetimes are unrelated to the lifetimes of proc_macro values. See https://github.com/rust-lang/rust/pull/46972 and the `Taming thread-local storage` section of https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606 r? @alexcrichton
2018-05-04proc_macro: Explicitly make everything !Send/SyncAlex Crichton-1/+46
This commit adds explicit imp blocks to ensure that all publicly exported types (except simple enums) are not `Send` nor `Sync` in the `proc_macro` crate. cc #38356