Fix issue 30063 (reset codegen-units to 1 when necessary) #30208
Conversation
|
|
||
| // Issue #30063: if user requests llvm-related output to one | ||
| // particular path, disable codegen-units. | ||
| if matches.opt_present("o") && cg.codegen_units != 1 { |
There was a problem hiding this comment.
I'd personally prefer to omit the check here for -o and always execute this logic if codegen_units != 1, that way we maintain equivalence between rustc -o foo foo.rs and rustc foo.rs (for all emit types)
There was a problem hiding this comment.
Okay; I was trying to minimize the impact of the change over the current state of affairs, but I'm willing to concede that the principle of least surprise implies we should adopt the tack you suggest.
There was a problem hiding this comment.
@alexcrichton (okay commit 24bc2d2 should address this concern.)
|
r=me, thanks @pnkfelix! |
pnkfelix
changed the title
|
@bors r=alexcrichton |
|
📌 Commit 199d2e4 has been approved by |
|
⌛ Testing commit 199d2e4 with merge ff6fa09... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
Doh,I was running the Makefile by hand and forgot the driver will already add an |
|
@bors r=alexcrichton |
|
📌 Commit d623dd9 has been approved by |
|
@bors r=alexcrichton |
|
📌 Commit d623dd9 has been approved by |
|
⌛ Testing commit d623dd9 with merge 0191c29... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
Hmm, it seems that |
|
@alexcrichton given that at least one pre-existing test is relying on the ability to mix What do you think?
Update: @alexcrichton gave me a quicker solution to the problem here: don't use |
This didn't work, since I discussed the matter face-to-face with @alexcrichton and @huonw , and @alexcrichton agreed that my original approach (of only downshifting to code-units=1 if one also passed |
…ts back to 1. Fix rust-lang#30063 Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream.
pnkfelix
force-pushed
the
fix-issue-30063
branch
from
d623dd9 to
9b5b2e3
Compare
The `rsbegin.o` and `rsend.o` build products should not be generated on non WinGnu platforms. This is another path to resolving rust-lang#30063 for non win-gnu targets. (And it won't require a snapshot, unlike PR rust-lang#30208.)
When given `rustc -C codegen-units=4 --emit=obj`, reset units back to 1. Fix #30063 Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream. (Multiple emit types without `-o PATH` will "work", though it will downgrade codegen-units to 1 just like all the other cases.) r? @alexcrichton
…alexcrichton The `rsbegin.o` and `rsend.o` build products should not be generated on non WinGnu platforms. This is another path to resolving #30063 for non win-gnu targets. (And it won't require a snapshot, unlike PR #30208.) r? @alexcrichton
When given
rustc -C codegen-units=4 --emit=obj, reset units back to 1.Fix #30063
Note: while this code is careful to handle the case of mutliple emit types (e.g.
--emit=asm,obj) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types and-o PATHwill continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream. (Multiple emit types without-o PATHwill "work", though it will downgrade codegen-units to 1 just like all the other cases.)r? @alexcrichton