Initial import of the Aster syntax::ast builder library

[erickt]

This imports the aster library into the Rust repository as an unstable library. Aster is a syntax::ast builder, that simplifies the generation of rust AST. It abstracts away many of the default options, and shields the user from fields being added, removed, or restructured in many circumstances. This allows a library like Serde to be much more reliably compiled on nightly, which has not been broken by aster in the past couple months.

This is specifically being done for the Servo project, which has started to use Serde and has gotten broken a few times because of the lag between libsyntax changes and the requisite changes needed to be made in Aster.

I realize that while this is an unstable library this still might need to go through the RFC process, so please let me know and I'll write one up.

cc @nrc, @pcwalton, @SimonSapin, @Manishearth

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[Manishearth]

🎊

IMO we should let this bake on master for a while without an RfC and then make one when we plan to stabilize it. I don't see the point for an RfC in the more unstable parts of the compiler unless you want more feedback on it.

I'll do some reviewing of this PR later, no time now 😄

[brson]

Bad revert.

[erickt]

@brson: thanks for catching that! I removed those changes.

[brson]

r? @nrc

[brson]

For my part I don't think I should make this decision. I can understand why we might want this in-tree to keep it from breaking, but I'm wary: we don't import entire crates into the compiler often; the prime motivation here is for Servo, not general improvement; there may be ways to offer the stability Servo needs out of tree (with more work perhaps); this forces our hand on compiler interfaces, positioning this as the way to build ASTs without a lot of premeditation on our end.

Just listing downsides. Don't feel strongly.

[Manishearth]

the prime motivation here is for Servo

While that is the immediate motivation, I see lots of value in having a more stable libsyntax in-tree for people to use. Aster has already proven its public interface to be pretty stable, and this might pave the way for eventual libsyntax stabilization. If we don't like it, we can always remove it -- we're not proposing to mark aster as stable, but having a practically stable (even if officially unstable) library sounds better than a practically and officially unstable library.

(Also, serde isn't just used by Servo, it seems to be a rather popular library 😄)

[SimonSapin]

This is specifically being done for the Servo project, which has started to use Serde and has gotten broken a few times because of the lag between libsyntax changes and the requisite changes needed to be made in Aster.

I don’t believe this is inevitable. With http://nightli.es/ or something like it we can be notified of breakage within a day or so, and with more people who can publish new releases Aster can be kept closely up-to-date with Nightly.

[erickt]

@SimonSapin: Did the aster breakage from earlier today cause you any problems?

[SimonSapin]

No, I just got notified from https://github.com/SimonSapin/run-nightly

[nrc]

fwiw, I would much rather have a mechanism for keeping crates like this up to date without importing it into the distro. I think other projects could benefit (I know rustfmt would) and otherwise we will end up getting a bloated distro.

This should also be discussed somewhere more visible. I'll start an internals thread, it probably doesn't need an RFC.

The libs team have a path to stable which involves first being a 'blessed' crate as part of the rust-lang GH org, then possibly being added to the distro. We should probably follow that path here.

I'll postpone a proper review until we decide what to do.

[nrc]

See https://internals.rust-lang.org/t/aster-crate/2580

[bors]

☔ The latest upstream changes (presumably #27893) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

I'm gonna close this due to inactivity (and I think the internals thread was a bit up in the air), but feel free to reopen!