-
Notifications
You must be signed in to change notification settings - Fork 10.5k
NFC: Some small refactoring in buildCompilation
#16762
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
NFC: Some small refactoring in buildCompilation
#16762
Conversation
@swift-ci please smoke test |
6f10073
to
328b3b1
Compare
buildCompilation
buildCompilation
@swift-ci please smoke test |
@jrose-apple This a minor refactoring of |
buildCompilation
buildCompilation
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.
Looks good to me!
lib/Driver/Driver.cpp
Outdated
@@ -857,7 +880,7 @@ Driver::buildCompilation(const ToolChain &TC, | |||
} | |||
|
|||
// For getting bulk fixits, or for when users explicitly request to continue | |||
// building despite errors. | |||
// building despite errors.) |
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.
Stray parenthesis?
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.
Thanks! Fixed.
de3dd3f
to
732f41b
Compare
@swift-ci please smoke test |
@jrose-apple I've rebased to the latest. Looking forward to your thoughts. |
@CodaFi Don't know if you want to review this or not, but cc'ing you since you are into this code nowadays. I started refactoring this function a week ago because I felt we might be elaborating and extending it, and in lieu of a major restructure, thought I would do a few small things to help its malleability. If you do want to look at this, we can better align our efforts. |
lib/Driver/Driver.cpp
Outdated
SmallString<128> workingDirectory; | ||
workingDirectory = A->getValue(); | ||
llvm::sys::fs::make_absolute(workingDirectory); | ||
return workingDirectory.str(); |
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'm generally not a fan of escaping SmallString
buffers like this. The lifetime of the buffer being in the scope of buildCompilation
clarified that it should survive through its uses - here we're relying on the StringRef
of its contents being copied by the conversion to std::string
.
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.
Thank you for this. Yes. In this case, the copying overhead is not significant, we get to shrink down a super-long function, and encapsulate the intension-shift.
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 think Robert was saying that the implicit conversion here from StringRef to std::string was too subtle for him. Is that correct?
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'm not sure what "implicit" means here because I had thought that the .str()
part as well as the return type made the conversion explicit. I would like to encapsulate this computation in a function in order to capture the intension-shift (aka abstract-level change), from the caller to this callee. Is there a way to do it that you would prefer? How else would one write a function that returns a string?
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'll let Robert decide what he'd prefer—I have no further comments—but str()
produces a StringRef, not a std::string. The maximally explicit thing would be *sigh* workingDirectory.str().str()
.
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.
@jrose-apple Thanks! I didn't realize that--not familiar enough with SmallString and str
didn't convey that to me. I have changed that to make it clearer.
@CodaFi How do you feel about how it reads now?
lib/Driver/Driver.cpp
Outdated
computeStatsReporter(ArgList.get(), Inputs, OI, DefaultTargetTriple); | ||
|
||
C = | ||
llvm::make_unique<Compilation>( |
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.
Nit: clang-format
wants this to be
C = llvm::make_unique<Compilation>(
Diags, TC, OI, Level, std::move(ArgList), std::move(TranslatedArgList),
std::move(Inputs), buildRecordPath, outputBuildRecordForModuleOnlyBuild,
ArgsHash, StartTime, LastBuildTime, DriverFilelistThreshold,
Incremental, BatchMode, DriverBatchSeed, DriverForceOneBatchRepartition,
SaveTemps, ShowDriverTimeCompilation, std::move(StatsReporter));
but I like the stacked argument list here, so I guess an outdent of the argument list would split the difference.
C = llvm::make_unique<Compilation>(
Diags, TC, OI, Level,
std::move(ArgList),
std::move(TranslatedArgList),
std::move(Inputs),
buildRecordPath,
outputBuildRecordForModuleOnlyBuild,
ArgsHash,
StartTime,
LastBuildTime,
DriverFilelistThreshold,
Incremental,
BatchMode,
DriverBatchSeed,
DriverForceOneBatchRepartition,
SaveTemps,
ShowDriverTimeCompilation,
std::move(StatsReporter));
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.
Yes, I'll outdent it. This is a case where git-clang-format does the "wrong" thing and makes the deltas harder to read.
Only little things I noticed on my pass through this. LGTM |
1. Compute things closer to use, and use const, and 2. Factor out some computations into subroutines in order to shorten buildCompilation.
12b3812
to
9fd23bb
Compare
@swift-ci please smoke test |
@graydon I have redone this to include your recent SIGINT changes. |
@jrose-apple Now that WWDC is past, it would be great if you could give this PR a review. You always find good things to fix. |
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.
Sure, works for me.
lib/Driver/Driver.cpp
Outdated
const bool ShowIncrementalBuildDecisions) { | ||
{ | ||
const bool WasIncrementalRequested = | ||
ArgList->hasArg(options::OPT_incremental); |
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.
Indentation got messed up here, but also it seems like this doesn't need its own variable at all.
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 tried it without the variable and you are right; it's better that way.
lib/Driver/Driver.cpp
Outdated
} | ||
|
||
static std::unique_ptr<UnifiedStatsReporter> | ||
computeStatsReporter(const llvm::opt::InputArgList *ArgList, |
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.
createStatsReporter
, maybe? The reporter isn't being computed.
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.
Fixed, thanks.
lib/Driver/Driver.cpp
Outdated
ArgList->hasArg(options::OPT_whole_module_optimization) | ||
? "is not compatible with whole module optimization." | ||
: ArgList->hasArg(options::OPT_embed_bitcode) | ||
? "is not currently compatible with embedding LLVM IR bitcode" |
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.
Tiny nitpick: you're being inconsistent about periods here. (The old code used them in both messages.)
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.
Nice catch!
@swift-ci please smoke test |
@jrose-apple Review ping (tx!) |
@swift-ci please smoke test |
1 similar comment
@swift-ci please smoke test |
lib/Driver/Driver.cpp
Outdated
@@ -700,7 +700,9 @@ computeWorkingDirectory(const llvm::opt::InputArgList *ArgList) { | |||
SmallString<128> workingDirectory; | |||
workingDirectory = A->getValue(); | |||
llvm::sys::fs::make_absolute(workingDirectory); | |||
return workingDirectory.str(); | |||
// Create a new string that can outlive ArgList. |
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.
It's not about outliving ArgList; it's outliving the stack-based workingDirectory
.
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.
Sigh.. yes! Fixed!!. Thanks.
lib/Driver/Driver.cpp
Outdated
@@ -700,7 +700,7 @@ computeWorkingDirectory(const llvm::opt::InputArgList *ArgList) { | |||
SmallString<128> workingDirectory; | |||
workingDirectory = A->getValue(); | |||
llvm::sys::fs::make_absolute(workingDirectory); | |||
// Create a new string that can outlive ArgList. | |||
// Create a new string that can outlive workingDirectory. |
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.
…
That doesn't add anything. It doesn't say why workingDirectory
is worth outliving.
(I wouldn't have added a comment at all, but if you're going to add one, please make it as high-level / semantic as possible.)
@swift-ci please smoke test |
@jrose-apple I have removed the comment you objected to. Is there anything else? Thanks. |
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.
Go for it!
@jrose-apple Thanks! |
@CodaFi thanks! |
Minor refactoring of
buildCompilation
to try to get the function to be fewer lines, and also moving definitions closer to uses.