Ownership of Syntex

[dtolnay]

Now that Serde's code generation is stable and we no longer depend on Syntex, it no longer makes sense for our team to continue owning the Syntex stack.

Please let me know if you would be interested in taking over ownership. If nobody needs Syntex updates so much that they would be willing to run the stack, I think it means we can abandon Syntex and Aster and Quasi.

[dtolnay]

x-posted to u.r-l.o: https://users.rust-lang.org/t/seeking-new-maintainer-for-syntex/9288

[dtolnay]

cc owners of <1 month old dependencies on syntex and aster and quasi:

• rustfmt: @steveklabnik @nrc
• racer: @phildawes @jwilm
• bindgen: @emilio @fitzgen @mahkoh @crabtw @nox @Yamakaky
• cargo-modules: @regexident
• cargo-safety: @alexkehayias
• easy-plugin: @KyleMayes
• extprim_literals: @kennytm
• gdax-client: @KenanSulayman
• hypospray_extensions: @jonysy
• mockers_codegen: @kriomant
• pnet_macros: @mrmonday @faern

[fitzgen]

@dtolnay can you describe what maintainership of syntex/aster/quasi looks like in practice? Is it mostly un-nightly-ifying code from rustc?

bindgen would be pretty negatively impacted by the loss of syntex.

[emilio]

Yes, though even though bindgen is really dependent on syntax for code generation, I think our need to update syntex is sporadic (i.e., when we need to generate code for something our current syntex version can't, which is rather unfrequent).

I think other projects that use rust code as input (rustfmt comes to mind) could be more affected by this.

I'm happy doing a syntex/aster/etc update once in a while when bindgen needs it for some reason, but I don't think bindgen has as much of a need for keeping syntex/quote/quasi constantly updated compared to other crates.

[dtolnay]

@fitzgen

can you describe what maintainership of syntex/aster/quasi looks like in practice? Is it mostly un-nightly-ifying code from rustc?

It is exclusively un-nightly-ifying code from rustc and bumping version numbers. Here are some example commits to give you an idea:

• https://github.com/serde-rs/syntex/commit/8b40e6d964c25dbc1cc85c9058e9dd6a1844e0a3
• https://github.com/serde-rs/syntex/commit/fbedee1569f2b6122ebdfb44be950c97f90b5067
• https://github.com/serde-rs/syntex/commit/8759cfe5a61c2e922be62401fe52696a67c5422d
• https://github.com/serde-rs/quasi/commit/b7acde7b29c9d7ac6c5c8d2f028a3b6004d9879f
• https://github.com/serde-rs/aster/commit/1bfac817c031f309078b6b02f34420c9c9386569

@emilio the thing is, resolving these merge conflicts sporadically in big batches is MUCH harder than resolving them in real time as they happen. So even if bindgen only bumps its syntex dependency very rarely, you still want to have a version of syntex that is based on a relatively recent rustc at all times.

[nox]

@emilio @dtolnay How hard would it be to migrate bindgen to syn's trees or just quotations?

[emilio]

@nox: I assume it's going to be hardish to migrate to just quotations, since we need something a bit more procedural (though maybe quotations have now support for that?). Mainly, I don't know off-hand (haven't looked to much arguably, aster is nice for that) into how to replace patterns like:

for field in struct.fields() {
    // ...
    builder = builder.with_field(..);
}

I'd had to try to know how hard would be to migrate to syn, but in any case all that is kind of off-topic in this issue.

[Dushistov]

@dtolnay

Why syntex was dropped at 163d8d6c24144fdd6fd6c79c24d643043f8cf206 and in version 0.59? Personaly I use syntex in my project for macros expansions.

I thought the project was stoped, but it is moving according to commit history, but for some reason drops important parts.

[dtolnay]

I updated syntex_syntax to Rust 2017-06-01 to use in rustfmt. I did not update syntex because rustfmt does not use it. Rustfmt is going to be moving into the main Rust distro and no longer using syntex_syntax, so you should consider both syntex and syntex_syntax abandoned.

[Techcable]

You might want to post syn on the readmee as an alternative.