-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Wrap Command Line Arguments in a Response File if System Limits are Exceeded #16362
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
Changes from all commits
5976901
da19625
2297f75
2b5e3c7
62813f4
fe4f21d
2a30e25
3fe62b9
3b38fa6
6592b42
8e6abee
e65cb23
d71373c
f6b5cf5
9d51350
d6ec8fa
be229fc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -271,6 +271,14 @@ class Job { | |
/// Whether the job wants a list of input or output files created. | ||
std::vector<FilelistInfo> FilelistFileInfos; | ||
|
||
/// Response file path | ||
const char *ResponseFilePath; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A bit of a nitpick, but I would prefer it with another "const" after the star ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still like the const after the star here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I count about 100 lines of code in methods of that class. If I had to maintain this code and needed to know if that instance variable ever changed, I would have to read them. Adding the "cost" would save me that work. Therefore, I would not approve this PR without this "const". (Of course you don't need my approval to land it & that's OK. I would just feel derelict in my duty to favor consistency over maintainability in this case.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Meta: At this point you've expressed a strong enough opinion that Austin does need your approval to land the PR. If you want to rescind that, you'd have to signify that, perhaps by "dismissing" your X review. Personally, I'm with Austin on this one. Being inconsistent can imply that the inconsistency is deliberate, and therefore it is better to be consistent with existing code in a PR that's adding functionality. (That's especially true for someone who's a relative newcomer.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Meta: @jrose-apple Please help me out here. Since the merge box is green, I figured he did not need my approval to land the PR. (I seem to recall reading verbiage to that effect on github, too.) Is there some policy (or implicit understanding) that I've missed? Where are you thinking that I express such a strong enough opinion? Was the need expressed, or implied? I don't understand. You have a fair point about inconsistency, but I weigh that point against the benefits of this particular proposed inconsistency. In this case I would argue (on your side) that if the const is added to one variable, a future reader might infer that the other variables are not const. However, the counter argument would be that it would be clear for anyone with a passing familiarity with the code base that const is often not used when it could be. Thus, it seems to me that the consistency benefit is outweighed by the not-having-to-read-100-lines-of-code benefit of the const. My experience as a novitiate to this code base has been that such consts would save me significant time. Ironically, it was my experience with adopting Swift for my code that convinced me of the significance of the benefits of write-once variables. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We aren't using GitHub's built-in gating for reviewers, true. But only a little above the green merge button is the part where "@davidungar requested changes", with a red X. Even without that, though, I think we want to take expressed concerns seriously unless the reviewer explicitly says something like "this is fine as is (but I think it could be better in these ways)". |
||
|
||
/// This contains a single argument pointing to the response file path with | ||
/// the '@' prefix. | ||
/// The argument string must be kept alive as long as the Job is alive. | ||
const char *ResponseFileArg; | ||
|
||
/// The modification time of the main input file, if any. | ||
llvm::sys::TimePoint<> InputModTime = llvm::sys::TimePoint<>::max(); | ||
|
||
|
@@ -281,12 +289,16 @@ class Job { | |
const char *Executable, | ||
llvm::opt::ArgStringList Arguments, | ||
EnvironmentVector ExtraEnvironment = {}, | ||
std::vector<FilelistInfo> Infos = {}) | ||
std::vector<FilelistInfo> Infos = {}, | ||
const char *ResponseFilePath = nullptr, | ||
const char *ResponseFileArg = nullptr) | ||
: SourceAndCondition(&Source, Condition::Always), | ||
Inputs(std::move(Inputs)), Output(std::move(Output)), | ||
Executable(Executable), Arguments(std::move(Arguments)), | ||
ExtraEnvironment(std::move(ExtraEnvironment)), | ||
FilelistFileInfos(std::move(Infos)) {} | ||
FilelistFileInfos(std::move(Infos)), | ||
ResponseFilePath(ResponseFilePath), | ||
ResponseFileArg(ResponseFileArg) {} | ||
|
||
virtual ~Job(); | ||
|
||
|
@@ -296,7 +308,9 @@ class Job { | |
|
||
const char *getExecutable() const { return Executable; } | ||
const llvm::opt::ArgStringList &getArguments() const { return Arguments; } | ||
ArrayRef<const char *> getResponseFileArg() const { return ResponseFileArg; } | ||
ArrayRef<FilelistInfo> getFilelistInfos() const { return FilelistFileInfos; } | ||
ArrayRef<const char *> getArgumentsForTaskExecution() const; | ||
|
||
ArrayRef<const Job *> getInputs() const { return Inputs; } | ||
const CommandOutput &getOutput() const { return *Output; } | ||
|
@@ -347,6 +361,10 @@ class Job { | |
|
||
static void printArguments(raw_ostream &Stream, | ||
const llvm::opt::ArgStringList &Args); | ||
|
||
bool hasResponseFile() const { return ResponseFilePath != nullptr; } | ||
|
||
bool writeArgsToResponseFile() const; | ||
}; | ||
|
||
/// A BatchJob comprises a _set_ of jobs, each of which is sufficiently similar | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -247,6 +247,7 @@ ToolChain::constructInvocation(const CompileJobAction &job, | |
const JobContext &context) const { | ||
InvocationInfo II{SWIFT_EXECUTABLE_NAME}; | ||
ArgStringList &Arguments = II.Arguments; | ||
II.allowsResponseFiles = true; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is it true in this case? Comment? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I remain puzzled by that line. Please add a comment. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Never mind, see below. |
||
|
||
Arguments.push_back("-frontend"); | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -325,7 +325,10 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job, | |
Arguments.push_back( | ||
context.Args.MakeArgString(context.Output.getPrimaryOutputFilename())); | ||
|
||
return {Clang, Arguments}; | ||
InvocationInfo II{Clang, Arguments}; | ||
II.allowsResponseFiles = true; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why true? Comment? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If there are a bunch of similar lines, could you please factor them into an intention-revealing method? Or add a comment to each? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Never mind, see below. |
||
|
||
return II; | ||
} | ||
|
||
std::string toolchains::Android::getTargetForLinker() const { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -168,5 +168,8 @@ toolchains::Windows::constructInvocation(const LinkJobAction &job, | |
Arguments.push_back( | ||
context.Args.MakeArgString(context.Output.getPrimaryOutputFilename())); | ||
|
||
return {Clang, Arguments}; | ||
InvocationInfo II{Clang, Arguments}; | ||
II.allowsResponseFiles = true; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, this is the third time I'm seeing the setting to true. Is there something in common that the code should be reifying? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope. It's all based on what other tool is getting invoked, which is not necessarily the same across each toolchain and certainly not the same across each job. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is, this is the customization point, so that the rest of the code can treat everything the same. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, but how about comments explaining why There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The comment would read: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am still with Austin on this. If the executable specified in the InvocationInfo constructor supports response files, you can put There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I updated the comment in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you for updating the comment. In thinking about this item, the comment you added is good and it is sufficient. I'm not asking for the following, but if I were to try to make it even clearer, I would use a one-line intention-revealing function. But, never mind. |
||
|
||
return II; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove this comment. It is completely redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the point of this comment? @jrose-apple Is there some coding standard I don't know about? Why not remove it entirely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This purpose of the comment is to remain consistent with the rest of the file. A few lines above reads:
for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand. Since I believe that this sort of comment degrades maintainability (yes, it's a tiny cut but there are virtually thousands of them), and since I try to enhance the maintainabilty of the code with each review, I asked for its deletion. However, a consistent-but-redundant comment is only a mere bagatelle.