rustc should support compiling C code

[thoughtpolice]

The metaticket is #1850.

Summary: rustc should provide some external means of compiling C files as part of a crate, and referring to it later. Two possible options are:

1. Just make rustc accept .c files and compile them appropriately.

2. Add an external attribute that describes a set of .c files and other options that a crate depends on.

I am a fan of 2, particularly because I think it could go well with #[cfg] and it means the rustc driver doesn't have to do stuff like throw options at the C compiler or something.

So I have foo.rc, that has some modules, but I can say:

#[external(c_src="foo.cc ...",
                 cc_opts="-DOMG_HAX")]

#[cfg(target_os = "win32")]
#[external(cc_opts="-DPLATFORM_WIN32")]
...

This makes it easy to compile a lot of C code directly inline with the crate. rustc just handles it in the backend. I feel this is the right approach since rustc may also be aware of other necessary flags, like if you should compile the .c files with -fPIC or not.

Furthermore, according to @brson in #1850, native modules do not strictly have to refer to shared libraries, and instead can use nolink as an attribute. I haven't tried, but perhaps right now it might look like:

#[nolink]
native mod glue {
  fn c_foo_bar(baz: *u8, quux: uint);
}

where c_foo_bar is the externally visible symbol name, that refers to part of the C code you're compiling. Alternatively the module declaration could have some other attribute; I'm not sure if nolink seems to make a lot of sense considering this is a clear use case, but it's not a huge deal here.

Thoughts?

[erickt]

I've been working on a project that's related to this issue. I've partially implemented libclang bindings, with the intention on parsing c-headers and auto-generating native modules from them. Perhaps rust-clang could also be used to just call out to the clang compiler to compile external code?

[brson]

I like trying to keep a clear separation between rustc and the C compiler, so don't favor having rustc compile .c files without it being clear that it's some kind of extension (so I like the attribute-based scheme).

I don't think I want to take a clang dependency yet. Obviously it would open up a lot of possibilities, but that's a big step. Maybe when we're closer to getting the native binding generation working, and after we have real compiler plugins (I don't want to keep piling peripheral code into the compiler without a clear delineation between the 'core' compiler and extensions).

[thoughtpolice]

I have no idea why I closed this; misclick, sorry!

Either way I feel the same about a clang dependency. It's a very large addition, for one. An auto-binding generator would certainly be excellent (Clang and Rustc both export all the necessary infrastructure to make it a robust tool, too,) but I feel the need for it is somewhat different than what's necessary here.

I look very much forward to such a tool though; I've pondered it a bit in the past on IRC as well.

[thoughtpolice]

Also, I will go ahead and mention that I may begin working on this soon, as opposed to #1861, which is a much more tricky issue to get right. This issue covers plenty of use-cases on its own, IMO.

I think the proposed scheme here is fine, personally, and I'll begin experimenting with it, but can I ask, @brson, how far away is a reality with compiler plugins? If it's not an incredible chore and there's a ticket about discussion/what people expect, it may be better to bite the bullet and implement that, and then start implementing this as a plugin. I agree the compiler is going to grow awfully complex if we start bundling all this stuff, so it may just be worth doing that first, and then coming back here (it also makes auto-binding generators, C code compilers, and all sorts of lint/analysis tools much more maintainable.)

[brson]

Regarding plugins, there is no complete design, nor even general consensus that plugins are the way forward, so it will take some discussion and design work. pcwalton and dherman have recently been discussing how to overhaul the macro system, which is closely related. Most of the existing work being performed by extensions should not be directly coded into compiler, imo.

#458 (dynamic loading) is a prerequisite. #1762 is about extracting the syntax extensions from the compiler.

One possible way to make progress on this issue while sidestepping the plugin issue would be to implement a separate tool that parses the appropriate attributes out of the crate, runs the C compiler, then uses #612 to merge link_args attributes into the crate. The tool would use librustc, so would be trivial to convert to a plugin (or merge into the compiler) later.

[metajack]

I think the decision was reached that if this kind of thing was done, it would be done in rustpkg instead of in rustc. #6403 tracks that work. I'm going to close this in favor of the newer bug.