-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proc_macro: Reorganize public API #49597
Conversation
cc @dtolnay, @nrc, @jseyfried |
r? @nrc |
Are there concrete plans on changes there? Has this been documented anywhere? |
@sgrif AFAIK there are no concrete plans yet, so no documentation either |
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@alexcrichton LMK if there's any discussion. Diesel is using pretty much all the methods on |
e211ef8
to
2b24ea5
Compare
@sgrif will do! |
This commit is a reorganization of the `proc_macro` crate's public user-facing API. This is the result of a number of discussions at the recent Rust All-Hands where we're hoping to get the `proc_macro` crate into ship shape for stabilization of a subset of its functionality in the Rust 2018 release. The reorganization here is motivated by experiences from the `proc-macro2`, `quote`, and `syn` crates on crates.io (and other crates which depend on them). The main focus is future flexibility along with making a few more operations consistent and/or fixing bugs. A summary of the changes made from today's `proc_macro` API is: * The `TokenNode` enum has been removed and the public fields of `TokenTree` have also been removed. Instead the `TokenTree` type is now a public enum (what `TokenNode` was) and each variant is an opaque struct which internally contains `Span` information. This makes the various tokens a bit more consistent, require fewer wrappers, and otherwise provides good future-compatibility as opaque structs are easy to modify later on. * `Literal` integer constructors have been expanded to be unambiguous as to what they're doing and also allow for more future flexibility. Previously constructors like `Literal::float` and `Literal::integer` were used to create unsuffixed literals and the concrete methods like `Literal::i32` would create a suffixed token. This wasn't immediately clear to all users (the suffixed/unsuffixed aspect) and having *one* constructor for unsuffixed literals required us to pick a largest type which may not always be true. To fix these issues all constructors are now of the form `Literal::i32_unsuffixed` or `Literal::i32_suffixed` (for all integral types). This should allow future compatibility as well as being immediately clear what's suffixed and what isn't. * Each variant of `TokenTree` internally contains a `Span` which can also be configured via `set_span`. For example `Literal` and `Term` now both internally contain a `Span` rather than having it stored in an auxiliary location. * Constructors of all tokens are called `new` now (aka `Term::intern` is gone) and most do not take spans. Manufactured tokens typically don't have a fresh span to go with them and the span is purely used for error-reporting **except** the span for `Term`, which currently affects hygiene. The default spans for all these constructed tokens is `Span::call_site()` for now. The `Term` type's constructor explicitly requires passing in a `Span` to provide future-proofing against possible hygiene changes. It's intended that a first pass of stabilization will likely only stabilize `Span::call_site()` which is an explicit opt-in for "I would like no hygiene here please". The intention here is to make this explicit in procedural macros to be forwards-compatible with a hygiene-specifying solution. * Some of the conversions for `TokenStream` have been simplified a little. * The `TokenTreeIter` iterator was renamed to `token_stream::IntoIter`. Overall the hope is that this is the "final pass" at the API of `TokenStream` and most of `TokenTree` before stabilization. Explicitly left out here is any changes to `Span`'s API which will likely need to be re-evaluated before stabilization. All changes in this PR have already been reflected to the [`proc-macro2`], `quote`, and `syn` crates. New versions of all these crates have also been published to crates.io. Once this lands in nightly I plan on making an internals post again summarizing the changes made here and also calling on all macro authors to give the APIs a spin and see how they work. Hopefully pending no major issues we can then have an FCP to stabilize later this cycle! [`proc-macro2`]: https://docs.rs/proc-macro2/0.3.1/proc_macro2/
2b24ea5
to
553c04d
Compare
Ok, maybe it's time to ask before it's stabilized. I always found it actively confusing. |
Maybe |
@petrochenkov I think |
Sigh, macros 1.1 strike again.
As I see it: enum TokenTree {
Leaf(LeafAuxData /* leaf kind, span, ... */),
Subtree(Vec<TokenTree>, SubTreeAuxData /* delimiter kind, span, ... */),
} In this sense The current library, however introduces one more layer of abstraction than strictly necessary - type TokenStream = impl Iterator<TokenTree> + Aux /* printing, parsing, ...*/; From this perspective the name "stream" actually starts making sense. I'm not 100% sure this additional layer is necessary, but it probably is, at least it's certainly better to put something like I also can guess where this scheme comes from historically - |
The only thing I'm not entirely happy about is naming for |
Ok thanks for the review! I talked about this pretty extensively with @nrc at the recent all-hands so I'm going to go ahead and... @bors: r=petrochenkov @dtolnay do you have thoughts on @petrochenkov's thoughts? I'd personally agree that |
📌 Commit 553c04d has been approved by |
* Expand `!` tokens for inner doc comments * Trim leading doc comment decoration in the string literal Both of these should help bring the expansion inline with what `macro_rules!` already does. Closes rust-lang#49655 Closes rust-lang#49656
21e8cd2
to
a57b1fb
Compare
📌 Commit a57b1fb has been approved by |
lgtm, r+ |
…chenkov proc_macro: Reorganize public API This commit is a reorganization of the `proc_macro` crate's public user-facing API. This is the result of a number of discussions at the recent Rust All-Hands where we're hoping to get the `proc_macro` crate into ship shape for stabilization of a subset of its functionality in the Rust 2018 release. The reorganization here is motivated by experiences from the `proc-macro2`, `quote`, and `syn` crates on crates.io (and other crates which depend on them). The main focus is future flexibility along with making a few more operations consistent and/or fixing bugs. A summary of the changes made from today's `proc_macro` API is: * The `TokenNode` enum has been removed and the public fields of `TokenTree` have also been removed. Instead the `TokenTree` type is now a public enum (what `TokenNode` was) and each variant is an opaque struct which internally contains `Span` information. This makes the various tokens a bit more consistent, require fewer wrappers, and otherwise provides good future-compatibility as opaque structs are easy to modify later on. * `Literal` integer constructors have been expanded to be unambiguous as to what they're doing and also allow for more future flexibility. Previously constructors like `Literal::float` and `Literal::integer` were used to create unsuffixed literals and the concrete methods like `Literal::i32` would create a suffixed token. This wasn't immediately clear to all users (the suffixed/unsuffixed aspect) and having *one* constructor for unsuffixed literals required us to pick a largest type which may not always be true. To fix these issues all constructors are now of the form `Literal::i32_unsuffixed` or `Literal::i32_suffixed` (for all integral types). This should allow future compatibility as well as being immediately clear what's suffixed and what isn't. * Each variant of `TokenTree` internally contains a `Span` which can also be configured via `set_span`. For example `Literal` and `Term` now both internally contain a `Span` rather than having it stored in an auxiliary location. * Constructors of all tokens are called `new` now (aka `Term::intern` is gone) and most do not take spans. Manufactured tokens typically don't have a fresh span to go with them and the span is purely used for error-reporting **except** the span for `Term`, which currently affects hygiene. The default spans for all these constructed tokens is `Span::call_site()` for now. The `Term` type's constructor explicitly requires passing in a `Span` to provide future-proofing against possible hygiene changes. It's intended that a first pass of stabilization will likely only stabilize `Span::call_site()` which is an explicit opt-in for "I would like no hygiene here please". The intention here is to make this explicit in procedural macros to be forwards-compatible with a hygiene-specifying solution. * Some of the conversions for `TokenStream` have been simplified a little. * The `TokenTreeIter` iterator was renamed to `token_stream::IntoIter`. Overall the hope is that this is the "final pass" at the API of `TokenStream` and most of `TokenTree` before stabilization. Explicitly left out here is any changes to `Span`'s API which will likely need to be re-evaluated before stabilization. All changes in this PR have already been reflected to the [`proc-macro2`], `quote`, and `syn` crates. New versions of all these crates have also been published to crates.io. Once this lands in nightly I plan on making an internals post again summarizing the changes made here and also calling on all macro authors to give the APIs a spin and see how they work. Hopefully pending no major issues we can then have an FCP to stabilize later this cycle! [`proc-macro2`]: https://docs.rs/proc-macro2/0.3.1/proc_macro2/ Closes rust-lang#49596
I think this has regressed a stable impl: #49725 |
While never intended to be stable we forgot that trait impls are insta-stable! This construction of `FromIterator` wasn't our first choice of how to stabilize the impl but our hands are tied at this point, so revert back to the original definition of `FromIterator` before rust-lang#49597 Closes rust-lang#49725
…m, r=nikomatsakis proc_macro: Generalize `FromIterator` impl While never intended to be stable we forgot that trait impls are insta-stable! This construction of `FromIterator` wasn't our first choice of how to stabilize the impl but our hands are tied at this point, so revert back to the original definition of `FromIterator` before rust-lang#49597 Closes rust-lang#49725
This commit is a reorganization of the
proc_macro
crate's public user-facingAPI. This is the result of a number of discussions at the recent Rust All-Hands
where we're hoping to get the
proc_macro
crate into ship shape forstabilization of a subset of its functionality in the Rust 2018 release.
The reorganization here is motivated by experiences from the
proc-macro2
,quote
, andsyn
crates on crates.io (and other crates which depend on them).The main focus is future flexibility along with making a few more operations
consistent and/or fixing bugs. A summary of the changes made from today's
proc_macro
API is:The
TokenNode
enum has been removed and the public fields ofTokenTree
have also been removed. Instead the
TokenTree
type is now a public enum(what
TokenNode
was) and each variant is an opaque struct which internallycontains
Span
information. This makes the various tokens a bit moreconsistent, require fewer wrappers, and otherwise provides good
future-compatibility as opaque structs are easy to modify later on.
Literal
integer constructors have been expanded to be unambiguous as to whatthey're doing and also allow for more future flexibility. Previously
constructors like
Literal::float
andLiteral::integer
were used to createunsuffixed literals and the concrete methods like
Literal::i32
would createa suffixed token. This wasn't immediately clear to all users (the
suffixed/unsuffixed aspect) and having one constructor for unsuffixed
literals required us to pick a largest type which may not always be true. To
fix these issues all constructors are now of the form
Literal::i32_unsuffixed
orLiteral::i32_suffixed
(for all integral types).This should allow future compatibility as well as being immediately clear
what's suffixed and what isn't.
Each variant of
TokenTree
internally contains aSpan
which can also beconfigured via
set_span
. For exampleLiteral
andTerm
now bothinternally contain a
Span
rather than having it stored in an auxiliarylocation.
Constructors of all tokens are called
new
now (akaTerm::intern
is gone)and most do not take spans. Manufactured tokens typically don't have a fresh
span to go with them and the span is purely used for error-reporting
except the span for
Term
, which currently affects hygiene. The defaultspans for all these constructed tokens is
Span::call_site()
for now.The
Term
type's constructor explicitly requires passing in aSpan
toprovide future-proofing against possible hygiene changes. It's intended that a
first pass of stabilization will likely only stabilize
Span::call_site()
which is an explicit opt-in for "I would like no hygiene here please". The
intention here is to make this explicit in procedural macros to be
forwards-compatible with a hygiene-specifying solution.
Some of the conversions for
TokenStream
have been simplified a little.The
TokenTreeIter
iterator was renamed totoken_stream::IntoIter
.Overall the hope is that this is the "final pass" at the API of
TokenStream
and most of
TokenTree
before stabilization. Explicitly left out here is anychanges to
Span
's API which will likely need to be re-evaluated beforestabilization.
All changes in this PR have already been reflected to the
proc-macro2
,quote
, andsyn
crates. New versions of all these crates have also beenpublished to crates.io.
Once this lands in nightly I plan on making an internals post again summarizing
the changes made here and also calling on all macro authors to give the APIs a
spin and see how they work. Hopefully pending no major issues we can then have
an FCP to stabilize later this cycle!
Closes #49596