[clang-tools-extra] 64f74bf - [clang-tidy] Rewrite modernize-avoid-bind check.

[Zachary Turner via cfe-commits]

Author: Zachary Turner
Date: 2019-12-02T15:36:26-08:00
New Revision: 64f74bf72eb484aa32e1104050cb54745116decf

URL: 
https://github.com/llvm/llvm-project/commit/64f74bf72eb484aa32e1104050cb54745116decf
DIFF: 
https://github.com/llvm/llvm-project/commit/64f74bf72eb484aa32e1104050cb54745116decf.diff

LOG: [clang-tidy] Rewrite modernize-avoid-bind check.

This represents largely a full re-write of modernize-avoid-bind, adding
significant new functionality in the process. In particular:

* Both boost::bind and std::bind are now supported
* Function objects are supported in addition to functions
* Member functions are supported
* Nested calls are supported using capture-init syntax
* std::ref() and boost::ref() are now recognized, and will capture by reference.
* Rather than capturing with a global =, we now build up an individual
  capture list that is both necessary and sufficient for the call.
* Fixits are supported in a much larger variety of scenarios than before.

All previous tests pass under the re-write, but a large number of new
tests have been added as well.

Differential Revision: https://reviews.llvm.org/D70368

Added: 

clang-tools-extra/test/clang-tidy/checkers/modernize-avoid-bind-permissive-parameter-list.cpp

Modified: 
clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp
clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.h
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/modernize-avoid-bind.rst
clang-tools-extra/test/clang-tidy/checkers/modernize-avoid-bind.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp
index 2d4475c991ca..d1994073bd07 100644
--- a/clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp
@@ -14,11 +14,12 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/SmallVector.h"
-#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Casting.h"
+#include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Regex.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -34,45 +35,270 @@ namespace modernize {
 namespace {
 
 enum BindArgumentKind { BK_Temporary, BK_Placeholder, BK_CallExpr, BK_Other };
+enum CaptureMode { CM_None, CM_ByRef, CM_ByValue, CM_InitExpression };
+
+enum CallableType {
+  CT_Other,  // unknown
+  CT_Function,   // global or static function
+  CT_MemberFunction, // member function with implicit this
+  CT_Object, // object with operator()
+};
+
+enum CallableMaterializationKind {
+  CMK_Other,   // unknown
+  CMK_Function,// callable is the name of a member or non-member function.
+  CMK_VariableRef, // callable is a simple expression involving a global or
+   // local variable.
+  CMK_CallExpression, // callable is obtained as the result of a call 
expression
+};
 
 struct BindArgument {
-  StringRef Tokens;
+  // A rough classification of the type of expression this argument was.
   BindArgumentKind Kind = BK_Other;
+
+  // If this argument required a capture, a value indicating how it was
+  // captured.
+  CaptureMode CaptureMode = CM_None;
+
+  // The exact spelling of this argument in the source code.
+  StringRef SourceTokens;
+
+  // The identifier of the variable within the capture list.  This may be
+  // 
diff erent from UsageIdentifier for example in the expression *d, where the
+  // variable is captured as d, but referred to as *d.
+  std::string CaptureIdentifier;
+
+  // If this is a placeholder or capture init expression, contains the tokens
+  // used to refer to this parameter from within the body of the lambda.
+  std::string UsageIdentifier;
+
+  // If Kind == BK_Placeholder, the index of the placeholder.
   size_t PlaceHolderIndex = 0;
+
+  // True if the argument is used inside the lambda, false otherwise.
+  bool IsUsed = false;
+
+  // The actual Expr object representing this expression.
+  const Expr *E = nullptr;
+};
+
+struct CallableInfo {
+  CallableType Type = CT_Other;
+  CallableMaterializationKind Materialization = CMK_Other;
+  CaptureMode CaptureMode = CM_None;
+  StringRef SourceTokens;
+  std::string CaptureIdentifier;
+  std::string UsageIdentifier;
+  StringRef CaptureInitializer;
+  const FunctionDecl *Decl = nullptr;
+};
+
+struct LambdaProperties {
+  CallableInfo Callable;
+  SmallVector BindArguments;
+  StringRef BindNamespace;
+  bool IsFixitSupported = false;
 };
 
 } // end namespace
 
+static const Expr *ignoreTemporariesAndPointers(const Expr *E) {
+  if (const auto *T = dyn_cast(E))
+return ignoreTemporariesAndPointers(T->getSubExpr());
+
+  const Expr *F = 

r374443 - [MSVC] Automatically add atlmfc folder to include and libpath.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Oct 10 13:25:54 2019
New Revision: 374443

URL: http://llvm.org/viewvc/llvm-project?rev=374443=rev
Log:
[MSVC] Automatically add atlmfc folder to include and libpath.

Differential Revision: https://reviews.llvm.org/D68736

Modified:
cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
cfe/trunk/lib/Driver/ToolChains/MSVC.h

Modified: cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MSVC.cpp?rev=374443=374442=374443=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MSVC.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/MSVC.cpp Thu Oct 10 13:25:54 2019
@@ -331,6 +331,11 @@ void visualstudio::Linker::ConstructJob(
 TC.getSubDirectoryPath(
 toolchains::MSVCToolChain::SubDirectoryType::Lib)));
 
+CmdArgs.push_back(Args.MakeArgString(
+Twine("-libpath:") +
+
TC.getSubDirectoryPath(toolchains::MSVCToolChain::SubDirectoryType::Lib,
+   "atlmfc")));
+
 if (TC.useUniversalCRT()) {
   std::string UniversalCRTLibPath;
   if (TC.getUniversalCRTLibraryPath(UniversalCRTLibPath))
@@ -548,7 +553,7 @@ void visualstudio::Linker::ConstructJob(
   EnvVar.substr(0, PrefixLen) +
   TC.getSubDirectoryPath(SubDirectoryType::Bin) +
   llvm::Twine(llvm::sys::EnvPathSeparator) +
-  TC.getSubDirectoryPath(SubDirectoryType::Bin, HostArch) +
+  TC.getSubDirectoryPath(SubDirectoryType::Bin, "", HostArch) +
   (EnvVar.size() > PrefixLen
? llvm::Twine(llvm::sys::EnvPathSeparator) +
  EnvVar.substr(PrefixLen)
@@ -824,6 +829,7 @@ static const char *llvmArchToDevDivInter
 // of hardcoding paths.
 std::string
 MSVCToolChain::getSubDirectoryPath(SubDirectoryType Type,
+   llvm::StringRef SubdirParent,
llvm::Triple::ArchType TargetArch) const {
   const char *SubdirName;
   const char *IncludeName;
@@ -843,6 +849,9 @@ MSVCToolChain::getSubDirectoryPath(SubDi
   }
 
   llvm::SmallString<256> Path(VCToolChainPath);
+  if (!SubdirParent.empty())
+llvm::sys::path::append(Path, SubdirParent);
+
   switch (Type) {
   case SubDirectoryType::Bin:
 if (VSLayout == ToolsetLayout::VS2017OrNewer) {
@@ -1228,6 +1237,8 @@ void MSVCToolChain::AddClangSystemInclud
   if (!VCToolChainPath.empty()) {
 addSystemInclude(DriverArgs, CC1Args,
  getSubDirectoryPath(SubDirectoryType::Include));
+addSystemInclude(DriverArgs, CC1Args,
+ getSubDirectoryPath(SubDirectoryType::Include, "atlmfc"));
 
 if (useUniversalCRT()) {
   std::string UniversalCRTSdkPath;

Modified: cfe/trunk/lib/Driver/ToolChains/MSVC.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MSVC.h?rev=374443=374442=374443=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MSVC.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/MSVC.h Thu Oct 10 13:25:54 2019
@@ -98,12 +98,14 @@ public:
 Lib,
   };
   std::string getSubDirectoryPath(SubDirectoryType Type,
+  llvm::StringRef SubdirParent,
   llvm::Triple::ArchType TargetArch) const;
 
   // Convenience overload.
   // Uses the current target arch.
-  std::string getSubDirectoryPath(SubDirectoryType Type) const {
-return getSubDirectoryPath(Type, getArch());
+  std::string getSubDirectoryPath(SubDirectoryType Type,
+  llvm::StringRef SubdirParent = "") const {
+return getSubDirectoryPath(Type, SubdirParent, getArch());
   }
 
   enum class ToolsetLayout {


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56393: [DebugInfo] Don't emit DW_AT_enum_class unless it's actually an 'enum class'.

[Zachary Turner via cfe-commits]

PDB/CodeView doesn’t doesn’t distinguish between various flavors of enums
On Mon, Jan 7, 2019 at 8:14 AM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson created this revision.
> probinson added reviewers: dblaikie, rnk, zturner.
> probinson added a project: debug-info.
> Herald added subscribers: cfe-commits, JDevlieghere, aprantl.
>
> The original fix for PR36168 would emit DW_AT_enum_class for both of these
> cases:
>
> enum Fixed : short { F1  = 1 };
> enum class Class { C1 = 1 };
>
> However, it really should be applied only to the latter case.
>
> I'd just do this, except I'm not sure whether PDB cares about this
> difference.  If it does, let me know and I guess we'll have to invent a new
> flag so the DWARF and PDB generators can each DTRT.
>
> If not, I'll follow up with NFC name changes so the flag becomes
> DIFlagEnumClass.
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D56393
>
> Files:
>   clang/lib/CodeGen/CGDebugInfo.cpp
>   clang/test/CodeGenCXX/debug-info-enum-class.cpp
>
>
> Index: clang/test/CodeGenCXX/debug-info-enum-class.cpp
> ===
> --- clang/test/CodeGenCXX/debug-info-enum-class.cpp
> +++ clang/test/CodeGenCXX/debug-info-enum-class.cpp
> @@ -52,6 +52,7 @@
>  // FIXME: this should just be a declaration under -fno-standalone-debug
>  // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
>  // CHECK-SAME: scope: [[TEST2:![0-9]+]]
> +// CHECK-NOT:  DIFlagFixedEnum
>  // CHECK-SAME: elements: [[TEST_ENUMS:![0-9]+]]
>  // CHECK-SAME: identifier: "_ZTSN5test21EE"
>  // CHECK: [[TEST2]] = !DINamespace(name: "test2"
> @@ -67,6 +68,7 @@
>  // FIXME: this should just be a declaration under -fno-standalone-debug
>  // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
>  // CHECK-SAME: scope: [[TEST3:![0-9]+]]
> +// CHECK-NOT:  DIFlagFixedEnum
>  // CHECK-SAME: elements: [[TEST_ENUMS]]
>  // CHECK-SAME: identifier: "_ZTSN5test31EE"
>  // CHECK: [[TEST3]] = !DINamespace(name: "test3"
> @@ -78,6 +80,7 @@
>  namespace test4 {
>  // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
>  // CHECK-SAME: scope: [[TEST4:![0-9]+]]
> +// CHECK-NOT:  DIFlagFixedEnum
>  // CHECK-SAME: elements: [[TEST_ENUMS]]
>  // CHECK-SAME: identifier: "_ZTSN5test41EE"
>  // CHECK: [[TEST4]] = !DINamespace(name: "test4"
> Index: clang/lib/CodeGen/CGDebugInfo.cpp
> ===
> --- clang/lib/CodeGen/CGDebugInfo.cpp
> +++ clang/lib/CodeGen/CGDebugInfo.cpp
> @@ -2711,7 +2711,7 @@
>llvm::DIType *ClassTy = getOrCreateType(ED->getIntegerType(), DefUnit);
>return DBuilder.createEnumerationType(EnumContext, ED->getName(),
> DefUnit,
>  Line, Size, Align, EltArray,
> ClassTy,
> -Identifier, ED->isFixed());
> +Identifier, ED->isScoped());
>  }
>
>  llvm::DIMacro *CGDebugInfo::CreateMacro(llvm::DIMacroFile *Parent,
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r348176 - Fix compilation failure on Windows.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Dec  3 11:59:00 2018
New Revision: 348176

URL: http://llvm.org/viewvc/llvm-project?rev=348176=rev
Log:
Fix compilation failure on Windows.

This was introduced earlier but apparently used an incorrect
class name so it doesn't compile on Windows.

Modified:
clang-tools-extra/trunk/clangd/FSProvider.cpp

Modified: clang-tools-extra/trunk/clangd/FSProvider.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/FSProvider.cpp?rev=348176=348175=348176=diff
==
--- clang-tools-extra/trunk/clangd/FSProvider.cpp (original)
+++ clang-tools-extra/trunk/clangd/FSProvider.cpp Mon Dec  3 11:59:00 2018
@@ -76,7 +76,7 @@ clang::clangd::RealFileSystemProvider::g
 // FIXME: Try to use a similar approach in Sema instead of relying on
 //propagation of the 'isVolatile' flag through all layers.
 #ifdef _WIN32
-  return new VolatileFSProvider(vfs::getRealFileSystem());
+  return new VolatileFileSystem(vfs::getRealFileSystem());
 #else
   return vfs::getRealFileSystem();
 #endif


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D54995: [MemoryBuffer] Add the setter to be able to force disabled mmap

[Zachary Turner via cfe-commits]

I don’t think we really need this. isn’t Ilya’s solution in the other patch
already sufficient?
On Mon, Dec 3, 2018 at 7:34 AM Ivan Donchevskii via Phabricator <
revi...@reviews.llvm.org> wrote:

> yvvan added a comment.
>
> @ilya-biryukov
>
> Hm. What about another way around? - We have user include paths (-I) and
> report them to the filesystem. This means that we have specific paths under
> which nothing can be mmaped and everything else can be. In particular cases
> we can also report -isystem there. This is quite the same logic as current
> isVolatile parameter but is set only once for each path.
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D54995/new/
>
> https://reviews.llvm.org/D54995
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D54995: [MemoryBuffer] By default assume that all files are volatile to prevent unintended file locks

[Zachary Turner via cfe-commits]

If this is to go in (which I think is still not clear), it definitely
should be limited to clangd. Not using mapped files is an order of
magnitude performance regression for many use cases.
On Thu, Nov 29, 2018 at 3:15 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri added a comment.
>
> Passing-by thought, feel free to ignore: this seems to so far only affect
> windows only?
> So the fix shouldn't probably pessimize all other arches? (and maybe even
> non-clangd)
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D54995/new/
>
> https://reviews.llvm.org/D54995
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D54995: [MemoryBuffer] By default assume that all files are volatile to prevent unintended file locks

[Zachary Turner via cfe-commits]

Do you all have Windows machines? The easiest thing to do is just write a
sample program that mmaps a file and then tries to delete it, iterating
over every possible set of flags.
On Wed, Nov 28, 2018 at 7:25 AM Ivan Donchevskii via Phabricator <
revi...@reviews.llvm.org> wrote:

> yvvan added a comment.
>
> @ilya-biryukov
>
> According to https://stackoverflow.com/a/7414798 (if it's true) we can't
> prevent locks.
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D54995/new/
>
> https://reviews.llvm.org/D54995
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D54995: [MemoryBuffer] By default assume that all files are volatile to prevent unintended file locks

[Zachary Turner via cfe-commits]

I’m afraid this is going to be too severe a performance regression if we
change the default. So I don’t think this should be an LLVM-wide default
On Wed, Nov 28, 2018 at 1:38 AM Ivan Donchevskii via Phabricator <
revi...@reviews.llvm.org> wrote:

> yvvan added a comment.
>
> @ilya-biryukov
>
> I have the reported evidence but didn't yet have time to investigate
> myself.
> This is probably caused by our upgrade to Clang-7 which shows that we
> can't rely on the aimed fixes like the one I mention (D47460 <
> https://reviews.llvm.org/D47460>).
>
> Another option that I can suggest here is to remove all default isVolatile
> values at all, track all callers and specify the proper value in each case
> (ideally depending on the current flags). What do you think?
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D54995/new/
>
> https://reviews.llvm.org/D54995
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r347216 - Fix some issues with LLDB's lit configuration files.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Nov 19 07:12:34 2018
New Revision: 347216

URL: http://llvm.org/viewvc/llvm-project?rev=347216=rev
Log:
Fix some issues with LLDB's lit configuration files.

Recently I tried to port LLDB's lit configuration files over to use a
on the surface, but broke some cases that weren't broken before and also
exposed some additional problems with the old approach that we were just
getting lucky with.

When we set up a lit environment, the goal is to make it as hermetic as
possible. We should not be relying on PATH and enabling the use of
arbitrary shell commands. Instead, only whitelisted commands should be
allowed. These are, generally speaking, the lit builtins such as echo,
cd, etc, as well as anything for which substitutions have been
explicitly set up for. These substitutions should map to the build
output directory, but in some cases it's useful to be able to override
this (for example to point to an installed tools directory).

This is, of course, how it's supposed to work. What was actually
happening is that we were bringing in PATH and LD_LIBRARY_PATH and then
just running the given run line as a shell command. This led to problems
such as finding the wrong version of clang-cl on PATH since it wasn't
even a substitution, and flakiness / non-determinism since the
environment the tests were running in would change per-machine. On the
other hand, it also made other things possible. For example, we had some
tests that were explicitly running cl.exe and link.exe instead of
clang-cl and lld-link and the only reason it worked at all is because it
was finding them on PATH. Unfortunately we can't entirely get rid of
these tests, because they support a few things in debug info that
clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record
which makes some of the tests fail.

The high level changes introduced in this patch are:

1. Removal of functionality - The lit test suite no longer respects
   LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no
   more support for gcc, but nobody was using this anyway (note: The
   functionality is still there for the dotest suite, just not the lit test
   suite). There is no longer a single substitution %cxx and %cc which maps
   to , you now explicitly specify the compiler with a
   substitution like %clang or %clangxx or %clang_cl. We can revisit this
   in the future when someone needs gcc.

2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit
   what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now
   more friendly. If this is not specified, all tools are expected to be
   the just-built tools. If it is specified, the tools which are not
   themselves being tested but are being used to construct and run checks
   (e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this
   directory first, then the build output directory.

3. Changes to core llvm lit files. The use_lld() and use_clang()
   functions were introduced long ago in anticipation of using them in
   lldb, but since they were never actually used anywhere but their
   respective problems, there were some issues to be resolved regarding
   generality and ability to use them outside their project.

4. Changes to .test files - These are all just replacing things like
   clang-cl with %clang_cl and %cxx with %clangxx, etc.

5. Changes to lit.cfg.py - Previously we would load up some system
   environment variables and then add some new things to them. Then do a
   bunch of work building out our own substitutions. First, we delete the
   system environment variable code, making the environment hermetic. Then,
   we refactor the substitution logic into two separate helper functions,
   one which sets up substitutions for the tools we want to test (which
   must come from the build output directory), and another which sets up
   substitutions for support tools (like compilers, etc).

6. New substitutions for MSVC -- Previously we relied on location of
   MSVC by bringing in the entire parent's PATH and letting
   subprocess.Popen just run the command line. Now we set up real
   substitutions that should have the same effect. We use PATH to find
   them, and then look for INCLUDE and LIB to construct a substitution
   command line with appropriate /I and /LIBPATH: arguments. The nice thing
   about this is that it opens the door to having separate %msvc-cl32 and
   %msvc-cl64 substitutions, rather than only requiring the user to run
   vcvars first. Because we can deduce the path to 32-bit libraries from
   64-bit library directories, and vice versa. Without these substitutions
   this would have been impossible.

Differential Revision: https://reviews.llvm.org/D54567

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=347216=347215=347216=diff
==

Re: [PATCH] D54405: Record whether a AST Matcher constructs a Node

[Zachary Turner via cfe-commits]

I don’t really have much more to add here except to refer you to the style
guide:

https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable

Specifically this line: “Use auto if and only if it makes the code more
readable or easier to maintain.”

Given that 2 out of 2 reviewers who have looked at this have said it did
not make the code more readable or easier to maintain for them , and have
further said that they feel the return type is not “obvious from the
context”, i do not believe this usage fits within our style guidelines.

I don’t think it’s worth beating on this anymore though, because this is a
lot of back and forth over something that doesn’t actually merit this much
discussion. So in the interest of conforming to the style guide above,
please remove auto and then start a thread on llvm-dev if you disagree with
the policy
On Tue, Nov 13, 2018 at 1:57 AM Stephen Kelly via Phabricator <
revi...@reviews.llvm.org> wrote:

> steveire added inline comments.
>
>
> 
> Comment at: lib/ASTMatchers/Dynamic/Registry.cpp:77
> +  internal::MatcherDescriptor *matchDescriptor, StringRef
> MatcherName) {
> +auto K = ast_type_traits::ASTNodeKind::getFromNodeKind<
> +typename
> ast_matchers::internal::VariadicAllOfMatcher::Type>();
> 
> zturner wrote:
> > steveire wrote:
> > > aaron.ballman wrote:
> > > > zturner wrote:
> > > > > steveire wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > steveire wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > Mildly not keen on the use of `auto` here. It's a factory
> function, so it kind of names the resulting type, but it also looks like
> the type will be
> `ast_matchers::internal::VariadicAllOfMatcher::Type` from the
> template argument, which is incorrect.
> > > > > > > > There is no reason to assume that taking a template argument
> means that type is result.
> > > > > > > >
> > > > > > > > The method is `getFrom` which decreases the ambiguity still
> further.
> > > > > > > >
> > > > > > > > Spelling out the type doesn't add anything useful. This
> should be ok.
> > > > > > > > There is no reason to assume that taking a template argument
> means that type is result.
> > > > > > >
> > > > > > > Aside from all the other places that do exactly that (getAs<>,
> cast<>, dyn_cast<>, castAs<>, and so on). Generally, when we have a
> function named get that takes a template type argument, the result when
> seen in proximity to auto is the template type.
> > > > > > >
> > > > > > > > Spelling out the type doesn't add anything useful. This
> should be ok.
> > > > > > >
> > > > > > > I slept on this one and fall on the other side of it; using
> auto hides information that tripped up at least one person when reading the
> code, so don't use auto. It's not clear enough what the resulting type will
> be.
> > > > > > I put this in the category of requiring
> > > > > >
> > > > > > SomeType ST = SomeType::create();
> > > > > >
> > > > > > instead of
> > > > > >
> > > > > > auto ST = SomeType::create();
> > > > > >
> > > > > > `ast_type_traits::ASTNodeKind` is already on that line and you
> want to see it again.
> > > > > >
> > > > > FWIW I'm with Aaron here.  Im' not familiar at all with this
> codebase, and looking at the code, my first instinct is "the result type is
> probably `ast_matchers::internal::VariadicAllOfMatcher::Type`".
> According to Aaron's earlier comment, that is incorrect, so there's at
> least 1 data point that it hinders readability.
> > > > >
> > > > > So, honest question.  What *is* the return type here?
> > > > > So, honest question. What *is* the return type here?
> > > >
> > > > Much to my surprise, it's `ASTNodeKind`. It was entirely unobvious
> to me that this was a factory function.
> > > @zturner Quoting myself:
> > >
> > > > `ast_type_traits::ASTNodeKind` is already on that line and you want
> to see it again.
> > >
> > > The expression is `getFromNodeKind`. There is a pattern of
> `SomeType::fromFooKind()` returning a `SomeType`. This is not so
> unusual.
> > >
> > >
> > Note that at the top of this file there's already a `using namespace
> clang::ast_type_traits;`  So if you're worried about verbosity, then you
> can remove the `ast_type_traits::`, remove the `auto`, and the net effect
> is that the overall line will end up being shorter.
> The funny thing is - if you see a line like
>
> Parser CodeParser = Parser::getFromArgs(Args);
>
> you have no idea what type `Parser` is!
>
> To start, it could be `clang::Parser` or
> `clang::ast_matchers::dynamic::Parser`, depending on a `using namespace`
> which might appear any distance up in the file. It is not uncommon for
> clang files to be thousands of lines lone.
>
> Or it could be inside a template with `template`, or
> there could be a `using Parser = Foo;` any distance up in the file.
>
> Parser CodeParser = Parser::getFromArgs(Args);
>
> is no more helpful than
>
> auto CodeParser = 

Re: [PATCH] D53066: [Driver] Use forward slashes in most linker arguments

[Zachary Turner via cfe-commits]

It seems like some combination of checking the target triple, host triple,
and driver mode and putting the conversions behind those checks could work?

For paths like resource dir that are going into debug info it should be
driver mode. For paths we pass to another tool it should probably be based
on target triple . This probably isn’t perfect, but WDYT?
On Wed, Oct 24, 2018 at 12:16 AM Martin Storsjö via Phabricator <
revi...@reviews.llvm.org> wrote:

> mstorsjo added inline comments.
>
>
> 
> Comment at: lib/Driver/Driver.cpp:1013-1014
>}
> +  for (auto *Str : {, , , ,
> })
> +*Str = llvm::sys::path::convert_to_slash(*Str);
>
> 
> rnk wrote:
> > zturner wrote:
> > > Is this going to affect the cl driver as well?
> > Yeah, if we change the resource dir, I think it's going to have knock-on
> affects to the debug info we emit to describe the locations of compiler
> intrinsic headers. I was imagining that this would be limited to flags
> which only get passed to GNU-ld-compatible linkers.
> Well, the first minimal version that was committed in rL345004 was enough
> to produce paths that worked with libtool, but I guess that one also would
> cause some amount of changes for the cl driver.
>
> Now in order for all the tests to pass, I had to change (almost) all of
> these as I have here. (After rechecking, I think I can spare one or two of
> them.)
>
> But I do have to touch ResourceDir for
> test/Driver/linux-per-target-runtime-dir.c to pass, since it requires that
> a `-resource-dir` parameter matches a later `-L` linker flag, and I do need
> to change the `-L` linker flag for the libtool case.
>
> So I guess it's back to the drawing board with this change then. What do
> you guys think is the path of least impact on e.g. the cl driver and PDB
> generation in general (and least messy scattered rewrites), without
> breaking a bunch of tests (e.g. test/Driver/linux-ld.c requires the
> `--sysroot` parameter to match `-L`), while still getting libtool
> compatible paths with forward slashes out of `-v`. At least when targeting
> mingw, but maybe ideally for any non-msvc target? For cross compiling for a
> linux target from windows, I would guess forward slashes would be preferred
> as well.
>
>
> https://reviews.llvm.org/D53066
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r344362 - Fix one additional test broken by the YAML quoting change.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct 12 09:41:37 2018
New Revision: 344362

URL: http://llvm.org/viewvc/llvm-project?rev=344362=rev
Log:
Fix one additional test broken by the YAML quoting change.

Modified:
clang-tools-extra/trunk/test/include-fixer/merge.test

Modified: clang-tools-extra/trunk/test/include-fixer/merge.test
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/include-fixer/merge.test?rev=344362=344361=344362=diff
==
--- clang-tools-extra/trunk/test/include-fixer/merge.test (original)
+++ clang-tools-extra/trunk/test/include-fixer/merge.test Fri Oct 12 09:41:37 
2018
@@ -6,7 +6,7 @@ Name:bar
 Contexts:
   - ContextType: Namespace
 ContextName: a
-FilePath:../include/bar.h
+FilePath:'../include/bar.h'
 Type:Class
 Seen:1
 Used:1
@@ -16,7 +16,7 @@ Name:bar
 Contexts:
   - ContextType: Namespace
 ContextName: a
-FilePath:../include/barbar.h
+FilePath:'../include/barbar.h'
 Type:Class
 Seen:1
 Used:0


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r344359 - Make YAML quote forward slashes.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct 12 09:31:20 2018
New Revision: 344359

URL: http://llvm.org/viewvc/llvm-project?rev=344359=rev
Log:
Make YAML quote forward slashes.

If you have the string /usr/bin, prior to this patch it would not
be quoted by our YAML serializer.  But a string like C:\src would
be, due to the presence of a backslash.  This makes the quoting
rules of basically every single file path different depending on
the path syntax (posix vs. Windows).

While technically not required by the YAML specification to quote
forward slashes, when the behavior of paths is inconsistent it
makes it difficult to portably write FileCheck lines that will
work with either kind of path.

Differential Revision: https://reviews.llvm.org/D53169

Modified:
cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp
cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp

Modified: cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp?rev=344359=344358=344359=diff
==
--- cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp Fri Oct 12 09:31:20 2018
@@ -58,30 +58,30 @@ TEST(DiagnosticsYamlTest, serializesDiag
   YAML << TUD;
 
   EXPECT_EQ("---\n"
-"MainSourceFile:  path/to/source.cpp\n"
+"MainSourceFile:  'path/to/source.cpp'\n"
 "Diagnostics: \n"
 "  - DiagnosticName:  'diagnostic#1\'\n"
 "Message: 'message #1'\n"
 "FileOffset:  55\n"
-"FilePath:path/to/source.cpp\n"
+"FilePath:'path/to/source.cpp'\n"
 "Replacements:\n"
-"  - FilePath:path/to/source.cpp\n"
+"  - FilePath:'path/to/source.cpp'\n"
 "Offset:  100\n"
 "Length:  12\n"
 "ReplacementText: 'replacement #1'\n"
 "  - DiagnosticName:  'diagnostic#2'\n"
 "Message: 'message #2'\n"
 "FileOffset:  60\n"
-"FilePath:path/to/header.h\n"
+"FilePath:'path/to/header.h'\n"
 "Replacements:\n"
-"  - FilePath:path/to/header.h\n"
+"  - FilePath:'path/to/header.h'\n"
 "Offset:  62\n"
 "Length:  2\n"
 "ReplacementText: 'replacement #2'\n"
 "  - DiagnosticName:  'diagnostic#3'\n"
 "Message: 'message #3'\n"
 "FileOffset:  72\n"
-"FilePath:path/to/source2.cpp\n"
+"FilePath:'path/to/source2.cpp'\n"
 "Replacements:\n"
 "...\n",
 YamlContentStream.str());

Modified: cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp?rev=344359=344358=344359=diff
==
--- cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp Fri Oct 12 09:31:20 
2018
@@ -33,13 +33,13 @@ TEST(ReplacementsYamlTest, serializesRep
 
   // NOTE: If this test starts to fail for no obvious reason, check whitespace.
   ASSERT_STREQ("---\n"
-   "MainSourceFile:  /path/to/source.cpp\n"
+   "MainSourceFile:  '/path/to/source.cpp'\n"
"Replacements:\n" // Extra whitespace here!
-   "  - FilePath:/path/to/file1.h\n"
+   "  - FilePath:'/path/to/file1.h'\n"
"Offset:  232\n"
"Length:  56\n"
"ReplacementText: 'replacement #1'\n"
-   "  - FilePath:/path/to/file2.h\n"
+   "  - FilePath:'/path/to/file2.h'\n"
"Offset:  301\n"
"Length:  2\n"
"ReplacementText: 'replacement #2'\n"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r344358 - Revert "Make YAML quote forward slashes."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct 12 09:31:08 2018
New Revision: 344358

URL: http://llvm.org/viewvc/llvm-project?rev=344358=rev
Log:
Revert "Make YAML quote forward slashes."

This reverts commit b86c16ad8c97dadc1f529da72a5bb74e9eaed344.

This is being reverted because I forgot to write a useful
commit message, so I'm going to resubmit it with an actual
commit message.

Modified:
cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp
cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp

Modified: cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp?rev=344358=344357=344358=diff
==
--- cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp Fri Oct 12 09:31:08 2018
@@ -58,30 +58,30 @@ TEST(DiagnosticsYamlTest, serializesDiag
   YAML << TUD;
 
   EXPECT_EQ("---\n"
-"MainSourceFile:  'path/to/source.cpp'\n"
+"MainSourceFile:  path/to/source.cpp\n"
 "Diagnostics: \n"
 "  - DiagnosticName:  'diagnostic#1\'\n"
 "Message: 'message #1'\n"
 "FileOffset:  55\n"
-"FilePath:'path/to/source.cpp'\n"
+"FilePath:path/to/source.cpp\n"
 "Replacements:\n"
-"  - FilePath:'path/to/source.cpp'\n"
+"  - FilePath:path/to/source.cpp\n"
 "Offset:  100\n"
 "Length:  12\n"
 "ReplacementText: 'replacement #1'\n"
 "  - DiagnosticName:  'diagnostic#2'\n"
 "Message: 'message #2'\n"
 "FileOffset:  60\n"
-"FilePath:'path/to/header.h'\n"
+"FilePath:path/to/header.h\n"
 "Replacements:\n"
-"  - FilePath:'path/to/header.h'\n"
+"  - FilePath:path/to/header.h\n"
 "Offset:  62\n"
 "Length:  2\n"
 "ReplacementText: 'replacement #2'\n"
 "  - DiagnosticName:  'diagnostic#3'\n"
 "Message: 'message #3'\n"
 "FileOffset:  72\n"
-"FilePath:'path/to/source2.cpp'\n"
+"FilePath:path/to/source2.cpp\n"
 "Replacements:\n"
 "...\n",
 YamlContentStream.str());

Modified: cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp?rev=344358=344357=344358=diff
==
--- cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp Fri Oct 12 09:31:08 
2018
@@ -33,13 +33,13 @@ TEST(ReplacementsYamlTest, serializesRep
 
   // NOTE: If this test starts to fail for no obvious reason, check whitespace.
   ASSERT_STREQ("---\n"
-   "MainSourceFile:  '/path/to/source.cpp'\n"
+   "MainSourceFile:  /path/to/source.cpp\n"
"Replacements:\n" // Extra whitespace here!
-   "  - FilePath:'/path/to/file1.h'\n"
+   "  - FilePath:/path/to/file1.h\n"
"Offset:  232\n"
"Length:  56\n"
"ReplacementText: 'replacement #1'\n"
-   "  - FilePath:'/path/to/file2.h'\n"
+   "  - FilePath:/path/to/file2.h\n"
"Offset:  301\n"
"Length:  2\n"
"ReplacementText: 'replacement #2'\n"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r344357 - Make YAML quote forward slashes.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct 12 09:24:09 2018
New Revision: 344357

URL: http://llvm.org/viewvc/llvm-project?rev=344357=rev
Log:
Make YAML quote forward slashes.

Modified:
cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp
cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp

Modified: cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp?rev=344357=344356=344357=diff
==
--- cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/DiagnosticsYamlTest.cpp Fri Oct 12 09:24:09 2018
@@ -58,30 +58,30 @@ TEST(DiagnosticsYamlTest, serializesDiag
   YAML << TUD;
 
   EXPECT_EQ("---\n"
-"MainSourceFile:  path/to/source.cpp\n"
+"MainSourceFile:  'path/to/source.cpp'\n"
 "Diagnostics: \n"
 "  - DiagnosticName:  'diagnostic#1\'\n"
 "Message: 'message #1'\n"
 "FileOffset:  55\n"
-"FilePath:path/to/source.cpp\n"
+"FilePath:'path/to/source.cpp'\n"
 "Replacements:\n"
-"  - FilePath:path/to/source.cpp\n"
+"  - FilePath:'path/to/source.cpp'\n"
 "Offset:  100\n"
 "Length:  12\n"
 "ReplacementText: 'replacement #1'\n"
 "  - DiagnosticName:  'diagnostic#2'\n"
 "Message: 'message #2'\n"
 "FileOffset:  60\n"
-"FilePath:path/to/header.h\n"
+"FilePath:'path/to/header.h'\n"
 "Replacements:\n"
-"  - FilePath:path/to/header.h\n"
+"  - FilePath:'path/to/header.h'\n"
 "Offset:  62\n"
 "Length:  2\n"
 "ReplacementText: 'replacement #2'\n"
 "  - DiagnosticName:  'diagnostic#3'\n"
 "Message: 'message #3'\n"
 "FileOffset:  72\n"
-"FilePath:path/to/source2.cpp\n"
+"FilePath:'path/to/source2.cpp'\n"
 "Replacements:\n"
 "...\n",
 YamlContentStream.str());

Modified: cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp?rev=344357=344356=344357=diff
==
--- cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/ReplacementsYamlTest.cpp Fri Oct 12 09:24:09 
2018
@@ -33,13 +33,13 @@ TEST(ReplacementsYamlTest, serializesRep
 
   // NOTE: If this test starts to fail for no obvious reason, check whitespace.
   ASSERT_STREQ("---\n"
-   "MainSourceFile:  /path/to/source.cpp\n"
+   "MainSourceFile:  '/path/to/source.cpp'\n"
"Replacements:\n" // Extra whitespace here!
-   "  - FilePath:/path/to/file1.h\n"
+   "  - FilePath:'/path/to/file1.h'\n"
"Offset:  232\n"
"Length:  56\n"
"ReplacementText: 'replacement #1'\n"
-   "  - FilePath:/path/to/file2.h\n"
+   "  - FilePath:'/path/to/file2.h'\n"
"Offset:  301\n"
"Length:  2\n"
"ReplacementText: 'replacement #2'\n"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r280840 - Add a clang-tidy visual studio extension.

[Zachary Turner via cfe-commits]

Yea, that’s actually another reason I suggest trying the Clang Power Tools
extension. It seems to have “won” in this area, and few people ever used
the LLVM one to begin with.
On Wed, Oct 10, 2018 at 2:09 PM Aaron Ballman 
wrote:

> On Wed, Oct 10, 2018 at 4:54 PM Zachary Turner  wrote:
> >
> > Honestly I hadn’t thought about this ever since the patch. Out of
> curiosity, have you tried the clang power tools extension? I think it’s
> more actively maintained and at this point probably even is good enough
> that this one could just go away
>
> I've not tried either, truth be told. :-D This came up in GrammaTech
> while I was reviewing someone's clang-tidy check for upstreaming.
> Given how much I review clang-tidy checks on trunk, the fact that I
> hadn't heard of this file surprised me so I did some code archaeology
> and here we are. I don't have a strong opinion on whether this has
> been superseded or not, but I probably should know whether clang-tidy
> check authors are required to maintain this or not.
>
> Btw, I didn't see any bug reports about missing checks. In fact, the
> only bug report I can find for clang-tidy-vs suggests it may not even
> work. https://bugs.llvm.org/show_bug.cgi?id=34176
>
> ~Aaron
>
> > On Wed, Oct 10, 2018 at 1:52 PM Aaron Ballman 
> wrote:
> >>
> >> On Wed, Sep 7, 2016 at 2:37 PM Zachary Turner via cfe-commits
> >>  wrote:
> >> >
> >> > Author: zturner
> >> > Date: Wed Sep  7 13:28:55 2016
> >> > New Revision: 280840
> >> >
> >> > URL: http://llvm.org/viewvc/llvm-project?rev=280840=rev
> >> > Log:
> >> > Add a clang-tidy visual studio extension.
> >> >
> >> > For now this only adds the UI necessary to configure clang-tidy
> >> > settings graphically, and it enables reading in and saving out
> >> > of .clang-tidy files.  It does not actually run clang-tidy on
> >> > any source files yet.
> >>
> >> Sorry to resurrect an old commit, but this commit added the following:
> >>
> >> Added:
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> >> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml?rev=280840=auto
> >>
> ==
> >> ---
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> >> (added)
> >> +++
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> >> Wed Sep  7 13:28:55 2016
> >> @@ -0,0 +1,325 @@
> >> +---
> >> +Checks:
> >> +   # This file should be updated when new checks are added, and
> >> eventually we should
> >> +   # generate this file automatically from the .rst files in
> clang-tidy.
> >>
> >> However, as best I can tell, this file is not reliably updated and is
> >> currently *very* out of date (in fact, it's only been updated twice in
> >> two years). You had mentioned in the review thread that you wanted to
> >> think of a way to automate this from RST
> >> (https://reviews.llvm.org/D23848?id=69168#inline-204743) -- any chance
> >> you're still thinking on that and have a solution in mind? ;-)
> >>
> >> ~Aaron
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r280840 - Add a clang-tidy visual studio extension.

[Zachary Turner via cfe-commits]

Honestly I hadn’t thought about this ever since the patch. Out of
curiosity, have you tried the clang power tools extension? I think it’s
more actively maintained and at this point probably even is good enough
that this one could just go away
On Wed, Oct 10, 2018 at 1:52 PM Aaron Ballman 
wrote:

> On Wed, Sep 7, 2016 at 2:37 PM Zachary Turner via cfe-commits
>  wrote:
> >
> > Author: zturner
> > Date: Wed Sep  7 13:28:55 2016
> > New Revision: 280840
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=280840=rev
> > Log:
> > Add a clang-tidy visual studio extension.
> >
> > For now this only adds the UI necessary to configure clang-tidy
> > settings graphically, and it enables reading in and saving out
> > of .clang-tidy files.  It does not actually run clang-tidy on
> > any source files yet.
>
> Sorry to resurrect an old commit, but this commit added the following:
>
> Added:
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml?rev=280840=auto
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> (added)
> +++
> clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/Resources/ClangTidyChecks.yaml
> Wed Sep  7 13:28:55 2016
> @@ -0,0 +1,325 @@
> +---
> +Checks:
> +   # This file should be updated when new checks are added, and
> eventually we should
> +   # generate this file automatically from the .rst files in clang-tidy.
>
> However, as best I can tell, this file is not reliably updated and is
> currently *very* out of date (in fact, it's only been updated twice in
> two years). You had mentioned in the review thread that you wanted to
> think of a way to automate this from RST
> (https://reviews.llvm.org/D23848?id=69168#inline-204743) -- any chance
> you're still thinking on that and have a solution in mind? ;-)
>
> ~Aaron
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D52193: RFC: [clang] Multithreaded compilation support

[Zachary Turner via cfe-commits]

I can try to get some timings from my machine.  How do we handle crash
recovery in the case where we don't spawn a child process?  I thought the
whole reason for spawning the cc1 driver as a separate process was so that
we could collect and report crash information in a nice way.  Not having
that seems like a heavy price to pay.

On Wed, Oct 10, 2018 at 11:34 AM Alexandre Ganea via Phabricator <
revi...@reviews.llvm.org> wrote:

> aganea added a comment.
>
> Updated tests again. This time I've closed all applications, all unused
> services, and tried to have a "clean" machine.
>
> New timings without the child `clang-cl.exe` being invoked (hacked from
> https://reviews.llvm.org/D52411). The test consists in building
> Clang+LLVM+LLD at r343846 using the compiler specified on each line of the
> table.
>
> **Config 1:** Intel Xeon Haswell 6 cores / 12 HW threads, 3.5 GHz, 15 MB
> cache, 128 GB RAM, SSD 550 MB/s (Windows 10 Fall Creators update 1709)
>
> __Ninja:__
>
> | MSVC 15.8.6 (cl + link)
>| 29 min 4 sec  |
> | clang-cl + lld-link 7.0 official release
> | 25 min 45 sec |
> | clang-cl + lld-link 8.0 r343846 //built with clang-cl 7.0 official//
> **(no child)** | **23 min 27 sec** |
> |
>
> **Config 2:** Intel Xeon Skylake 18 cores / 36 HW threads, x2 (Dual CPU),
> 72 HW threads total, 2.3 GHz, 24.75 MB cache each, 128 GB RAM, NVMe SSD 4.6
> GB/s (Windows 10 Fall Creators update 1709)
>
> __Ninja:__
>
> | MSVC 15.8.6 (cl + link)
>| 6 min 40 sec |
> | clang-cl + lld-link 7.0 official release
> | 6 min 24 sec |
> | clang-cl + lld-link 8.0 r343846 //built with clang-cl 7.0 official//
> **(no child)** | **5 min 10 sec** |
> |
>
> I'm wondering if the improvement is of the same order on Linux. I'd be
> interested to see your build times, out of curiosity? Can any of you try it
> with and without https://reviews.llvm.org/D52411?
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D52193
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D52998: [benchmark] Disable exceptions in Microsoft STL

[Zachary Turner via cfe-commits]

`_HAS_EXCEPTIONS=0` is an undocumented STL specific thing that the library
implementation uses to mean "don't write code that does `throw X;`, do
something else instead".

On Mon, Oct 8, 2018 at 2:27 PM Elizabeth Andrews via Phabricator <
revi...@reviews.llvm.org> wrote:

> eandrews added a comment.
>
> I do not think defining _HAS_EXCEPTIONS=0 affects C++ exceptions in the
> application. I thought it only affected the STL. I will verify this and
> update you.
>
>
> https://reviews.llvm.org/D52998
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D52773: clang-cl: Add /showFilenames option (PR31957)

[Zachary Turner via cfe-commits]

I agree magic environment variables are bad, but without it we don’t
address the only current actual use we have for this, which is making the
vs integration print filenames. Detecting compiler version from inside the
integration is hard, but with an environment variable it’s very easy to
solve.

I’m not against a flag as the supported way, but I think we should also
have some backdoor into this functionality, because if we’re not going to
satisfy the only known use case, then maybe it’s better to not even do it
at all.
On Thu, Oct 4, 2018 at 5:13 AM Hans Wennborg via Phabricator <
revi...@reviews.llvm.org> wrote:

> hans added a comment.
>
> In https://reviews.llvm.org/D52773#1252584, @zturner wrote:
>
> > Canyou add a test that demonstrates that multiple input files on the
> command line will print all of them?
>
>
> Will do.
>
> > Also does this really need to be a cc1 arg?  Why not just print it in
> the driver?
>
> Yeah, I'll give printing from the driver a try.
>
>
>
> 
> Comment at: include/clang/Driver/CLCompatOptions.td:163
> +  HelpText<"Print the name of each compiled file">,
> +  Alias;
>  def _SLASH_source_charset : CLCompileJoined<"source-charset:">,
> 
> thakis wrote:
> > Can you add /showFilenames- (a no-op) too, for symmetry?
> Will do. Actually not just a no-op, but the last option should win.
>
>
> 
> Comment at: lib/Driver/ToolChains/Clang.cpp:3533-3534
>CmdArgs.push_back(getBaseInputName(Args, Input));
> +  if (Arg *A = Args.getLastArg(options::OPT_echo_main_file_name))
> +A->render(Args, CmdArgs);
>
> 
> rnk wrote:
> > Is a -cc1 flag actually necessary? I was imagining we'd print it in the
> driver before we launch the compile job.
> Yeah, that's probably better, but will take a bit more work to keep track
> of if and what to print in the compile job. I'll give it a try.
>
>
> 
> Comment at: lib/Frontend/CompilerInvocation.cpp:792
>Opts.MainFileName = Args.getLastArgValue(OPT_main_file_name);
> +  if (Args.hasArg(OPT_echo_main_file_name))
> +llvm::outs() << Opts.MainFileName << "\n";
> 
> zturner wrote:
> > steveire wrote:
> > > zturner wrote:
> > > > zturner wrote:
> > > > > steveire wrote:
> > > > > > hans wrote:
> > > > > > > zturner wrote:
> > > > > > > > steveire wrote:
> > > > > > > > > I'll have to keep a patch around anyway for myself locally
> to remove this condition. But maybe someone else will benefit from this.
> > > > > > > > >
> > > > > > > > > What do you think about changing CMake to so that this is
> passed by default when using Clang-CL?
> > > > > > > > >
> > > > > > > > Do you mean llvms cmake?  Or cmake itself?  Which generator
> are you using?
> > > > > > > Can't you just configure your build to pass the flag to
> clang-cl?
> > > > > > >
> > > > > > > I suppose CMake could be made to do that by default when using
> clang-cl versions that support the flag and using the MSBuild generator,
> but that's for the CMake community to decide I think. Or perhaps our VS
> integration could do that, but it gets tricky because it needs to know
> whether the flag is supported or not.
> > > > > > I mean upstream cmake. My suggestion is independent of the
> generator, but it would depend on what Brad decides anyway. I don't intend
> to implement it, just report it.
> > > > > >
> > > > > > I only have one clang but I have multiple buildsystems, and I
> don't want to have to add a new flag too all of them. In each toplevel
> CMakeLists everyone will need this to make use of the flag:
> > > > > >
> > > > > > ```
> > > > > >
> > > > > > # Have to remember to use "${CMAKE_CXX_SIMULATE_ID}" instead of
> > > > > > # Undecorated "CMAKE_CXX_SIMULATE_ID" because there is a
> > > > > > # variable named "MSVC" and
> > > > > > # the way CMake variables and the "if()" command work requires
> this.
> > > > > > if (CMAKE_CXX_COMPILER_ID STREQUAL Clang
> > > > > > AND ${CMAKE_CXX_SIMULATE_ID} STREQUAL MSVC)
> > > > > > # CMake does not have explicit Clang-CL support yet.
> > > > > > # It should have a COMPILER_ID for it.
> > > > > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /showFilename")
> > > > > > # etc
> > > > > > endif()
> > > > > > ```
> > > > > >
> > > > > > Upstream CMake can have the logic to add the flag instead.
> > > > > But then what if you don’t want it?  There would be no way to turn
> it off.  I don’t think it’s a good fit for cmake
> > > > Yes, and actually for this reason i was wondering if we can do it
> without a flag at all.  What if we just set an magic environment variable?
> It handles Stephen’s use case (he can just set it globally), and MSBuild
> (we can set it in the extension).
> > > > But then what if you don’t want it? There would be no way to turn it
> off.
> > >
> > > Oh, I thought that the last flag would dominate. ie, if cmake
> generated `/showFilename` and the user adds `/showFilename-`, then you
> would end up with
> > >
> > 

r343629 - [cl-compat] Change /JMC from unsupported to ignored.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Tue Oct  2 13:42:36 2018
New Revision: 343629

URL: http://llvm.org/viewvc/llvm-project?rev=343629=rev
Log:
[cl-compat] Change /JMC from unsupported to ignored.

A tracking bug for actually implementing this in clang-cl is at
https://bugs.llvm.org/show_bug.cgi?id=39156.

Differential Revision: https://reviews.llvm.org/D52798

Modified:
cfe/trunk/include/clang/Driver/CLCompatOptions.td

Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=343629=343628=343629=diff
==
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Tue Oct  2 13:42:36 2018
@@ -354,6 +354,7 @@ def _SLASH_errorReport : CLIgnoredJoined
 def _SLASH_FC : CLIgnoredFlag<"FC">;
 def _SLASH_Fd : CLIgnoredJoined<"Fd">;
 def _SLASH_FS : CLIgnoredFlag<"FS">;
+def _SLASH_JMC : CLIgnoredFlag<"JMC">;
 def _SLASH_kernel_ : CLIgnoredFlag<"kernel-">;
 def _SLASH_nologo : CLIgnoredFlag<"nologo">;
 def _SLASH_openmp_ : CLIgnoredFlag<"openmp-">;
@@ -405,7 +406,6 @@ def _SLASH_GZ : CLFlag<"GZ">;
 def _SLASH_H : CLFlag<"H">;
 def _SLASH_homeparams : CLFlag<"homeparams">;
 def _SLASH_hotpatch : CLFlag<"hotpatch">;
-def _SLASH_JMC : CLFlag<"JMC">;
 def _SLASH_kernel : CLFlag<"kernel">;
 def _SLASH_LN : CLFlag<"LN">;
 def _SLASH_MP : CLJoined<"MP">;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r342668 - Add testcases for r342667.

[Zachary Turner via cfe-commits]

Test removed in r342693.

On Thu, Sep 20, 2018 at 3:30 PM Jorge Gorbe Moya  wrote:

> Zach and I were able to find the cause.
>
> Clang on Windows manages to find "file.h" when you #include "/file.h" and
> that makes the expected diagnostic not appear. MSVC inteprets an #include
> with a leading slash as an absolute path so I think we have accidentally
> hit a different bug in Clang :)
>
> One option to fix the test would be replacing the slash with another
> random non-alphanumeric character that can't be interpreted as a directory
> separator, but at that point I think we can just delete the failing test
> and rely on the existing include-likely-typo.c that tests with both leading
> and trailing non-alphanumeric characters.
>
> The other test in r342668 works because it includes a file that doesn't
> exist even if you interpret the path as relative so it should be OK to keep
> while the bug is found.
>
> I'll go find a bug about the behavior on windows. Thanks!
>
> Jorge
>
> On Thu, Sep 20, 2018 at 2:51 PM Eric Christopher 
> wrote:
>
>> FWIW we're trying to reproduce here real fast and then will revert or fix
>> real fast.
>>
>> Thanks!
>>
>> -eric
>>
>> On Thu, Sep 20, 2018 at 2:46 PM Eric Christopher 
>> wrote:
>>
>>> Adding Jorge...
>>>
>>> On Thu, Sep 20, 2018 at 2:36 PM  wrote:
>>>
 Hi Eric,

 The test that you added in this commit is failing on the PS4 Windows
 bot. Can you please take a look?


 http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20052

 FAIL: Clang :: Preprocessor/include-leading-nonalpha-suggest.c (10765
 of 43992)
  TEST 'Clang ::
 Preprocessor/include-leading-nonalpha-suggest.c' FAILED 
 
 Script:
 --
 : 'RUN: at line 1';
  
 c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.EXE
 -cc1 -internal-isystem
 c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\lib\clang\8.0.0\include
 -nostdsysteminc
 C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Preprocessor\include-leading-nonalpha-suggest.c
 -verify
 --
 Exit Code: 1

 Command Output (stdout):
 --
 $ ":" "RUN: at line 1"
 $
 "c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.EXE"
 "-cc1" "-internal-isystem"
 "c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\lib\clang\8.0.0\include"
 "-nostdsysteminc"
 "C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Preprocessor\include-leading-nonalpha-suggest.c"
 "-verify"
 # command stderr:
 error: 'error' diagnostics expected but not seen:

   File
 C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Preprocessor\include-leading-nonalpha-suggest.c
 Line 3: '/empty_file_to_include.h' file not found, did you mean
 'empty_file_to_include.h'?

 1 error generated.


 error: command failed with exit status: 1


>>> Oof. Thanks. If I don't have something in 10 minutes I'll just revert.
>>>
>>> Thanks!
>>>
>>> -eric
>>>
>>>
>>>
 Douglas Yung

 > -Original Message-
 > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On
 Behalf
 > Of Eric Christopher via cfe-commits
 > Sent: Thursday, September 20, 2018 10:23
 > To: cfe-commits@lists.llvm.org
 > Subject: r342668 - Add testcases for r342667.
 >
 > Author: echristo
 > Date: Thu Sep 20 10:22:43 2018
 > New Revision: 342668
 >
 > URL: http://llvm.org/viewvc/llvm-project?rev=342668=rev
 > Log:
 > Add testcases for r342667.
 >
 > Added:
 > cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-suggest.c
 > cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c
 >
 > Added: cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-
 > suggest.c
 > URL: http://llvm.org/viewvc/llvm-
 > project/cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-
 > suggest.c?rev=342668=auto
 >
 ===
 > ===
 > --- cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-suggest.c
 > (added)
 > +++ cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-suggest.c
 > Thu Sep 20 10:22:43 2018
 > @@ -0,0 +1,3 @@
 > +// RUN: %clang_cc1 %s -verify
 > +
 > +#include "/non_existing_file_to_include.h" // expected-error
 > {{'/non_existing_file_to_include.h' file not found}}
 >
 > Added: cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c
 > URL: http://llvm.org/viewvc/llvm-
 > project/cfe/trunk/test/Preprocessor/include-leading-nonalpha-
 > 

r342693 - Remove failing test.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 20 15:32:51 2018
New Revision: 342693

URL: http://llvm.org/viewvc/llvm-project?rev=342693=rev
Log:
Remove failing test.

Removing on behalf of Jorge Moya.  This test is broken on
Windows due to it actually being able to resolve the path.  There
is an actual Windows-specific bug somewhere, but we already have
sufficient test coverage of this with a different test, so removing
this was the approach suggested by Jorge.

Removed:
cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c

Removed: cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c?rev=342692=auto
==
--- cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c (original)
+++ cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c (removed)
@@ -1,3 +0,0 @@
-// RUN: %clang_cc1 %s -verify
-
-#include "/empty_file_to_include.h" // expected-error 
{{'/empty_file_to_include.h' file not found, did you mean 
'empty_file_to_include.h'?}}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D52193: RFC: [clang] Multithreaded compilation support

[Zachary Turner via cfe-commits]

In an ideal world yes, but the reality is that many people still use
MSBuild, and in that world /MP presumably helps quite a bit. And given that
many people already depend on this functionality of cl, it’s a potential
showstopper for migrating if we don’t support it. That said, if the benefit
isn’t significant that’s a stronger argument for not supporting it imo
On Tue, Sep 18, 2018 at 12:45 AM Hans Wennborg via Phabricator <
revi...@reviews.llvm.org> wrote:

> hans added a comment.
>
> In https://reviews.llvm.org/D52193#1237468, @zturner wrote:
>
> > What about the timings of clang-cl without /MP?
>
>
> And one using Ninja rather than msbuild.
>
> I think the real question is whether we want clang and clang-cl to do
> this. I'm not sure we do as it adds complexity for solving a problem that's
> better solved at the build system level.
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D52193
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D51847: Print correctly dependency paths on Windows

[Zachary Turner via cfe-commits]

Lgtm
On Wed, Sep 12, 2018 at 3:23 AM Dávid Bolvanský via Phabricator <
revi...@reviews.llvm.org> wrote:

> xbolva00 updated this revision to Diff 165052.
> xbolva00 added a comment.
>
> - Fixed failing test
>
>
> https://reviews.llvm.org/D51847
>
> Files:
>   lib/Frontend/DependencyFile.cpp
>   test/Frontend/dependency-gen-escaping.c
>
>
> Index: test/Frontend/dependency-gen-escaping.c
> ===
> --- test/Frontend/dependency-gen-escaping.c
> +++ test/Frontend/dependency-gen-escaping.c
> @@ -21,7 +21,7 @@
>  // Backslash followed by # or space should escape both characters, because
>  // that's what GNU Make wants.  GCC does the right thing with space, but
> not
>  // #, so Clang does too. (There should be 3 backslashes before the #.)
> -// SEP2F: a\b\\#c\\\ d.h
> +// SEP2F: a{{[/\\]}}b{{[/\\]}}\#c{{/|}}\ d.h
>  // With -fms-compatibility, Backslashes in #include are treated as path
> separators.
>  // Backslashes are given in the emission for special characters, like
> 0x20 or 0x23.
>  // SEP5C: a{{[/\\]}}b{{[/\\]}}\#c{{/|}}\ d.h
> Index: lib/Frontend/DependencyFile.cpp
> ===
> --- lib/Frontend/DependencyFile.cpp
> +++ lib/Frontend/DependencyFile.cpp
> @@ -386,28 +386,32 @@
>  /// for Windows file-naming info.
>  static void PrintFilename(raw_ostream , StringRef Filename,
>DependencyOutputFormat OutputFormat) {
> +  // Convert filename to platform native path
> +  llvm::SmallString<256> NativePath;
> +  llvm::sys::path::native(Filename.str(), NativePath);
> +
>if (OutputFormat == DependencyOutputFormat::NMake) {
>  // Add quotes if needed. These are the characters listed as "special"
> to
>  // NMake, that are legal in a Windows filespec, and that could cause
>  // misinterpretation of the dependency string.
> -if (Filename.find_first_of(" #${}^!") != StringRef::npos)
> -  OS << '\"' << Filename << '\"';
> +if (NativePath.find_first_of(" #${}^!") != StringRef::npos)
> +  OS << '\"' << NativePath << '\"';
>  else
> -  OS << Filename;
> +  OS << NativePath;
>  return;
>}
>assert(OutputFormat == DependencyOutputFormat::Make);
> -  for (unsigned i = 0, e = Filename.size(); i != e; ++i) {
> -if (Filename[i] == '#') // Handle '#' the broken gcc way.
> +  for (unsigned i = 0, e = NativePath.size(); i != e; ++i) {
> +if (NativePath[i] == '#') // Handle '#' the broken gcc way.
>OS << '\\';
> -else if (Filename[i] == ' ') { // Handle space correctly.
> +else if (NativePath[i] == ' ') { // Handle space correctly.
>OS << '\\';
>unsigned j = i;
> -  while (j > 0 && Filename[--j] == '\\')
> +  while (j > 0 && NativePath[--j] == '\\')
>  OS << '\\';
> -} else if (Filename[i] == '$') // $ is escaped by $$.
> +} else if (NativePath[i] == '$') // $ is escaped by $$.
>OS << '$';
> -OS << Filename[i];
> +OS << NativePath[i];
>}
>  }
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D51847: Print correctly dependency paths on Windows

[Zachary Turner via cfe-commits]

I mean in practice. What command do i run to hit this and what will the
output look like? Can you paste some terminal output showing the command
and output?
On Tue, Sep 11, 2018 at 12:55 AM Dávid Bolvanský via Phabricator <
revi...@reviews.llvm.org> wrote:

> xbolva00 added a comment.
>
> In https://reviews.llvm.org/D51847#1228927, @zturner wrote:
>
> > What prints this? How do you exercise this codepath?
>
>
> DFGImpl::OutputDependencyFile() -> for (StringRef File : Files)
>
>
> https://reviews.llvm.org/D51847
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r341117 - [MS ABI] Fix mangling issue with dynamic initializer stubs.

[Zachary Turner via cfe-commits]

It looks like tnorthover has fixed these in r341240

On Fri, Aug 31, 2018 at 1:08 PM Zachary Turner  wrote:

> Are we sure it was my commit?  Because this seems like a very unusual
> failure given the nature of the commit.  I'll try to reproduce it locally
> and report back.
>
> On Fri, Aug 31, 2018 at 11:49 AM Galina Kistanova 
> wrote:
>
>> Hello Zachary,
>>
>> It looks like this commit added broken tests on one of our builders:
>>
>> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/19508
>>
>> . . .
>> Failing Tests (2):
>> LLVM-Unit :: ADT/./ADTTests.exe/HashingTest.HashCombineRangeGoldenTest
>> Clang :: CodeGenCXX/catch-undef-behavior.cpp
>>
>> Please have a look?
>> The builder was already red and did not send notifications on this.
>>
>> Thanks
>>
>> Galina
>>
>> On Thu, Aug 30, 2018 at 1:54 PM Zachary Turner via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: zturner
>>> Date: Thu Aug 30 13:53:11 2018
>>> New Revision: 341117
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=341117=rev
>>> Log:
>>> [MS ABI] Fix mangling issue with dynamic initializer stubs.
>>>
>>> There are two types of dynamic initializer stubs.  There's
>>>
>>>   `dynamic initializer for 'x''(void)
>>>
>>> and
>>>
>>>   `dynamic initializer for `static Foo::Bar StaticDataMember''(void)
>>>
>>> The second case is disambiguated from the first by the presence of
>>> a ? after the operator code.  So the first will appear something like
>>> ?__E while the second will appear something like ?__E?.
>>> clang-cl was mangling these both the same though.  This patch
>>> matches behavior with cl.
>>>
>>> Differential Revision: https://reviews.llvm.org/D51500
>>>
>>> Modified:
>>> cfe/trunk/lib/AST/MicrosoftMangle.cpp
>>> cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
>>> cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp
>>>
>>> Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=341117=341116=341117=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
>>> +++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Thu Aug 30 13:53:11 2018
>>> @@ -3217,10 +3217,13 @@ void MicrosoftMangleContextImpl::mangleI
>>>msvc_hashing_ostream MHO(Out);
>>>MicrosoftCXXNameMangler Mangler(*this, MHO);
>>>Mangler.getStream() << "??__" << CharCode;
>>> -  Mangler.mangleName(D);
>>>if (D->isStaticDataMember()) {
>>> +Mangler.getStream() << '?';
>>> +Mangler.mangleName(D);
>>>  Mangler.mangleVariableEncoding(D);
>>> -Mangler.getStream() << '@';
>>> +Mangler.getStream() << "@@";
>>> +  } else {
>>> +Mangler.mangleName(D);
>>>}
>>>// This is the function class mangling.  These stubs are global,
>>> non-variadic,
>>>// cdecl functions that return void and take no args.
>>>
>>> Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp?rev=341117=341116=341117=diff
>>>
>>> ==
>>> --- cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
>>> (original)
>>> +++ cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp Thu
>>> Aug 30 13:53:11 2018
>>> @@ -3,8 +3,8 @@
>>>  // CHECK: @llvm.global_ctors = appending global [5 x { i32, void ()*,
>>> i8* }] [
>>>  // CHECK: { i32, void ()*, i8* } { i32 65535, void ()*
>>> @"??__Eselectany1@@YAXXZ", i8* getelementptr inbounds (%struct.S,
>>> %struct.S* @"?selectany1@@3US@@A", i32 0, i32 0) },
>>>  // CHECK: { i32, void ()*, i8* } { i32 65535, void ()*
>>> @"??__Eselectany2@@YAXXZ", i8* getelementptr inbounds (%struct.S,
>>> %struct.S* @"?selectany2@@3US@@A", i32 0, i32 0) },
>>> -// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"??__Es@
>>> ?$ExportedTemplate@H@@2US@@A@YAXXZ", i8* 

Re: r341117 - [MS ABI] Fix mangling issue with dynamic initializer stubs.

[Zachary Turner via cfe-commits]

Are we sure it was my commit?  Because this seems like a very unusual
failure given the nature of the commit.  I'll try to reproduce it locally
and report back.

On Fri, Aug 31, 2018 at 11:49 AM Galina Kistanova 
wrote:

> Hello Zachary,
>
> It looks like this commit added broken tests on one of our builders:
>
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/19508
>
> . . .
> Failing Tests (2):
> LLVM-Unit :: ADT/./ADTTests.exe/HashingTest.HashCombineRangeGoldenTest
> Clang :: CodeGenCXX/catch-undef-behavior.cpp
>
> Please have a look?
> The builder was already red and did not send notifications on this.
>
> Thanks
>
> Galina
>
> On Thu, Aug 30, 2018 at 1:54 PM Zachary Turner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: zturner
>> Date: Thu Aug 30 13:53:11 2018
>> New Revision: 341117
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=341117=rev
>> Log:
>> [MS ABI] Fix mangling issue with dynamic initializer stubs.
>>
>> There are two types of dynamic initializer stubs.  There's
>>
>>   `dynamic initializer for 'x''(void)
>>
>> and
>>
>>   `dynamic initializer for `static Foo::Bar StaticDataMember''(void)
>>
>> The second case is disambiguated from the first by the presence of
>> a ? after the operator code.  So the first will appear something like
>> ?__E while the second will appear something like ?__E?.
>> clang-cl was mangling these both the same though.  This patch
>> matches behavior with cl.
>>
>> Differential Revision: https://reviews.llvm.org/D51500
>>
>> Modified:
>> cfe/trunk/lib/AST/MicrosoftMangle.cpp
>> cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
>> cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp
>>
>> Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=341117=341116=341117=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
>> +++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Thu Aug 30 13:53:11 2018
>> @@ -3217,10 +3217,13 @@ void MicrosoftMangleContextImpl::mangleI
>>msvc_hashing_ostream MHO(Out);
>>MicrosoftCXXNameMangler Mangler(*this, MHO);
>>Mangler.getStream() << "??__" << CharCode;
>> -  Mangler.mangleName(D);
>>if (D->isStaticDataMember()) {
>> +Mangler.getStream() << '?';
>> +Mangler.mangleName(D);
>>  Mangler.mangleVariableEncoding(D);
>> -Mangler.getStream() << '@';
>> +Mangler.getStream() << "@@";
>> +  } else {
>> +Mangler.mangleName(D);
>>}
>>// This is the function class mangling.  These stubs are global,
>> non-variadic,
>>// cdecl functions that return void and take no args.
>>
>> Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp?rev=341117=341116=341117=diff
>>
>> ==
>> --- cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
>> (original)
>> +++ cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp Thu
>> Aug 30 13:53:11 2018
>> @@ -3,8 +3,8 @@
>>  // CHECK: @llvm.global_ctors = appending global [5 x { i32, void ()*,
>> i8* }] [
>>  // CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
>> @"??__Eselectany1@@YAXXZ",
>> i8* getelementptr inbounds (%struct.S, %struct.S* @"?selectany1@@3US@@A",
>> i32 0, i32 0) },
>>  // CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
>> @"??__Eselectany2@@YAXXZ",
>> i8* getelementptr inbounds (%struct.S, %struct.S* @"?selectany2@@3US@@A",
>> i32 0, i32 0) },
>> -// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"??__Es@
>> ?$ExportedTemplate@H@@2US@@A@YAXXZ", i8* getelementptr inbounds
>> (%struct.S, %struct.S* @"?s@?$ExportedTemplate@H@@2US@@A", i32 0, i32 0)
>> },
>> -// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"??__Efoo@?$B@H
>> @@2VA@@A@YAXXZ", i8* bitcast (%class.A* @"?foo@?$B@H@@2VA@@A" to i8*) },
>> +// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* @"??__E?s@
>> ?$ExportedTemplate@H@@2US@@A@@YAXXZ", i8* getelementptr inbounds
>> (%struct.S, %struct.

r341117 - [MS ABI] Fix mangling issue with dynamic initializer stubs.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Aug 30 13:53:11 2018
New Revision: 341117

URL: http://llvm.org/viewvc/llvm-project?rev=341117=rev
Log:
[MS ABI] Fix mangling issue with dynamic initializer stubs.

There are two types of dynamic initializer stubs.  There's

  `dynamic initializer for 'x''(void)

and

  `dynamic initializer for `static Foo::Bar StaticDataMember''(void)

The second case is disambiguated from the first by the presence of
a ? after the operator code.  So the first will appear something like
?__E while the second will appear something like ?__E?.
clang-cl was mangling these both the same though.  This patch
matches behavior with cl.

Differential Revision: https://reviews.llvm.org/D51500

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=341117=341116=341117=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Thu Aug 30 13:53:11 2018
@@ -3217,10 +3217,13 @@ void MicrosoftMangleContextImpl::mangleI
   msvc_hashing_ostream MHO(Out);
   MicrosoftCXXNameMangler Mangler(*this, MHO);
   Mangler.getStream() << "??__" << CharCode;
-  Mangler.mangleName(D);
   if (D->isStaticDataMember()) {
+Mangler.getStream() << '?';
+Mangler.mangleName(D);
 Mangler.mangleVariableEncoding(D);
-Mangler.getStream() << '@';
+Mangler.getStream() << "@@";
+  } else {
+Mangler.mangleName(D);
   }
   // This is the function class mangling.  These stubs are global, 
non-variadic,
   // cdecl functions that return void and take no args.

Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp?rev=341117=341116=341117=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-static-initializers.cpp Thu Aug 30 
13:53:11 2018
@@ -3,8 +3,8 @@
 // CHECK: @llvm.global_ctors = appending global [5 x { i32, void ()*, i8* }] [
 // CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
@"??__Eselectany1@@YAXXZ", i8* getelementptr inbounds (%struct.S, %struct.S* 
@"?selectany1@@3US@@A", i32 0, i32 0) },
 // CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
@"??__Eselectany2@@YAXXZ", i8* getelementptr inbounds (%struct.S, %struct.S* 
@"?selectany2@@3US@@A", i32 0, i32 0) },
-// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
@"??__Es@?$ExportedTemplate@H@@2US@@A@YAXXZ", i8* getelementptr inbounds 
(%struct.S, %struct.S* @"?s@?$ExportedTemplate@H@@2US@@A", i32 0, i32 0) },
-// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
@"??__Efoo@?$B@H@@2VA@@A@YAXXZ", i8* bitcast (%class.A* @"?foo@?$B@H@@2VA@@A" 
to i8*) },
+// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
@"??__E?s@?$ExportedTemplate@H@@2US@@A@@YAXXZ", i8* getelementptr inbounds 
(%struct.S, %struct.S* @"?s@?$ExportedTemplate@H@@2US@@A", i32 0, i32 0) },
+// CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
@"??__E?foo@?$B@H@@2VA@@A@@YAXXZ", i8* bitcast (%class.A* @"?foo@?$B@H@@2VA@@A" 
to i8*) },
 // CHECK: { i32, void ()*, i8* } { i32 65535, void ()* 
@_GLOBAL__sub_I_microsoft_abi_static_initializers.cpp, i8* null }
 // CHECK: ]
 
@@ -231,18 +231,18 @@ void force_usage() {
   DynamicDLLImportInitVSMangling::switch_test3();
 }
 
-// CHECK: define linkonce_odr dso_local void @"??__Efoo@?$B@H@@2VA@@A@YAXXZ"() 
{{.*}} comdat
+// CHECK: define linkonce_odr dso_local void 
@"??__E?foo@?$B@H@@2VA@@A@@YAXXZ"() {{.*}} comdat
 // CHECK-NOT: and
 // CHECK-NOT: ?_Bfoo@
 // CHECK: call x86_thiscallcc %class.A* @"??0A@@QAE@XZ"
-// CHECK: call i32 @atexit(void ()* @"??__Ffoo@?$B@H@@2VA@@A@YAXXZ")
+// CHECK: call i32 @atexit(void ()* @"??__F?foo@?$B@H@@2VA@@A@@YAXXZ")
 // CHECK: ret void
 
 // CHECK: define linkonce_odr dso_local x86_thiscallcc %class.A* 
@"??0A@@QAE@XZ"({{.*}}) {{.*}} comdat
 
 // CHECK: define linkonce_odr dso_local x86_thiscallcc void 
@"??1A@@QAE@XZ"({{.*}}) {{.*}} comdat
 
-// CHECK: define internal void @"??__Ffoo@?$B@H@@2VA@@A@YAXXZ"
+// CHECK: define internal void @"??__F?foo@?$B@H@@2VA@@A@@YAXXZ"
 // CHECK: call x86_thiscallcc void @"??1A@@QAE@XZ"{{.*}}foo
 // CHECK: ret void
 

Modified: cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp?rev=341117=341116=341117=diff
==
--- cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp Thu Aug 30 13:53:11 2018
@@ -44,7 +44,7 @@ template  struct 

Re: [PATCH] D50877: [MS] Mangle a hash of the main file path into anonymous namespaces

[Zachary Turner via cfe-commits]

IIRC it’s `?A0xABCDABCD@` where the hex value is some kind of hash
On Thu, Aug 16, 2018 at 5:27 PM David Majnemer via Phabricator <
revi...@reviews.llvm.org> wrote:

> majnemer added a comment.
>
> How does MSVC handle this case? What mangled name does it generate?
>
>
> https://reviews.llvm.org/D50877
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxxabi] r337582 - Merge changes to ItaniumDemangle over to libcxxabi.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Jul 20 10:16:49 2018
New Revision: 337582

URL: http://llvm.org/viewvc/llvm-project?rev=337582=rev
Log:
Merge changes to ItaniumDemangle over to libcxxabi.

ItaniumDemangle had a small NFC refactor to make some of its
code reusable by the newly added Microsoft demangler.  To keep
the libcxxabi demangler as close as possible to the master copy
this refactor is being merged over.

Differential Revision: https://reviews.llvm.org/D49575

Added:
libcxxabi/trunk/src/demangle/
libcxxabi/trunk/src/demangle/Compiler.h
libcxxabi/trunk/src/demangle/StringView.h
libcxxabi/trunk/src/demangle/Utility.h
Modified:
libcxxabi/trunk/src/cxa_demangle.cpp

Modified: libcxxabi/trunk/src/cxa_demangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp?rev=337582=337581=337582=diff
==
--- libcxxabi/trunk/src/cxa_demangle.cpp (original)
+++ libcxxabi/trunk/src/cxa_demangle.cpp Fri Jul 20 10:16:49 2018
@@ -15,150 +15,27 @@
 
 #include "__cxxabi_config.h"
 
-#include 
-#include 
-#include 
+#include "demangle/Compiler.h"
+#include "demangle/StringView.h"
+#include "demangle/Utility.h"
+
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
-#ifdef _MSC_VER
-// snprintf is implemented in VS 2015
-#if _MSC_VER < 1900
-#define snprintf _snprintf_s
-#endif
-#endif
-
-#ifndef NDEBUG
-#if __has_attribute(noinline) && __has_attribute(used)
-#define DUMP_METHOD __attribute__((noinline,used))
-#else
-#define DUMP_METHOD
-#endif
-#endif
 
 namespace {
 
-class StringView {
-  const char *First;
-  const char *Last;
-
-public:
-  template 
-  StringView(const char ()[N]) : First(Str), Last(Str + N - 1) {}
-  StringView(const char *First_, const char *Last_) : First(First_), 
Last(Last_) {}
-  StringView() : First(nullptr), Last(nullptr) {}
-
-  StringView substr(size_t From, size_t To) {
-if (To >= size())
-  To = size() - 1;
-if (From >= size())
-  From = size() - 1;
-return StringView(First + From, First + To);
-  }
-
-  StringView dropFront(size_t N) const {
-if (N >= size())
-  N = size() - 1;
-return StringView(First + N, Last);
-  }
-
-  bool startsWith(StringView Str) const {
-if (Str.size() > size())
-  return false;
-return std::equal(Str.begin(), Str.end(), begin());
-  }
-
-  const char [](size_t Idx) const { return *(begin() + Idx); }
-
-  const char *begin() const { return First; }
-  const char *end() const { return Last; }
-  size_t size() const { return static_cast(Last - First); }
-  bool empty() const { return First == Last; }
-};
-
-bool operator==(const StringView , const StringView ) {
-  return LHS.size() == RHS.size() &&
- std::equal(LHS.begin(), LHS.end(), RHS.begin());
-}
-
-// Stream that AST nodes write their string representation into after the AST
-// has been parsed.
-class OutputStream {
-  char *Buffer;
-  size_t CurrentPosition;
-  size_t BufferCapacity;
-
-  // Ensure there is at least n more positions in buffer.
-  void grow(size_t N) {
-if (N + CurrentPosition >= BufferCapacity) {
-  BufferCapacity *= 2;
-  if (BufferCapacity < N + CurrentPosition)
-BufferCapacity = N + CurrentPosition;
-  Buffer = static_cast(std::realloc(Buffer, BufferCapacity));
-}
-  }
-
-public:
-  OutputStream(char *StartBuf, size_t Size)
-  : Buffer(StartBuf), CurrentPosition(0), BufferCapacity(Size) {}
-  OutputStream() = default;
-  void reset(char *Buffer_, size_t BufferCapacity_) {
-CurrentPosition = 0;
-Buffer = Buffer_;
-BufferCapacity = BufferCapacity_;
-  }
-
-  /// If a ParameterPackExpansion (or similar type) is encountered, the offset
-  /// into the pack that we're currently printing.
-  unsigned CurrentPackIndex = std::numeric_limits::max();
-  unsigned CurrentPackMax = std::numeric_limits::max();
-
-  OutputStream +=(StringView R) {
-size_t Size = R.size();
-if (Size == 0)
-  return *this;
-grow(Size);
-memmove(Buffer + CurrentPosition, R.begin(), Size);
-CurrentPosition += Size;
-return *this;
-  }
-
-  OutputStream +=(char C) {
-grow(1);
-Buffer[CurrentPosition++] = C;
-return *this;
-  }
-
-  size_t getCurrentPosition() const { return CurrentPosition; }
-  void setCurrentPosition(size_t NewPos) { CurrentPosition = NewPos; }
-
-  char back() const {
-return CurrentPosition ? Buffer[CurrentPosition - 1] : '\0';
-  }
-
-  bool empty() const { return CurrentPosition == 0; }
-
-  char *getBuffer() { return Buffer; }
-  char *getBufferEnd() { return Buffer + CurrentPosition - 1; }
-  size_t getBufferCapacity() { return BufferCapacity; }
-};
-
-template 
-class SwapAndRestore {
-  T 
-  T OriginalValue;
-public:
-  SwapAndRestore(T& Restore_, T NewVal)
-  : Restore(Restore_), OriginalValue(Restore) {
-Restore = std::move(NewVal);
-  }
-  ~SwapAndRestore() { Restore = std::move(OriginalValue); 

r337572 - Rewrite the VS integration scripts.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Jul 20 09:30:02 2018
New Revision: 337572

URL: http://llvm.org/viewvc/llvm-project?rev=337572=rev
Log:
Rewrite the VS integration scripts.

This is a new modernized VS integration installer.  It adds a
Visual Studio .sln file which, when built, outputs a VSIX that can
be used to install ourselves as a "real" Visual Studio Extension.
We can even upload this extension to the visual studio marketplace.

This fixes a longstanding problem where we didn't support installing
into VS 2017 and higher.  In addition to supporting VS 2017, due
to the way this is written we now longer need to do anything special
to support future versions of VS as well.  Everything should
"just work".  This also fixes several bugs with our old integration,
such as MSBuild triggering full rebuilds when /Zi was used.

Finally, we add a new UI page called "LLVM" which becomes visible
when the LLVM toolchain is selected.  For now this only contains
one option which is the path to clang-cl.exe, but in the future
we can add more things here.

Differential Revision: https://reviews.llvm.org/D42762

Modified:
cfe/trunk/tools/driver/CMakeLists.txt

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=337572=337571=337572=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Fri Jul 20 09:30:02 2018
@@ -63,10 +63,6 @@ add_dependencies(clang clang-headers)
 
 if(NOT CLANG_LINKS_TO_CREATE)
   set(CLANG_LINKS_TO_CREATE clang++ clang-cl clang-cpp)
-
-  if (MSVC)
-list(APPEND CLANG_LINKS_TO_CREATE ../msbuild-bin/cl)
-  endif()
 endif()
 
 foreach(link ${CLANG_LINKS_TO_CREATE})


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D49398: clang-cl: Postpone Wmsvc-not-found emission until link.exe gets used.

[Zachary Turner via cfe-commits]

Lgtm. I also have a hard time saying which is best, we’re basically trying
to help people who have already strayed from the path, so there’s probably
no objectively correct answer
On Tue, Jul 17, 2018 at 7:26 AM Nico Weber via Phabricator <
revi...@reviews.llvm.org> wrote:

> thakis updated this revision to Diff 155885.
> thakis added a comment.
>
> address comment
>
>
> https://reviews.llvm.org/D49398
>
> Files:
>   lib/Driver/ToolChains/MSVC.cpp
>   lib/Driver/ToolChains/MSVC.h
>
>
> Index: lib/Driver/ToolChains/MSVC.h
> ===
> --- lib/Driver/ToolChains/MSVC.h
> +++ lib/Driver/ToolChains/MSVC.h
> @@ -123,6 +123,8 @@
>
>void printVerboseInfo(raw_ostream ) const override;
>
> +  bool FoundMSVCInstall() const { return !VCToolChainPath.empty(); }
> +
>  protected:
>void AddSystemIncludeWithSubfolder(const llvm::opt::ArgList ,
>   llvm::opt::ArgStringList ,
> Index: lib/Driver/ToolChains/MSVC.cpp
> ===
> --- lib/Driver/ToolChains/MSVC.cpp
> +++ lib/Driver/ToolChains/MSVC.cpp
> @@ -469,6 +469,9 @@
>  // their own link.exe which may come first.
>  linkPath = FindVisualStudioExecutable(TC, "link.exe");
>
> +if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath))
> +  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
> +
>  #ifdef _WIN32
>  // When cross-compiling with VS2017 or newer, link.exe expects to have
>  // its containing bin directory at the top of PATH, followed by the
> @@ -684,8 +687,6 @@
>  }
>
>  Tool *MSVCToolChain::buildLinker() const {
> -  if (VCToolChainPath.empty())
> -getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
>return new tools::visualstudio::Linker(*this);
>  }
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r336219 - Fix crash in clang.

[Zachary Turner via cfe-commits]

makeArrayRef() isn't necessary, but when I was first looking at this I had
to stare at the code for a bit to see that there was an implicit conversion
happening.  So I put the makeArrayRef() just for the benefit of the person
reading the code.  But no, it's not necessary.

This did not fail on existing tests, it failed when a user reported a
crash.  I'm not sure of a way to write a test to force the original crash
though.  Every invocation of the clang cc1 driver from the cl driver
already goes through this code path, and it wasn't crashing on any bots.
The crash was due to freeing stack memory and then immediately accessing
that memory.  This will accidentally work a lot of the time.

(Also not sure why our sanitizer bots didn't catch it).

On Mon, Jul 9, 2018 at 1:42 PM David Blaikie  wrote:

> Did this fail on an existing regression test, or is there a need for more
> test coverage? (guessing it failed on existing tests)
>
> Also, is the makeArrayRef necessary? Looks like if the original code
> compiled (implicitly converting from vector to ArrayRef) then the new code
> wouldn't need a makeArrayRef either?
>
> On Tue, Jul 3, 2018 at 11:17 AM Zachary Turner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: zturner
>> Date: Tue Jul  3 11:12:39 2018
>> New Revision: 336219
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=336219=rev
>> Log:
>> Fix crash in clang.
>>
>> This happened during a recent refactor.  toStringRefArray() returns
>> a vector, which was being implicitly converted to an
>> ArrayRef, and then the vector was immediately being
>> destroyed, so the ArrayRef<> was losing its backing storage.
>> Fix this by making sure the vector gets permanent storage.
>>
>> Modified:
>> cfe/trunk/lib/Driver/Job.cpp
>>
>> Modified: cfe/trunk/lib/Driver/Job.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Job.cpp?rev=336219=336218=336219=diff
>>
>> ==
>> --- cfe/trunk/lib/Driver/Job.cpp (original)
>> +++ cfe/trunk/lib/Driver/Job.cpp Tue Jul  3 11:12:39 2018
>> @@ -318,10 +318,12 @@ int Command::Execute(ArrayRef>SmallVector Argv;
>>
>>Optional> Env;
>> +  std::vector ArgvVectorStorage;
>>if (!Environment.empty()) {
>>  assert(Environment.back() == nullptr &&
>> "Environment vector should be null-terminated by now");
>> -Env = llvm::toStringRefArray(Environment.data());
>> +ArgvVectorStorage = llvm::toStringRefArray(Environment.data());
>> +Env = makeArrayRef(ArgvVectorStorage);
>>}
>>
>>if (ResponseFile == nullptr) {
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r336219 - Fix crash in clang.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Tue Jul  3 11:12:39 2018
New Revision: 336219

URL: http://llvm.org/viewvc/llvm-project?rev=336219=rev
Log:
Fix crash in clang.

This happened during a recent refactor.  toStringRefArray() returns
a vector, which was being implicitly converted to an
ArrayRef, and then the vector was immediately being
destroyed, so the ArrayRef<> was losing its backing storage.
Fix this by making sure the vector gets permanent storage.

Modified:
cfe/trunk/lib/Driver/Job.cpp

Modified: cfe/trunk/lib/Driver/Job.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Job.cpp?rev=336219=336218=336219=diff
==
--- cfe/trunk/lib/Driver/Job.cpp (original)
+++ cfe/trunk/lib/Driver/Job.cpp Tue Jul  3 11:12:39 2018
@@ -318,10 +318,12 @@ int Command::Execute(ArrayRef Argv;
 
   Optional> Env;
+  std::vector ArgvVectorStorage;
   if (!Environment.empty()) {
 assert(Environment.back() == nullptr &&
"Environment vector should be null-terminated by now");
-Env = llvm::toStringRefArray(Environment.data());
+ArgvVectorStorage = llvm::toStringRefArray(Environment.data());
+Env = makeArrayRef(ArgvVectorStorage);
   }
 
   if (ResponseFile == nullptr) {


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r335702 - Fix warning about unhandled enumeration in switch.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Tue Jun 26 19:49:22 2018
New Revision: 335702

URL: http://llvm.org/viewvc/llvm-project?rev=335702=rev
Log:
Fix warning about unhandled enumeration in switch.

Modified:
cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp?rev=335702=335701=335702=diff
==
--- cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp Tue Jun 26 19:49:22 2018
@@ -198,6 +198,8 @@ void freebsd::Linker::ConstructJob(Compi
 else
   CmdArgs.push_back("elf64ltsmip_fbsd");
 break;
+  default:
+break;
   }
 
   if (Arg *A = Args.getLastArg(options::OPT_G)) {


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r334518 - Refactor ExecuteAndWait to take StringRefs.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Tue Jun 12 10:43:52 2018
New Revision: 334518

URL: http://llvm.org/viewvc/llvm-project?rev=334518=rev
Log:
Refactor ExecuteAndWait to take StringRefs.

This simplifies some code which had StringRefs to begin with, and
makes other code more complicated which had const char* to begin
with.

In the end, I think this makes for a more idiomatic and platform
agnostic API.  Not all platforms launch process with null terminated
c-string arrays for the environment pointer and argv, but the api
was designed that way because it allowed easy pass-through for
posix-based platforms.  There's a little additional overhead now
since on posix based platforms we'll be takign StringRefs which
were constructed from null terminated strings and then copying
them to null terminate them again, but from a readability and
usability standpoint of the API user, I think this API signature
is strictly better.

Modified:
cfe/trunk/lib/Driver/Job.cpp
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Modified: cfe/trunk/lib/Driver/Job.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Job.cpp?rev=334518=334517=334518=diff
==
--- cfe/trunk/lib/Driver/Job.cpp (original)
+++ cfe/trunk/lib/Driver/Job.cpp Tue Jun 12 10:43:52 2018
@@ -317,13 +317,11 @@ int Command::Execute(ArrayRef Argv;
 
-  const char **Envp;
-  if (Environment.empty()) {
-Envp = nullptr;
-  } else {
+  Optional> Env;
+  if (!Environment.empty()) {
 assert(Environment.back() == nullptr &&
"Environment vector should be null-terminated by now");
-Envp = const_cast(Environment.data());
+Env = llvm::toStringRefArray(Environment.data());
   }
 
   if (ResponseFile == nullptr) {
@@ -331,8 +329,9 @@ int Command::Execute(ArrayRefhttp://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp?rev=334518=334517=334518=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp Tue Jun 12 
10:43:52 2018
@@ -883,9 +883,9 @@ UbigraphViz::~UbigraphViz() {
   std::string Ubiviz;
   if (auto Path = llvm::sys::findProgramByName("ubiviz"))
 Ubiviz = *Path;
-  const char *args[] = {Ubiviz.c_str(), Filename.c_str(), nullptr};
+  std::array Args = {Ubiviz, Filename};
 
-  if (llvm::sys::ExecuteAndWait(Ubiviz, [0], nullptr, {}, 0, 0, )) 
{
+  if (llvm::sys::ExecuteAndWait(Ubiviz, Args, llvm::None, {}, 0, 0, )) {
 llvm::errs() << "Error viewing graph: " << ErrMsg << "\n";
   }
 

Modified: cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp?rev=334518=334517=334518=diff
==
--- cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp (original)
+++ cfe/trunk/tools/clang-offload-bundler/ClangOffloadBundler.cpp Tue Jun 12 
10:43:52 2018
@@ -536,23 +536,22 @@ public:
 // close it and use the name to pass down to clang.
 OS.close();
 SmallString<128> TargetName = getTriple(TargetNames[HostInputIndex]);
-const char *ClangArgs[] = {"clang",
-   "-r",
-   "-target",
-   TargetName.c_str(),
-   "-o",
-   OutputFileNames.front().c_str(),
-   InputFileNames[HostInputIndex].c_str(),
-   BitcodeFileName.c_str(),
-   "-nostdlib",
-   nullptr};
+std::vector ClangArgs = {"clang",
+"-r",
+"-target",
+TargetName.c_str(),
+"-o",
+OutputFileNames.front().c_str(),
+InputFileNames[HostInputIndex].c_str(),
+BitcodeFileName.c_str(),
+"-nostdlib"};
 
 // If the user asked for the commands to be printed out, we do that instead
 // of executing it.
 if (PrintExternalCommands) {
   errs() << "\"" << ClangBinary.get() << "\"";
-  for (unsigned I = 1; ClangArgs[I]; ++I)
-errs() << " \"" << ClangArgs[I] << "\"";
+  for (StringRef Arg : ClangArgs)
+errs() << " \"" << Arg << "\"";
   errs() << "\n";
 } else {
   // Write the bitcode contents to the temporary file.


___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[clang-tools-extra] r334221 - [FileSystem] Split up the OpenFlags enumeration.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Jun  7 12:58:58 2018
New Revision: 334221

URL: http://llvm.org/viewvc/llvm-project?rev=334221=rev
Log:
[FileSystem] Split up the OpenFlags enumeration.

This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition.  The first
controls the behavior of the API depending on whether or not
the target file already exists, and is not a flags-based
enum.  The second controls more flags-like values.

This yields a more easy to understand API, while also allowing
flags to be passed to the openForRead api, where most of the
values didn't make sense before.  This also makes the apis more
testable as it becomes easy to enumerate all the configurations
which make sense, so I've added many new tests to exercise all
the different values.

Modified:
clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp
clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp

Modified: clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp?rev=334221=334220=334221=diff
==
--- clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp (original)
+++ clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp Thu Jun  7 
12:58:58 2018
@@ -30,8 +30,8 @@ namespace {
 
 std::error_code CreateNewFile(const llvm::Twine ) {
   int fd = 0;
-  if (std::error_code ec =
-  llvm::sys::fs::openFileForWrite(path, fd, llvm::sys::fs::F_Text))
+  if (std::error_code ec = llvm::sys::fs::openFileForWrite(
+  path, fd, llvm::sys::fs::CD_CreateAlways, llvm::sys::fs::F_Text))
 return ec;
 
   return llvm::sys::Process::SafelyCloseFileDescriptor(fd);

Modified: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp?rev=334221=334220=334221=diff
==
--- clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp (original)
+++ clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp Thu Jun  7 12:58:58 2018
@@ -159,7 +159,8 @@ int main(int argc, char *argv[]) {
   llvm::Optional InputMirrorStream;
   if (!InputMirrorFile.empty()) {
 std::error_code EC;
-InputMirrorStream.emplace(InputMirrorFile, /*ref*/ EC, 
llvm::sys::fs::F_RW);
+InputMirrorStream.emplace(InputMirrorFile, /*ref*/ EC,
+  llvm::sys::fs::FA_Read | 
llvm::sys::fs::FA_Write);
 if (EC) {
   InputMirrorStream.reset();
   llvm::errs() << "Error while opening an input mirror file: "
@@ -174,7 +175,8 @@ int main(int argc, char *argv[]) {
   std::unique_ptr Tracer;
   if (auto *TraceFile = getenv("CLANGD_TRACE")) {
 std::error_code EC;
-TraceStream.emplace(TraceFile, /*ref*/ EC, llvm::sys::fs::F_RW);
+TraceStream.emplace(TraceFile, /*ref*/ EC,
+llvm::sys::fs::FA_Read | llvm::sys::fs::FA_Write);
 if (EC) {
   TraceStream.reset();
   llvm::errs() << "Error while opening trace file " << TraceFile << ": "


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r334221 - [FileSystem] Split up the OpenFlags enumeration.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Jun  7 12:58:58 2018
New Revision: 334221

URL: http://llvm.org/viewvc/llvm-project?rev=334221=rev
Log:
[FileSystem] Split up the OpenFlags enumeration.

This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition.  The first
controls the behavior of the API depending on whether or not
the target file already exists, and is not a flags-based
enum.  The second controls more flags-like values.

This yields a more easy to understand API, while also allowing
flags to be passed to the openForRead api, where most of the
values didn't make sense before.  This also makes the apis more
testable as it becomes easy to enumerate all the configurations
which make sense, so I've added many new tests to exercise all
the different values.

Modified:
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp

Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=334221=334220=334221=diff
==
--- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
+++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Thu Jun  7 12:58:58 2018
@@ -258,7 +258,8 @@ ErrorOr>
 RealFileSystem::openFileForRead(const Twine ) {
   int FD;
   SmallString<256> RealName;
-  if (std::error_code EC = sys::fs::openFileForRead(Name, FD, ))
+  if (std::error_code EC =
+  sys::fs::openFileForRead(Name, FD, sys::fs::OF_None, ))
 return EC;
   return std::unique_ptr(new RealFile(FD, Name.str(), RealName.str()));
 }

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=334221=334220=334221=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Thu Jun  7 12:58:58 2018
@@ -1293,7 +1293,7 @@ void Driver::generateCompilationDiagnost
 
   std::string Script = CrashInfo.Filename.rsplit('.').first.str() + ".sh";
   std::error_code EC;
-  llvm::raw_fd_ostream ScriptOS(Script, EC, llvm::sys::fs::F_Excl);
+  llvm::raw_fd_ostream ScriptOS(Script, EC, llvm::sys::fs::CD_CreateNew);
   if (EC) {
 Diag(clang::diag::note_drv_command_failed_diag_msg)
 << "Error generating run script: " + Script + " " + EC.message();

Modified: cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp?rev=334221=334220=334221=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp Thu Jun  7 12:58:58 
2018
@@ -238,10 +238,8 @@ void HTMLDiagnostics::ReportDiag(const P
<< "-" << i << ".html";
   llvm::sys::path::append(Model, Directory,
   filename.str());
-  EC = llvm::sys::fs::openFileForWrite(Model,
-   FD,
-   llvm::sys::fs::F_RW |
-   llvm::sys::fs::F_Excl);
+  EC = llvm::sys::fs::openFileForReadWrite(
+  Model, FD, llvm::sys::fs::CD_CreateNew, llvm::sys::fs::OF_None);
   if (EC && EC != llvm::errc::file_exists) {
   llvm::errs() << "warning: could not create file '" << Model
<< "': " << EC.message() << '\n';


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r331786 - [lit] Fix running tests that require 'examples'.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Tue May  8 11:20:10 2018
New Revision: 331786

URL: http://llvm.org/viewvc/llvm-project?rev=331786=rev
Log:
[lit] Fix running tests that require 'examples'.

Differential Revision: https://reviews.llvm.org/D46514
Patch by Nikolai Kosjar.

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=331786=331785=331786=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Tue May  8 11:20:10 2018
@@ -63,6 +63,7 @@ tools = [
 ]
 
 if config.clang_examples:
+config.available_features.add('examples')
 tools.append('clang-interpreter')
 
 llvm_config.add_tool_substitutions(tools, tool_dirs)


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D44778: [clang-format] Wildcard expansion on Windows.

[Zachary Turner via cfe-commits]

Never seen this PURE_WINDOWS CMake variable. How is it different than MSVC?
On Thu, Mar 22, 2018 at 5:30 AM Alexander Kornienko via Phabricator <
revi...@reviews.llvm.org> wrote:

> alexfh created this revision.
> alexfh added reviewers: klimek, djasper.
> Herald added a subscriber: mgorny.
>
> Add support for wildcard expansion in command line arguments on Windows.
> See
> https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments
>
> Fixes https://bugs.llvm.org/show_bug.cgi?id=17217
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D44778
>
> Files:
>   tools/clang-format/CMakeLists.txt
>
>
> Index: tools/clang-format/CMakeLists.txt
> ===
> --- tools/clang-format/CMakeLists.txt
> +++ tools/clang-format/CMakeLists.txt
> @@ -4,6 +4,14 @@
>ClangFormat.cpp
>)
>
> +if( PURE_WINDOWS )
> +  # Add support for wildcard expansion in command-line arguments on
> Windows.
> +  # See
> +  #
> https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments
> +  set_property(TARGET clang-format APPEND_STRING PROPERTY
> +LINK_FLAGS " setargv.obj")
> +endif()
> +
>  set(CLANG_FORMAT_LIB_DEPS
>clangBasic
>clangFormat
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r326168 - Attempt to fix greendragon bot after r326141

[Zachary Turner via cfe-commits]

So this doesn’t appear to fix the issue that led to my revert earlier.

http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6760

There’s no slashes in the command line that’s failing. However, this bot
doesn’t seem to be updating and hasn’t pulled in this cl yet, but I expect
it to fail again when it does
On Mon, Feb 26, 2018 at 10:27 PM Zachary Turner  wrote:

> Never mind, I didn’t realize Reid resubmitted my cl after I reverted it.
> In fact, I reverted it because of this greendragon failure which I wasn’t
> sure how to fix at the time
> On Mon, Feb 26, 2018 at 10:12 PM Adam Nemet  wrote:
>
>> BTW, I think that the LLVM bots have trouble accessing subversion too.  I
>> already let Galina know.
>>
>>
>> On Feb 26, 2018, at 10:06 PM, Shoaib Meenai  wrote:
>>
>> r326171 works locally. I'll keep an eye on the bots.
>>
>> *From: * on behalf of Adam Nemet 
>> *Date: *Monday, February 26, 2018 at 9:51 PM
>> *To: *Shoaib Meenai 
>> *Cc: *Zachary Turner , "cfe-commits@lists.llvm.org" <
>> cfe-commits@lists.llvm.org>, Reid Kleckner 
>> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>>
>> Yep.
>>
>>
>> On Feb 26, 2018, at 9:50 PM, Shoaib Meenai  wrote:
>>
>> Reid re-committed r326141 this morning (and followed up with r326144),
>> and I don't think either of those have been reverted?
>>
>> *From: *Zachary Turner 
>> *Date: *Monday, February 26, 2018 at 9:47 PM
>> *To: *Adam Nemet 
>> *Cc: *Shoaib Meenai , "cfe-commits@lists.llvm.org" <
>> cfe-commits@lists.llvm.org>, Reid Kleckner 
>> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>>
>> I already reverted this a long time ago, but if Shoaib has a proper fix
>> that would be great
>> On Mon, Feb 26, 2018 at 9:45 PM Adam Nemet  wrote:
>>
>> Ah, that should be sufficient.
>>
>>
>>
>>
>> On Feb 26, 2018, at 9:44 PM, Shoaib Meenai  wrote:
>>
>> Thanks. I'm building on macOS locally to confirm the original problem and
>> my fix.
>>
>> *From: * on behalf of Adam Nemet 
>> *Date: *Monday, February 26, 2018 at 9:42 PM
>> *To: *Shoaib Meenai 
>> *Cc: *"cfe-commits@lists.llvm.org" , Reid
>> Kleckner , Zachary Turner 
>> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>>
>> This is the bot with the failure:
>>
>>
>> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/46794/#showFailuresLink
>> 
>>
>> But to make matters worse, greendragon is experience some difficulty
>> fetching from SVN so you might want to wait until things recover.  I am not
>> sure if I will be able to get in touch with Mike Edwards until the morning
>> PST.
>>
>> There may also be llvm bots that exhibit the same problem.  You may have
>> better luck with those in the short term.
>>
>> Adam
>>
>>
>>
>> On Feb 26, 2018, at 9:35 PM, Shoaib Meenai  wrote:
>>
>> Could you point me to the specific bot that was failing? I've dealt with
>> that problem before, and it shouldn't be hard to fix, but I wanna monitor
>> the bot after the fix to make sure it stays green.
>>
>> *From: * on behalf of Adam Nemet 
>> *Date: *Monday, February 26, 2018 at 9:30 PM
>> *To: *Shoaib Meenai 
>> *Cc: *"cfe-commits@lists.llvm.org" , Reid
>> Kleckner , Zachary Turner 
>> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>>
>> I don’t think we can deal with the slash options:
>>
>> clang-7.0: warning:
>> '/Users/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
>> treated as the '/U' option [-Wslash-u-filename]
>> clang-7.0: note: Use '--' to treat subsequent arguments as filenames
>> clang-7.0: warning: argument unused during compilation: '/Z7'
>> [-Wunused-command-line-argument]
>> clang-7.0: warning: argument unused during compilation: ‘-U
>> sers/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
>> [-Wunused-command-line-argument]
>>
>> Anyhow as I said to Reid, feel free to improve the patch, I am just
>> bringing back a bot that has been red for hours.
>>
>> Adam
>>
>>
>>
>>
>> On Feb 26, 2018, at 9:22 PM, Shoaib Meenai  

Re: r326168 - Attempt to fix greendragon bot after r326141

[Zachary Turner via cfe-commits]

Never mind, I didn’t realize Reid resubmitted my cl after I reverted it. In
fact, I reverted it because of this greendragon failure which I wasn’t sure
how to fix at the time
On Mon, Feb 26, 2018 at 10:12 PM Adam Nemet  wrote:

> BTW, I think that the LLVM bots have trouble accessing subversion too.  I
> already let Galina know.
>
>
> On Feb 26, 2018, at 10:06 PM, Shoaib Meenai  wrote:
>
> r326171 works locally. I'll keep an eye on the bots.
>
> *From: * on behalf of Adam Nemet 
> *Date: *Monday, February 26, 2018 at 9:51 PM
> *To: *Shoaib Meenai 
> *Cc: *Zachary Turner , "cfe-commits@lists.llvm.org" <
> cfe-commits@lists.llvm.org>, Reid Kleckner 
> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>
> Yep.
>
>
> On Feb 26, 2018, at 9:50 PM, Shoaib Meenai  wrote:
>
> Reid re-committed r326141 this morning (and followed up with r326144), and
> I don't think either of those have been reverted?
>
> *From: *Zachary Turner 
> *Date: *Monday, February 26, 2018 at 9:47 PM
> *To: *Adam Nemet 
> *Cc: *Shoaib Meenai , "cfe-commits@lists.llvm.org" <
> cfe-commits@lists.llvm.org>, Reid Kleckner 
> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>
> I already reverted this a long time ago, but if Shoaib has a proper fix
> that would be great
> On Mon, Feb 26, 2018 at 9:45 PM Adam Nemet  wrote:
>
> Ah, that should be sufficient.
>
>
>
>
> On Feb 26, 2018, at 9:44 PM, Shoaib Meenai  wrote:
>
> Thanks. I'm building on macOS locally to confirm the original problem and
> my fix.
>
> *From: * on behalf of Adam Nemet 
> *Date: *Monday, February 26, 2018 at 9:42 PM
> *To: *Shoaib Meenai 
> *Cc: *"cfe-commits@lists.llvm.org" , Reid
> Kleckner , Zachary Turner 
> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>
> This is the bot with the failure:
>
>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/46794/#showFailuresLink
> 
>
> But to make matters worse, greendragon is experience some difficulty
> fetching from SVN so you might want to wait until things recover.  I am not
> sure if I will be able to get in touch with Mike Edwards until the morning
> PST.
>
> There may also be llvm bots that exhibit the same problem.  You may have
> better luck with those in the short term.
>
> Adam
>
>
>
> On Feb 26, 2018, at 9:35 PM, Shoaib Meenai  wrote:
>
> Could you point me to the specific bot that was failing? I've dealt with
> that problem before, and it shouldn't be hard to fix, but I wanna monitor
> the bot after the fix to make sure it stays green.
>
> *From: * on behalf of Adam Nemet 
> *Date: *Monday, February 26, 2018 at 9:30 PM
> *To: *Shoaib Meenai 
> *Cc: *"cfe-commits@lists.llvm.org" , Reid
> Kleckner , Zachary Turner 
> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>
> I don’t think we can deal with the slash options:
>
> clang-7.0: warning:
> '/Users/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
> treated as the '/U' option [-Wslash-u-filename]
> clang-7.0: note: Use '--' to treat subsequent arguments as filenames
> clang-7.0: warning: argument unused during compilation: '/Z7'
> [-Wunused-command-line-argument]
> clang-7.0: warning: argument unused during compilation: ‘-U
> sers/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
> [-Wunused-command-line-argument]
>
> Anyhow as I said to Reid, feel free to improve the patch, I am just
> bringing back a bot that has been red for hours.
>
> Adam
>
>
>
>
> On Feb 26, 2018, at 9:22 PM, Shoaib Meenai  wrote:
>
> This seems bogus to me. CodeView can be generated on any build platform;
> it just needs the correct triple, which Reid added in r326144.
>
> *From: *cfe-commits  on behalf of
> Adam Nemet via cfe-commits 
> *Reply-To: *Adam Nemet 
> *Date: *Monday, February 26, 2018 at 8:51 PM
> *To: *"cfe-commits@lists.llvm.org" 
> *Subject: *r326168 - Attempt to fix greendragon bot after r326141
>
> Author: anemet

Re: r326168 - Attempt to fix greendragon bot after r326141

[Zachary Turner via cfe-commits]

I already reverted this a long time ago, but if Shoaib has a proper fix
that would be great
On Mon, Feb 26, 2018 at 9:45 PM Adam Nemet  wrote:

> Ah, that should be sufficient.
>
>
> On Feb 26, 2018, at 9:44 PM, Shoaib Meenai  wrote:
>
> Thanks. I'm building on macOS locally to confirm the original problem and
> my fix.
>
> *From: * on behalf of Adam Nemet 
> *Date: *Monday, February 26, 2018 at 9:42 PM
> *To: *Shoaib Meenai 
> *Cc: *"cfe-commits@lists.llvm.org" , Reid
> Kleckner , Zachary Turner 
> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>
> This is the bot with the failure:
>
>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/46794/#showFailuresLink
> 
>
> But to make matters worse, greendragon is experience some difficulty
> fetching from SVN so you might want to wait until things recover.  I am not
> sure if I will be able to get in touch with Mike Edwards until the morning
> PST.
>
> There may also be llvm bots that exhibit the same problem.  You may have
> better luck with those in the short term.
>
> Adam
>
>
> On Feb 26, 2018, at 9:35 PM, Shoaib Meenai  wrote:
>
> Could you point me to the specific bot that was failing? I've dealt with
> that problem before, and it shouldn't be hard to fix, but I wanna monitor
> the bot after the fix to make sure it stays green.
>
> *From: * on behalf of Adam Nemet 
> *Date: *Monday, February 26, 2018 at 9:30 PM
> *To: *Shoaib Meenai 
> *Cc: *"cfe-commits@lists.llvm.org" , Reid
> Kleckner , Zachary Turner 
> *Subject: *Re: r326168 - Attempt to fix greendragon bot after r326141
>
> I don’t think we can deal with the slash options:
>
> clang-7.0: warning:
> '/Users/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
> treated as the '/U' option [-Wslash-u-filename]
> clang-7.0: note: Use '--' to treat subsequent arguments as filenames
> clang-7.0: warning: argument unused during compilation: '/Z7'
> [-Wunused-command-line-argument]
> clang-7.0: warning: argument unused during compilation: ‘-U
> sers/buildslave/jenkins/workspace/apple-clang-master-RA-stage1-cmake-incremental/clang/src/tools/clang/test/Driver/codeview-column-info.c'
> [-Wunused-command-line-argument]
>
> Anyhow as I said to Reid, feel free to improve the patch, I am just
> bringing back a bot that has been red for hours.
>
> Adam
>
>
>
> On Feb 26, 2018, at 9:22 PM, Shoaib Meenai  wrote:
>
> This seems bogus to me. CodeView can be generated on any build platform;
> it just needs the correct triple, which Reid added in r326144.
>
> *From: *cfe-commits  on behalf of
> Adam Nemet via cfe-commits 
> *Reply-To: *Adam Nemet 
> *Date: *Monday, February 26, 2018 at 8:51 PM
> *To: *"cfe-commits@lists.llvm.org" 
> *Subject: *r326168 - Attempt to fix greendragon bot after r326141
>
> Author: anemet
> Date: Mon Feb 26 20:49:26 2018
> New Revision: 326168
>
> URL:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D326168-26view-3Drev=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k=oqoKnyrAT6kNwxIasdWb7eopGd0q41TFJ5Hxp_eoiZs=
> Log:
> Attempt to fix greendragon bot after r326141
>
> Modified:
> cfe/trunk/test/Driver/codeview-column-info.c
>
> Modified: cfe/trunk/test/Driver/codeview-column-info.c
> URL:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_Driver_codeview-2Dcolumn-2Dinfo.c-3Frev-3D326168-26r1-3D326167-26r2-3D326168-26view-3Ddiff=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=B6WfLLVLbYMU_571sI0XgBTcOm561QyDCKF2UOJyc-k=Hs37wkn2y2OFh6b_DWdNuK_AD--vySi-ptv_d_HDqxg=
>
> ==
> --- cfe/trunk/test/Driver/codeview-column-info.c (original)
> +++ cfe/trunk/test/Driver/codeview-column-info.c Mon Feb 26 20:49:26 2018
> @@ -1,3 +1,4 @@
> +// REQUIRES: system-windows
> // Check that -dwarf-column-info does not get added to the cc1 line:
> // 1) When -gcodeview is present via the clang or clang++ driver
> // 2) When /Z7 is present via the cl driver.
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
>
> 

r326116 - Revert "Emit proper CodeView when -gcodeview is passed without the cl driver."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Feb 26 11:51:29 2018
New Revision: 326116

URL: http://llvm.org/viewvc/llvm-project?rev=326116=rev
Log:
Revert "Emit proper CodeView when -gcodeview is passed without the cl driver."

This reverts commit e17911006548518634fad66bb8648bcad49a1d64.

This is failing on ASAN bots because asan expects column info,
and it's also failing on some linux bots for unknown reasons which
i need to investigate.

Removed:
cfe/trunk/test/Driver/codeview-column-info.c
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=326116=326115=326116=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Feb 26 11:51:29 2018
@@ -2968,7 +2968,7 @@ static void RenderDebugOptions(const Too
 
   // Forward -gcodeview. EmitCodeView might have been set by CL-compatibility
   // argument parsing.
-  if (EmitCodeView) {
+  if (Args.hasArg(options::OPT_gcodeview) || EmitCodeView) {
 // DWARFVersion remains at 0 if no explicit choice was made.
 CmdArgs.push_back("-gcodeview");
   } else if (DWARFVersion == 0 &&
@@ -3567,8 +3567,6 @@ void Clang::ConstructJob(Compilation ,
   types::ID InputType = Input.getType();
   if (D.IsCLMode())
 AddClangCLArgs(Args, InputType, CmdArgs, , );
-  else
-EmitCodeView = Args.hasArg(options::OPT_gcodeview);
 
   const Arg *SplitDWARFArg = nullptr;
   RenderDebugOptions(getToolChain(), D, RawTriple, Args, EmitCodeView,

Removed: cfe/trunk/test/Driver/codeview-column-info.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/codeview-column-info.c?rev=326115=auto
==
--- cfe/trunk/test/Driver/codeview-column-info.c (original)
+++ cfe/trunk/test/Driver/codeview-column-info.c (removed)
@@ -1,13 +0,0 @@
-// Check that -dwarf-column-info does not get added to the cc1 line:
-// 1) When -gcodeview is present via the clang or clang++ driver
-// 2) When /Z7 is present via the cl driver.
-
-// RUN: %clang -### -c -g -gcodeview %s 2> %t1
-// RUN: FileCheck < %t1 %s
-// RUN: %clangxx -### -c -g -gcodeview %s 2> %t2
-// RUN: FileCheck < %t2 %s
-// RUN: %clang_cl -### /c /Z7 %s 2> %t2
-// RUN: FileCheck < %t2 %s
-
-// CHECK: "-cc1"
-// CHECK-NOT: "-dwarf-column-info"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r326113 - Emit proper CodeView when -gcodeview is passed without the cl driver.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Feb 26 11:25:39 2018
New Revision: 326113

URL: http://llvm.org/viewvc/llvm-project?rev=326113=rev
Log:
Emit proper CodeView when -gcodeview is passed without the cl driver.

Windows debuggers don't work properly when column info is emitted
with lines.  We handled this by checking if the driver mode was
cl, but it's possible to cause the gcc driver to emit codeview as
well, and in that path we were emitting column info with codeview.

Differential Revision: https://reviews.llvm.org/D43700

Added:
cfe/trunk/test/Driver/codeview-column-info.c
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=326113=326112=326113=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Feb 26 11:25:39 2018
@@ -2968,7 +2968,7 @@ static void RenderDebugOptions(const Too
 
   // Forward -gcodeview. EmitCodeView might have been set by CL-compatibility
   // argument parsing.
-  if (Args.hasArg(options::OPT_gcodeview) || EmitCodeView) {
+  if (EmitCodeView) {
 // DWARFVersion remains at 0 if no explicit choice was made.
 CmdArgs.push_back("-gcodeview");
   } else if (DWARFVersion == 0 &&
@@ -3567,6 +3567,8 @@ void Clang::ConstructJob(Compilation ,
   types::ID InputType = Input.getType();
   if (D.IsCLMode())
 AddClangCLArgs(Args, InputType, CmdArgs, , );
+  else
+EmitCodeView = Args.hasArg(options::OPT_gcodeview);
 
   const Arg *SplitDWARFArg = nullptr;
   RenderDebugOptions(getToolChain(), D, RawTriple, Args, EmitCodeView,

Added: cfe/trunk/test/Driver/codeview-column-info.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/codeview-column-info.c?rev=326113=auto
==
--- cfe/trunk/test/Driver/codeview-column-info.c (added)
+++ cfe/trunk/test/Driver/codeview-column-info.c Mon Feb 26 11:25:39 2018
@@ -0,0 +1,13 @@
+// Check that -dwarf-column-info does not get added to the cc1 line:
+// 1) When -gcodeview is present via the clang or clang++ driver
+// 2) When /Z7 is present via the cl driver.
+
+// RUN: %clang -### -c -g -gcodeview %s 2> %t1
+// RUN: FileCheck < %t1 %s
+// RUN: %clangxx -### -c -g -gcodeview %s 2> %t2
+// RUN: FileCheck < %t2 %s
+// RUN: %clang_cl -### /c /Z7 %s 2> %t2
+// RUN: FileCheck < %t2 %s
+
+// CHECK: "-cc1"
+// CHECK-NOT: "-dwarf-column-info"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D43164: Fix test from failing when the python path has spaces

[Zachary Turner via cfe-commits]

Lgtm
On Sat, Feb 10, 2018 at 12:16 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:

> asmith created this revision.
> asmith added reviewers: zturner, llvm-commits.
> Herald added subscribers: cfe-commits, klimek.
>
> This test would fail if the python path had spaces. Add a quote around the
> path to fix this problem and update some test values changed by the
> addition of quotes around the path.
>
> Tested on Windows and Linux with Python 3.x
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D43164
>
> Files:
>   test/Tooling/clang-diff-json.cpp
>
>
> Index: test/Tooling/clang-diff-json.cpp
> ===
> --- test/Tooling/clang-diff-json.cpp
> +++ test/Tooling/clang-diff-json.cpp
> @@ -1,10 +1,10 @@
>  // RUN: clang-diff -ast-dump-json %s -- \
> -// RUN: | %python -c 'import json, sys;
> json.dump(json.loads(sys.stdin.read()), sys.stdout, sort_keys=True,
> indent=2)' \
> +// RUN: | '%python' -c 'import json, sys;
> json.dump(json.loads(sys.stdin.read()), sys.stdout, sort_keys=True,
> indent=2)' \
>  // RUN: | FileCheck %s
>
> -// CHECK: "begin": 299,
> +// CHECK: "begin": 301,
>  // CHECK: "type": "FieldDecl",
> -// CHECK: "end": 319,
> +// CHECK: "end": 321,
>  // CHECK: "type": "CXXRecordDecl",
>  class A {
>int x;
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D41444: [ASTImporterTest] Make testing under '-fdelayed-template-parsing' mandatory

[Zachary Turner via cfe-commits]

On the other hand, it doesn’t hurt anything to run the tests twice does it?
I’d feel better if this patch were *adding* test coverage as opposed to
changing coverage
On Wed, Dec 20, 2017 at 6:50 AM Gábor Horváth via Phabricator <
revi...@reviews.llvm.org> wrote:

> xazax.hun added a comment.
>
> In https://reviews.llvm.org/D41444#960848, @a.sidorin wrote:
>
> > In https://reviews.llvm.org/D41444#960841, @xazax.hun wrote:
> >
> > > Is it possible that this will hide other problems? Wouldn't it be
> better to run the tests twice once with this argument and once without it?
> >
> >
> > I don't think so. In fact, without instantiation, we are not even able
> to check semantic code correctness inside templates. So, we are solving
> this problem as well.
>
>
> E.g. the following code only compiles with `-fdelayed-template-parsing`
> flag added:
>
>   template
>   struct Base {
> int x;
>   };
>
>
>   template
>   struct Derived : Base {
> int f() {
>   return x;
> }
>   };
>
> But yeah, maybe it is not very likely that we hit such issues.
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D41444
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r320750 - Fix many -Wsign-compare and -Wtautological-constant-compare warnings.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Dec 14 14:07:03 2017
New Revision: 320750

URL: http://llvm.org/viewvc/llvm-project?rev=320750=rev
Log:
Fix many -Wsign-compare and -Wtautological-constant-compare warnings.

Most of the -Wsign-compare warnings are due to the fact that
enums are signed by default in the MS ABI, while the
tautological comparison warnings trigger on x86 builds where
sizeof(size_t) is 4 bytes, so N > numeric_limits::max()
is always false.

Differential Revision: https://reviews.llvm.org/D41256

Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=320750=320749=320750=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Thu Dec 14 14:07:03 2017
@@ -2825,7 +2825,7 @@ void CodeGenFunction::EmitCheck(
   assert(IsSanitizerScope);
   assert(Checked.size() > 0);
   assert(CheckHandler >= 0 &&
- CheckHandler < sizeof(SanitizerHandlers) / 
sizeof(*SanitizerHandlers));
+ size_t(CheckHandler) < llvm::array_lengthof(SanitizerHandlers));
   const StringRef CheckName = SanitizerHandlers[CheckHandler].Name;
 
   llvm::Value *FatalCond = nullptr;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D41081: Fix clang Lexer Windows line-ending bug

[Zachary Turner via cfe-commits]

I'll let rnk@ weigh in (he's on vacation today though).

I don't feel comfortable lgtm'ing any change where "don't use
core.autocrlf=true" is an alternative solution, but if other people want to
disagree with me and lgtm this, then that suggests I'm in the minority,
which is fine.  :)

On Mon, Dec 11, 2017 at 1:13 PM Zhen Cao  wrote:

> I think adding two lit substitutions is not a significant issue since
> dos2unix and unix2dos are common Unix utilities. This solution also has the
> advantage of testing both styles of line-endings with only one test case,
> which I think actually reduces complexity and maintenance burden.
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Monday, December 11, 2017 3:42 PM
> *To:* Benoit Belley 
> *Cc:* reviews+d41081+public+5a71b504a12c1...@reviews.llvm.org; Zhen Cao <
> zhen@autodesk.com>; r...@google.com
>
>
> *Subject:* Re: [PATCH] D41081: Fix clang Lexer Windows line-ending bug
>
>
>
> To be honest, I'm not a fan of testing code in a way that tries to work
> around issues related to source control.  I think we had a similar
> discussion before on a previous patch, and my suggested fix was to simply
> set core.autocrlf=false in your git config.  This solves all of these
> problems and does not come with any real downsides that I'm aware of.
>
>
>
> It also yields better tests IMO, because the fewer steps of translation
> that an input has to go through before being fed to the test program the
> better.  If you want to test the behavior of a file with \r\n, just check
> in an input file with \r\n and you're ready to go.  Furthermore, by not
> doing this we are adding complexity (and hence, technical debt) *to the
> code* to deal with issues that could easily be solved using an appropriate
> developer configuration.  I'm not saying that we should not be testing the
> case of \r\n newlines, because we can't control what perforce outputs and
> the tool itself needs to work with either style of newline.  But we can
> control how we configure our git clones, and if doing so leads to better
> tests with less testing infrastructure hacks and workarounds, then I think
> we should do that.
>
>
>
> On Mon, Dec 11, 2017 at 12:32 PM Benoit Belley 
> wrote:
>
> Hi Zachary,
>
>
>
> We are trying to be agnostic to how a particular SCM (SVN, Git) is
> handling line termination. For example, any CR, CRLF line-ending would be
> translated automatically by Git (CR only on unix, and CRLF on windows)
> unless these files are marked explicitly as binary files using a special
> .gitattribute file.
>
>
>
> In summary, the proposed solution is:
>
>- SCM agnostic
>- Tests the handling both types of line endings on any platforms where
>the tests are run.
>
> Cheers,
>
> Benoit
>
>
>
> *From: *Zachary Turner 
> *Date: *lundi 11 décembre 2017 à 15:22
> *To: *"reviews+d41081+public+5a71b504a12c1...@reviews.llvm.org" <
> reviews+d41081+public+5a71b504a12c1...@reviews.llvm.org>
> *Cc: *Zhen Cao , "r...@google.com" ,
> Benoit Belley 
> *Subject: *Re: [PATCH] D41081: Fix clang Lexer Windows line-ending bug
>
>
>
> Would it be possible to do this without any substitutions at all? It seems
> a little heavy handed to add a new lit substitution for something that is
> only going to be used in one test.
>
> Can we just check in two different input files, one with CR and another
> with CRLF, and use those as inputs to the test?
>
> On Mon, Dec 11, 2017 at 12:18 PM Zhen Cao via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> caoz added a subscriber: cfe-commits.
>
> https://reviews.llvm.org/D41081
> 
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D41081: Fix clang Lexer Windows line-ending bug

[Zachary Turner via cfe-commits]

See my other response. Maybe we don’t even need a substitution at all?
On Mon, Dec 11, 2017 at 12:24 PM Benoit Belley via Phabricator <
revi...@reviews.llvm.org> wrote:

> belleyb added inline comments.
>
>
> 
> Comment at: test/lit.cfg.py:52-57
> +if platform.system() in ['Windows']:
> +config.substitutions.append(('dos2unix', 'sed -b "s/\r$//"'))
> +config.substitutions.append(('unix2dos', 'sed -b "s/\r*$/\r/"'))
> +else:
> +config.substitutions.append(('dos2unix', "sed $'s/\r$//'"))
> +config.substitutions.append(('unix2dos', "sed $'s/\r*$/\r/'"))
> 
> caoz wrote:
> > zturner wrote:
> > > Since the user has `sed` already, why wouldn't they have the actual
> tool `dos2unix` and `unix2dos`?
> > Thanks Zachary. dos2unix and unix2dos aren't installed by default on
> Linux/Mac. However, if the user can be assumed to have them, I can remove
> these substitutions.
> @zturner According to https://llvm.org/docs/GettingStarted.html#software,
> we shouldn't be relying on `dos2unix` nor `unix2dos` to be present on a
> build machine.
>
> Note that the `$'string'` syntax (ANSI-C quotes) is a `bash` extension.
> According to the page mentioned above, the LLVM builds should only be
> relying on having a Bourne shell (`sh`). But, are there still any *nix
> system out there where `/bin/sh` isn't a link for `\bin\bash` ? I.e. Is
> relying on `bash+sed` fine here ?
>
> A fully portable solution would be to write python scripts for
> `dos2unix.py` and `unix2dos.py`. That way, one would not be relying on
> build tools that LLVM isn't already using.
>
> Any advice on how to proceed ?
>
>
>
>
> https://reviews.llvm.org/D41081
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r319505 - Mark all library options as hidden.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Nov 30 16:53:10 2017
New Revision: 319505

URL: http://llvm.org/viewvc/llvm-project?rev=319505=rev
Log:
Mark all library options as hidden.

These command line options are not intended for public use, and often
don't even make sense in the context of a particular tool anyway. About
90% of them are already hidden, but when people add new options they
forget to hide them, so if you were to make a brand new tool today, link
against one of LLVM's libraries, and run tool -help you would get a
bunch of junk that doesn't make sense for the tool you're writing.

This patch hides these options. The real solution is to not have
libraries defining command line options, but that's a much larger effort
and not something I'm prepared to take on.

Differential Revision: https://reviews.llvm.org/D40674

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=319505=319504=319505=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Thu Nov 30 16:53:10 2017
@@ -61,7 +61,7 @@ using namespace clang;
 using namespace CodeGen;
 
 static llvm::cl::opt LimitedCoverage(
-"limited-coverage-experimental", llvm::cl::ZeroOrMore,
+"limited-coverage-experimental", llvm::cl::ZeroOrMore, llvm::cl::Hidden,
 llvm::cl::desc("Emit limited coverage mapping information (experimental)"),
 llvm::cl::init(false));
 

Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenPGO.cpp?rev=319505=319504=319505=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Thu Nov 30 16:53:10 2017
@@ -22,9 +22,10 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MD5.h"
 
-static llvm::cl::opt EnableValueProfiling(
-  "enable-value-profiling", llvm::cl::ZeroOrMore,
-  llvm::cl::desc("Enable value profiling"), llvm::cl::init(false));
+static llvm::cl::opt
+EnableValueProfiling("enable-value-profiling", llvm::cl::ZeroOrMore,
+ llvm::cl::desc("Enable value profiling"),
+ llvm::cl::Hidden, llvm::cl::init(false));
 
 using namespace clang;
 using namespace CodeGen;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r318722 - Re-revert "Refactor debuginfo-tests."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Nov 20 17:20:28 2017
New Revision: 318722

URL: http://llvm.org/viewvc/llvm-project?rev=318722=rev
Log:
Re-revert "Refactor debuginfo-tests."

This is still breaking greendragon.

At this point I give up until someone can fix the greendragon
bots, and I will probably abandon this effort in favor of using
a private github repository.

Modified:
cfe/trunk/test/CMakeLists.txt
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=318722=318721=318722=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Mon Nov 20 17:20:28 2017
@@ -88,14 +88,6 @@ set(CLANG_TEST_PARAMS
   clang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   )
 
-if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
-  # This is a hack to keep existing build build infrastructure working while we
-  # can migrate to the new standard workflow of checking out debuginfo-tests 
into
-  # llvm/projects or using it in a mono-repo
-  set(DEBUGINFO_TESTS_EXCLUDE_FROM_ALL ON)
-  add_subdirectory(debuginfo-tests)
-endif()
-
 if( NOT CLANG_BUILT_STANDALONE )
   list(APPEND CLANG_TEST_DEPS
 llvm-config

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=318722=318721=318722=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Mon Nov 20 17:20:28 2017
@@ -58,6 +58,8 @@ tool_dirs = [config.clang_tools_dir, con
 
 tools = [
 'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
+ToolSubst('%test_debuginfo', command=os.path.join(
+config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
 ToolSubst('%clang_func_map', command=FindTool(
 'clang-func-mapping'), unresolved='ignore'),
 ]


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r318697 - Resubmit "Refactor debuginfo-tests" again.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Nov 20 13:41:36 2017
New Revision: 318697

URL: http://llvm.org/viewvc/llvm-project?rev=318697=rev
Log:
Resubmit "Refactor debuginfo-tests" again.

This was reverted due to the tests being run twice on some
build bots.  Each run had a slightly different configuration
due to the way in which it was being invoked.  This fixes
the problem (albeit in a somewhat hacky way).  Hopefully in
the future we can get rid of the workflow of running
debuginfo-tests as part of clang, and then this hack can
go away.

Modified:
cfe/trunk/test/CMakeLists.txt
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=318697=318696=318697=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Mon Nov 20 13:41:36 2017
@@ -88,6 +88,14 @@ set(CLANG_TEST_PARAMS
   clang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   )
 
+if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
+  # This is a hack to keep existing build build infrastructure working while we
+  # can migrate to the new standard workflow of checking out debuginfo-tests 
into
+  # llvm/projects or using it in a mono-repo
+  set(DEBUGINFO_TESTS_EXCLUDE_FROM_ALL ON)
+  add_subdirectory(debuginfo-tests)
+endif()
+
 if( NOT CLANG_BUILT_STANDALONE )
   list(APPEND CLANG_TEST_DEPS
 llvm-config

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=318697=318696=318697=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Mon Nov 20 13:41:36 2017
@@ -58,8 +58,6 @@ tool_dirs = [config.clang_tools_dir, con
 
 tools = [
 'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
-ToolSubst('%test_debuginfo', command=os.path.join(
-config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
 ToolSubst('%clang_func_map', command=FindTool(
 'clang-func-mapping'), unresolved='ignore'),
 ]


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D40217: [LIT] Fix testing out-of-tree Clang builds

[Zachary Turner via cfe-commits]

+mgorny

On Sat, Nov 18, 2017 at 2:24 PM Eric Fiselier via Phabricator <
revi...@reviews.llvm.org> wrote:

> EricWF created this revision.
> Herald added a reviewer: modocache.
>
> Currently, LIT configures the LLVM binary path before the Clang binary
> path. However this breaks testing out-of-tree Clang builds (where the LLVM
> binary path includes a copy of Clang).
>
> This patch reverses the order of the paths when looking for Clang, putting
> the Clang binary directory first.
>
>
> https://reviews.llvm.org/D40217
>
> Files:
>   utils/lit/lit/llvm/config.py
>
>
> Index: utils/lit/lit/llvm/config.py
> ===
> --- utils/lit/lit/llvm/config.py
> +++ utils/lit/lit/llvm/config.py
> @@ -369,8 +369,9 @@
>  # Tweak the PATH to include the tools dir and the scripts dir.
>  paths = [self.config.llvm_tools_dir]
>  tools = getattr(self.config, 'clang_tools_dir', None)
> +# Put Clang first to avoid LLVM from overriding out-of-tree clang
> builds.
>  if tools:
> -paths = paths + [tools]
> +paths = [tools] + paths
>  self.with_environment('PATH', paths, append_path=True)
>
>  paths = [self.config.llvm_shlib_dir, self.config.llvm_libs_dir]
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r318486 - Re-revert "Refactor debuginfo-tests"

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Nov 16 16:41:18 2017
New Revision: 318486

URL: http://llvm.org/viewvc/llvm-project?rev=318486=rev
Log:
Re-revert "Refactor debuginfo-tests"

This is still broken because it causes certain tests to be
run twice with slightly different configurations, which is
wrong in some cases.

You can observe this by running:

  ninja -nv check-all | grep debuginfo-tests

And seeing that it passes clang/test and clang/test/debuginfo-tests
to lit, which causes it to run debuginfo-tests twice.  The fix is
going to involve either:

  a) figuring out that we're running in this "deprecated" configuration,
 and then deleting the clang/test/debuginfo-tests path, which should
 cause it to behave identically to before, or:
  b) make lit smart enough that it doesn't descend into a sub-suite if
 that sub-suite already has a lit.cfg file.

Modified:
cfe/trunk/test/CMakeLists.txt
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=318486=318485=318486=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Thu Nov 16 16:41:18 2017
@@ -88,13 +88,6 @@ set(CLANG_TEST_PARAMS
   clang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   )
 
-if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
-  # This is a hack to keep existing build build infrastructure working while we
-  # can migrate to the new standard workflow of checking out debuginfo-tests 
into
-  # llvm/projects or using it in a mono-repo
-  add_subdirectory(debuginfo-tests)
-endif()
-
 if( NOT CLANG_BUILT_STANDALONE )
   list(APPEND CLANG_TEST_DEPS
 llvm-config

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=318486=318485=318486=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Thu Nov 16 16:41:18 2017
@@ -58,6 +58,8 @@ tool_dirs = [config.clang_tools_dir, con
 
 tools = [
 'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
+ToolSubst('%test_debuginfo', command=os.path.join(
+config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
 ToolSubst('%clang_func_map', command=FindTool(
 'clang-func-mapping'), unresolved='ignore'),
 ]


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r318435 - Resubmit "Refactor debuginfo-tests"

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Nov 16 10:26:20 2017
New Revision: 318435

URL: http://llvm.org/viewvc/llvm-project?rev=318435=rev
Log:
Resubmit "Refactor debuginfo-tests"

This was reverted due to some failures on specific darwin buildbots,
the issue being that the new lit configuration was not setting the
SDKROOT environment variable.  We've tested a fix locally and confirmed
that it works, so this patch resubmits everything with the fix
applied.

Modified:
cfe/trunk/test/CMakeLists.txt
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=318435=318434=318435=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Thu Nov 16 10:26:20 2017
@@ -88,6 +88,13 @@ set(CLANG_TEST_PARAMS
   clang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   )
 
+if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
+  # This is a hack to keep existing build build infrastructure working while we
+  # can migrate to the new standard workflow of checking out debuginfo-tests 
into
+  # llvm/projects or using it in a mono-repo
+  add_subdirectory(debuginfo-tests)
+endif()
+
 if( NOT CLANG_BUILT_STANDALONE )
   list(APPEND CLANG_TEST_DEPS
 llvm-config

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=318435=318434=318435=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Thu Nov 16 10:26:20 2017
@@ -58,8 +58,6 @@ tool_dirs = [config.clang_tools_dir, con
 
 tools = [
 'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
-ToolSubst('%test_debuginfo', command=os.path.join(
-config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
 ToolSubst('%clang_func_map', command=FindTool(
 'clang-func-mapping'), unresolved='ignore'),
 ]


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r318112 - Revert "Update test_debuginfo.pl script to point to new tree location."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Nov 13 15:33:29 2017
New Revision: 318112

URL: http://llvm.org/viewvc/llvm-project?rev=318112=rev
Log:
Revert "Update test_debuginfo.pl script to point to new tree location."

This reverts the aforementioned patch and 2 subsequent follow-ups,
as some buildbots are still failing 2 tests because of it.
Investigation is ongoing into the cause of the failures.

Modified:
cfe/trunk/test/CMakeLists.txt
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=318112=318111=318112=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Mon Nov 13 15:33:29 2017
@@ -88,13 +88,6 @@ set(CLANG_TEST_PARAMS
   clang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   )
 
-if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
-  # This is a hack to keep existing build build infrastructure working while we
-  # can migrate to the new standard workflow of checking out debuginfo-tests 
into
-  # llvm/projects or using it in a mono-repo
-  add_subdirectory(debuginfo-tests)
-endif()
-
 if( NOT CLANG_BUILT_STANDALONE )
   list(APPEND CLANG_TEST_DEPS
 llvm-config

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=318112=318111=318112=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Mon Nov 13 15:33:29 2017
@@ -58,6 +58,8 @@ tool_dirs = [config.clang_tools_dir, con
 
 tools = [
 'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
+ToolSubst('%test_debuginfo', command=os.path.join(
+config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
 ToolSubst('%clang_func_map', command=FindTool(
 'clang-func-mapping'), unresolved='ignore'),
 ]


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r317931 - Fix for skipped CMake configuration on debuginfo-tests.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Nov 10 14:12:04 2017
New Revision: 317931

URL: http://llvm.org/viewvc/llvm-project?rev=317931=rev
Log:
Fix for skipped CMake configuration on debuginfo-tests.

This should have been part of the change to debuginfo-tests, but
it was left out.  This should get the buildbots green.

Modified:
cfe/trunk/test/CMakeLists.txt

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=317931=317930=317931=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Fri Nov 10 14:12:04 2017
@@ -88,6 +88,13 @@ set(CLANG_TEST_PARAMS
   clang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   )
 
+if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
+  # This is a hack to keep existing build build infrastructure working while we
+  # can migrate to the new standard workflow of checking out debuginfo-tests 
into
+  # llvm/projects or using it in a mono-repo
+  add_subdirectory(debuginfo-tests)
+endif()
+
 if( NOT CLANG_BUILT_STANDALONE )
   list(APPEND CLANG_TEST_DEPS
 llvm-config


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r317925 - [debuginfo-tests] Make debuginfo-tests work in a standard configuration.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Nov 10 12:57:57 2017
New Revision: 317925

URL: http://llvm.org/viewvc/llvm-project?rev=317925=rev
Log:
[debuginfo-tests] Make debuginfo-tests work in a standard configuration.

Previously, debuginfo-tests was expected to be checked out into
clang/test and then the tests would automatically run as part of
check-clang.  This is not a standard workflow for handling
external projects, and it brings with it some serious drawbacks
such as the inability to depend on things other than clang, which
we will need going forward.

The goal of this patch is to migrate towards a more standard
workflow.  To ease the transition for build bot maintainers,
this patch tries not to break the existing workflow, but instead
simply deprecate it to give maintainers a chance to update
the build infrastructure.

Differential Revision: https://reviews.llvm.org/D39605

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=317925=317924=317925=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Fri Nov 10 12:57:57 2017
@@ -58,8 +58,6 @@ tool_dirs = [config.clang_tools_dir, con
 
 tools = [
 'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
-ToolSubst('%test_debuginfo', command=os.path.join(
-config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
 ToolSubst('%clang_func_map', command=FindTool(
 'clang-func-mapping'), unresolved='ignore'),
 ]


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

[Zachary Turner via cfe-commits]

The reason I ask is because I remember several months ago when I originally
made these changes, there was quite a bit of difficulty because some of the
Jenkins builders were wanting to run libcxx tests without any llvm source
tree on the machine.

Does this configuration still exist, or is it gone?  If it is gone, I think
many libcxx maintainers would be very happy if they can assume the presence
of an LLVM source tree somewhere on the disk.

On Fri, Nov 3, 2017 at 3:18 PM Volodymyr Sapsai  wrote:

> We have llvm source tree next to libcxx and configure libcxx with
> -DLLVM_PATH.
>
>
> On Nov 2, 2017, at 16:53, Zachary Turner  wrote:
>
> No problem.  If you don't mind me asking, what was the configuration
> change you made?  Or do you have a link to the patch which fixed it that I
> can look at?
>
> On Thu, Nov 2, 2017 at 4:43 PM Volodymyr Sapsai via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> vsapsai abandoned this revision.
>> vsapsai added a comment.
>>
>> Fixed by changing libcxx build configuration, no CMake change required.
>>
>>
>> https://reviews.llvm.org/D39520
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

[Zachary Turner via cfe-commits]

No problem.  If you don't mind me asking, what was the configuration change
you made?  Or do you have a link to the patch which fixed it that I can
look at?

On Thu, Nov 2, 2017 at 4:43 PM Volodymyr Sapsai via Phabricator <
revi...@reviews.llvm.org> wrote:

> vsapsai abandoned this revision.
> vsapsai added a comment.
>
> Fixed by changing libcxx build configuration, no CMake change required.
>
>
> https://reviews.llvm.org/D39520
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

[Zachary Turner via cfe-commits]

Yes that is the reason.  But in a way it is more than that, because if
those variables aren't available to lit.cfg, then test suite won't work.
lit *must* be able to find a site config.

There are three ways to get around this:

1) When you run lit.py, pass it a directory to your build tree.  Then it
points right to the site config, and everything works.  The disadvantage to
this method is that you might want to just run test, i.e. point lit to a
single file in your source tree.  You can't do that with this method.

2) pass param=libcxx_site_config= to lit.  This is
cumbersome and a lot of typing.  It might also not work 100% like you
expect when used in conjunction with pointing to a single file in source
tree.  I don't know, I haven't really tested it.

3) use the generated llvm-lit script.  This embeds the mapping from source
tree site config -> build tree site config in the script, so that instead
of `lit ` you run `llvm-lit `.  This way, we
can detect that that you are pointing into the source tree, translate that
to the build tree, and then load the proper site config automatically.

On Thu, Nov 2, 2017 at 3:44 PM Volodymyr Sapsai  wrote:

> On Nov 1, 2017, at 17:22, Zachary Turner  wrote:
>
>
>
>
> On Wed, Nov 1, 2017 at 5:13 PM Volodymyr Sapsai  wrote:
>
>> On Nov 1, 2017, at 16:47, Zachary Turner  wrote:
>>
>>
>> This will remove the ability to use llvm-lit script even if source tree
>> is available.
>>
>> Can you please point me to the place where llvm-lit is enabled in
>> configure_lit_site_cfg? Asking for my education, to understand lit
>> configuration better and to avoid breaking it. And how do you test llvm-lit
>> script if source tree is available? I tried to check out libcxx to
>> llvm/projects/, `ninja check-libcxx` worked fine. Though I didn’t use extra
>> options, so this case might not reflect real-world usage.
>>
>
> configure_lit_site_cfg doesn't actually enable llvm-lit generation, but if
> llvm-lit generation is already enabled, then using configure_lit_site_cfg
> will cause additional information to be written to the generated llvm-lit
> script so that you can use bin/llvm-lit .
>
> I think all you need to do is say:
>
> if (LIBCXX_STANDALONE_BUILD)
>   configure_file(...
> else()
>configure_lit_site_cfg(...
> endif()
>
> If this doesn't work for some reason though, or is too much effort, I'm
> not opposed to your original patch, since I think llvm-lit script
> generation is unconditionally disabled for libcxx right now anyway.
>
>
>
> Thanks, now I see that with my change in llvm-lit there is no mapping in
> config_map for libcxx/test/lit.cfg What is the purpose of this mapping? Is
> it only to make variables from lit.site.cfg.in expanded during
> configuration available to lit.cfg? Or are there some other use cases?
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

[Zachary Turner via cfe-commits]

On Wed, Nov 1, 2017 at 5:13 PM Volodymyr Sapsai  wrote:

> On Nov 1, 2017, at 16:47, Zachary Turner  wrote:
>
>
> This will remove the ability to use llvm-lit script even if source tree is
> available.
>
> Can you please point me to the place where llvm-lit is enabled in
> configure_lit_site_cfg? Asking for my education, to understand lit
> configuration better and to avoid breaking it. And how do you test llvm-lit
> script if source tree is available? I tried to check out libcxx to
> llvm/projects/, `ninja check-libcxx` worked fine. Though I didn’t use extra
> options, so this case might not reflect real-world usage.
>

configure_lit_site_cfg doesn't actually enable llvm-lit generation, but if
llvm-lit generation is already enabled, then using configure_lit_site_cfg
will cause additional information to be written to the generated llvm-lit
script so that you can use bin/llvm-lit .

I think all you need to do is say:

if (LIBCXX_STANDALONE_BUILD)
  configure_file(...
else()
   configure_lit_site_cfg(...
endif()

If this doesn't work for some reason though, or is too much effort, I'm not
opposed to your original patch, since I think llvm-lit script generation is
unconditionally disabled for libcxx right now anyway.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

[Zachary Turner via cfe-commits]

This will remove the ability to use llvm-lit script even if source tree is
available.

Can you put this behind a check that for standalone build?

Also, why was this just found? shouldnt this have been failing on Apple’s
libcxx for the past several months?
On Wed, Nov 1, 2017 at 4:38 PM Volodymyr Sapsai via Phabricator <
revi...@reviews.llvm.org> wrote:

> vsapsai created this revision.
> Herald added a subscriber: mgorny.
>
> Fixes error
>
> > CMake Error at test/CMakeLists.txt:52 (configure_lit_site_cfg):
> >  Unknown CMake command "configure_lit_site_cfg".
>
> configure_lit_site_cfg is defined in AddLLVM module and not available
> without LLVM source tree. Revert back to configure_file (reverts part of
> r313643).  It is possible as libcxx/test/lit.site.cfg.in doesn't use
> latest lit capabilities.
>
> Tested with
>
> - in-tree libcxx - no change in generated lit.site.cfg and running tests;
> - standalone libcxx with lit checked out next to it - no CMake errors.
>
> If there are other tricky configurations worth testing, let me know.
>
> rdar://problem/35303262
>
>
> https://reviews.llvm.org/D39520
>
> Files:
>   libcxx/test/CMakeLists.txt
>
>
> Index: libcxx/test/CMakeLists.txt
> ===
> --- libcxx/test/CMakeLists.txt
> +++ libcxx/test/CMakeLists.txt
> @@ -49,9 +49,10 @@
>
>  set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not
> edit!")
>
> -configure_lit_site_cfg(
> +configure_file(
>${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
> -  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
> +  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
> +  @ONLY)
>
>  set(LIBCXX_TEST_DEPS "")
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

[Zachary Turner via cfe-commits]

looks good!  Feel free to commit whenever, I'd definitely recommend posting
a PSA on cfe-dev@ (after you commit) so that people know about it.  You
might also get some useful ideas for improvements that way too.

On Thu, Oct 26, 2017 at 9:52 PM Don Hinton  wrote:

> On Thu, Oct 26, 2017 at 5:44 PM, Zachary Turner 
> wrote:
>
>>
>>
>> On Thu, Oct 26, 2017 at 3:18 PM Don Hinton  wrote:
>>
>>> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner 
>>> wrote:
>>>
 Seems fine, it would be nice if the workflow could be improved a little
 bit so that all you have to do is say `clangdiag break
 —error=“-Wcovered-switch”` or something . I think that gives the most
 intuitive usage for people, even it’s a bit harder to implement.

>>>
>>> The idea was to break on actual diagnostics emitted, but if you want to
>>> break on diagnostic usage, i.e., when it was checked but not emitted, I
>>> suppose that's possible as well.  diagtool doesn't produce a mapping for
>>> this, but it could be added -- assuming tablegen produced enough info in
>>> the .inc files to support it.  I added the feature I'm using here a few
>>> months ago, which was an extension to what Alex added earlier.
>>>
>>
>> That was my idea too.  But still, wouldn't it be possible to say
>> `clangdiag break --error="-Wcovered-switch"` and then have it break only
>> when the -Wcovered-switch diagnostic is *emitted*?
>>
>
> Please give it a try, e.g., here are a few I tried:
>
> clangdiag enable covered-switch-default
> clangdiag enable c++11-compat
>
> You can't pass the "-W" part since argparse thinks it's an option (can
> probably fix that if it's a problem), and you must provide the entire
> name.  You can get the available names from diagtool, e.g.:
>
> diagtool list-warnings
>
> Please let me know what you think, and thanks for suggesting it.
>
>
>
>>
>> The reason I keep using this syntax though is because clang developers
>> always think in terms of the warning names.  If you want to find out why a
>> warning is being emitted amidst a spew of other warnings and errors, you
>> really want to be able to specify the name of the warning.
>>
>> Don't get me wrong though, I do think this is a nice feature, I'm just
>> thinking of ways to make it more compelling by looking at it from the clang
>> developer's perspective and how they will most likely want to use it.
>>
>> Also, I still think it should go in lldb, not in clang.  That's kind of
>> exactly what the lldb/examples folder is for.
>>
>> That said, lgtm, but I'm still interested to see if the workflow can be
>> streamlined down the line.  Perhaps after it gets checked in you can make a
>> PSA on cfe-dev@ and mention that you want people to try it out and offer
>> feedback ;-)
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

[Zachary Turner via cfe-commits]

On Thu, Oct 26, 2017 at 3:18 PM Don Hinton  wrote:

> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner 
> wrote:
>
>> Seems fine, it would be nice if the workflow could be improved a little
>> bit so that all you have to do is say `clangdiag break
>> —error=“-Wcovered-switch”` or something . I think that gives the most
>> intuitive usage for people, even it’s a bit harder to implement.
>>
>
> The idea was to break on actual diagnostics emitted, but if you want to
> break on diagnostic usage, i.e., when it was checked but not emitted, I
> suppose that's possible as well.  diagtool doesn't produce a mapping for
> this, but it could be added -- assuming tablegen produced enough info in
> the .inc files to support it.  I added the feature I'm using here a few
> months ago, which was an extension to what Alex added earlier.
>

That was my idea too.  But still, wouldn't it be possible to say `clangdiag
break --error="-Wcovered-switch"` and then have it break only when the
-Wcovered-switch diagnostic is *emitted*?

The reason I keep using this syntax though is because clang developers
always think in terms of the warning names.  If you want to find out why a
warning is being emitted amidst a spew of other warnings and errors, you
really want to be able to specify the name of the warning.

Don't get me wrong though, I do think this is a nice feature, I'm just
thinking of ways to make it more compelling by looking at it from the clang
developer's perspective and how they will most likely want to use it.

Also, I still think it should go in lldb, not in clang.  That's kind of
exactly what the lldb/examples folder is for.

That said, lgtm, but I'm still interested to see if the workflow can be
streamlined down the line.  Perhaps after it gets checked in you can make a
PSA on cfe-dev@ and mention that you want people to try it out and offer
feedback ;-)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

[Zachary Turner via cfe-commits]

Seems fine, it would be nice if the workflow could be improved a little bit
so that all you have to do is say `clangdiag break
—error=“-Wcovered-switch”` or something . I think that gives the most
intuitive usage for people, even it’s a bit harder to implement.

I also think user shouldn’t really have to concern themselves with
diagtool, it should all just be magic. I get why it’s easier to do this
way, but from the users perspective, having the commands map as closely as
possible to the thing the person wants to do and hiding implementation
details is a big win from a usability standpoint.

We can iterate on it later though
On Thu, Oct 26, 2017 at 2:38 PM Don Hinton via Phabricator <
revi...@reviews.llvm.org> wrote:

> hintonda updated this revision to Diff 120492.
> hintonda added a comment.
>
> - Remove debugging print statement, and enhance help message.
>
>
> https://reviews.llvm.org/D36347
>
> Files:
>   utils/clangdiag.py
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39162: [test] Fix clang-test for FreeBSD and NetBSD

[Zachary Turner via cfe-commits]

Because this is not tge only part of ghe library search algorithm, and it’s
not necessarily an error if the variable isn’t set

On Sun, Oct 22, 2017 at 1:56 PM Zhihao Yuan via Phabricator <
revi...@reviews.llvm.org> wrote:

> lichray marked an inline comment as done.
> lichray added a comment.
>
> In https://reviews.llvm.org/D39162#903179, @zturner wrote:
>
> > Please don't throw an exception here.  Instead, write this as:
> >
> >   lit_config.warning('Unable to determine shared library path variable
> for platform {}'.format(platform.system()))
> >
> >
>
>
> Why a warning rather than fatal?
>
>
> https://reviews.llvm.org/D39162
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r316247 - [clang-tidy] Remove MSVC inline assembly test from cross-plat test.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct 20 16:09:20 2017
New Revision: 316247

URL: http://llvm.org/viewvc/llvm-project?rev=316247=rev
Log:
[clang-tidy] Remove MSVC inline assembly test from cross-plat test.

This originally started out here in dev, but I moved it to another
file when it became clear this wouldn't work on non-Windows.
Unfortunately I forgot to remove it from this file.  Test is still
live, just in another source file.

Modified:
clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp

Modified: clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp?rev=316247=316246=316247=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp Fri Oct 20 
16:09:20 2017
@@ -9,9 +9,4 @@ static int s asm("spam");
 void f() {
   __asm("mov al, 2");
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use inline assembler in 
safety-critical code [hicpp-no-assembler]
-
-  _asm {
-mov al, 2;
-// CHECK-MESSAGES: :[[@LINE-2]]:3: warning: do not use inline assembler in 
safety-critical code [hicpp-no-assembler]
-  }
 }


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r316246 - [clang-tidy] Don't error on MS-style inline assembly.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct 20 16:00:51 2017
New Revision: 316246

URL: http://llvm.org/viewvc/llvm-project?rev=316246=rev
Log:
[clang-tidy] Don't error on MS-style inline assembly.

To get MS-style inline assembly, we need to link in the various
backends.  Some other clang tools already do this, and this issue
has been raised with clang-tidy several times, indicating there
is sufficient desire to make this work.

Differential Revision: https://reviews.llvm.org/D38549

Added:
clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler-msvc.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp

Modified: clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/CMakeLists.txt?rev=316246=316245=316246=diff
==
--- clang-tools-extra/trunk/clang-tidy/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/CMakeLists.txt Fri Oct 20 16:00:51 2017
@@ -1,4 +1,7 @@
 set(LLVM_LINK_COMPONENTS
+  AllTargetsAsmParsers
+  AllTargetsDescs
+  AllTargetsInfos
   Support
   )
 

Modified: clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp?rev=316246=316245=316246=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp Fri Oct 20 
16:00:51 2017
@@ -18,6 +18,7 @@
 #include "../ClangTidy.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "llvm/Support/Process.h"
+#include "llvm/Support/TargetSelect.h"
 
 using namespace clang::ast_matchers;
 using namespace clang::driver;
@@ -403,6 +404,10 @@ static int clangTidyMain(int argc, const
 
   ProfileData Profile;
 
+  llvm::InitializeAllTargetInfos();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmParsers();
+
   ClangTidyContext Context(std::move(OwningOptionsProvider));
   runClangTidy(Context, OptionsParser.getCompilations(), PathList,
EnableCheckProfile ?  : nullptr);

Added: clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler-msvc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler-msvc.cpp?rev=316246=auto
==
--- clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler-msvc.cpp (added)
+++ clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler-msvc.cpp Fri Oct 
20 16:00:51 2017
@@ -0,0 +1,9 @@
+// REQUIRES: system-windows
+// RUN: %check_clang_tidy %s hicpp-no-assembler %t
+
+void f() {
+  _asm {
+mov al, 2;
+// CHECK-MESSAGES: :[[@LINE-2]]:3: warning: do not use inline assembler in 
safety-critical code [hicpp-no-assembler]
+  }
+}

Modified: clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp?rev=316246=316245=316246=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/hicpp-no-assembler.cpp Fri Oct 20 
16:00:51 2017
@@ -9,4 +9,9 @@ static int s asm("spam");
 void f() {
   __asm("mov al, 2");
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use inline assembler in 
safety-critical code [hicpp-no-assembler]
+
+  _asm {
+mov al, 2;
+// CHECK-MESSAGES: :[[@LINE-2]]:3: warning: do not use inline assembler in 
safety-critical code [hicpp-no-assembler]
+  }
 }


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36347: Add new script to launch lldb and set breakpoints for diagnostics all diagnostics seen.

[Zachary Turner via cfe-commits]

+jingham


On Fri, Oct 20, 2017 at 6:57 AM Don Hinton via Phabricator <
revi...@reviews.llvm.org> wrote:

> hintonda added a comment.
>
> In https://reviews.llvm.org/D36347#901885, @zturner wrote:
>
> > One possible reason for why this never got any traction is that
> `lldb-commits` wasn't added as a subscriber.  While it's true that the
> tagged people should have chimed in, having the whole commits list will get
> some more visibility.  I never saw this come to my inbox.
> >
> > I think this would be most suitable in the `lldb/examples` folder.
> >
> > I can't really review this thoroughly, because it relies on a bash
> script, and I use Windows where we bash isn't really a thing.  My bash is
> rusty, but it looks like you're embedding a python script in the bash
> script?  It might be good if this were just an lldb script command.  Take a
> look at `command script add` in LLDB, and in the `examples` folder for some
> examples of existing commands that work this way.  The nice thing about
> doing it this way is that you could just be inside LLDB and write `(lldb)
> break-diag -Wcovered-switch`, for example, which would be a much tighter
> integration with the debugger.
>
>
> Thanks for taking a look.
>
> I mainly work on *nix systems, hence the initial shell script, but if
> there's an interest, I'll be happy to convert it to a single python script
> as you suggest, and resubmit it as a patch to lldb.
>
> Thanks again...
>
>
> https://reviews.llvm.org/D36347
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r316043 - Resubmit "[lit] Raise the logic for enabling clang & lld substitutions to llvm."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Tue Oct 17 16:43:36 2017
New Revision: 316043

URL: http://llvm.org/viewvc/llvm-project?rev=316043=rev
Log:
Resubmit "[lit] Raise the logic for enabling clang & lld substitutions to llvm."

The substitution for %debuginfo_tests had been inadvertently removed.
This adds it back.

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=316043=316042=316043=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Tue Oct 17 16:43:36 2017
@@ -39,162 +39,45 @@ config.test_source_root = os.path.dirnam
 # test_exec_root: The root path where tests should be run.
 config.test_exec_root = os.path.join(config.clang_obj_root, 'test')
 
-# Clear some environment variables that might affect Clang.
-#
-# This first set of vars are read by Clang, but shouldn't affect tests
-# that aren't specifically looking for these features, or are required
-# simply to run the tests at all.
-#
-# FIXME: Should we have a tool that enforces this?
-
-# safe_env_vars = ('TMPDIR', 'TEMP', 'TMP', 'USERPROFILE', 'PWD',
-#  'MACOSX_DEPLOYMENT_TARGET', 'IPHONEOS_DEPLOYMENT_TARGET',
-#  'VCINSTALLDIR', 'VC100COMNTOOLS', 'VC90COMNTOOLS',
-#  'VC80COMNTOOLS')
-possibly_dangerous_env_vars = ['COMPILER_PATH', 'RC_DEBUG_OPTIONS',
-   'CINDEXTEST_PREAMBLE_FILE', 'LIBRARY_PATH',
-   'CPATH', 'C_INCLUDE_PATH', 'CPLUS_INCLUDE_PATH',
-   'OBJC_INCLUDE_PATH', 'OBJCPLUS_INCLUDE_PATH',
-   'LIBCLANG_TIMING', 'LIBCLANG_OBJTRACKING',
-   'LIBCLANG_LOGGING', 'LIBCLANG_BGPRIO_INDEX',
-   'LIBCLANG_BGPRIO_EDIT', 'LIBCLANG_NOTHREADS',
-   'LIBCLANG_RESOURCE_USAGE',
-   'LIBCLANG_CODE_COMPLETION_LOGGING']
-# Clang/Win32 may refer to %INCLUDE%. vsvarsall.bat sets it.
-if platform.system() != 'Windows':
-possibly_dangerous_env_vars.append('INCLUDE')
-
-llvm_config.clear_environment(possibly_dangerous_env_vars)
-
-# Tweak the PATH to include the tools dir and the scripts dir.
-llvm_config.with_environment(
-'PATH', [config.llvm_tools_dir, config.clang_tools_dir], append_path=True)
+llvm_config.use_default_substitutions()
 
-llvm_config.with_environment('LD_LIBRARY_PATH', [
- config.llvm_shlib_dir, config.llvm_libs_dir], 
append_path=True)
+llvm_config.use_clang()
 
 # Propagate path to symbolizer for ASan/MSan.
 llvm_config.with_system_environment(
 ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH'])
 
-llvm_config.use_default_substitutions()
-
-# Discover the 'clang' and 'clangcc' to use.
-
-
-def inferClang(PATH):
-# Determine which clang to use.
-clang = os.getenv('CLANG')
-
-# If the user set clang in the environment, definitely use that and don't
-# try to validate.
-if clang:
-return clang
-
-# Otherwise look in the path.
-clang = lit.util.which('clang', PATH)
-
-if not clang:
-lit_config.fatal("couldn't find 'clang' program, try setting "
- 'CLANG in your environment')
-
-return clang
-
-
-config.clang = inferClang(config.environment['PATH']).replace('\\', '/')
-if not lit_config.quiet:
-lit_config.note('using clang: %r' % config.clang)
-
-# Plugins (loadable modules)
-# TODO: This should be supplied by Makefile or autoconf.
-if sys.platform in ['win32', 'cygwin']:
-has_plugins = config.enable_shared
-else:
-has_plugins = True
-
-if has_plugins and config.llvm_plugin_ext:
-config.available_features.add('plugins')
-
-config.substitutions.append(('%llvmshlibdir', config.llvm_shlib_dir))
-config.substitutions.append(('%pluginext', config.llvm_plugin_ext))
 config.substitutions.append(('%PATH%', config.environment['PATH']))
 
-if config.clang_examples:
-config.available_features.add('examples')
 
-builtin_include_dir = llvm_config.get_clang_builtin_include_dir(config.clang)
+# For each occurrence of a clang tool name, replace it with the full path to
+# the build directory holding that tool.  We explicitly specify the directories
+# to search to ensure that we get the tools just built and not some random
+# tools that might happen to be in the user's PATH.
+tool_dirs = [config.clang_tools_dir, config.llvm_tools_dir]
 
 tools = [
-# By specifying %clang_cc1 as part of the substitution, this substitution
-# relies on repeated substitution, so must come before %clang_cc1.
-ToolSubst('%clang_analyze_cc1', command='%clang_cc1',
-  extra_args=['-analyze', '%analyze']),
-ToolSubst('%clang_cc1', command=config.clang, extra_args=[
-  '-cc1', '-internal-isystem', builtin_include_dir, 
'-nostdsysteminc']),
-

r315627 - [lit] Raise the logic for enabling clang & lld substitutions to llvm.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Oct 12 14:56:05 2017
New Revision: 315627

URL: http://llvm.org/viewvc/llvm-project?rev=315627=rev
Log:
[lit] Raise the logic for enabling clang & lld substitutions to llvm.

This paves the way for other projects which might /use/ clang or
lld but not necessarily need to the full set of functionality
available to clang and lld tests to be able to have a basic set
of substitutions that allow a project to run the clang or lld
executables.

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=315627=315626=315627=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Thu Oct 12 14:56:05 2017
@@ -39,162 +39,43 @@ config.test_source_root = os.path.dirnam
 # test_exec_root: The root path where tests should be run.
 config.test_exec_root = os.path.join(config.clang_obj_root, 'test')
 
-# Clear some environment variables that might affect Clang.
-#
-# This first set of vars are read by Clang, but shouldn't affect tests
-# that aren't specifically looking for these features, or are required
-# simply to run the tests at all.
-#
-# FIXME: Should we have a tool that enforces this?
-
-# safe_env_vars = ('TMPDIR', 'TEMP', 'TMP', 'USERPROFILE', 'PWD',
-#  'MACOSX_DEPLOYMENT_TARGET', 'IPHONEOS_DEPLOYMENT_TARGET',
-#  'VCINSTALLDIR', 'VC100COMNTOOLS', 'VC90COMNTOOLS',
-#  'VC80COMNTOOLS')
-possibly_dangerous_env_vars = ['COMPILER_PATH', 'RC_DEBUG_OPTIONS',
-   'CINDEXTEST_PREAMBLE_FILE', 'LIBRARY_PATH',
-   'CPATH', 'C_INCLUDE_PATH', 'CPLUS_INCLUDE_PATH',
-   'OBJC_INCLUDE_PATH', 'OBJCPLUS_INCLUDE_PATH',
-   'LIBCLANG_TIMING', 'LIBCLANG_OBJTRACKING',
-   'LIBCLANG_LOGGING', 'LIBCLANG_BGPRIO_INDEX',
-   'LIBCLANG_BGPRIO_EDIT', 'LIBCLANG_NOTHREADS',
-   'LIBCLANG_RESOURCE_USAGE',
-   'LIBCLANG_CODE_COMPLETION_LOGGING']
-# Clang/Win32 may refer to %INCLUDE%. vsvarsall.bat sets it.
-if platform.system() != 'Windows':
-possibly_dangerous_env_vars.append('INCLUDE')
-
-llvm_config.clear_environment(possibly_dangerous_env_vars)
-
-# Tweak the PATH to include the tools dir and the scripts dir.
-llvm_config.with_environment(
-'PATH', [config.llvm_tools_dir, config.clang_tools_dir], append_path=True)
+llvm_config.use_default_substitutions()
 
-llvm_config.with_environment('LD_LIBRARY_PATH', [
- config.llvm_shlib_dir, config.llvm_libs_dir], 
append_path=True)
+llvm_config.use_clang()
 
 # Propagate path to symbolizer for ASan/MSan.
 llvm_config.with_system_environment(
 ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH'])
 
-llvm_config.use_default_substitutions()
-
-# Discover the 'clang' and 'clangcc' to use.
-
-
-def inferClang(PATH):
-# Determine which clang to use.
-clang = os.getenv('CLANG')
-
-# If the user set clang in the environment, definitely use that and don't
-# try to validate.
-if clang:
-return clang
-
-# Otherwise look in the path.
-clang = lit.util.which('clang', PATH)
-
-if not clang:
-lit_config.fatal("couldn't find 'clang' program, try setting "
- 'CLANG in your environment')
-
-return clang
-
-
-config.clang = inferClang(config.environment['PATH']).replace('\\', '/')
-if not lit_config.quiet:
-lit_config.note('using clang: %r' % config.clang)
-
-# Plugins (loadable modules)
-# TODO: This should be supplied by Makefile or autoconf.
-if sys.platform in ['win32', 'cygwin']:
-has_plugins = config.enable_shared
-else:
-has_plugins = True
-
-if has_plugins and config.llvm_plugin_ext:
-config.available_features.add('plugins')
-
-config.substitutions.append(('%llvmshlibdir', config.llvm_shlib_dir))
-config.substitutions.append(('%pluginext', config.llvm_plugin_ext))
 config.substitutions.append(('%PATH%', config.environment['PATH']))
 
-if config.clang_examples:
-config.available_features.add('examples')
 
-builtin_include_dir = llvm_config.get_clang_builtin_include_dir(config.clang)
+# For each occurrence of a clang tool name, replace it with the full path to
+# the build directory holding that tool.  We explicitly specify the directories
+# to search to ensure that we get the tools just built and not some random
+# tools that might happen to be in the user's PATH.
+tool_dirs = [config.clang_tools_dir, config.llvm_tools_dir]
 
 tools = [
-# By specifying %clang_cc1 as part of the substitution, this substitution
-# relies on repeated substitution, so must come before %clang_cc1.
-ToolSubst('%clang_analyze_cc1', command='%clang_cc1',
-  extra_args=['-analyze', '%analyze']),
-

r315536 - Revert "[ADT] Make Twine's copy constructor private."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Wed Oct 11 16:54:34 2017
New Revision: 315536

URL: http://llvm.org/viewvc/llvm-project?rev=315536=rev
Log:
Revert "[ADT] Make Twine's copy constructor private."

This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.

This is failing due to some code that isn't built on MSVC
so I didn't catch.  Not immediately obvious how to fix this
at first glance, so I'm reverting for now.

Modified:
cfe/trunk/include/clang/Tooling/CompilationDatabase.h
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
cfe/trunk/lib/Tooling/CompilationDatabase.cpp
cfe/trunk/unittests/Tooling/TestVisitor.h

Modified: cfe/trunk/include/clang/Tooling/CompilationDatabase.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/CompilationDatabase.h?rev=315536=315535=315536=diff
==
--- cfe/trunk/include/clang/Tooling/CompilationDatabase.h (original)
+++ cfe/trunk/include/clang/Tooling/CompilationDatabase.h Wed Oct 11 16:54:34 
2017
@@ -42,10 +42,12 @@ namespace tooling {
 /// \brief Specifies the working directory and command of a compilation.
 struct CompileCommand {
   CompileCommand() {}
-  CompileCommand(const Twine , const Twine ,
- std::vector CommandLine, const Twine )
-  : Directory(Directory.str()), Filename(Filename.str()),
-CommandLine(std::move(CommandLine)), Output(Output.str()) {}
+  CompileCommand(Twine Directory, Twine Filename,
+ std::vector CommandLine, Twine Output)
+  : Directory(Directory.str()),
+Filename(Filename.str()),
+CommandLine(std::move(CommandLine)),
+Output(Output.str()){}
 
   /// \brief The working directory the command was executed from.
   std::string Directory;
@@ -176,14 +178,13 @@ public:
   /// \param Argv Points to the command line arguments.
   /// \param ErrorMsg Contains error text if the function returns null pointer.
   /// \param Directory The base directory used in the FixedCompilationDatabase.
-  static std::unique_ptr
-  loadFromCommandLine(int , const char *const *Argv, std::string 
,
-  const Twine  = ".");
+  static std::unique_ptr loadFromCommandLine(
+  int , const char *const *Argv, std::string ,
+  Twine Directory = ".");
 
   /// \brief Constructs a compilation data base from a specified directory
   /// and command line.
-  FixedCompilationDatabase(const Twine ,
-   ArrayRef CommandLine);
+  FixedCompilationDatabase(Twine Directory, ArrayRef CommandLine);
 
   /// \brief Returns the given compile command.
   ///

Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=315536=315535=315536=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Wed Oct 11 16:54:34 2017
@@ -981,17 +981,17 @@ protected:
 
   /// EmitPropertyList - Emit the given property list. The return
   /// value has type PropertyListPtrTy.
-  llvm::Constant *EmitPropertyList(const Twine , const Decl *Container,
+  llvm::Constant *EmitPropertyList(Twine Name,
+   const Decl *Container,
const ObjCContainerDecl *OCD,
const ObjCCommonTypesHelper ,
bool IsClassProperty);
 
   /// EmitProtocolMethodTypes - Generate the array of extended method type 
   /// strings. The return value has type Int8PtrPtrTy.
-  llvm::Constant *
-  EmitProtocolMethodTypes(const Twine ,
-  ArrayRef MethodTypes,
-  const ObjCCommonTypesHelper );
+  llvm::Constant *EmitProtocolMethodTypes(Twine Name, 
+  ArrayRef 
MethodTypes,
+   const ObjCCommonTypesHelper );
 
   /// GetProtocolRef - Return a reference to the internal protocol
   /// description, creating an empty one if it has not been
@@ -1021,11 +1021,11 @@ public:
   /// \param Align - The alignment for the variable, or 0.
   /// \param AddToUsed - Whether the variable should be added to
   ///   "llvm.used".
-  llvm::GlobalVariable *CreateMetadataVar(const Twine ,
+  llvm::GlobalVariable *CreateMetadataVar(Twine Name,
   ConstantStructBuilder ,
   StringRef Section, CharUnits Align,
   bool AddToUsed);
-  llvm::GlobalVariable *CreateMetadataVar(const Twine ,
+  llvm::GlobalVariable *CreateMetadataVar(Twine Name,
   llvm::Constant *Init,
   StringRef 

r315530 - [ADT] Make Twine's copy constructor private.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Wed Oct 11 16:33:06 2017
New Revision: 315530

URL: http://llvm.org/viewvc/llvm-project?rev=315530=rev
Log:
[ADT] Make Twine's copy constructor private.

There's a lot of misuse of Twine scattered around LLVM.  This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class).  While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.

This patch makes Twine's copy constructor private, and fixes up
all callsites.

Differential Revision: https://reviews.llvm.org/D38767

Modified:
cfe/trunk/include/clang/Tooling/CompilationDatabase.h
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
cfe/trunk/lib/Tooling/CompilationDatabase.cpp
cfe/trunk/unittests/Tooling/TestVisitor.h

Modified: cfe/trunk/include/clang/Tooling/CompilationDatabase.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/CompilationDatabase.h?rev=315530=315529=315530=diff
==
--- cfe/trunk/include/clang/Tooling/CompilationDatabase.h (original)
+++ cfe/trunk/include/clang/Tooling/CompilationDatabase.h Wed Oct 11 16:33:06 
2017
@@ -42,12 +42,10 @@ namespace tooling {
 /// \brief Specifies the working directory and command of a compilation.
 struct CompileCommand {
   CompileCommand() {}
-  CompileCommand(Twine Directory, Twine Filename,
- std::vector CommandLine, Twine Output)
-  : Directory(Directory.str()),
-Filename(Filename.str()),
-CommandLine(std::move(CommandLine)),
-Output(Output.str()){}
+  CompileCommand(const Twine , const Twine ,
+ std::vector CommandLine, const Twine )
+  : Directory(Directory.str()), Filename(Filename.str()),
+CommandLine(std::move(CommandLine)), Output(Output.str()) {}
 
   /// \brief The working directory the command was executed from.
   std::string Directory;
@@ -178,13 +176,14 @@ public:
   /// \param Argv Points to the command line arguments.
   /// \param ErrorMsg Contains error text if the function returns null pointer.
   /// \param Directory The base directory used in the FixedCompilationDatabase.
-  static std::unique_ptr loadFromCommandLine(
-  int , const char *const *Argv, std::string ,
-  Twine Directory = ".");
+  static std::unique_ptr
+  loadFromCommandLine(int , const char *const *Argv, std::string 
,
+  const Twine  = ".");
 
   /// \brief Constructs a compilation data base from a specified directory
   /// and command line.
-  FixedCompilationDatabase(Twine Directory, ArrayRef CommandLine);
+  FixedCompilationDatabase(const Twine ,
+   ArrayRef CommandLine);
 
   /// \brief Returns the given compile command.
   ///

Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=315530=315529=315530=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Wed Oct 11 16:33:06 2017
@@ -981,17 +981,17 @@ protected:
 
   /// EmitPropertyList - Emit the given property list. The return
   /// value has type PropertyListPtrTy.
-  llvm::Constant *EmitPropertyList(Twine Name,
-   const Decl *Container,
+  llvm::Constant *EmitPropertyList(const Twine , const Decl *Container,
const ObjCContainerDecl *OCD,
const ObjCCommonTypesHelper ,
bool IsClassProperty);
 
   /// EmitProtocolMethodTypes - Generate the array of extended method type 
   /// strings. The return value has type Int8PtrPtrTy.
-  llvm::Constant *EmitProtocolMethodTypes(Twine Name, 
-  ArrayRef 
MethodTypes,
-   const ObjCCommonTypesHelper );
+  llvm::Constant *
+  EmitProtocolMethodTypes(const Twine ,
+  ArrayRef MethodTypes,
+  const ObjCCommonTypesHelper );
 
   /// GetProtocolRef - Return a reference to the internal protocol
   /// description, creating an empty one if it has not been
@@ -1021,11 +1021,11 @@ public:
   /// \param Align - The alignment for the variable, or 0.
   /// \param AddToUsed - Whether the variable should be added to
   ///   "llvm.used".
-  llvm::GlobalVariable *CreateMetadataVar(Twine Name,
+  llvm::GlobalVariable *CreateMetadataVar(const Twine ,
   ConstantStructBuilder ,
   

r315085 - [lit] Improve tool substitution in lit.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct  6 10:54:46 2017
New Revision: 315085

URL: http://llvm.org/viewvc/llvm-project?rev=315085=rev
Log:
[lit] Improve tool substitution in lit.

This addresses two sources of inconsistency in test configuration
files.

1. Substitution boundaries.  Previously you would specify a
   substitution, such as 'lli', and then additionally a set
   of characters that should fail to match before and after
   the tool.  This was used, for example, so that matches that
   are parts of full paths would not be replaced.  But not all
   tools did this, and those that did would often re-invent
   the set of characters themselves, leading to inconsistency.
   Now, every tool substitution defaults to using a sane set
   of reasonable defaults and you have to explicitly opt out
   of it.  This actually fixed a few latent bugs that were
   never being surfaced, but only on accident.

2. There was no standard way for the system to decide how to
   locate a tool.  Sometimes you have an explicit path, sometimes
   we would search for it and build up a path ourselves, and
   sometimes we would build up a full command line.  Furthermore,
   there was no standardized way to handle missing tools.  Do we
   warn, fail, ignore, etc?  All of this is now encapsulated in
   the ToolSubst class.  You either specify an exact command to
   run, or an instance of FindTool('') and everything
   else just works.  Furthermore, you can specify an action to
   take if the tool cannot be resolved.

Differential Revision: https://reviews.llvm.org/D38565

Modified:
cfe/trunk/test/Index/recover-bad-code-rdar_7487294.c
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/Index/recover-bad-code-rdar_7487294.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/recover-bad-code-rdar_7487294.c?rev=315085=315084=315085=diff
==
--- cfe/trunk/test/Index/recover-bad-code-rdar_7487294.c (original)
+++ cfe/trunk/test/Index/recover-bad-code-rdar_7487294.c Fri Oct  6 10:54:46 
2017
@@ -1,4 +1,4 @@
-// RUN: not %clang-cc1 -fsyntax-only %s 2>&1 | FileCheck %s
+// RUN: not %clang_cc1 -fsyntax-only %s 2>&1 | FileCheck %s
 
 // IMPORTANT: This test case intentionally DOES NOT use --disable-free.  It
 // tests that we are properly reclaiming the ASTs and we do not have a double 
free.

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=315085=315084=315085=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Fri Oct  6 10:54:46 2017
@@ -10,7 +10,8 @@ import lit.formats
 import lit.util
 
 from lit.llvm import llvm_config
-from lit.llvm import ToolFilter
+from lit.llvm.subst import ToolSubst
+from lit.llvm.subst import FindTool
 
 # Configuration file for the 'lit' test runner.
 
@@ -76,6 +77,8 @@ llvm_config.with_environment('LD_LIBRARY
 llvm_config.with_system_environment(
 ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH'])
 
+llvm_config.use_default_substitutions()
+
 # Discover the 'clang' and 'clangcc' to use.
 
 
@@ -120,44 +123,37 @@ if config.clang_examples:
 config.available_features.add('examples')
 
 builtin_include_dir = llvm_config.get_clang_builtin_include_dir(config.clang)
-config.substitutions.append(('%clang_analyze_cc1',
- '%clang_cc1 -analyze %analyze'))
-config.substitutions.append(('%clang_cc1',
- '%s -cc1 -internal-isystem %s -nostdsysteminc'
- % (config.clang, builtin_include_dir)))
-config.substitutions.append(('%clang_cpp', ' ' + config.clang +
- ' --driver-mode=cpp '))
-config.substitutions.append(('%clang_cl', ' ' + config.clang +
- ' --driver-mode=cl '))
-config.substitutions.append(('%clangxx', ' ' + config.clang +
- ' --driver-mode=g++ '))
-
-clang_func_map = lit.util.which(
-'clang-func-mapping', config.environment['PATH'])
-if clang_func_map:
-config.substitutions.append(
-('%clang_func_map', ' ' + clang_func_map + ' '))
-
-config.substitutions.append(('%clang', ' ' + config.clang + ' '))
-config.substitutions.append(('%test_debuginfo',
- ' ' + config.llvm_src_root + 
'/utils/test_debuginfo.pl '))
-config.substitutions.append(('%itanium_abi_triple',
- 
llvm_config.make_itanium_abi_triple(config.target_triple)))
-config.substitutions.append(('%ms_abi_triple',
- 
llvm_config.make_msabi_triple(config.target_triple)))
-config.substitutions.append(('%resource_dir', builtin_include_dir))
-config.substitutions.append(('%python', config.python_executable))
 
-# The host triple might not be set, at least if we're compiling clang from
-# an already installed llvm.
-if config.host_triple and 

r315084 - Run pyformat on lit code.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Oct  6 10:54:27 2017
New Revision: 315084

URL: http://llvm.org/viewvc/llvm-project?rev=315084=rev
Log:
Run pyformat on lit code.

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=315084=315083=315084=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Fri Oct  6 10:54:27 2017
@@ -24,7 +24,8 @@ config.name = 'Clang'
 config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
 
 # suffixes: A list of file extensions to treat as test files.
-config.suffixes = ['.c', '.cpp', '.cppm', '.m', '.mm', '.cu', '.ll', '.cl', 
'.s', '.S', '.modulemap', '.test', '.rs']
+config.suffixes = ['.c', '.cpp', '.cppm', '.m', '.mm', '.cu',
+   '.ll', '.cl', '.s', '.S', '.modulemap', '.test', '.rs']
 
 # excludes: A list of directories to exclude from the testsuite. The 'Inputs'
 # subdirectories contain auxiliary inputs for various tests in their parent
@@ -65,15 +66,19 @@ if platform.system() != 'Windows':
 llvm_config.clear_environment(possibly_dangerous_env_vars)
 
 # Tweak the PATH to include the tools dir and the scripts dir.
-llvm_config.with_environment('PATH', [config.llvm_tools_dir, 
config.clang_tools_dir], append_path=True)
+llvm_config.with_environment(
+'PATH', [config.llvm_tools_dir, config.clang_tools_dir], append_path=True)
 
-llvm_config.with_environment('LD_LIBRARY_PATH', [config.llvm_shlib_dir, 
config.llvm_libs_dir], append_path=True)
+llvm_config.with_environment('LD_LIBRARY_PATH', [
+ config.llvm_shlib_dir, config.llvm_libs_dir], 
append_path=True)
 
 # Propagate path to symbolizer for ASan/MSan.
-llvm_config.with_system_environment(['ASAN_SYMBOLIZER_PATH', 
'MSAN_SYMBOLIZER_PATH'])
+llvm_config.with_system_environment(
+['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH'])
 
 # Discover the 'clang' and 'clangcc' to use.
 
+
 def inferClang(PATH):
 # Determine which clang to use.
 clang = os.getenv('CLANG')
@@ -88,10 +93,11 @@ def inferClang(PATH):
 
 if not clang:
 lit_config.fatal("couldn't find 'clang' program, try setting "
- "CLANG in your environment")
+ 'CLANG in your environment')
 
 return clang
 
+
 config.clang = inferClang(config.environment['PATH']).replace('\\', '/')
 if not lit_config.quiet:
 lit_config.note('using clang: %r' % config.clang)
@@ -106,73 +112,76 @@ else:
 if has_plugins and config.llvm_plugin_ext:
 config.available_features.add('plugins')
 
-config.substitutions.append( ('%llvmshlibdir', config.llvm_shlib_dir) )
-config.substitutions.append( ('%pluginext', config.llvm_plugin_ext) )
-config.substitutions.append( ('%PATH%', config.environment['PATH']) )
+config.substitutions.append(('%llvmshlibdir', config.llvm_shlib_dir))
+config.substitutions.append(('%pluginext', config.llvm_plugin_ext))
+config.substitutions.append(('%PATH%', config.environment['PATH']))
 
 if config.clang_examples:
 config.available_features.add('examples')
 
 builtin_include_dir = llvm_config.get_clang_builtin_include_dir(config.clang)
-config.substitutions.append( ('%clang_analyze_cc1',
-  '%clang_cc1 -analyze %analyze') )
-config.substitutions.append( ('%clang_cc1',
-  '%s -cc1 -internal-isystem %s -nostdsysteminc'
-  % (config.clang, builtin_include_dir)) )
-config.substitutions.append( ('%clang_cpp', ' ' + config.clang +
-  ' --driver-mode=cpp '))
-config.substitutions.append( ('%clang_cl', ' ' + config.clang +
-  ' --driver-mode=cl '))
-config.substitutions.append( ('%clangxx', ' ' + config.clang +
-  ' --driver-mode=g++ '))
+config.substitutions.append(('%clang_analyze_cc1',
+ '%clang_cc1 -analyze %analyze'))
+config.substitutions.append(('%clang_cc1',
+ '%s -cc1 -internal-isystem %s -nostdsysteminc'
+ % (config.clang, builtin_include_dir)))
+config.substitutions.append(('%clang_cpp', ' ' + config.clang +
+ ' --driver-mode=cpp '))
+config.substitutions.append(('%clang_cl', ' ' + config.clang +
+ ' --driver-mode=cl '))
+config.substitutions.append(('%clangxx', ' ' + config.clang +
+ ' --driver-mode=g++ '))
 
-clang_func_map = lit.util.which('clang-func-mapping', 
config.environment['PATH'])
+clang_func_map = lit.util.which(
+'clang-func-mapping', config.environment['PATH'])
 if clang_func_map:
-config.substitutions.append( ('%clang_func_map', ' ' + clang_func_map + ' 
') )
+config.substitutions.append(
+('%clang_func_map', ' ' + clang_func_map + ' '))
 
-config.substitutions.append( 

Re: [PATCH] D31363: [libc++] Remove cmake glob for source files

[Zachary Turner via cfe-commits]

It’s not, but the point is we’re already skirting the line
On Wed, Oct 4, 2017 at 9:37 PM Duncan P. N. Exon Smith 
wrote:

> I haven't looked at the patch.  If this is guarded behind NOT
> LIBCXX_STANDALONE_BUILD checks, then it's probably fine.
>
>
> On Oct 4, 2017, at 21:36, Zachary Turner  wrote:
>
> This doesn’t match up with what beanz said. While I assume Duncan is the
> final word, can we get some confirmation from beanz that everyone is on the
> same page?
>
> (Note that libcxx already uses some of LLVM’s cmake, but it’s behind some
> NOT LIBCXX_STANDALONE_BUILD checks)
>
> Assuming the answer remains no, what can we do to make code sharing and
> reuse easier? There’s clearly a need to reuse certain low level things and
> not keep reinventing the wheel
> On Wed, Oct 4, 2017 at 9:22 PM Duncan P. N. Exon Smith <
> dexonsm...@apple.com> wrote:
>
>> Thanks correct.
>>
>> > On Oct 4, 2017, at 18:49, Shoaib Meenai via Phabricator via cfe-commits
>>  wrote:
>> >
>> > smeenai added subscribers: zturner, rjmccall.
>> > smeenai added a comment.
>> >
>> > @rjmccall, this adds a libc++ build dependency on LLVM's cmake modules.
>> There were some issues when @zturner had added a similar dependency for his
>> work on lit. To confirm, Apple still cares about the use case of building
>> libc++ without having any LLVM cmake modules available (either from source
>> or from an LLVM installation), right?
>> >
>> >
>> > https://reviews.llvm.org/D31363
>> >
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D31363: [libc++] Remove cmake glob for source files

[Zachary Turner via cfe-commits]

This doesn’t match up with what beanz said. While I assume Duncan is the
final word, can we get some confirmation from beanz that everyone is on the
same page?

(Note that libcxx already uses some of LLVM’s cmake, but it’s behind some
NOT LIBCXX_STANDALONE_BUILD checks)

Assuming the answer remains no, what can we do to make code sharing and
reuse easier? There’s clearly a need to reuse certain low level things and
not keep reinventing the wheel
On Wed, Oct 4, 2017 at 9:22 PM Duncan P. N. Exon Smith 
wrote:

> Thanks correct.
>
> > On Oct 4, 2017, at 18:49, Shoaib Meenai via Phabricator via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > smeenai added subscribers: zturner, rjmccall.
> > smeenai added a comment.
> >
> > @rjmccall, this adds a libc++ build dependency on LLVM's cmake modules.
> There were some issues when @zturner had added a similar dependency for his
> work on lit. To confirm, Apple still cares about the use case of building
> libc++ without having any LLVM cmake modules available (either from source
> or from an LLVM installation), right?
> >
> >
> > https://reviews.llvm.org/D31363
> >
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r313928 - Resubmit "[lit] Refactor out some more common lit configuration code."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 21 15:16:40 2017
New Revision: 313928

URL: http://llvm.org/viewvc/llvm-project?rev=313928=rev
Log:
Resubmit "[lit] Refactor out some more common lit configuration code."

There were two issues, one Python 3 specific related to Unicode,
and another which is that the tool substitution for lld no longer
rejected matches where a / preceded the tool name.

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=313928=313927=313928=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Thu Sep 21 15:16:40 2017
@@ -10,6 +10,7 @@ import lit.formats
 import lit.util
 
 from lit.llvm import llvm_config
+from lit.llvm import ToolFilter
 
 # Configuration file for the 'lit' test runner.
 
@@ -112,55 +113,12 @@ config.substitutions.append( ('%PATH%',
 if config.clang_examples:
 config.available_features.add('examples')
 
-# Note that when substituting %clang_cc1 also fill in the include directory of
-# the builtin headers. Those are part of even a freestanding environment, but
-# Clang relies on the driver to locate them.
-def getClangBuiltinIncludeDir(clang):
-# FIXME: Rather than just getting the version, we should have clang print
-# out its resource dir here in an easy to scrape form.
-cmd = subprocess.Popen([clang, '-print-file-name=include'],
-   stdout=subprocess.PIPE,
-   env=config.environment)
-if not cmd.stdout:
-  lit_config.fatal("Couldn't find the include dir for Clang ('%s')" % 
clang)
-dir = cmd.stdout.read().strip()
-if sys.platform in ['win32'] and not llvm_config.use_lit_shell:
-# Don't pass dosish path separator to msys bash.exe.
-dir = dir.replace('\\', '/')
-# Ensure the result is an ascii string, across Python2.5+ - Python3.
-return str(dir.decode('ascii'))
-
-def makeItaniumABITriple(triple):
-m = re.match(r'(\w+)-(\w+)-(\w+)', triple)
-if not m:
-  lit_config.fatal("Could not turn '%s' into Itanium ABI triple" % triple)
-if m.group(3).lower() != 'win32':
-  # All non-win32 triples use the Itanium ABI.
-  return triple
-return m.group(1) + '-' + m.group(2) + '-mingw32'
-
-def makeMSABITriple(triple):
-m = re.match(r'(\w+)-(\w+)-(\w+)', triple)
-if not m:
-  lit_config.fatal("Could not turn '%s' into MS ABI triple" % triple)
-isa = m.group(1).lower()
-vendor = m.group(2).lower()
-os = m.group(3).lower()
-if os == 'win32':
-  # If the OS is win32, we're done.
-  return triple
-if isa.startswith('x86') or isa == 'amd64' or re.match(r'i\d86', isa):
-  # For x86 ISAs, adjust the OS.
-  return isa + '-' + vendor + '-win32'
-# -win32 is not supported for non-x86 targets; use a default.
-return 'i686-pc-win32'
-
+builtin_include_dir = llvm_config.get_clang_builtin_include_dir(config.clang)
 config.substitutions.append( ('%clang_analyze_cc1',
   '%clang_cc1 -analyze %analyze') )
 config.substitutions.append( ('%clang_cc1',
   '%s -cc1 -internal-isystem %s -nostdsysteminc'
-  % (config.clang,
- getClangBuiltinIncludeDir(config.clang))) )
+  % (config.clang, builtin_include_dir)) )
 config.substitutions.append( ('%clang_cpp', ' ' + config.clang +
   ' --driver-mode=cpp '))
 config.substitutions.append( ('%clang_cl', ' ' + config.clang +
@@ -168,16 +126,20 @@ config.substitutions.append( ('%clang_cl
 config.substitutions.append( ('%clangxx', ' ' + config.clang +
   ' --driver-mode=g++ '))
 config.substitutions.append( ('%clang', ' ' + config.clang + ' ') )
-config.substitutions.append( ('%test_debuginfo', ' ' + config.llvm_src_root + 
'/utils/test_debuginfo.pl ') )
-config.substitutions.append( ('%itanium_abi_triple', 
makeItaniumABITriple(config.target_triple)) )
-config.substitutions.append( ('%ms_abi_triple', 
makeMSABITriple(config.target_triple)) )
-config.substitutions.append( ('%resource_dir', 
getClangBuiltinIncludeDir(config.clang)) )
+config.substitutions.append( ('%test_debuginfo',
+ ' ' + config.llvm_src_root +  
'/utils/test_debuginfo.pl ') )
+config.substitutions.append( ('%itanium_abi_triple',
+ 
llvm_config.make_itanium_abi_triple(config.target_triple)) )
+config.substitutions.append( ('%ms_abi_triple',
+ 
llvm_config.make_msabi_triple(config.target_triple)) )
+config.substitutions.append( ('%resource_dir', builtin_include_dir) )
 config.substitutions.append( ('%python', config.python_executable) )
 
 # The host triple might not be set, at least if we're compiling clang from
 # an already installed llvm.
 

r313922 - Revert "[lit] Refactor out some more common lit configuration code."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 21 14:45:45 2017
New Revision: 313922

URL: http://llvm.org/viewvc/llvm-project?rev=313922=rev
Log:
Revert "[lit] Refactor out some more common lit configuration code."

This is breaking several bots.  I have enough information to
investigate, so I'm reverting to green until I get it figured
out.

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=313922=313921=313922=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Thu Sep 21 14:45:45 2017
@@ -10,7 +10,6 @@ import lit.formats
 import lit.util
 
 from lit.llvm import llvm_config
-from lit.llvm import ToolFilter
 
 # Configuration file for the 'lit' test runner.
 
@@ -113,12 +112,55 @@ config.substitutions.append( ('%PATH%',
 if config.clang_examples:
 config.available_features.add('examples')
 
-builtin_include_dir = llvm_config.get_clang_builtin_include_dir(config.clang)
+# Note that when substituting %clang_cc1 also fill in the include directory of
+# the builtin headers. Those are part of even a freestanding environment, but
+# Clang relies on the driver to locate them.
+def getClangBuiltinIncludeDir(clang):
+# FIXME: Rather than just getting the version, we should have clang print
+# out its resource dir here in an easy to scrape form.
+cmd = subprocess.Popen([clang, '-print-file-name=include'],
+   stdout=subprocess.PIPE,
+   env=config.environment)
+if not cmd.stdout:
+  lit_config.fatal("Couldn't find the include dir for Clang ('%s')" % 
clang)
+dir = cmd.stdout.read().strip()
+if sys.platform in ['win32'] and not llvm_config.use_lit_shell:
+# Don't pass dosish path separator to msys bash.exe.
+dir = dir.replace('\\', '/')
+# Ensure the result is an ascii string, across Python2.5+ - Python3.
+return str(dir.decode('ascii'))
+
+def makeItaniumABITriple(triple):
+m = re.match(r'(\w+)-(\w+)-(\w+)', triple)
+if not m:
+  lit_config.fatal("Could not turn '%s' into Itanium ABI triple" % triple)
+if m.group(3).lower() != 'win32':
+  # All non-win32 triples use the Itanium ABI.
+  return triple
+return m.group(1) + '-' + m.group(2) + '-mingw32'
+
+def makeMSABITriple(triple):
+m = re.match(r'(\w+)-(\w+)-(\w+)', triple)
+if not m:
+  lit_config.fatal("Could not turn '%s' into MS ABI triple" % triple)
+isa = m.group(1).lower()
+vendor = m.group(2).lower()
+os = m.group(3).lower()
+if os == 'win32':
+  # If the OS is win32, we're done.
+  return triple
+if isa.startswith('x86') or isa == 'amd64' or re.match(r'i\d86', isa):
+  # For x86 ISAs, adjust the OS.
+  return isa + '-' + vendor + '-win32'
+# -win32 is not supported for non-x86 targets; use a default.
+return 'i686-pc-win32'
+
 config.substitutions.append( ('%clang_analyze_cc1',
   '%clang_cc1 -analyze %analyze') )
 config.substitutions.append( ('%clang_cc1',
   '%s -cc1 -internal-isystem %s -nostdsysteminc'
-  % (config.clang, builtin_include_dir)) )
+  % (config.clang,
+ getClangBuiltinIncludeDir(config.clang))) )
 config.substitutions.append( ('%clang_cpp', ' ' + config.clang +
   ' --driver-mode=cpp '))
 config.substitutions.append( ('%clang_cl', ' ' + config.clang +
@@ -126,20 +168,16 @@ config.substitutions.append( ('%clang_cl
 config.substitutions.append( ('%clangxx', ' ' + config.clang +
   ' --driver-mode=g++ '))
 config.substitutions.append( ('%clang', ' ' + config.clang + ' ') )
-config.substitutions.append( ('%test_debuginfo',
- ' ' + config.llvm_src_root +  
'/utils/test_debuginfo.pl ') )
-config.substitutions.append( ('%itanium_abi_triple',
- 
llvm_config.make_itanium_abi_triple(config.target_triple)) )
-config.substitutions.append( ('%ms_abi_triple',
- 
llvm_config.make_msabi_triple(config.target_triple)) )
-config.substitutions.append( ('%resource_dir', builtin_include_dir) )
+config.substitutions.append( ('%test_debuginfo', ' ' + config.llvm_src_root + 
'/utils/test_debuginfo.pl ') )
+config.substitutions.append( ('%itanium_abi_triple', 
makeItaniumABITriple(config.target_triple)) )
+config.substitutions.append( ('%ms_abi_triple', 
makeMSABITriple(config.target_triple)) )
+config.substitutions.append( ('%resource_dir', 
getClangBuiltinIncludeDir(config.clang)) )
 config.substitutions.append( ('%python', config.python_executable) )
 
 # The host triple might not be set, at least if we're compiling clang from
 # an already installed llvm.
 if config.host_triple and config.host_triple != 

r313919 - [lit] Refactor out some more common lit configuration code.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 21 14:27:31 2017
New Revision: 313919

URL: http://llvm.org/viewvc/llvm-project?rev=313919=rev
Log:
[lit] Refactor out some more common lit configuration code.

debuginfo-tests has need to reuse a lot of common configuration
from clang and lld, and in general it seems like all of the
projects which are tightly coupled (e.g. lld, clang, llvm, lldb,
etc) can benefit from knowing about one other.  For example,
lldb needs to know various things about how to run clang in its
test suite.  Since there's a lot of common substitutions and
operations that need to be shared among projects, sinking this
up into LLVM makes sense.

In addition, this patch introduces a function add_tool_substitution
which handles all the dirty intricacies of matching tool names
which was previously copied around the various config files.  This
is now a simple straightforward interface which is hard to mess
up.

Differential Revision: https://reviews.llvm.org/D37944

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=313919=313918=313919=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Thu Sep 21 14:27:31 2017
@@ -10,6 +10,7 @@ import lit.formats
 import lit.util
 
 from lit.llvm import llvm_config
+from lit.llvm import ToolFilter
 
 # Configuration file for the 'lit' test runner.
 
@@ -112,55 +113,12 @@ config.substitutions.append( ('%PATH%',
 if config.clang_examples:
 config.available_features.add('examples')
 
-# Note that when substituting %clang_cc1 also fill in the include directory of
-# the builtin headers. Those are part of even a freestanding environment, but
-# Clang relies on the driver to locate them.
-def getClangBuiltinIncludeDir(clang):
-# FIXME: Rather than just getting the version, we should have clang print
-# out its resource dir here in an easy to scrape form.
-cmd = subprocess.Popen([clang, '-print-file-name=include'],
-   stdout=subprocess.PIPE,
-   env=config.environment)
-if not cmd.stdout:
-  lit_config.fatal("Couldn't find the include dir for Clang ('%s')" % 
clang)
-dir = cmd.stdout.read().strip()
-if sys.platform in ['win32'] and not llvm_config.use_lit_shell:
-# Don't pass dosish path separator to msys bash.exe.
-dir = dir.replace('\\', '/')
-# Ensure the result is an ascii string, across Python2.5+ - Python3.
-return str(dir.decode('ascii'))
-
-def makeItaniumABITriple(triple):
-m = re.match(r'(\w+)-(\w+)-(\w+)', triple)
-if not m:
-  lit_config.fatal("Could not turn '%s' into Itanium ABI triple" % triple)
-if m.group(3).lower() != 'win32':
-  # All non-win32 triples use the Itanium ABI.
-  return triple
-return m.group(1) + '-' + m.group(2) + '-mingw32'
-
-def makeMSABITriple(triple):
-m = re.match(r'(\w+)-(\w+)-(\w+)', triple)
-if not m:
-  lit_config.fatal("Could not turn '%s' into MS ABI triple" % triple)
-isa = m.group(1).lower()
-vendor = m.group(2).lower()
-os = m.group(3).lower()
-if os == 'win32':
-  # If the OS is win32, we're done.
-  return triple
-if isa.startswith('x86') or isa == 'amd64' or re.match(r'i\d86', isa):
-  # For x86 ISAs, adjust the OS.
-  return isa + '-' + vendor + '-win32'
-# -win32 is not supported for non-x86 targets; use a default.
-return 'i686-pc-win32'
-
+builtin_include_dir = llvm_config.get_clang_builtin_include_dir(config.clang)
 config.substitutions.append( ('%clang_analyze_cc1',
   '%clang_cc1 -analyze %analyze') )
 config.substitutions.append( ('%clang_cc1',
   '%s -cc1 -internal-isystem %s -nostdsysteminc'
-  % (config.clang,
- getClangBuiltinIncludeDir(config.clang))) )
+  % (config.clang, builtin_include_dir)) )
 config.substitutions.append( ('%clang_cpp', ' ' + config.clang +
   ' --driver-mode=cpp '))
 config.substitutions.append( ('%clang_cl', ' ' + config.clang +
@@ -168,16 +126,20 @@ config.substitutions.append( ('%clang_cl
 config.substitutions.append( ('%clangxx', ' ' + config.clang +
   ' --driver-mode=g++ '))
 config.substitutions.append( ('%clang', ' ' + config.clang + ' ') )
-config.substitutions.append( ('%test_debuginfo', ' ' + config.llvm_src_root + 
'/utils/test_debuginfo.pl ') )
-config.substitutions.append( ('%itanium_abi_triple', 
makeItaniumABITriple(config.target_triple)) )
-config.substitutions.append( ('%ms_abi_triple', 
makeMSABITriple(config.target_triple)) )
-config.substitutions.append( ('%resource_dir', 
getClangBuiltinIncludeDir(config.clang)) )
+config.substitutions.append( ('%test_debuginfo',
+ 

r313892 - [lit] Rename lld and clang lit configs to end in .py

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 21 10:38:13 2017
New Revision: 313892

URL: http://llvm.org/viewvc/llvm-project?rev=313892=rev
Log:
[lit] Rename lld and clang lit configs to end in .py

This follows in line with a previous patch of renaming LLVM's.

Working on these files is difficult in certain operating systems
and/or environments that don't like handling python code with a
non .py file extension.

Added:
cfe/trunk/test/Unit/lit.cfg.py
cfe/trunk/test/Unit/lit.site.cfg.py.in
cfe/trunk/test/lit.cfg.py
cfe/trunk/test/lit.site.cfg.py.in
Removed:
cfe/trunk/test/Unit/lit.cfg
cfe/trunk/test/Unit/lit.site.cfg.in
cfe/trunk/test/lit.cfg
cfe/trunk/test/lit.site.cfg.in
Modified:
cfe/trunk/test/CMakeLists.txt

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=313892=313891=313892=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Thu Sep 21 10:38:13 2017
@@ -26,13 +26,17 @@ llvm_canonicalize_cmake_booleans(
   HAVE_LIBZ)
 
 configure_lit_site_cfg(
-  ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
-  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+  ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py
+  MAIN_CONFIG
+  ${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py
   )
 
 configure_lit_site_cfg(
-  ${CMAKE_CURRENT_SOURCE_DIR}/Unit/lit.site.cfg.in
-  ${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg
+  ${CMAKE_CURRENT_SOURCE_DIR}/Unit/lit.site.cfg.py.in
+  ${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg.py
+  MAIN_CONFIG
+  ${CMAKE_CURRENT_SOURCE_DIR}/Unit/lit.cfg.py
   )
 
 option(CLANG_TEST_USE_VG "Run Clang tests under Valgrind" OFF)

Removed: cfe/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Unit/lit.cfg?rev=313891=auto
==
--- cfe/trunk/test/Unit/lit.cfg (original)
+++ cfe/trunk/test/Unit/lit.cfg (removed)
@@ -1,51 +0,0 @@
-# -*- Python -*-
-
-# Configuration file for the 'lit' test runner.
-
-import os
-import platform
-import subprocess
-
-import lit.formats
-import lit.util
-
-# name: The name of this test suite.
-config.name = 'Clang-Unit'
-
-# suffixes: A list of file extensions to treat as test files.
-config.suffixes = []
-
-# test_source_root: The root path where tests are located.
-# test_exec_root: The root path where tests should be run.
-config.test_exec_root = os.path.join(config.clang_obj_root, 'unittests')
-config.test_source_root = config.test_exec_root
-
-# testFormat: The test format to use to interpret tests.
-config.test_format = lit.formats.GoogleTest(config.llvm_build_mode, 'Tests')
-
-# Propagate the temp directory. Windows requires this because it uses \Windows\
-# if none of these are present.
-if 'TMP' in os.environ:
-config.environment['TMP'] = os.environ['TMP']
-if 'TEMP' in os.environ:
-config.environment['TEMP'] = os.environ['TEMP']
-
-# Propagate path to symbolizer for ASan/MSan.
-for symbolizer in ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH']:
-if symbolizer in os.environ:
-config.environment[symbolizer] = os.environ[symbolizer]
-
-shlibpath_var = ''
-if platform.system() == 'Linux':
-shlibpath_var = 'LD_LIBRARY_PATH'
-elif platform.system() == 'Darwin':
-shlibpath_var = 'DYLD_LIBRARY_PATH'
-elif platform.system() == 'Windows':
-shlibpath_var = 'PATH'
-
-# in stand-alone builds, shlibdir is clang's build tree
-# while llvm_libs_dir is installed LLVM (and possibly older clang)
-shlibpath = os.path.pathsep.join((config.shlibdir, config.llvm_libs_dir,
- config.environment.get(shlibpath_var,'')))
-
-config.environment[shlibpath_var] = shlibpath

Added: cfe/trunk/test/Unit/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Unit/lit.cfg.py?rev=313892=auto
==
--- cfe/trunk/test/Unit/lit.cfg.py (added)
+++ cfe/trunk/test/Unit/lit.cfg.py Thu Sep 21 10:38:13 2017
@@ -0,0 +1,51 @@
+# -*- Python -*-
+
+# Configuration file for the 'lit' test runner.
+
+import os
+import platform
+import subprocess
+
+import lit.formats
+import lit.util
+
+# name: The name of this test suite.
+config.name = 'Clang-Unit'
+
+# suffixes: A list of file extensions to treat as test files.
+config.suffixes = []
+
+# test_source_root: The root path where tests are located.
+# test_exec_root: The root path where tests should be run.
+config.test_exec_root = os.path.join(config.clang_obj_root, 'unittests')
+config.test_source_root = config.test_exec_root
+
+# testFormat: The test format to use to interpret tests.
+config.test_format = lit.formats.GoogleTest(config.llvm_build_mode, 'Tests')
+
+# Propagate the temp directory. Windows requires this because it uses \Windows\
+# if none of these are present.
+if 'TMP' in os.environ:

[libcxx] r313763 - Make libcxx tests work when llvm sources are not present.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Wed Sep 20 09:01:50 2017
New Revision: 313763

URL: http://llvm.org/viewvc/llvm-project?rev=313763=rev
Log:
Make libcxx tests work when llvm sources are not present.

Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.

A previous patch broke that workflow, so this is making it work
again.  Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces.  libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.

Differential Revision: https://reviews.llvm.org/D38057

Modified:
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=313763=313762=313763=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Wed Sep 20 09:01:50 
2017
@@ -111,14 +111,17 @@ macro(configure_out_of_tree_llvm)
   # the configurator should write the script into.
   set(LLVM_LIT_OUTPUT_DIR "${libcxx_BINARY_DIR}/bin")
 
-  # Required LIT Configuration 
-  # Define the default arguments to use with 'lit', and an option for the user
-  # to override.
-  set(LIT_ARGS_DEFAULT "-sv --show-xfail --show-unsupported")
-  if (MSVC OR XCODE)
-set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
+  if (LLVM_INCLUDE_TESTS)
+# Required LIT Configuration 

+# Define the default arguments to use with 'lit', and an option for the 
user
+# to override.
+set(LLVM_EXTERNAL_LIT "${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py")
+set(LIT_ARGS_DEFAULT "-sv --show-xfail --show-unsupported")
+if (MSVC OR XCODE)
+  set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
+endif()
+set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for 
lit")
   endif()
-  set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for 
lit")
 
   # Required doc configuration
   if (LLVM_ENABLE_SPHINX)


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r313643 - Resubmit "Fix llvm-lit script generation in libcxx."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Tue Sep 19 10:19:10 2017
New Revision: 313643

URL: http://llvm.org/viewvc/llvm-project?rev=313643=rev
Log:
Resubmit "Fix llvm-lit script generation in libcxx."

After speaking with the libcxx owners, they agreed that this is
a bug in the bot that needs to be fixed by the bot owners, and
the CMake changes are correct.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
libcxx/trunk/test/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=313643=313642=313643=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Sep 19 10:19:10 2017
@@ -653,6 +653,7 @@ endif()
 #
 # However, since some submission systems strip test/ subdirectories, check for
 # it before adding it.
+
 if(IS_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/test")
   add_subdirectory(test)
 endif()
@@ -660,6 +661,15 @@ if (LIBCXX_INCLUDE_TESTS)
   add_subdirectory(lib/abi)
 endif()
 
+if (LIBCXX_STANDALONE_BUILD AND EXISTS "${LLVM_MAIN_SRC_DIR}/utils/llvm-lit")
+  # Make sure the llvm-lit script is generated into the bin directory, and do
+  # it after adding all tests, since the generated script will only work
+  # correctly discovered tests against test locations from the source tree that
+  # have already been discovered.
+  add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit
+   ${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
+endif()
+
 if (LIBCXX_INCLUDE_DOCS)
   add_subdirectory(docs)
 endif()

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=313643=313642=313643=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Tue Sep 19 10:19:10 
2017
@@ -106,6 +106,11 @@ macro(configure_out_of_tree_llvm)
 set(LLVM_ENABLE_SPHINX OFF)
   endif()
 
+  # In a standalone build, we don't have llvm to automatically generate the
+  # llvm-lit script for us.  So we need to provide an explicit directory that
+  # the configurator should write the script into.
+  set(LLVM_LIT_OUTPUT_DIR "${libcxx_BINARY_DIR}/bin")
+
   # Required LIT Configuration 
   # Define the default arguments to use with 'lit', and an option for the user
   # to override.

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=313643=313642=313643=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++ libcxx/trunk/test/CMakeLists.txt Tue Sep 19 10:19:10 2017
@@ -49,10 +49,9 @@ set(LIBCXX_EXECUTOR "None" CACHE STRING
 
 set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not 
edit!")
 
-configure_file(
+configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
-  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
-  @ONLY)
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
 
 set(LIBCXX_TEST_DEPS "")
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r313607 - Revert "Fix llvm-lit script generation in libcxx."

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Sep 18 20:11:35 2017
New Revision: 313607

URL: http://llvm.org/viewvc/llvm-project?rev=313607=rev
Log:
Revert "Fix llvm-lit script generation in libcxx."

This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9.

There is a bot that is checking out libcxx and lit with nothing
else and then running lit.py against the test tree.  Since there's
no LLVM source tree, there's no LLVM CMake.  CMake actually
reports this as a warning saying unsupported libcxx configuration,
but I guess someone is depending on it anyway.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
libcxx/trunk/test/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=313607=313606=313607=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Mon Sep 18 20:11:35 2017
@@ -653,7 +653,6 @@ endif()
 #
 # However, since some submission systems strip test/ subdirectories, check for
 # it before adding it.
-
 if(IS_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/test")
   add_subdirectory(test)
 endif()
@@ -661,15 +660,6 @@ if (LIBCXX_INCLUDE_TESTS)
   add_subdirectory(lib/abi)
 endif()
 
-if (LIBCXX_STANDALONE_BUILD AND EXISTS "${LLVM_MAIN_SRC_DIR}/utils/llvm-lit")
-  # Make sure the llvm-lit script is generated into the bin directory, and do
-  # it after adding all tests, since the generated script will only work
-  # correctly discovered tests against test locations from the source tree that
-  # have already been discovered.
-  add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit
-   ${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
-endif()
-
 if (LIBCXX_INCLUDE_DOCS)
   add_subdirectory(docs)
 endif()

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=313607=313606=313607=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Mon Sep 18 20:11:35 
2017
@@ -106,11 +106,6 @@ macro(configure_out_of_tree_llvm)
 set(LLVM_ENABLE_SPHINX OFF)
   endif()
 
-  # In a standalone build, we don't have llvm to automatically generate the
-  # llvm-lit script for us.  So we need to provide an explicit directory that
-  # the configurator should write the script into.
-  set(LLVM_LIT_OUTPUT_DIR "${libcxx_BINARY_DIR}/bin")
-
   # Required LIT Configuration 
   # Define the default arguments to use with 'lit', and an option for the user
   # to override.

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=313607=313606=313607=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++ libcxx/trunk/test/CMakeLists.txt Mon Sep 18 20:11:35 2017
@@ -49,9 +49,10 @@ set(LIBCXX_EXECUTOR "None" CACHE STRING
 
 set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not 
edit!")
 
-configure_lit_site_cfg(
+configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
-  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+  @ONLY)
 
 set(LIBCXX_TEST_DEPS "")
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r313606 - Fix llvm-lit script generation in libcxx.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Sep 18 19:46:28 2017
New Revision: 313606

URL: http://llvm.org/viewvc/llvm-project?rev=313606=rev
Log:
Fix llvm-lit script generation in libcxx.

Differential Revision: https://reviews.llvm.org/D37997

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
libcxx/trunk/test/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=313606=313605=313606=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Mon Sep 18 19:46:28 2017
@@ -653,6 +653,7 @@ endif()
 #
 # However, since some submission systems strip test/ subdirectories, check for
 # it before adding it.
+
 if(IS_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/test")
   add_subdirectory(test)
 endif()
@@ -660,6 +661,15 @@ if (LIBCXX_INCLUDE_TESTS)
   add_subdirectory(lib/abi)
 endif()
 
+if (LIBCXX_STANDALONE_BUILD AND EXISTS "${LLVM_MAIN_SRC_DIR}/utils/llvm-lit")
+  # Make sure the llvm-lit script is generated into the bin directory, and do
+  # it after adding all tests, since the generated script will only work
+  # correctly discovered tests against test locations from the source tree that
+  # have already been discovered.
+  add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit
+   ${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
+endif()
+
 if (LIBCXX_INCLUDE_DOCS)
   add_subdirectory(docs)
 endif()

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=313606=313605=313606=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Mon Sep 18 19:46:28 
2017
@@ -106,6 +106,11 @@ macro(configure_out_of_tree_llvm)
 set(LLVM_ENABLE_SPHINX OFF)
   endif()
 
+  # In a standalone build, we don't have llvm to automatically generate the
+  # llvm-lit script for us.  So we need to provide an explicit directory that
+  # the configurator should write the script into.
+  set(LLVM_LIT_OUTPUT_DIR "${libcxx_BINARY_DIR}/bin")
+
   # Required LIT Configuration 
   # Define the default arguments to use with 'lit', and an option for the user
   # to override.

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=313606=313605=313606=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++ libcxx/trunk/test/CMakeLists.txt Mon Sep 18 19:46:28 2017
@@ -49,10 +49,9 @@ set(LIBCXX_EXECUTOR "None" CACHE STRING
 
 set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not 
edit!")
 
-configure_file(
+configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
-  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
-  @ONLY)
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
 
 set(LIBCXX_TEST_DEPS "")
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r313579 - [lit] Update clang and lld to use new config helpers.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Sep 18 15:26:48 2017
New Revision: 313579

URL: http://llvm.org/viewvc/llvm-project?rev=313579=rev
Log:
[lit] Update clang and lld to use new config helpers.

NFC intended here, this only updates clang and lld's lit configs
to use some helper functionality in the lit.llvm submodule.

Modified:
cfe/trunk/test/lit.cfg
cfe/trunk/test/lit.site.cfg.in

Modified: cfe/trunk/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg?rev=313579=313578=313579=diff
==
--- cfe/trunk/test/lit.cfg (original)
+++ cfe/trunk/test/lit.cfg Mon Sep 18 15:26:48 2017
@@ -9,39 +9,18 @@ import tempfile
 import lit.formats
 import lit.util
 
+from lit.llvm import llvm_config
+
 # Configuration file for the 'lit' test runner.
 
 # name: The name of this test suite.
 config.name = 'Clang'
 
-# Tweak PATH for Win32
-if platform.system() == 'Windows':
-# Seek sane tools in directories and set to $PATH.
-path = getattr(config, 'lit_tools_dir', None)
-path = lit_config.getToolsPath(path,
-   config.environment['PATH'],
-   ['cmp.exe', 'grep.exe', 'sed.exe'])
-if path is not None:
-path = os.path.pathsep.join((path,
- config.environment['PATH']))
-config.environment['PATH'] = path
-
-# Choose between lit's internal shell pipeline runner and a real shell.  If
-# LIT_USE_INTERNAL_SHELL is in the environment, we use that as an override.
-use_lit_shell = os.environ.get("LIT_USE_INTERNAL_SHELL")
-if use_lit_shell:
-# 0 is external, "" is default, and everything else is internal.
-execute_external = (use_lit_shell == "0")
-else:
-# Otherwise we default to internal on Windows and external elsewhere, as
-# bash on Windows is usually very slow.
-execute_external = (not sys.platform in ['win32'])
-
 # testFormat: The test format to use to interpret tests.
 #
 # For now we require '&&' between commands, until they get globally killed and
 # the test runner updated.
-config.test_format = lit.formats.ShTest(execute_external)
+config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
 
 # suffixes: A list of file extensions to treat as test files.
 config.suffixes = ['.c', '.cpp', '.cppm', '.m', '.mm', '.cu', '.ll', '.cl', 
'.s', '.S', '.modulemap', '.test', '.rs']
@@ -81,22 +60,16 @@ possibly_dangerous_env_vars = ['COMPILER
 # Clang/Win32 may refer to %INCLUDE%. vsvarsall.bat sets it.
 if platform.system() != 'Windows':
 possibly_dangerous_env_vars.append('INCLUDE')
-for name in possibly_dangerous_env_vars:
-  if name in config.environment:
-del config.environment[name]
+
+llvm_config.clear_environment(possibly_dangerous_env_vars)
 
 # Tweak the PATH to include the tools dir and the scripts dir.
-path = os.path.pathsep.join((
-config.clang_tools_dir, config.llvm_tools_dir, 
config.environment['PATH']))
-config.environment['PATH'] = path
-path = os.path.pathsep.join((config.llvm_shlib_dir, config.llvm_libs_dir,
-  config.environment.get('LD_LIBRARY_PATH','')))
-config.environment['LD_LIBRARY_PATH'] = path
+llvm_config.with_environment('PATH', [config.llvm_tools_dir, 
config.clang_tools_dir], append_path=True)
+
+llvm_config.with_environment('LD_LIBRARY_PATH', [config.llvm_shlib_dir, 
config.llvm_libs_dir], append_path=True)
 
 # Propagate path to symbolizer for ASan/MSan.
-for symbolizer in ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH']:
-if symbolizer in os.environ:
-config.environment[symbolizer] = os.environ[symbolizer]
+llvm_config.with_system_environment(['ASAN_SYMBOLIZER_PATH', 
'MSAN_SYMBOLIZER_PATH'])
 
 # Discover the 'clang' and 'clangcc' to use.
 
@@ -151,7 +124,7 @@ def getClangBuiltinIncludeDir(clang):
 if not cmd.stdout:
   lit_config.fatal("Couldn't find the include dir for Clang ('%s')" % 
clang)
 dir = cmd.stdout.read().strip()
-if sys.platform in ['win32'] and execute_external:
+if sys.platform in ['win32'] and not llvm_config.use_lit_shell:
 # Don't pass dosish path separator to msys bash.exe.
 dir = dir.replace('\\', '/')
 # Ensure the result is an ascii string, across Python2.5+ - Python3.
@@ -295,18 +268,6 @@ if config.clang_staticanalyzer:
 if platform.system() not in ['FreeBSD']:
 config.available_features.add('crash-recovery')
 
-# Shell execution
-if execute_external:
-config.available_features.add('shell')
-
-# For tests that require Darwin to run.
-# This is used by debuginfo-tests/*block*.m and debuginfo-tests/foreach.m.
-if platform.system() in ['Darwin']:
-config.available_features.add('system-darwin')
-elif platform.system() in ['Windows']:
-# For tests that require Windows to run.
-config.available_features.add('system-windows')
-
 # ANSI escape sequences in non-dumb terminal
 if platform.system() not in 

[clang-tools-extra] r313407 - Resubmit "[lit] Force site configs to run before source-tree configs"

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Sep 15 15:10:46 2017
New Revision: 313407

URL: http://llvm.org/viewvc/llvm-project?rev=313407=rev
Log:
Resubmit "[lit] Force site configs to run before source-tree configs"

This is a resubmission of r313270.  It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.

The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config.  If present, it
will generate llvm-lit into the output directory.  Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system.  This supports the use case of
someone installing lit via a package manager.  If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.

Differential Revision: https://reviews.llvm.org/D37756

Modified:
clang-tools-extra/trunk/test/Unit/lit.cfg
clang-tools-extra/trunk/test/lit.cfg

Modified: clang-tools-extra/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/Unit/lit.cfg?rev=313407=313406=313407=diff
==
--- clang-tools-extra/trunk/test/Unit/lit.cfg (original)
+++ clang-tools-extra/trunk/test/Unit/lit.cfg Fri Sep 15 15:10:46 2017
@@ -9,10 +9,9 @@ config.suffixes = [] # Seems not to matt
 
 # Test Source and Exec root dirs both point to the same directory where google
 # test binaries are built.
-extra_tools_obj_dir = getattr(config, 'extra_tools_obj_dir', None)
-if extra_tools_obj_dir is not None:
-  config.test_source_root = extra_tools_obj_dir
-  config.test_exec_root = config.test_source_root
+
+config.test_source_root = config.extra_tools_obj_dir
+config.test_exec_root = config.test_source_root
 
 # All GoogleTests are named to have 'Tests' as their suffix. The '.' option is
 # a special value for GoogleTest indicating that it should look through the
@@ -20,18 +19,6 @@ if extra_tools_obj_dir is not None:
 # ;-separated list of subdirectories).
 config.test_format = lit.formats.GoogleTest('.', 'Tests')
 
-# If the site-specific configuration wasn't loaded (e.g. the build system 
failed
-# to create it or the user is running a test file directly) try to come up with
-# sane config options.
-if config.test_exec_root is None:
-  # Look for a --param=extra_tools_unit_site_config option.
-  site_cfg = lit_config.params.get('extra_tools_unit_site_config', None)
-  if site_cfg and os.path.exists(site_cfg):
-  lit_config.load_config(config, site_cfg)
-  raise SystemExit
-
-  # FIXME: Support out-of-tree builds? See clang/test/Unit/lit.cfg if we care.
-
 shlibpath_var = ''
 if platform.system() == 'Linux':
 shlibpath_var = 'LD_LIBRARY_PATH'
@@ -41,17 +28,11 @@ elif platform.system() == 'Windows':
 shlibpath_var = 'PATH'
 
 # Point the dynamic loader at dynamic libraries in 'lib'.
-shlibdir = getattr(config, 'shlibdir', None)
-if not shlibdir:
-lit_config.fatal('No shlibdir set!')
-llvm_libs_dir = getattr(config, 'llvm_libs_dir', None)
-if not llvm_libs_dir:
-lit_config.fatal('No LLVM libs dir set!')
-shlibpath = os.path.pathsep.join((shlibdir, llvm_libs_dir,
+shlibpath = os.path.pathsep.join((config.shlibdir, config.llvm_libs_dir,
  config.environment.get(shlibpath_var,'')))
 
 # Win32 seeks DLLs along %PATH%.
-if sys.platform in ['win32', 'cygwin'] and os.path.isdir(shlibdir):
-shlibpath = os.path.pathsep.join((shlibdir, shlibpath))
+if sys.platform in ['win32', 'cygwin'] and os.path.isdir(config.shlibdir):
+shlibpath = os.path.pathsep.join((config.shlibdir, shlibpath))
 
 config.environment[shlibpath_var] = shlibpath

Modified: clang-tools-extra/trunk/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/lit.cfg?rev=313407=313406=313407=diff
==
--- clang-tools-extra/trunk/test/lit.cfg (original)
+++ clang-tools-extra/trunk/test/lit.cfg Fri Sep 15 15:10:46 2017
@@ -54,9 +54,7 @@ config.excludes = ['Inputs']
 config.test_source_root = os.path.dirname(__file__)
 
 # test_exec_root: The root path where tests should be run.
-clang_tools_binary_dir = getattr(config, 'clang_tools_binary_dir', None)
-if clang_tools_binary_dir is not None:
-config.test_exec_root = os.path.join(clang_tools_binary_dir, 'test')
+config.test_exec_root = os.path.join(config.clang_tools_binary_dir, 'test')
 
 # Clear some environment variables that might affect Clang.
 #
@@ -88,92 +86,19 @@ for name in possibly_dangerous_env_vars:
 del config.environment[name]
 
 # Tweak the PATH to include the tools dir and the scripts dir.
-if clang_tools_binary_dir is not None:
-clang_tools_dir = getattr(config, 'clang_tools_dir', None)
-if not clang_tools_dir:
-lit_config.fatal('No Clang tools dir 

r313407 - Resubmit "[lit] Force site configs to run before source-tree configs"

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Sep 15 15:10:46 2017
New Revision: 313407

URL: http://llvm.org/viewvc/llvm-project?rev=313407=rev
Log:
Resubmit "[lit] Force site configs to run before source-tree configs"

This is a resubmission of r313270.  It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.

The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config.  If present, it
will generate llvm-lit into the output directory.  Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system.  This supports the use case of
someone installing lit via a package manager.  If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.

Differential Revision: https://reviews.llvm.org/D37756

Modified:
cfe/trunk/runtime/CMakeLists.txt
cfe/trunk/test/Unit/lit.cfg
cfe/trunk/test/lit.cfg

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=313407=313406=313407=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Fri Sep 15 15:10:46 2017
@@ -77,6 +77,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
-DCOMPILER_RT_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
-DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
+   -DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
-DCMAKE_OSX_DEPLOYMENT_TARGET=${CMAKE_OSX_DEPLOYMENT_TARGET}
-DCMAKE_OSX_SYSROOT:PATH=${CMAKE_OSX_SYSROOT}
${COMPILER_RT_PASSTHROUGH_VARIABLES}

Modified: cfe/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Unit/lit.cfg?rev=313407=313406=313407=diff
==
--- cfe/trunk/test/Unit/lit.cfg (original)
+++ cfe/trunk/test/Unit/lit.cfg Fri Sep 15 15:10:46 2017
@@ -17,14 +17,11 @@ config.suffixes = []
 
 # test_source_root: The root path where tests are located.
 # test_exec_root: The root path where tests should be run.
-clang_obj_root = getattr(config, 'clang_obj_root', None)
-if clang_obj_root is not None:
-config.test_exec_root = os.path.join(clang_obj_root, 'unittests')
-config.test_source_root = config.test_exec_root
+config.test_exec_root = os.path.join(config.clang_obj_root, 'unittests')
+config.test_source_root = config.test_exec_root
 
 # testFormat: The test format to use to interpret tests.
-llvm_build_mode = getattr(config, 'llvm_build_mode', "Debug")
-config.test_format = lit.formats.GoogleTest(llvm_build_mode, 'Tests')
+config.test_format = lit.formats.GoogleTest(config.llvm_build_mode, 'Tests')
 
 # Propagate the temp directory. Windows requires this because it uses \Windows\
 # if none of these are present.
@@ -38,55 +35,6 @@ for symbolizer in ['ASAN_SYMBOLIZER_PATH
 if symbolizer in os.environ:
 config.environment[symbolizer] = os.environ[symbolizer]
 
-###
-
-# Check that the object root is known.
-if config.test_exec_root is None:
-# Otherwise, we haven't loaded the site specific configuration (the user is
-# probably trying to run on a test file directly, and either the site
-# configuration hasn't been created by the build system, or we are in an
-# out-of-tree build situation).
-
-# Check for 'clang_unit_site_config' user parameter, and use that if 
available.
-site_cfg = lit_config.params.get('clang_unit_site_config', None)
-if site_cfg and os.path.exists(site_cfg):
-lit_config.load_config(config, site_cfg)
-raise SystemExit
-
-# Try to detect the situation where we are using an out-of-tree build by
-# looking for 'llvm-config'.
-#
-# FIXME: I debated (i.e., wrote and threw away) adding logic to
-# automagically generate the lit.site.cfg if we are in some kind of fresh
-# build situation. This means knowing how to invoke the build system
-# though, and I decided it was too much magic.
-
-llvm_config = lit.util.which('llvm-config', config.environment['PATH'])
-if not llvm_config:
-lit_config.fatal('No site specific configuration available!')
-
-# Get the source and object roots.
-llvm_src_root = subprocess.check_output(['llvm-config', 
'--src-root']).strip()
-llvm_obj_root = subprocess.check_output(['llvm-config', 
'--obj-root']).strip()
-clang_src_root = os.path.join(llvm_src_root, "tools", "clang")
-clang_obj_root = os.path.join(llvm_obj_root, "tools", "clang")
-
-# Validate that we got a tree which points to here, using the standard
-# tools/clang layout.
-this_src_root = os.path.join(os.path.dirname(__file__),'..','..')
- 

[clang-tools-extra] r313335 - Revert "[lit] Force site configs to run before source-tree configs"

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 14 19:56:40 2017
New Revision: 313335

URL: http://llvm.org/viewvc/llvm-project?rev=313335=rev
Log:
Revert "[lit] Force site configs to run before source-tree configs"

This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.

Modified:
clang-tools-extra/trunk/test/Unit/lit.cfg
clang-tools-extra/trunk/test/lit.cfg

Modified: clang-tools-extra/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/Unit/lit.cfg?rev=313335=313334=313335=diff
==
--- clang-tools-extra/trunk/test/Unit/lit.cfg (original)
+++ clang-tools-extra/trunk/test/Unit/lit.cfg Thu Sep 14 19:56:40 2017
@@ -9,9 +9,10 @@ config.suffixes = [] # Seems not to matt
 
 # Test Source and Exec root dirs both point to the same directory where google
 # test binaries are built.
-
-config.test_source_root = config.extra_tools_obj_dir
-config.test_exec_root = config.test_source_root
+extra_tools_obj_dir = getattr(config, 'extra_tools_obj_dir', None)
+if extra_tools_obj_dir is not None:
+  config.test_source_root = extra_tools_obj_dir
+  config.test_exec_root = config.test_source_root
 
 # All GoogleTests are named to have 'Tests' as their suffix. The '.' option is
 # a special value for GoogleTest indicating that it should look through the
@@ -19,6 +20,18 @@ config.test_exec_root = config.test_sour
 # ;-separated list of subdirectories).
 config.test_format = lit.formats.GoogleTest('.', 'Tests')
 
+# If the site-specific configuration wasn't loaded (e.g. the build system 
failed
+# to create it or the user is running a test file directly) try to come up with
+# sane config options.
+if config.test_exec_root is None:
+  # Look for a --param=extra_tools_unit_site_config option.
+  site_cfg = lit_config.params.get('extra_tools_unit_site_config', None)
+  if site_cfg and os.path.exists(site_cfg):
+  lit_config.load_config(config, site_cfg)
+  raise SystemExit
+
+  # FIXME: Support out-of-tree builds? See clang/test/Unit/lit.cfg if we care.
+
 shlibpath_var = ''
 if platform.system() == 'Linux':
 shlibpath_var = 'LD_LIBRARY_PATH'
@@ -28,11 +41,17 @@ elif platform.system() == 'Windows':
 shlibpath_var = 'PATH'
 
 # Point the dynamic loader at dynamic libraries in 'lib'.
-shlibpath = os.path.pathsep.join((config.shlibdir, config.llvm_libs_dir,
+shlibdir = getattr(config, 'shlibdir', None)
+if not shlibdir:
+lit_config.fatal('No shlibdir set!')
+llvm_libs_dir = getattr(config, 'llvm_libs_dir', None)
+if not llvm_libs_dir:
+lit_config.fatal('No LLVM libs dir set!')
+shlibpath = os.path.pathsep.join((shlibdir, llvm_libs_dir,
  config.environment.get(shlibpath_var,'')))
 
 # Win32 seeks DLLs along %PATH%.
-if sys.platform in ['win32', 'cygwin'] and os.path.isdir(config.shlibdir):
-shlibpath = os.path.pathsep.join((config.shlibdir, shlibpath))
+if sys.platform in ['win32', 'cygwin'] and os.path.isdir(shlibdir):
+shlibpath = os.path.pathsep.join((shlibdir, shlibpath))
 
 config.environment[shlibpath_var] = shlibpath

Modified: clang-tools-extra/trunk/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/lit.cfg?rev=313335=313334=313335=diff
==
--- clang-tools-extra/trunk/test/lit.cfg (original)
+++ clang-tools-extra/trunk/test/lit.cfg Thu Sep 14 19:56:40 2017
@@ -54,7 +54,9 @@ config.excludes = ['Inputs']
 config.test_source_root = os.path.dirname(__file__)
 
 # test_exec_root: The root path where tests should be run.
-config.test_exec_root = os.path.join(config.clang_tools_binary_dir, 'test')
+clang_tools_binary_dir = getattr(config, 'clang_tools_binary_dir', None)
+if clang_tools_binary_dir is not None:
+config.test_exec_root = os.path.join(clang_tools_binary_dir, 'test')
 
 # Clear some environment variables that might affect Clang.
 #
@@ -86,19 +88,92 @@ for name in possibly_dangerous_env_vars:
 del config.environment[name]
 
 # Tweak the PATH to include the tools dir and the scripts dir.
-path = os.path.pathsep.join((
-config.clang_tools_dir, config.llvm_tools_dir, 
config.environment['PATH']))
-config.environment['PATH'] = path
-
-path = os.path.pathsep.join((config.clang_libs_dir, config.llvm_libs_dir,
-  config.environment.get('LD_LIBRARY_PATH','')))
-config.environment['LD_LIBRARY_PATH'] = path
+if clang_tools_binary_dir is not None:
+clang_tools_dir = getattr(config, 'clang_tools_dir', None)
+if not clang_tools_dir:
+lit_config.fatal('No Clang tools dir set!')
+llvm_tools_dir = getattr(config, 'llvm_tools_dir', None)
+if not llvm_tools_dir:
+lit_config.fatal('No LLVM tools dir set!')
+path = os.path.pathsep.join((
+

r313335 - Revert "[lit] Force site configs to run before source-tree configs"

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 14 19:56:40 2017
New Revision: 313335

URL: http://llvm.org/viewvc/llvm-project?rev=313335=rev
Log:
Revert "[lit] Force site configs to run before source-tree configs"

This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.

Modified:
cfe/trunk/runtime/CMakeLists.txt
cfe/trunk/test/Unit/lit.cfg
cfe/trunk/test/lit.cfg

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=313335=313334=313335=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Thu Sep 14 19:56:40 2017
@@ -77,7 +77,6 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
-DCOMPILER_RT_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
-DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
-   -DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
-DCMAKE_OSX_DEPLOYMENT_TARGET=${CMAKE_OSX_DEPLOYMENT_TARGET}
-DCMAKE_OSX_SYSROOT:PATH=${CMAKE_OSX_SYSROOT}
${COMPILER_RT_PASSTHROUGH_VARIABLES}

Modified: cfe/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Unit/lit.cfg?rev=313335=313334=313335=diff
==
--- cfe/trunk/test/Unit/lit.cfg (original)
+++ cfe/trunk/test/Unit/lit.cfg Thu Sep 14 19:56:40 2017
@@ -17,11 +17,14 @@ config.suffixes = []
 
 # test_source_root: The root path where tests are located.
 # test_exec_root: The root path where tests should be run.
-config.test_exec_root = os.path.join(config.clang_obj_root, 'unittests')
-config.test_source_root = config.test_exec_root
+clang_obj_root = getattr(config, 'clang_obj_root', None)
+if clang_obj_root is not None:
+config.test_exec_root = os.path.join(clang_obj_root, 'unittests')
+config.test_source_root = config.test_exec_root
 
 # testFormat: The test format to use to interpret tests.
-config.test_format = lit.formats.GoogleTest(config.llvm_build_mode, 'Tests')
+llvm_build_mode = getattr(config, 'llvm_build_mode', "Debug")
+config.test_format = lit.formats.GoogleTest(llvm_build_mode, 'Tests')
 
 # Propagate the temp directory. Windows requires this because it uses \Windows\
 # if none of these are present.
@@ -35,6 +38,55 @@ for symbolizer in ['ASAN_SYMBOLIZER_PATH
 if symbolizer in os.environ:
 config.environment[symbolizer] = os.environ[symbolizer]
 
+###
+
+# Check that the object root is known.
+if config.test_exec_root is None:
+# Otherwise, we haven't loaded the site specific configuration (the user is
+# probably trying to run on a test file directly, and either the site
+# configuration hasn't been created by the build system, or we are in an
+# out-of-tree build situation).
+
+# Check for 'clang_unit_site_config' user parameter, and use that if 
available.
+site_cfg = lit_config.params.get('clang_unit_site_config', None)
+if site_cfg and os.path.exists(site_cfg):
+lit_config.load_config(config, site_cfg)
+raise SystemExit
+
+# Try to detect the situation where we are using an out-of-tree build by
+# looking for 'llvm-config'.
+#
+# FIXME: I debated (i.e., wrote and threw away) adding logic to
+# automagically generate the lit.site.cfg if we are in some kind of fresh
+# build situation. This means knowing how to invoke the build system
+# though, and I decided it was too much magic.
+
+llvm_config = lit.util.which('llvm-config', config.environment['PATH'])
+if not llvm_config:
+lit_config.fatal('No site specific configuration available!')
+
+# Get the source and object roots.
+llvm_src_root = subprocess.check_output(['llvm-config', 
'--src-root']).strip()
+llvm_obj_root = subprocess.check_output(['llvm-config', 
'--obj-root']).strip()
+clang_src_root = os.path.join(llvm_src_root, "tools", "clang")
+clang_obj_root = os.path.join(llvm_obj_root, "tools", "clang")
+
+# Validate that we got a tree which points to here, using the standard
+# tools/clang layout.
+this_src_root = os.path.join(os.path.dirname(__file__),'..','..')
+if os.path.realpath(clang_src_root) != os.path.realpath(this_src_root):
+lit_config.fatal('No site specific configuration available!')
+
+# Check that the site specific configuration exists.
+site_cfg = os.path.join(clang_obj_root, 'test', 'Unit', 'lit.site.cfg')
+if not os.path.exists(site_cfg):
+lit_config.fatal('No site specific configuration available!')
+
+# Okay, that worked. Notify the user of the automagic, and reconfigure.
+lit_config.note('using out-of-tree build at %r' % clang_obj_root)
+

r313300 - Fix 2 stage build on some apple bots.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 14 14:30:27 2017
New Revision: 313300

URL: http://llvm.org/viewvc/llvm-project?rev=313300=rev
Log:
Fix 2 stage build on some apple bots.

The recent lit refactor changed the location of the lit script
run by check targets from /utils/lit/lit.py to
/llvm-lit.py.  In some 2-stage build scenarios, the location
of  was not properly passed through to the second stage,
and it was looking for /llvm-lit.py instead, causing failures.

Fix suggested by Mike Edwards and Chris Bieneman @apple

Modified:
cfe/trunk/runtime/CMakeLists.txt

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=313300=313299=313300=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Thu Sep 14 14:30:27 2017
@@ -77,6 +77,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
-DCOMPILER_RT_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
-DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
+   -DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
-DCMAKE_OSX_DEPLOYMENT_TARGET=${CMAKE_OSX_DEPLOYMENT_TARGET}
-DCMAKE_OSX_SYSROOT:PATH=${CMAKE_OSX_SYSROOT}
${COMPILER_RT_PASSTHROUGH_VARIABLES}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r313270 - [lit] Force site configs to be run before source-tree configs

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 14 09:47:58 2017
New Revision: 313270

URL: http://llvm.org/viewvc/llvm-project?rev=313270=rev
Log:
[lit] Force site configs to be run before source-tree configs

This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.

A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run.  However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on.  As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.

This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.

This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.

On the other hand, for us it allows us to make many simplifications:

* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
  might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=
  on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
  support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
  finding a site config from the main config are now gone.

One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=` parameters.  Instead, you need to run
llvm-lit.py.

Differential Revision: https://reviews.llvm.org/D37756

Modified:
cfe/trunk/test/Unit/lit.cfg
cfe/trunk/test/lit.cfg

Modified: cfe/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Unit/lit.cfg?rev=313270=313269=313270=diff
==
--- cfe/trunk/test/Unit/lit.cfg (original)
+++ cfe/trunk/test/Unit/lit.cfg Thu Sep 14 09:47:58 2017
@@ -17,14 +17,11 @@ config.suffixes = []
 
 # test_source_root: The root path where tests are located.
 # test_exec_root: The root path where tests should be run.
-clang_obj_root = getattr(config, 'clang_obj_root', None)
-if clang_obj_root is not None:
-config.test_exec_root = os.path.join(clang_obj_root, 'unittests')
-config.test_source_root = config.test_exec_root
+config.test_exec_root = os.path.join(config.clang_obj_root, 'unittests')
+config.test_source_root = config.test_exec_root
 
 # testFormat: The test format to use to interpret tests.
-llvm_build_mode = getattr(config, 'llvm_build_mode', "Debug")
-config.test_format = lit.formats.GoogleTest(llvm_build_mode, 'Tests')
+config.test_format = lit.formats.GoogleTest(config.llvm_build_mode, 'Tests')
 
 # Propagate the temp directory. Windows requires this because it uses \Windows\
 # if none of these are present.
@@ -38,55 +35,6 @@ for symbolizer in ['ASAN_SYMBOLIZER_PATH
 if symbolizer in os.environ:
 config.environment[symbolizer] = os.environ[symbolizer]
 
-###
-
-# Check that the object root is known.
-if config.test_exec_root is None:
-# Otherwise, we haven't loaded the site specific configuration (the user is
-# probably trying to run on a test file directly, and either the site
-# configuration hasn't been created by the build system, or we are in an
-# out-of-tree build situation).
-
-# Check for 'clang_unit_site_config' user parameter, and use that if 
available.
-site_cfg = lit_config.params.get('clang_unit_site_config', None)
-if site_cfg and os.path.exists(site_cfg):
-lit_config.load_config(config, site_cfg)
-raise SystemExit
-
-# Try to detect the situation where we are using an out-of-tree build by
-# looking for 'llvm-config'.
-#
-# FIXME: I debated (i.e., wrote and threw away) adding logic to
-# automagically generate the lit.site.cfg if we are in some kind of fresh
-# build situation. This means knowing how to invoke the build system
-# though, and I decided it was too much magic.
-
-llvm_config = lit.util.which('llvm-config', config.environment['PATH'])
-if not llvm_config:
-lit_config.fatal('No site specific configuration available!')
-
-# Get the source and object roots.
-llvm_src_root = 

[clang-tools-extra] r313270 - [lit] Force site configs to be run before source-tree configs

[Zachary Turner via cfe-commits]

Author: zturner
Date: Thu Sep 14 09:47:58 2017
New Revision: 313270

URL: http://llvm.org/viewvc/llvm-project?rev=313270=rev
Log:
[lit] Force site configs to be run before source-tree configs

This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.

A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run.  However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on.  As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.

This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.

This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.

On the other hand, for us it allows us to make many simplifications:

* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
  might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=
  on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
  support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
  finding a site config from the main config are now gone.

One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=` parameters.  Instead, you need to run
llvm-lit.py.

Differential Revision: https://reviews.llvm.org/D37756

Modified:
clang-tools-extra/trunk/test/Unit/lit.cfg
clang-tools-extra/trunk/test/lit.cfg

Modified: clang-tools-extra/trunk/test/Unit/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/Unit/lit.cfg?rev=313270=313269=313270=diff
==
--- clang-tools-extra/trunk/test/Unit/lit.cfg (original)
+++ clang-tools-extra/trunk/test/Unit/lit.cfg Thu Sep 14 09:47:58 2017
@@ -9,10 +9,9 @@ config.suffixes = [] # Seems not to matt
 
 # Test Source and Exec root dirs both point to the same directory where google
 # test binaries are built.
-extra_tools_obj_dir = getattr(config, 'extra_tools_obj_dir', None)
-if extra_tools_obj_dir is not None:
-  config.test_source_root = extra_tools_obj_dir
-  config.test_exec_root = config.test_source_root
+
+config.test_source_root = config.extra_tools_obj_dir
+config.test_exec_root = config.test_source_root
 
 # All GoogleTests are named to have 'Tests' as their suffix. The '.' option is
 # a special value for GoogleTest indicating that it should look through the
@@ -20,18 +19,6 @@ if extra_tools_obj_dir is not None:
 # ;-separated list of subdirectories).
 config.test_format = lit.formats.GoogleTest('.', 'Tests')
 
-# If the site-specific configuration wasn't loaded (e.g. the build system 
failed
-# to create it or the user is running a test file directly) try to come up with
-# sane config options.
-if config.test_exec_root is None:
-  # Look for a --param=extra_tools_unit_site_config option.
-  site_cfg = lit_config.params.get('extra_tools_unit_site_config', None)
-  if site_cfg and os.path.exists(site_cfg):
-  lit_config.load_config(config, site_cfg)
-  raise SystemExit
-
-  # FIXME: Support out-of-tree builds? See clang/test/Unit/lit.cfg if we care.
-
 shlibpath_var = ''
 if platform.system() == 'Linux':
 shlibpath_var = 'LD_LIBRARY_PATH'
@@ -41,17 +28,11 @@ elif platform.system() == 'Windows':
 shlibpath_var = 'PATH'
 
 # Point the dynamic loader at dynamic libraries in 'lib'.
-shlibdir = getattr(config, 'shlibdir', None)
-if not shlibdir:
-lit_config.fatal('No shlibdir set!')
-llvm_libs_dir = getattr(config, 'llvm_libs_dir', None)
-if not llvm_libs_dir:
-lit_config.fatal('No LLVM libs dir set!')
-shlibpath = os.path.pathsep.join((shlibdir, llvm_libs_dir,
+shlibpath = os.path.pathsep.join((config.shlibdir, config.llvm_libs_dir,
  config.environment.get(shlibpath_var,'')))
 
 # Win32 seeks DLLs along %PATH%.
 if sys.platform in ['win32', 'cygwin'] and os.path.isdir(shlibdir):
-shlibpath = os.path.pathsep.join((shlibdir, shlibpath))
+shlibpath = 

Re: [PATCH] D37529: [codeview] omit debug locations for nested exprs unless column info enabled

[Zachary Turner via cfe-commits]

Well, if they worked I wasn't going to say we needed to add tests for them,
i just wanted to make sure they work before we move onto something else.
In any case, lgtm

On Fri, Sep 8, 2017 at 4:43 PM Bob Haarman via Phabricator <
revi...@reviews.llvm.org> wrote:

> inglorion updated this revision to Diff 114463.
> inglorion added a comment.
>
> added examples suggested by @zturner, verified step over and step into
> specific behavior matches MSVC, and added tests for them
>
>
> https://reviews.llvm.org/D37529
>
> Files:
>   clang/lib/CodeGen/CGDebugInfo.cpp
>   clang/lib/CodeGen/CodeGenModule.h
>   clang/test/CodeGenCXX/debug-info-nested-exprs.cpp
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D31697: Check for null before using TUScope

[Zachary Turner via cfe-commits]

Might want to ask on cfe-dev or irc for more visibility since this review
thread isn't getting much action
On Thu, Jun 29, 2017 at 5:12 AM Kim Gräsman via Phabricator <
revi...@reviews.llvm.org> wrote:

> kimgr added a comment.
>
> I did some more debugging today. This happens when we attempt to analyze
> llvm/Support/MathExtras.h, and only for the function templates that use
> Microsoft intrinsics (e.g. `_BitScanForward` in `TrailingZerosCounter`.)
> So there's something in the parsing of builtins/intrinsics that requires
> `TUScope` to be non-null.
>
> Can we seed Sema with a valid `TUScope` before invoking
> `LateTemplateParser`, and if so, how? Or is this because we invoke the
> parser multiple times? I'm guessing Clang is already done parsing when we
> invoke the late template parsing.
>
> Grateful for any ideas here.
>
>
> https://reviews.llvm.org/D31697
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r298322 - Add a function to MD5 a file's contents.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Mon Mar 20 18:33:18 2017
New Revision: 298322

URL: http://llvm.org/viewvc/llvm-project?rev=298322=rev
Log:
Add a function to MD5 a file's contents.

In doing so, clean up the MD5 interface a little.  Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface.  Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.

Differential Revision: https://reviews.llvm.org/D31105

Modified:
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
cfe/trunk/lib/Frontend/ASTUnit.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenPGO.cpp?rev=298322=298321=298322=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Mon Mar 20 18:33:18 2017
@@ -612,7 +612,7 @@ uint64_t PGOHash::finalize() {
   llvm::MD5::MD5Result Result;
   MD5.final(Result);
   using namespace llvm::support;
-  return endian::read(Result);
+  return Result.low();
 }
 
 void CodeGenPGO::assignRegionCounters(GlobalDecl GD, llvm::Function *Fn) {

Modified: cfe/trunk/lib/Frontend/ASTUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/ASTUnit.cpp?rev=298322=298321=298322=diff
==
--- cfe/trunk/lib/Frontend/ASTUnit.cpp (original)
+++ cfe/trunk/lib/Frontend/ASTUnit.cpp Mon Mar 20 18:33:18 2017
@@ -1252,7 +1252,7 @@ ASTUnit::PreambleFileHash::createForFile
   PreambleFileHash Result;
   Result.Size = Size;
   Result.ModTime = ModTime;
-  memset(Result.MD5, 0, sizeof(Result.MD5));
+  Result.MD5 = {};
   return Result;
 }
 
@@ -1273,7 +1273,7 @@ namespace clang {
 bool operator==(const ASTUnit::PreambleFileHash ,
 const ASTUnit::PreambleFileHash ) {
   return LHS.Size == RHS.Size && LHS.ModTime == RHS.ModTime &&
- memcmp(LHS.MD5, RHS.MD5, sizeof(LHS.MD5)) == 0;
+ LHS.MD5 == RHS.MD5;
 }
 } // namespace clang
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r298098 - [clang-cl] Fix cross-compilation with MSVC 2017.

[Zachary Turner via cfe-commits]

Author: zturner
Date: Fri Mar 17 11:24:34 2017
New Revision: 298098

URL: http://llvm.org/viewvc/llvm-project?rev=298098=rev
Log:
[clang-cl] Fix cross-compilation with MSVC 2017.

clang-cl works best when the user runs vcvarsall to set up
an environment before running, but even this is not enough
on VC 2017 when cross compiling (e.g. using an x64 toolchain
to target x86, or vice versa).

The reason is that although clang-cl itself will have a
valid environment, it will shell out to other tools (such
as link.exe) which may not.  Generally we solve this through
adding the appropriate linker flags, but this is not enough
in VC 2017.

The cross-linker and the regular linker both link against
some common DLLs, but these DLLs live in the binary directory
of the native linker.  When setting up a cross-compilation
environment through vcvarsall, it will add *both* directories
to %PATH%, so that when cl shells out to any of the associated
tools, those tools will be able to find all of the dependencies
that it links against.  If you don't do this, link.exe will
fail to run because the loader won't be able to find all of
the required DLLs that it links against.

To solve this we teach the driver how to spawn a process with
an explicitly specified environment.  Then we modify the
PATH before shelling out to subtools and run with the modified
PATH.

Patch by Hamza Sood
Differential Revision: https://reviews.llvm.org/D30991

Modified:
cfe/trunk/include/clang/Driver/Job.h
cfe/trunk/lib/Driver/Job.cpp
cfe/trunk/lib/Driver/ToolChains/MSVC.cpp

Modified: cfe/trunk/include/clang/Driver/Job.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Job.h?rev=298098=298097=298098=diff
==
--- cfe/trunk/include/clang/Driver/Job.h (original)
+++ cfe/trunk/include/clang/Driver/Job.h Fri Mar 17 11:24:34 2017
@@ -11,6 +11,7 @@
 #define LLVM_CLANG_DRIVER_JOB_H
 
 #include "clang/Basic/LLVM.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/iterator.h"
 #include "llvm/Option/Option.h"
@@ -69,6 +70,9 @@ class Command {
   /// file
   std::string ResponseFileFlag;
 
+  /// See Command::setEnvironment
+  std::vector Environment;
+
   /// When a response file is needed, we try to put most arguments in an
   /// exclusive file, while others remains as regular command line arguments.
   /// This functions fills a vector with the regular command line arguments,
@@ -111,6 +115,12 @@ public:
 InputFileList = std::move(List);
   }
 
+  /// \brief Sets the environment to be used by the new process.
+  /// \param NewEnvironment An array of environment variables.
+  /// \remark If the environment remains unset, then the environment
+  /// from the parent process will be used.
+  void setEnvironment(llvm::ArrayRef NewEnvironment);
+
   const char *getExecutable() const { return Executable; }
 
   const llvm::opt::ArgStringList () const { return Arguments; }

Modified: cfe/trunk/lib/Driver/Job.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Job.cpp?rev=298098=298097=298098=diff
==
--- cfe/trunk/lib/Driver/Job.cpp (original)
+++ cfe/trunk/lib/Driver/Job.cpp Fri Mar 17 11:24:34 2017
@@ -301,19 +301,33 @@ void Command::setResponseFile(const char
   ResponseFileFlag += FileName;
 }
 
+void Command::setEnvironment(llvm::ArrayRef NewEnvironment) {
+  Environment.reserve(NewEnvironment.size() + 1);
+  Environment.assign(NewEnvironment.begin(), NewEnvironment.end());
+  Environment.push_back(nullptr);
+}
+
 int Command::Execute(const StringRef **Redirects, std::string *ErrMsg,
  bool *ExecutionFailed) const {
   SmallVector Argv;
 
+  const char **Envp;
+  if (Environment.empty()) {
+Envp = nullptr;
+  } else {
+assert(Environment.back() == nullptr &&
+   "Environment vector should be null-terminated by now");
+Envp = const_cast(Environment.data());
+  }
+
   if (ResponseFile == nullptr) {
 Argv.push_back(Executable);
 Argv.append(Arguments.begin(), Arguments.end());
 Argv.push_back(nullptr);
 
-return llvm::sys::ExecuteAndWait(Executable, Argv.data(), /*env*/ nullptr,
- Redirects, /*secondsToWait*/ 0,
- /*memoryLimit*/ 0, ErrMsg,
- ExecutionFailed);
+return llvm::sys::ExecuteAndWait(
+Executable, Argv.data(), Envp, Redirects, /*secondsToWait*/ 0,
+/*memoryLimit*/ 0, ErrMsg, ExecutionFailed);
   }
 
   // We need to put arguments in a response file (command is too large)
@@ -337,8 +351,8 @@ int Command::Execute(const StringRef **R
 return -1;
   }
 
-  return llvm::sys::ExecuteAndWait(Executable, Argv.data(), /*env*/ nullptr,
-   Redirects, /*secondsToWait*/ 0,
+  return