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

rustc should support compiling C code #1862

Closed
thoughtpolice opened this issue Feb 17, 2012 · 6 comments
Closed

rustc should support compiling C code #1862

thoughtpolice opened this issue Feb 17, 2012 · 6 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@thoughtpolice
Copy link
Contributor

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
Copy link
Contributor

erickt commented Feb 17, 2012

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
Copy link
Contributor

brson commented Feb 17, 2012

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

brson commented Feb 22, 2012

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
Copy link
Contributor

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.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jan 30, 2024
Update books

## rust-lang/edition-guide

1 commits in bbffb074e16bef89772818b400b6c76a65eac126..baafacc6d8701269dab1e1e333f3547fb54b5a59
2024-01-18 18:44:06 UTC to 2024-01-18 18:44:06 UTC

- Update c-string literal stabilization release number. (rust-lang/edition-guide#289)

## rust-embedded/book

1 commits in 3f9df2b9885c6741365da2e12ed6662cd0e827d6..2e95fc2fd31d669947e993aa07ef10dc9828bee7
2024-01-29 07:19:07 UTC to 2024-01-29 07:19:07 UTC

- Mention generics in "optimizing dependencies" (rust-embedded/book#366)

## rust-lang/reference

3 commits in 8c77e8be9da1a9c70545556218d563c8d061f1fd..a0b119535e7740f68494c4f0582f7ad008b00ccd
2024-01-27 19:22:06 UTC to 2024-01-27 16:43:49 UTC

- Update C-String literals to reject NUL (rust-lang/reference#1450)
- pure asm blocks must terminate (rust-lang/reference#1442)
- String literal expressions (rust-lang/reference#1452)

## rust-lang/rust-by-example

4 commits in ddf5cb0e6ee54ba2dd84c8ca3e1314120014e20d..179256a445d6144f5f371fdefb993f48f33978b0
2024-01-22 12:21:42 UTC to 2024-01-20 23:10:42 UTC

- Updated first sentence of "parsing a string" in string.md (rust-lang/rust-by-example#1805)
- Update the rustdoc example to match best practice (rust-lang/rust-by-example#1804)
- Add reference to crates.io error handling crates (rust-lang/rust-by-example#1803)
- fix(str.md): avoid misunderstanding that there were only two string types (rust-lang/rust-by-example#1802)

## rust-lang/rustc-dev-guide

15 commits in 4af29d1..ec287e3
2024-01-28 22:45:18 UTC to 2024-01-15 17:44:49 UTC

- Upgrade actions to use Node.js v20 (rust-lang/rustc-dev-guide#1863)
- Fix some links (rust-lang/rustc-dev-guide#1865)
- Add link in salsa (rust-lang/rustc-dev-guide#1866)
- Clarify what rt.rs is. (rust-lang/rustc-dev-guide#1876)
- update link to rustc dependencies (rust-lang/rustc-dev-guide#1869)
- Followup to rust-lang#1862 (rust-lang/rustc-dev-guide#1864)
- Clarify debugging graph dependency (rust-lang/rustc-dev-guide#1862)
- Get diagnostics directly in `rustc-driver-getting-diagnostics` example (rust-lang/rustc-dev-guide#1857)
- Update examples (rust-lang/rustc-dev-guide#1856)
- Add a perf. bot command and a link to its help page (rust-lang/rustc-dev-guide#1855)
- Add some explanations for frequently used rustbot commands (rust-lang/rustc-dev-guide#1849)
- update some of the diagnostic translations info (rust-lang/rustc-dev-guide#1711)
- Document unsafety checking (rust-lang/rustc-dev-guide#1847)
- Remove outdated references to `-Z dump-mir-spanview` (rust-lang/rustc-dev-guide#1853)
- update old bootstrap docs (rust-lang/rustc-dev-guide#1852)
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 30, 2024
Rollup merge of rust-lang#120467 - rustbot:docs-update, r=ehuss

Update books

## rust-lang/edition-guide

1 commits in bbffb074e16bef89772818b400b6c76a65eac126..baafacc6d8701269dab1e1e333f3547fb54b5a59
2024-01-18 18:44:06 UTC to 2024-01-18 18:44:06 UTC

- Update c-string literal stabilization release number. (rust-lang/edition-guide#289)

## rust-embedded/book

1 commits in 3f9df2b9885c6741365da2e12ed6662cd0e827d6..2e95fc2fd31d669947e993aa07ef10dc9828bee7
2024-01-29 07:19:07 UTC to 2024-01-29 07:19:07 UTC

- Mention generics in "optimizing dependencies" (rust-embedded/book#366)

## rust-lang/reference

3 commits in 8c77e8be9da1a9c70545556218d563c8d061f1fd..a0b119535e7740f68494c4f0582f7ad008b00ccd
2024-01-27 19:22:06 UTC to 2024-01-27 16:43:49 UTC

- Update C-String literals to reject NUL (rust-lang/reference#1450)
- pure asm blocks must terminate (rust-lang/reference#1442)
- String literal expressions (rust-lang/reference#1452)

## rust-lang/rust-by-example

4 commits in ddf5cb0e6ee54ba2dd84c8ca3e1314120014e20d..179256a445d6144f5f371fdefb993f48f33978b0
2024-01-22 12:21:42 UTC to 2024-01-20 23:10:42 UTC

- Updated first sentence of "parsing a string" in string.md (rust-lang/rust-by-example#1805)
- Update the rustdoc example to match best practice (rust-lang/rust-by-example#1804)
- Add reference to crates.io error handling crates (rust-lang/rust-by-example#1803)
- fix(str.md): avoid misunderstanding that there were only two string types (rust-lang/rust-by-example#1802)

## rust-lang/rustc-dev-guide

15 commits in 4af29d1..ec287e3
2024-01-28 22:45:18 UTC to 2024-01-15 17:44:49 UTC

- Upgrade actions to use Node.js v20 (rust-lang/rustc-dev-guide#1863)
- Fix some links (rust-lang/rustc-dev-guide#1865)
- Add link in salsa (rust-lang/rustc-dev-guide#1866)
- Clarify what rt.rs is. (rust-lang/rustc-dev-guide#1876)
- update link to rustc dependencies (rust-lang/rustc-dev-guide#1869)
- Followup to rust-lang#1862 (rust-lang/rustc-dev-guide#1864)
- Clarify debugging graph dependency (rust-lang/rustc-dev-guide#1862)
- Get diagnostics directly in `rustc-driver-getting-diagnostics` example (rust-lang/rustc-dev-guide#1857)
- Update examples (rust-lang/rustc-dev-guide#1856)
- Add a perf. bot command and a link to its help page (rust-lang/rustc-dev-guide#1855)
- Add some explanations for frequently used rustbot commands (rust-lang/rustc-dev-guide#1849)
- update some of the diagnostic translations info (rust-lang/rustc-dev-guide#1711)
- Document unsafety checking (rust-lang/rustc-dev-guide#1847)
- Remove outdated references to `-Z dump-mir-spanview` (rust-lang/rustc-dev-guide#1853)
- update old bootstrap docs (rust-lang/rustc-dev-guide#1852)
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

4 participants