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

Compile basic rust project #5

Merged
merged 9 commits into from
Jun 14, 2021
Merged

Compile basic rust project #5

merged 9 commits into from
Jun 14, 2021

Conversation

CohenArthur
Copy link
Member

@CohenArthur CohenArthur commented Jun 10, 2021

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 from rustc and 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 -C option parser. I will definitely work on that and fix it.

Close #3
Close #4

match s {
"bin" => CrateType::Bin,
// FIXME: Is 'lib' really part of this? Not always, right?
"dylib" | "lib" => CrateType::DyLib,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, will fix!

// 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(),
Copy link
Contributor

@bjorn3 bjorn3 Jun 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- indicates read from stdin. When you use --print it is just necessary to provide an input file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

.github/workflows/build_test_fmt.yml Outdated Show resolved Hide resolved
Cargo.toml Show resolved Hide resolved
src/gccrs/args.rs Outdated Show resolved Hide resolved
src/gccrs/args.rs Outdated Show resolved Hide resolved
src/gccrs/args.rs Outdated Show resolved Hide resolved
src/gccrs/args.rs Outdated Show resolved Hide resolved
src/gccrs/args.rs Outdated Show resolved Hide resolved
src/gccrs/mod.rs Outdated Show resolved Hide resolved
src/gccrs/mod.rs Outdated Show resolved Hide resolved
src/main.rs Outdated Show resolved Hide resolved
@philberty philberty added this to In progress in Compile basic rust project via automation Jun 11, 2021
@philberty philberty added the enhancement New feature or request label Jun 11, 2021
@philberty
Copy link
Member

philberty commented Jun 11, 2021

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:

  1. Setup Clippy Automation
  2. Error handling

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.

@CohenArthur
Copy link
Member Author

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:

1. Setup Clippy Automation

2. Error handling

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

Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR looks way better/cleaner now, great work!

One more thing regarding GHA.

.github/workflows/build_test_fmt.yml Show resolved Hide resolved
Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

.gitignore Outdated Show resolved Hide resolved
@flip1995
Copy link
Member

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a fixme that the output needs to be adapted for the target triple?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks. Done in 98688f7

Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
@CohenArthur CohenArthur merged commit 2cfc3db into main Jun 14, 2021
Compile basic rust project automation moved this from In progress to Done Jun 14, 2021
@CohenArthur CohenArthur deleted the compile-basic-hw branch June 14, 2021 19:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

Use the getopts crate for parsing rustc arguments Handle --crate-name based on --crate-type
4 participants