Skip to content
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

Build error on nightly (2018-04-05) #121

Closed
anxiousmodernman opened this issue Apr 6, 2018 · 6 comments
Closed

Build error on nightly (2018-04-05) #121

anxiousmodernman opened this issue Apr 6, 2018 · 6 comments

Comments

@anxiousmodernman
Copy link
Contributor

anxiousmodernman commented Apr 6, 2018

I'm doing a release build with rocket features. I get a big run of errors when compiling maud_macros. This is a pretty recent development, so I don't think it's due to any code change in maud itself.

proc

many other errors not shown

These are the most recent docs I can find for the proc_macro crate. It looks like major changes to the API.

@lambda-fairy
Copy link
Owner

Thanks for reporting. I'll look into it over the coming weekend. (Unless you'd like to do the upgrade instead 😉)

anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 7, 2018
Instead of a `kind` field containting a `TokenNode` variant, a
TokenTree is not an enum with variants of different types. Note that a
TokenTree could be a sequence of TokenTrees. Refs lambda-fairy#121
@anxiousmodernman
Copy link
Contributor Author

anxiousmodernman commented Apr 7, 2018

I'll give it a shot and take some notes here.

It looks like a TokenTree is now an enum, not a struct, and so we express different token types as enum variants. Converting the struct syntax to the new enum shouldn't be so bad.

Not sure about an equivalent to TokenTreeIter yet. I think they want us to deal with a TokenStream directly, it has an IntoIterator impl. Update: maybe it's proc_macro::token_stream::IntoIter which itself is an Iterator<TokenTree>.

anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 8, 2018
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 8, 2018
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 8, 2018
Don't pass TokenStream::empty() here
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 8, 2018
@anxiousmodernman
Copy link
Contributor Author

Worked through markup and markups. So far I'm just letting complaints from my IDE (thanks RLS!) be my guide, until we are actually compiling under the new types. Then we can address correctness. Flagging this in the meantime: anxiousmodernman@4cd5451#diff-285844f0c3c48a3b23fa1b5ec1140722R166

A TokenTree::Group(x) holds a Group that has a stream() -> TokenStream method, but the yielded stream is the tokens without the specified delimiter. I'll keep going and assume this is what we want, but I'm actually not sure.

anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 9, 2018
also:
 remove dead code
 remove invalid import

Refs lambda-fairy#121
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 9, 2018
also:
 remove dead code
 remove invalid import

Refs lambda-fairy#121
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 9, 2018
@anxiousmodernman
Copy link
Contributor Author

anxiousmodernman commented Apr 9, 2018

A TokenStream can be built from an iterator of TokenTree. My idea is to change the signature of match_arm to support this. It yields a funky from_iter/into_iter dance, and looks like the internals of match_arm will need some rework.
match_arms


Or maybe not? :)
second_thoughts

anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 9, 2018
Use the `token_stream::FromIter` type to chain together the
Option<TokenStream> types that `match_arm` yields. There may be a way to
simplify this code. Refs lambda-fairy#121
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 9, 2018
I'm unsure about the set_span call, but I did not want to throw away the
passed in Span. Refs lambda-fairy#121
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 9, 2018
It doesn't seem as easy to compose/chain TokenStreams as it is to
collect a Vec<TokenTree> into a TokenStream. There is probably some
iterator API I could use instead.

Refs lambda-fairy#121
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 9, 2018
This compiles, but does not pass tests.

Instead of a `kind` field containting a `TokenNode` variant, a
TokenTree is now an enum with variants of different types (Literal, Op,
Term, etc). Note that a TokenTree could be a sequence of TokenTrees if it is a
Group variant.

Other notes:

I'm unsure about the set_span call in Builder::emit_if, but I did not want to
throw away the passed in Span.

Parsing relies on destructuring references to the values associated with
TokenTree enum variants

It doesn't seem as easy to compose/chain TokenStreams as it is to
collect a Vec<TokenTree> into a TokenStream. There is probably some
iterator API I could use instead. See `match_arms` and build.rs

Refs lambda-fairy#121
sh4869 added a commit to sh4869/dgen that referenced this issue Apr 10, 2018
sh4869 added a commit to sh4869/dgen that referenced this issue Apr 10, 2018
barzamin added a commit to rustodon/rustodon that referenced this issue Apr 11, 2018
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 12, 2018
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 12, 2018
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 12, 2018
Instead of a `kind` field containting a `TokenNode` variant, a
TokenTree is now an enum with variants of different types (Literal, Op,
Term, etc). Note that a TokenTree could be a sequence of TokenTrees if it is a
Group variant.

Other notes:

I'm unsure about the set_span call in Builder::emit_if, but I did not want to
throw away the passed in Span.

Parsing relies on destructuring references to the values associated with
TokenTree enum variants

It doesn't seem as easy to compose/chain TokenStreams as it is to
collect a Vec<TokenTree> into a TokenStream. There is probably some
iterator API I could use instead. See `match_arms` and build.rs

Refs lambda-fairy#121
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 12, 2018
Instead of a `kind` field containting a `TokenNode` variant, a
TokenTree is now an enum with variants of different types (Literal, Op,
Term, etc). Note that a TokenTree could be a sequence of TokenTrees if it is a
Group variant.

Other notes:

I'm unsure about the set_span call in Builder::emit_if, but I did not want to
throw away the passed in Span.

Parsing relies on destructuring references to the values associated with
TokenTree enum variants

It doesn't seem as easy to compose/chain TokenStreams as it is to
collect a Vec<TokenTree> into a TokenStream. There is probably some
iterator API I could use instead. See `match_arms` and build.rs

Refs lambda-fairy#121
@anxiousmodernman
Copy link
Contributor Author

anxiousmodernman commented Apr 12, 2018

This might be fixed. Interested parties can try testing with my fork:

# in Cargo.toml
[dependencies]
maud = { git = "https://github.com/anxiousmodernman/maud.git", branch = "121_proc_macro", features = ["rocket"] }

Of course, you will need to list the particular features your project depends on. Also note that TOML wants this hash all on one line.

barzamin added a commit to rustodon/rustodon that referenced this issue Apr 13, 2018
anxiousmodernman added a commit to anxiousmodernman/maud that referenced this issue Apr 16, 2018
Also remove conservative_impl_trait feature flag, as this is now a
stable feature.

Refs lambda-fairy#121
@anxiousmodernman
Copy link
Contributor Author

I'll leave my fork up for a while, but these changes are now in maud master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants