Move metadata handling into its own crate

[brson]

Seems like a good next candidate for breaking up rustc. Metadata will likely be needed by the libraries for dynamic loading.

[brson]

Probably necessary for doing dynamic loading and other reflection stuff.

It's very tangled up in the syntax and ty modules so I think parts of ty have to go with it.

[mstewartgallus]

I would appreciate this effort. I am currently working on wrapping the dlfcn API http://gitorious.org/rust-dlfcn/rust-dlfcn/trees and using it to load code dynamically. However this is not very good because I need to use the #[no_mangle] attribute (which doesn't work on static values #5972 )

[ssbr]

It would be nice if rustc::metadata were made be more easily usable for non-compilers. Essentially the entire public API assumes you've parsed a rust source file and are looking into its dependencies (or at least, that's how I interpret the tangling with syntax::ast and the usage in rustc's driver, but I never looked deeper than that.)

I tried to figure out how to use this to pull type information from crates to generate C header files; however, it can't be done with the public API as far as I can tell.

[pcwalton]

I don't believe this is backwards incompatible, renominating.

[graydon]

just a bug, removing milestone/nomination.

[graydon]

dynamic loading is unlikely to be typesafe, but if we go there we're likely to do it based on type hashing

[emberian]

This would hopefully be accomplished alongside the metadata reform that needs to happen.

[emberian]

Still a problem. I have some ideas about it, will post to ML.

[kmcallister]

+1, this is potentially useful for a lot of things, e.g.

• Defining syntax plugins without linking librustc
• Access to metadata through DynamicLib (Add "typechecking" to DynamicLib #17833)
• Piping metadata between running rustc processes (Parallelize some phases of compilation between a crate and its dependency #3431)

[brson]

Still an obvious but hard refactor. Not sure if this issue is still useful.

[steveklabnik]

@brson yeah, I'd side on the 'ticket not actually useful' side of things. @kmcallister has a list of some things that this would be useful for, but those have individual tickets that are actually goal-focused.