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

Add --emit metadata #37411

Closed
wants to merge 1 commit into from
Closed

Add --emit metadata #37411

wants to merge 1 commit into from

Conversation

nrc
Copy link
Member

@nrc nrc commented Oct 25, 2016

With the same semantics as -Zno-trans

cc @rust-lang/compiler @rust-lang/tools

r? @alexcrichton

With the same semantics as -Zno-trans
Copy link
Member

@eddyb eddyb left a comment

Choose a reason for hiding this comment

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

LGTM

@alexcrichton
Copy link
Member

This isn't quite what I personally had in mind for this flag, but rather something like:

  • The compiler recognizes --emit metadata
  • The produces a new artifact, like crate-name.rmeta
  • The compiler can load .rmeta files like it can rlibs
  • When the compiler resolves extern crate foo, it prioritizes libfoo.rlib but works with foo.rmeta
  • When linking, if we don't have rlibs for everything (e.g. some are just metadata), we print a nice error

I feel like we definitely want a separate artifact here to avoid the compiler getting confused with "rlibs with code" and "rlibs with only metadata", and it'd also help build systems and such as it wouldn't all generate to the same file.

@nrc
Copy link
Member Author

nrc commented Oct 26, 2016

@alexcrichton that is a much bigger change, I'd want to be sure there was a big benefit to this. ISTM that we can get a lot of that benefit from just building into a different directory (e.g., Cargo could have a check directory in addition to release and debug). I had hoped we could keep a strict separation between code and metadata libs without having to rely on the file type.

@alexcrichton
Copy link
Member

It is indeed a much bigger change, yeah. I do agree that the implementation of cargo check will likely not change all that much, but as a stable flag to the compiler we need to consider more consumers than just Cargo itself.

@brson will also likely have opinions on this as well!

@bors
Copy link
Contributor

bors commented Oct 30, 2016

☔ The latest upstream changes (presumably #37400) made this pull request unmergeable. Please resolve the merge conflicts.

@nikomatsakis
Copy link
Contributor

I also assumed (and would expect) a design like the one that @alexcrichton proposed. It is certainly a somewhat bigger change -- but not that much, right?

@nrc
Copy link
Member Author

nrc commented Nov 6, 2016

ping @brson - thoughts?

@nrc
Copy link
Member Author

nrc commented Nov 10, 2016

Closing in favour of #37681

@nrc nrc closed this Nov 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants