[PATCH] D27477: Refactor how the MSVC toolchain searches for a compatibility version.
Reid Kleckner via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Dec 6 13:11:09 PST 2016
rnk added a comment.
This seems like a nice refactoring, and I'm pretty sure there's no real functional change in practice.
================
Comment at: include/clang/Driver/ToolChain.h:446
+ /// \brief On Windows, returns the MSVC compatibility version.
+ virtual VersionTuple getMSVCVersion(const Driver *D,
+ const llvm::opt::ArgList &Args) const {
----------------
This isn't a cheap operation, and we don't cache it. Let's call it something like `computeMSVCVersion`. I don't want us to read the version out of cl.exe more than once. Besides, it mirrors `ComputeLLVMTriple` etc.
================
Comment at: lib/Driver/MSVCToolChain.cpp:476-478
+namespace {
+
+VersionTuple getMSCompatibilityVersion(unsigned Version) {
----------------
I know this is more of an RFC patch, but I'll note we prefer `static` on free functions in case you hadn't encountered that http://llvm.org/docs/CodingStandards.html#id53
Also, this is poorly named. It's really building a version tuple from an unseparated, possibly full, version number. So, maybe `inferMSVCVersionSeparators` or `separateMSVCFullVersion` or something?
================
Comment at: lib/Driver/Tools.cpp:5739
// -fms-compatibility-version=18.00 is default.
+ VersionTuple MSVT = getToolChain().getMSVCVersion(&D, Args);
----------------
This comment got separated from the the relevant default some time ago. Can you move it to the `return VersionTuple(18)`?
https://reviews.llvm.org/D27477
More information about the llvm-commits
mailing list