Skip to content

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

Merged
merged 5 commits into from
Jun 27, 2018

Conversation

davidungar
Copy link
Contributor

@davidungar davidungar commented May 22, 2018

Minor refactoring of buildCompilation to try to get the function to be fewer lines, and also moving definitions closer to uses.

@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

@davidungar davidungar force-pushed the buildCompilation-refactor-1 branch from 6f10073 to 328b3b1 Compare May 23, 2018 19:12
@davidungar davidungar changed the title NFC: Some small refactoring in buildCompilation NFC, WIP: Some small refactoring in buildCompilation May 23, 2018
@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

@davidungar davidungar requested a review from jrose-apple May 23, 2018 21:56
@davidungar
Copy link
Contributor Author

@jrose-apple This a minor refactoring of buildCompilation. How does it strike you?

@davidungar davidungar changed the title NFC, WIP: Some small refactoring in buildCompilation NFC: Some small refactoring in buildCompilation May 23, 2018
Copy link
Contributor

@graydon graydon left a 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!

@@ -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.)
Copy link
Contributor

Choose a reason for hiding this comment

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

Stray parenthesis?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! Fixed.

@davidungar davidungar force-pushed the buildCompilation-refactor-1 branch from de3dd3f to 732f41b Compare May 30, 2018 23:53
@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

@davidungar
Copy link
Contributor Author

@jrose-apple I've rebased to the latest. Looking forward to your thoughts.

@davidungar
Copy link
Contributor Author

@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.

SmallString<128> workingDirectory;
workingDirectory = A->getValue();
llvm::sys::fs::make_absolute(workingDirectory);
return workingDirectory.str();
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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().

Copy link
Contributor Author

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?

computeStatsReporter(ArgList.get(), Inputs, OI, DefaultTargetTriple);

C =
llvm::make_unique<Compilation>(
Copy link
Contributor

@CodaFi CodaFi May 31, 2018

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));

Copy link
Contributor Author

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.

@CodaFi
Copy link
Contributor

CodaFi commented May 31, 2018

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.
@davidungar davidungar force-pushed the buildCompilation-refactor-1 branch from 12b3812 to 9fd23bb Compare June 15, 2018 17:52
@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

@davidungar
Copy link
Contributor Author

@graydon I have redone this to include your recent SIGINT changes.

@davidungar
Copy link
Contributor Author

@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.

Copy link
Contributor

@jrose-apple jrose-apple left a 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.

const bool ShowIncrementalBuildDecisions) {
{
const bool WasIncrementalRequested =
ArgList->hasArg(options::OPT_incremental);
Copy link
Contributor

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.

Copy link
Contributor Author

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.

}

static std::unique_ptr<UnifiedStatsReporter>
computeStatsReporter(const llvm::opt::InputArgList *ArgList,
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed, thanks.

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"
Copy link
Contributor

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.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice catch!

@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

@davidungar
Copy link
Contributor Author

@jrose-apple Review ping (tx!)

@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

1 similar comment
@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

@@ -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.
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sigh.. yes! Fixed!!. Thanks.

@@ -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.
Copy link
Contributor

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.)

@davidungar
Copy link
Contributor Author

@swift-ci please smoke test

@davidungar
Copy link
Contributor Author

@jrose-apple I have removed the comment you objected to. Is there anything else? Thanks.

Copy link
Contributor

@jrose-apple jrose-apple left a comment

Choose a reason for hiding this comment

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

Go for it!

@davidungar davidungar merged commit c1c9cb8 into swiftlang:master Jun 27, 2018
@davidungar
Copy link
Contributor Author

@jrose-apple Thanks!

@davidungar
Copy link
Contributor Author

@CodaFi thanks!

@davidungar davidungar deleted the buildCompilation-refactor-1 branch June 14, 2019 18:03
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.

4 participants