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

Support compiling rustc without LLVM (try 2) #42932

Merged
merged 5 commits into from
Aug 11, 2017
Merged

Conversation

bjorn3
Copy link
Member

@bjorn3 bjorn3 commented Jun 27, 2017

Now doesn't change rustc_driver.

Supersedes #42752

@rust-highfive
Copy link
Collaborator

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@eddyb
Copy link
Member

eddyb commented Jun 27, 2017

cc @rust-lang/compiler
I am personally not in favor of the approach taken here and would rather make rustc_trans LLVM-only and extract all the other functionality out of it. There are just too many #[cfg(llvm)].

@arielb1 arielb1 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 27, 2017
@@ -14,6 +14,9 @@
# =============================================================================
[llvm]

# Indicates whether rustc will support compilation with LLVM (currently broken)
Copy link
Contributor

Choose a reason for hiding this comment

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

The comment seems to imply that the build with llvm is broken, not the build without it. Should be the other way round, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes

@bors
Copy link
Contributor

bors commented Jul 4, 2017

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

@oli-obk
Copy link
Contributor

oli-obk commented Jul 12, 2017

I am personally not in favor of the approach taken here and would rather make rustc_trans LLVM-only and extract all the other functionality out of it. There are just too many #[cfg(llvm)].

So llvm would just be a cargo feature of rustc_driver either including rustc_trans_llvm or not, depending on whether the feature is active or not?

@eddyb
Copy link
Member

eddyb commented Jul 12, 2017

@oli-obk More or less, yes.

@carols10cents
Copy link
Member

friendly ping to keep this on your radar, @bjorn3!

@nikomatsakis
Copy link
Contributor

Without looking in detail, I definitely agree with @eddyb that we should strive to factor things better and avoid quite so many #[cfg] gates. @bjorn3, do you need more detailed guidance on how to achieve that?

@bjorn3
Copy link
Member Author

bjorn3 commented Jul 20, 2017

@eddyb is this a bit like you mean. If so I will work it out further in a few days.

@bors
Copy link
Contributor

bors commented Jul 22, 2017

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

@alexcrichton alexcrichton added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 27, 2017
@alexcrichton
Copy link
Member

Looks like this may be ready for another round of review @eddyb!

@bjorn3 it also looks like there may be rebase conflicts here now.

ar = "0.3.0"

[features]
llvm = ["rustc_trans"]
Copy link
Member

Choose a reason for hiding this comment

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

Missing newline at the end of 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.

Fixed

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.

Now this looks much more streamlined!

@eddyb
Copy link
Member

eddyb commented Jul 28, 2017

@bjorn3 Ahh how I wish I had a way to un-dismiss github notifications... I keep losing track of some I've gone through on my phone 😞. @alexcrichton Thanks for the ping!

@bjorn3 bjorn3 force-pushed the no_llvm_try2 branch 2 times, most recently from 4c5839c to 7f191bc Compare July 31, 2017 08:18
@bjorn3
Copy link
Member Author

bjorn3 commented Jul 31, 2017

Rebased

@eddyb
Copy link
Member

eddyb commented Jul 31, 2017

@bjorn3 Can you squash the commits to remove the back-and-forth (X followed by revert X)?


#[cfg(not(feature="llvm"))]
impl MetadataLoader for NoLLvmMetadataLoader {
fn get_rlib_metadata(&self, _: &Target, filename: &Path) -> Result<ErasedBoxRef<[u8]>, String> {
Copy link
Member

@eddyb eddyb Jul 31, 2017

Choose a reason for hiding this comment

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

Was this copied wholesale from rustc_trans? Does that mean ar::Archive is independent of LLVM?
That could make rustc_metadata target-agnostic in the non-dynamic-library case!
cc @alexcrichton @rkruppe

Copy link
Member Author

@bjorn3 bjorn3 Jul 31, 2017

Choose a reason for hiding this comment

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

The ar crate is a rust only .a reader and writer.

Copy link
Member

@eddyb eddyb Jul 31, 2017

Choose a reason for hiding this comment

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

Then it should be used directly by rustc_metadata and get_rlib_metadata shouldn't exist as a pluggable API (but rather the code live in rustc_metadata) which means loader: Box<MetadataLoader> in rustc_metadata becomes just:

get_dylib_metadata: fn(&Target, &Path) -> Result<ErasedBoxRef<[u8]>, String>

When not available, one can just pass in |_, _| Err(String::from("unsupported")).

@bjorn3
Copy link
Member Author

bjorn3 commented Jul 31, 2017

Squashed

@bjorn3 bjorn3 force-pushed the no_llvm_try2 branch 3 times, most recently from 7b64996 to 47cd964 Compare August 1, 2017 13:26
@bjorn3
Copy link
Member Author

bjorn3 commented Aug 5, 2017

Doesn't fail locally (mac os)

@alexcrichton
Copy link
Member

Hm so looking over this it looks like this is changing how we're reading rlib metadata? The current construction is done specifically for speed as LLVM's ar parsing/reading is much speedier than many other solutions. Are we sure the ar crate is sufficiently fast enough? It initially looks that it is not, as one big difference is using memory maps vs actually reading the file into memory, which can make a huge difference here.

Also from a maintainability perspective, this seems like the kind of patch that'd bitrot almost instantly? Is there something we can do to avoid the #[cfg] jungle that will be very difficult to maintain over time?

@eddyb
Copy link
Member

eddyb commented Aug 10, 2017

@alexcrichton OH! Uhm, when I asked about it it sounded like we already moved away from using the LLVM support - but if that's not true, then the "Move rlib metadata reading code to rustc_metadata and replace MetadataLoader with a function pointer" commit was a mistake...

@bjorn3
Copy link
Member Author

bjorn3 commented Aug 11, 2017

Travis passes.

@eddyb
Copy link
Member

eddyb commented Aug 11, 2017

@bjorn3 Please squash the original commits with the reverts.

@bjorn3
Copy link
Member Author

bjorn3 commented Aug 11, 2017

Squashed and travis passes

@eddyb
Copy link
Member

eddyb commented Aug 11, 2017

@bors r+

@bors
Copy link
Contributor

bors commented Aug 11, 2017

📌 Commit e539996 has been approved by eddyb

@bors
Copy link
Contributor

bors commented Aug 11, 2017

⌛ Testing commit e539996 with merge edd82ee...

bors added a commit that referenced this pull request Aug 11, 2017
Support compiling rustc without LLVM (try 2)

Now doesn't change rustc_driver.

Supersedes #42752
@bors
Copy link
Contributor

bors commented Aug 11, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing edd82ee to master...

@alexcrichton
Copy link
Member

@eddyb and @bjorn3 did y'all have no comments about the maintainability aspect above? Specifically:

Also from a maintainability perspective, this seems like the kind of patch that'd bitrot almost instantly? Is there something we can do to avoid the #[cfg] jungle that will be very difficult to maintain over time?

@eddyb
Copy link
Member

eddyb commented Aug 11, 2017

@alexcrichton So I took a look at the diff to count them, remembering only 5-6... and now there's a lot more. And they're mostly in b7314c7 "Actually make rustc_driver compile without llvm".

@eddyb
Copy link
Member

eddyb commented Aug 11, 2017

So that is definitely my fault, and if @alexcrichton wants this reverted then I'm on board.
@bjorn3 What are you willing to do here? I know I've asked for a lot during this PR.

@bjorn3
Copy link
Member Author

bjorn3 commented Aug 12, 2017

Im writing a pr to remove most of the cfg's. It will likely be ready tomorrow.

@alexcrichton
Copy link
Member

Thanks @bjorn3! Feel free to cc or r? me on that

bors added a commit that referenced this pull request Aug 14, 2017
Cleanup for "Support compiling rustc without LLVM (try 2)"

This includes a small patch to allow running tests without llvm. Also check if you are not trying to compile a dylib.

cc #42932
r? @alexcrichton
@bjorn3 bjorn3 deleted the no_llvm_try2 branch August 14, 2017 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.