Compile basic rust project #5
Conversation
src/gccrs/args.rs
Outdated
| match s { | ||
| "bin" => CrateType::Bin, | ||
| // FIXME: Is 'lib' really part of this? Not always, right? | ||
| "dylib" | "lib" => CrateType::DyLib, |
There was a problem hiding this comment.
lib is an alias for rlib atm. it is officially documented as changable to dylib in the future, but I would consider it highly unlikely because it would break things.
| // If rustc is invoked with stdin as input, then it's simply to print the | ||
| // configuration option in our case, since we are compiling a rust project | ||
| // with files and crates | ||
| Some("-") => Gccrs::cfg_print(), |
There was a problem hiding this comment.
- indicates read from stdin. When you use --print it is just necessary to provide an input file.
There was a problem hiding this comment.
My question regarding the FIXME was related to cargo's usage of the "-" argument: Am I right in assuming that it will only ask rustc to read from stdin when initially printing the configuration? There is no weird, hidden flag to compile from stdin that I'm unaware about?
There was a problem hiding this comment.
I don't think cargo will ever ask rustc to read from stdin except for when using --print or maybe if using something weird like [lib] path = "-" in Cargo.toml. It os still cleaner to check for the right --print instead though.
There was a problem hiding this comment.
I tried it in an empty project, and cargo doesn't build anything with [lib] path = "-". It's invoking rustc/gccrs just like during compilation, which is without redirecting stdin to the spawned process's stdin.
I agree with you that it would be cleaner, but I think it should wait for now. Doing it this way is really practical since we can generate the gccrs.target_options.dump and parse it. Using the GccrsArgs struct and converting --print=cfg into -frust-dump-target_options would be nice, but it would require some sort of callback or other means to implement the parsing and printing of the configuration. Or, as discussed with @philberty, we could also make it so that gccrs displays target options in the same way as rustc, and on stdout instead of in a file. I've opened #7 to remember to get to this at some point
There was a problem hiding this comment.
Parts of this isn't really idiomatic Rust. So I suggest to use Clippy, which will help you in this regard.
I also see, that you don't really do error handling right now. I recommend that you think about this early. Retrofitting error handling usually isn't an easy task.
|
Thanks for reviewing @flip1995 and @bjorn3 and good work for this @CohenArthur. I think the review comments here are really good. There are 2 bigger issues after reading the comments:
If you prefer you could create github-issues out of these from the relevant comment, this way the other comments can be resolved with subsequent commits to this PR and this can be merged. Or you can continue to keep this PR open to fix those issues its up to you. |
I think the error handling and automation are really important and should therefore be part of the first PR in order to set a good base. But I agree that some things are out of scope for this and should be implemented later, as this PR only represents a minimum example of the final solution |
CohenArthur
force-pushed
the
compile-basic-hw
branch
from
990a7d4 to
8395fe7
Compare
CohenArthur
force-pushed
the
compile-basic-hw
branch
from
8395fe7 to
71fd09b
Compare
|
Since inline-comments easily get lost, see #5 (comment) |
| @@ -61,8 +71,7 @@ impl Gccrs { | |||
| } | |||
| } | |||
|
|
|||
| /// Convert arguments given to `rustc` into valid arguments for `gccrs` | |||
| pub fn handle_rust_args() -> Result { | |||
| fn cfg_print() -> Result { | |||
There was a problem hiding this comment.
Can you add a fixme that the output needs to be adapted for the target triple?
There was a problem hiding this comment.
Good catch, thanks. Done in 98688f7
Co-authored-by: bjorn3 <[email protected]>
Co-authored-by: flip1995 <[email protected]>
Co-authored-by: flip1995 <[email protected]>
Co-authored-by: flip1995 <[email protected]>
CohenArthur
force-pushed
the
compile-basic-hw
branch
from
d41b977 to
835dcb7
Compare
Co-authored-by: bjorn3 <[email protected]>
This PR allows the compilation of basic, single file Rust projects. I'd love to get some feedback on the different options given to
gccrs, the ones I'm parsing fromrustcand the implementation's quality overall. There is still a lot of room for improvement but this happily compiles the included basic Rust test. I believe that some necessary improvements are outside the scope of this PR, such as the-Coption parser. I will definitely work on that and fix it.Close #3
Close #4