Re: [PATCH] D16764: [clang-tidy] Move incorrect-roundings to upstream.
alexfh accepted this revision. alexfh added a comment. This revision is now accepted and ready to land. Looks good. Thanks! http://reviews.llvm.org/D16764 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability
ariccio added a comment. All clear. Ready for landing? http://reviews.llvm.org/D16873 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability
ariccio updated this revision to Diff 47161.
ariccio added a comment.
Responded to comments (fixed the bug noticed in review), and changed names.
http://reviews.llvm.org/D16873
Files:
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
Index: llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
===
--- llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
+++ llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
@@ -1180,6 +1180,16 @@
/// a specified VarDecl and LocationContext.
const VarRegion* getVarRegion(const VarDecl *D, const LocationContext *LC);
+private:
+ /// Retrieve or create the memory region
+ /// associated with a VarDecl for a global variable.
+ const MemRegion *getMemSpaceForGlobalVariable(const VarDecl *D);
+
+ /// Retrieve or create the memory region
+ /// associated with a specified VarDecl and LocationContext.
+ const MemRegion *getMemSpaceForLocalVariable(const VarDecl *D, llvm::PointerUnion &V);
+
+public:
/// getVarRegion - Retrieve or create the memory region associated with
/// a specified VarDecl and super region.
const VarRegion* getVarRegion(const VarDecl *D, const MemRegion *superR);
Index: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
===
--- llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
+++ llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp
@@ -766,34 +766,76 @@
return (const StackFrameContext *)nullptr;
}
+const MemRegion* MemRegionManager::getMemSpaceForGlobalVariable(const VarDecl *D) {
+ assert(D->hasGlobalStorage());
+ assert(!D->isStaticLocal());
+ // First handle the globals defined in system headers.
+ if (C.getSourceManager().isInSystemHeader(D->getLocation())) {
+// Whitelist the system globals which often DO GET modified, assume the
+// rest are immutable.
+if (D->getName().find("errno") != StringRef::npos)
+ return getGlobalsRegion(MemRegion::GlobalSystemSpaceRegionKind);
+
+return getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
+ }
+ // Treat other globals as GlobalInternal unless they are constants.
+ QualType GQT = D->getType();
+ const Type *GT = GQT.getTypePtrOrNull();
+ // TODO: We could walk the complex types here and see if everything is
+ // constified.
+ if (GT && GQT.isConstQualified() && GT->isArithmeticType())
+return getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
+
+ return getGlobalsRegion();
+}
+
+const MemRegion* MemRegionManager::getMemSpaceForLocalVariable(const VarDecl *D, llvm::PointerUnion &V) {
+ const StackFrameContext *STC = V.get();
+
+ if (!STC)
+return getUnknownRegion();
+
+ if (D->hasLocalStorage()) {
+return (isa(D) || isa(D)
+ ? static_cast(getStackArgumentsRegion(STC))
+ : static_cast(getStackLocalsRegion(STC)));
+ }
+ assert(D->isStaticLocal());
+ const Decl *STCD = STC->getDecl();
+ if (isa(STCD) || isa(STCD))
+return getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
+getFunctionCodeRegion(cast(STCD)));
+
+ else if (const BlockDecl *BD = dyn_cast(STCD)) {
+// FIXME: The fallback type here is totally bogus -- though it should
+// never be queried, it will prevent uniquing with the real
+// BlockCodeRegion. Ideally we'd fix the AST so that we always had a
+// signature.
+QualType T;
+if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
+ T = TSI->getType();
+if (T.isNull())
+ T = getContext().VoidTy;
+if (!T->getAs())
+ T = getContext().getFunctionNoProtoType(T);
+T = getContext().getBlockPointerType(T);
+
+const BlockCodeRegion *BTR =
+ getBlockCodeRegion(BD, C.getCanonicalType(T),
+ STC->getAnalysisDeclContext());
+return getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
+BTR);
+ }
+ return getGlobalsRegion();
+}
+
const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
const LocationContext *LC) {
const MemRegion *sReg = nullptr;
if (D->hasGlobalStorage() && !D->isStaticLocal()) {
+sReg = getMemSpaceForGlobalVariable(D);
-// First handle the globals defined in system headers.
-if (C.getSourceManager().isInSystemHeader(D->getLocation())) {
- // Whitelist the system globals which often DO GET modified, assume the
- // rest are immutable.
- if (D->getName().find("errno") != StringRef::npos)
-sReg = getGlobalsRegion(MemRegion::GlobalSystemSpaceRegionKind);
- else
-sReg = getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
-
-// Treat other globals as GlobalInternal unless they are constants.
-} el
Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability
ariccio marked 3 inline comments as done. ariccio added a comment. Alrighty, will update the diff momentarily. http://reviews.llvm.org/D16873 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization
This revision was automatically updated to reflect the committed changes.
Closed by commit rL260074: [Concepts] Implement a portion of Concepts
TS[dcl.spec.concept]p1 by (authored by nwilson).
Changed prior to commit:
http://reviews.llvm.org/D13357?vs=46863&id=47160#toc
Repository:
rL LLVM
http://reviews.llvm.org/D13357
Files:
cfe/trunk/include/clang/AST/DeclTemplate.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
Index: cfe/trunk/include/clang/AST/DeclTemplate.h
===
--- cfe/trunk/include/clang/AST/DeclTemplate.h
+++ cfe/trunk/include/clang/AST/DeclTemplate.h
@@ -332,32 +332,31 @@
void anchor() override;
protected:
// This is probably never used.
- TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L,
- DeclarationName Name)
-: NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr),
- TemplateParams(nullptr) {}
+ TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L, DeclarationName Name)
+ : NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr, false),
+TemplateParams(nullptr) {}
// Construct a template decl with the given name and parameters.
// Used when there is not templated element (tt-params).
- TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L,
- DeclarationName Name, TemplateParameterList *Params)
-: NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr),
- TemplateParams(Params) {}
+ TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L, DeclarationName Name,
+ TemplateParameterList *Params)
+ : NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr, false),
+TemplateParams(Params) {}
// Construct a template decl with name, parameters, and templated element.
- TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L,
- DeclarationName Name, TemplateParameterList *Params,
- NamedDecl *Decl)
-: NamedDecl(DK, DC, L, Name), TemplatedDecl(Decl),
- TemplateParams(Params) { }
+ TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L, DeclarationName Name,
+ TemplateParameterList *Params, NamedDecl *Decl)
+ : NamedDecl(DK, DC, L, Name), TemplatedDecl(Decl, false),
+TemplateParams(Params) {}
+
public:
/// Get the list of template parameters
TemplateParameterList *getTemplateParameters() const {
return TemplateParams;
}
/// Get the underlying, templated declaration.
- NamedDecl *getTemplatedDecl() const { return TemplatedDecl; }
+ NamedDecl *getTemplatedDecl() const { return TemplatedDecl.getPointer(); }
// Implement isa/cast/dyncast/etc.
static bool classof(const Decl *D) { return classofKind(D->getKind()); }
@@ -367,20 +366,30 @@
SourceRange getSourceRange() const override LLVM_READONLY {
return SourceRange(TemplateParams->getTemplateLoc(),
- TemplatedDecl->getSourceRange().getEnd());
+ TemplatedDecl.getPointer()->getSourceRange().getEnd());
}
+ /// Whether this is a (C++ Concepts TS) function or variable concept.
+ bool isConcept() const { return TemplatedDecl.getInt(); }
+ void setConcept() { TemplatedDecl.setInt(true); }
+
protected:
- NamedDecl *TemplatedDecl;
+ /// \brief The named declaration from which this template was instantiated.
+ /// (or null).
+ ///
+ /// The boolean value will be true to indicate that this template
+ /// (function or variable) is a concept.
+ llvm::PointerIntPair TemplatedDecl;
+
TemplateParameterList* TemplateParams;
public:
/// \brief Initialize the underlying templated declaration and
/// template parameters.
void init(NamedDecl *templatedDecl, TemplateParameterList* templateParams) {
-assert(!TemplatedDecl && "TemplatedDecl already set!");
+assert(!TemplatedDecl.getPointer() && "TemplatedDecl already set!");
assert(!TemplateParams && "TemplateParams already set!");
-TemplatedDecl = templatedDecl;
+TemplatedDecl.setPointer(templatedDecl);
TemplateParams = templateParams;
}
};
@@ -889,7 +898,7 @@
/// Get the underlying function declaration of the template.
FunctionDecl *getTemplatedDecl() const {
-return static_cast(TemplatedDecl);
+return static_cast(TemplatedDecl.getPointer());
}
/// Returns whether this template declaration defines the primary
@@ -1982,7 +1991,7 @@
/// \brief Get the underlying class declarations of the template.
CXXRecordDecl *getTemplatedDecl() const {
-return static_cast(TemplatedDecl);
+return static_cast(TemplatedDecl.getPointer());
}
/// \brief Returns whether this template declaration defines the primary
@@ -2245,7 +2254,7 @@
public:
/// Get the underlying function declaration of the template.
TypeAliasDecl *getTemplatedDecl() const {
-return static
r260074 - [Concepts] Implement a portion of Concepts TS[dcl.spec.concept]p1 by
Author: nwilson
Date: Sun Feb 7 23:34:00 2016
New Revision: 260074
URL: http://llvm.org/viewvc/llvm-project?rev=260074&view=rev
Log:
[Concepts] Implement a portion of Concepts TS[dcl.spec.concept]p1 by
diagnosing when 'concept' is specified on a function or template
specialization.
Since a concept can only be applied to a function or variable template,
the concept bit is stored in TemplateDecl as a PointerIntPair.
Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast
Differential Revision: http://reviews.llvm.org/D13357
Modified:
cfe/trunk/include/clang/AST/DeclTemplate.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=260074&r1=260073&r2=260074&view=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Sun Feb 7 23:34:00 2016
@@ -332,24 +332,23 @@ class TemplateDecl : public NamedDecl {
void anchor() override;
protected:
// This is probably never used.
- TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L,
- DeclarationName Name)
-: NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr),
- TemplateParams(nullptr) {}
+ TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L, DeclarationName
Name)
+ : NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr, false),
+TemplateParams(nullptr) {}
// Construct a template decl with the given name and parameters.
// Used when there is not templated element (tt-params).
- TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L,
- DeclarationName Name, TemplateParameterList *Params)
-: NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr),
- TemplateParams(Params) {}
+ TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L, DeclarationName
Name,
+ TemplateParameterList *Params)
+ : NamedDecl(DK, DC, L, Name), TemplatedDecl(nullptr, false),
+TemplateParams(Params) {}
// Construct a template decl with name, parameters, and templated element.
- TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L,
- DeclarationName Name, TemplateParameterList *Params,
- NamedDecl *Decl)
-: NamedDecl(DK, DC, L, Name), TemplatedDecl(Decl),
- TemplateParams(Params) { }
+ TemplateDecl(Kind DK, DeclContext *DC, SourceLocation L, DeclarationName
Name,
+ TemplateParameterList *Params, NamedDecl *Decl)
+ : NamedDecl(DK, DC, L, Name), TemplatedDecl(Decl, false),
+TemplateParams(Params) {}
+
public:
/// Get the list of template parameters
TemplateParameterList *getTemplateParameters() const {
@@ -357,7 +356,7 @@ public:
}
/// Get the underlying, templated declaration.
- NamedDecl *getTemplatedDecl() const { return TemplatedDecl; }
+ NamedDecl *getTemplatedDecl() const { return TemplatedDecl.getPointer(); }
// Implement isa/cast/dyncast/etc.
static bool classof(const Decl *D) { return classofKind(D->getKind()); }
@@ -367,20 +366,30 @@ public:
SourceRange getSourceRange() const override LLVM_READONLY {
return SourceRange(TemplateParams->getTemplateLoc(),
- TemplatedDecl->getSourceRange().getEnd());
+ TemplatedDecl.getPointer()->getSourceRange().getEnd());
}
+ /// Whether this is a (C++ Concepts TS) function or variable concept.
+ bool isConcept() const { return TemplatedDecl.getInt(); }
+ void setConcept() { TemplatedDecl.setInt(true); }
+
protected:
- NamedDecl *TemplatedDecl;
+ /// \brief The named declaration from which this template was instantiated.
+ /// (or null).
+ ///
+ /// The boolean value will be true to indicate that this template
+ /// (function or variable) is a concept.
+ llvm::PointerIntPair TemplatedDecl;
+
TemplateParameterList* TemplateParams;
public:
/// \brief Initialize the underlying templated declaration and
/// template parameters.
void init(NamedDecl *templatedDecl, TemplateParameterList* templateParams) {
-assert(!TemplatedDecl && "TemplatedDecl already set!");
+assert(!TemplatedDecl.getPointer() && "TemplatedDecl already set!");
assert(!TemplateParams && "TemplateParams already set!");
-TemplatedDecl = templatedDecl;
+TemplatedDecl.setPointer(templatedDecl);
TemplateParams = templateParams;
}
};
@@ -889,7 +898,7 @@ public:
/// Get the underlying function declaration of the template.
FunctionDecl *getTemplatedDecl() const {
-return static_cast(TemplatedDecl);
+return static_cast(TemplatedDecl.getPointer());
}
/// Returns whether this template declaration defines the primary
@@ -1982,7
Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability
dcoughlin added a comment. I think Aleksei is right and I was wrong. If you follow his advice and move the call to getStackOrCaptureRegionForDeclContext() to getVarRegion() and then pass the StackFrameContext to what you currently name "getMemRegionStaticLocal" then both methods have the very nice property that they return memory space regions and all the VarRegion stuff is kept in the caller. In my opinion `getMemSpaceForGlobalVariable()` and `getMemSpaceForLocalVariable()` are good names for these two new methods. If you prefer 'getMemSpaceForStaticLocalOrLocalVariable()' I think that would be fine too. http://reviews.llvm.org/D16873 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16517: ClangTidy check to flag uninitialized builtin and pointer fields.
flx updated this revision to Diff 47159.
flx marked 12 inline comments as done.
flx added a comment.
Thanks for the review, Alex!
This is an intermediate updated patch that addresses your detailed comments.
I'll rename the whole check in the next couple of days and will re-upload again.
http://reviews.llvm.org/D16517
Files:
clang-tidy/misc/CMakeLists.txt
clang-tidy/misc/MiscTidyModule.cpp
clang-tidy/misc/UninitializedFieldCheck.cpp
clang-tidy/misc/UninitializedFieldCheck.h
docs/clang-tidy/checks/misc-uninitialized-field.rst
test/clang-tidy/misc-uninitialized-field-cxx98.cpp
test/clang-tidy/misc-uninitialized-field.cpp
Index: test/clang-tidy/misc-uninitialized-field.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-uninitialized-field.cpp
@@ -0,0 +1,87 @@
+// RUN: %check_clang_tidy %s misc-uninitialized-field %t
+
+struct PositiveFieldBeforeConstructor {
+ int F;
+ // CHECK-FIXES: int F{};
+ PositiveFieldBeforeConstructor() {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+ // CHECK-FIXES: PositiveFieldBeforeConstructor() {}
+};
+
+struct PositiveFieldAfterConstructor {
+ PositiveFieldAfterConstructor() {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F, G
+ // CHECK-FIXES: PositiveFieldAfterConstructor() {}
+ int F;
+ // CHECK-FIXES: int F{};
+ bool G /* with comment */;
+ // CHECK-FIXES: bool G{} /* with comment */;
+ PositiveFieldBeforeConstructor IgnoredField;
+};
+
+struct PositiveSeparateDefinition {
+ PositiveSeparateDefinition();
+ int F;
+ // CHECK-FIXES: int F{};
+};
+
+PositiveSeparateDefinition::PositiveSeparateDefinition() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+// CHECK-FIXES: PositiveSeparateDefinition::PositiveSeparateDefinition() {}
+
+struct PositiveMixedFieldOrder {
+ PositiveMixedFieldOrder() : J(0) {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: I, K
+ // CHECK-FIXES: PositiveMixedFieldOrder() : J(0) {}
+ int I;
+ // CHECK-FIXES: int I{};
+ int J;
+ int K;
+ // CHECK-FIXES: int K{};
+};
+
+template
+struct Template {
+ Template() {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+ int F;
+ // CHECK-FIXES: int F{};
+ T T1;
+ // CHECK-FIXES: T T1;
+};
+
+void instantiate() {
+ Template TInt;
+}
+
+struct NegativeFieldInitialized {
+ int F;
+
+ NegativeFieldInitialized() : F() {}
+};
+
+struct NegativeFieldInitializedInDefinition {
+ int F;
+
+ NegativeFieldInitializedInDefinition();
+};
+NegativeFieldInitializedInDefinition::NegativeFieldInitializedInDefinition() : F() {}
+
+
+struct NegativeInClassInitialized {
+ int F = 0;
+
+ NegativeInClassInitialized() {}
+};
+
+struct NegativeConstructorDelegated {
+ int F;
+
+ NegativeConstructorDelegated(int F) : F(F) {}
+ NegativeConstructorDelegated() : NegativeConstructorDelegated(0) {}
+};
+
+struct NegativeInitializedInBody {
+ NegativeInitializedInBody() { I = 0; }
+ int I;
+};
Index: test/clang-tidy/misc-uninitialized-field-cxx98.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-uninitialized-field-cxx98.cpp
@@ -0,0 +1,65 @@
+// RUN: %check_clang_tidy %s misc-uninitialized-field %t -- -- -std=c++98
+
+struct PositiveFieldBeforeConstructor {
+ int F;
+ PositiveFieldBeforeConstructor() /* some comment */ {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+ // CHECK-FIXES: PositiveFieldBeforeConstructor() : F() /* some comment */ {}
+};
+
+struct PositiveFieldAfterConstructor {
+ PositiveFieldAfterConstructor() {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F, G, H
+ // CHECK-FIXES: PositiveFieldAfterConstructor() : F(), G(), H() {}
+ int F;
+ bool G /* with comment */;
+ int *H;
+ PositiveFieldBeforeConstructor IgnoredField;
+};
+
+struct PositiveSeparateDefinition {
+ PositiveSeparateDefinition();
+ int F;
+};
+
+PositiveSeparateDefinition::PositiveSeparateDefinition() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+// CHECK-FIXES: PositiveSeparateDefinition::PositiveSeparateDefinition() : F() {}
+
+struct PositiveMixedFieldOrder {
+ PositiveMixedFieldOrder() : /* some comment */ J(0), L(0), M(0) {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: I, K, N
+ // CHECK-FIXES: PositiveMixedFieldOrder() : I(), /* some comment */ J(0), K(), L(0), M(0), N() {}
+ int I;
+ int J;
+ int K;
+ int L;
+ int M;
+ int N;
+};
+
+struct PositiveAfterBaseInitializer : public Positiv
[libcxx] r260071 - build: silence warnings in in-tree build
Author: compnerd
Date: Sun Feb 7 21:50:18 2016
New Revision: 260071
URL: http://llvm.org/viewvc/llvm-project?rev=260071&view=rev
Log:
build: silence warnings in in-tree build
Avoid the developer warnings from cmake when configuring libc++ as part of the
LLVM layout. Setup the custom macro paths earlier to re-use the detection logic
prior to setting the project properties.
Modified:
libcxx/trunk/CMakeLists.txt
Modified: libcxx/trunk/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=260071&r1=260070&r2=260071&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Sun Feb 7 21:50:18 2016
@@ -12,13 +12,6 @@ if(POLICY CMP0022)
cmake_policy(SET CMP0022 NEW) # Required when interacting with LLVM and Clang
endif()
-project(libcxx CXX C)
-
-set(PACKAGE_NAME libcxx)
-set(PACKAGE_VERSION trunk-svn)
-set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
-set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
-
# Add path for custom modules
set(CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
@@ -26,15 +19,18 @@ set(CMAKE_MODULE_PATH
${CMAKE_MODULE_PATH}
)
-# Require out of source build.
-include(MacroEnsureOutOfSourceBuild)
-MACRO_ENSURE_OUT_OF_SOURCE_BUILD(
- "${PROJECT_NAME} requires an out of source build. Please create a separate
- build directory and run 'cmake /path/to/${PROJECT_NAME} [options]' there."
- )
-
# Find the LLVM sources and simulate LLVM CMake options.
include(HandleOutOfTreeLLVM)
+
+if (LIBCXX_BUILT_STANDALONE)
+ project(libcxx CXX C)
+
+ set(PACKAGE_NAME libcxx)
+ set(PACKAGE_VERSION trunk-svn)
+ set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
+ set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
+endif ()
+
if (LIBCXX_BUILT_STANDALONE AND NOT LLVM_FOUND)
message(WARNING "UNSUPPORTED LIBCXX CONFIGURATION DETECTED: "
"llvm-config not found and LLVM_PATH not defined.\n"
@@ -42,6 +38,13 @@ if (LIBCXX_BUILT_STANDALONE AND NOT LLVM
"or -DLLVM_PATH=path/to/llvm-source-root.")
endif()
+# Require out of source build.
+include(MacroEnsureOutOfSourceBuild)
+MACRO_ENSURE_OUT_OF_SOURCE_BUILD(
+ "${PROJECT_NAME} requires an out of source build. Please create a separate
+ build directory and run 'cmake /path/to/${PROJECT_NAME} [options]' there."
+ )
+
#===
# Setup CMake Options
#===
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers
LegalizeAdulthood added a comment. It's been almost a week. Is there some reason this hasn't been committed yet? http://reviews.llvm.org/D16308 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability
ariccio added a comment.
Bump?
Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:792
@@ -783,12 +791,3 @@
-// Treat other globals as GlobalInternal unless they are constants.
-} else {
- QualType GQT = D->getType();
- const Type *GT = GQT.getTypePtrOrNull();
- // TODO: We could walk the complex types here and see if everything is
- // constified.
- if (GT && GQT.isConstQualified() && GT->isArithmeticType())
-sReg = getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
- else
-sReg = getGlobalsRegion();
-}
+const MemRegion* MemRegionManager::getMemRegionStaticLocal(const VarDecl *D,
const LocationContext *LC) {
+ // FIXME: Once we implement scope handling, we will need to properly lookup
ariccio wrote:
> dcoughlin wrote:
> > It looks to me like this function operates on both locals *and* static
> > locals. I would change the name to reflect that.
> So, `getMemRegionStaticLocalOrLocal`?
Bump?
http://reviews.llvm.org/D16873
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16529: [clang-tidy] Add modernize-raw-string-literal check
LegalizeAdulthood updated this revision to Diff 47157.
LegalizeAdulthood marked 2 inline comments as done.
LegalizeAdulthood added a comment.
Update from review comments.
Added a bunch of test cases for non-printing characters, templates and macros.
Removed string literals containing newline (`\n`) from being considered for
transformation to raw string literals.
http://reviews.llvm.org/D16529
Files:
clang-tidy/modernize/CMakeLists.txt
clang-tidy/modernize/ModernizeTidyModule.cpp
clang-tidy/modernize/RawStringLiteralCheck.cpp
clang-tidy/modernize/RawStringLiteralCheck.h
docs/clang-tidy/checks/list.rst
docs/clang-tidy/checks/modernize-raw-string-literal.rst
test/clang-tidy/modernize-raw-string-literal.cpp
Index: test/clang-tidy/modernize-raw-string-literal.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-raw-string-literal.cpp
@@ -0,0 +1,122 @@
+// RUN: %check_clang_tidy %s modernize-raw-string-literal %t
+
+char const *const BackSlash{"goink\\frob"};
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: escaped string literal can be written as a raw string literal [modernize-raw-string-literal]
+// CHECK-FIXES: {{^}}char const *const BackSlash{R"(goink\frob)"};{{$}}
+
+char const *const PlainLiteral("plain literal");
+
+// Non-printable ASCII characters.
+char const *const Nul{"goink\\\000"};
+char const *const Soh{"goink\\\001"};
+char const *const Stx{"goink\\\002"};
+char const *const Etx{"goink\\\003"};
+char const *const Enq{"goink\\\004"};
+char const *const Ack{"goink\\\005"};
+char const *const Bell{"goink\\\afrob"};
+char const *const BackSpace{"goink\\\bfrob"};
+char const *const HorizontalTab{"goink\\\tfrob"};
+char const *const NewLine{"goink\nfrob"};
+char const *const VerticalTab{"goink\\\vfrob"};
+char const *const FormFeed{"goink\\\ffrob"};
+char const *const CarraigeReturn{"goink\\\rfrob"};
+char const *const So{"goink\\\016"};
+char const *const Si{"goink\\\017"};
+char const *const Dle{"goink\\\020"};
+char const *const Dc1{"goink\\\021"};
+char const *const Dc2{"goink\\\022"};
+char const *const Dc3{"goink\\\023"};
+char const *const Dc4{"goink\\\024"};
+char const *const Nak{"goink\\\025"};
+char const *const Syn{"goink\\\026"};
+char const *const Etb{"goink\\\027"};
+char const *const Can{"goink\\\030"};
+char const *const Em{"goink\\\031"};
+char const *const Sub{"goink\\\032"};
+char const *const Esc{"goink\\\033"};
+char const *const Fs{"goink\\\034"};
+char const *const Gs{"goink\\\035"};
+char const *const Rs{"goink\\\036"};
+char const *const Us{"goink\\\037"};
+char const *const HexNonPrintable{"\\\x03"};
+char const *const Delete{"\\\177"};
+
+char const *const TrailingSpace{"A line \\with space. \n"};
+char const *const TrailingNewLine{"A single \\line.\n"};
+char const *const AlreadyRaw{R"(foobie\\bletch)"};
+char const *const UTF8Literal{u8"foobie\\bletch"};
+char const *const UTF8RawLiteral{u8R"(foobie\\bletch)"};
+char16_t const *const UTF16Literal{u"foobie\\bletch"};
+char16_t const *const UTF16RawLiteral{uR"(foobie\\bletch)"};
+char32_t const *const UTF32Literal{U"foobie\\bletch"};
+char32_t const *const UTF32RawLiteral{UR"(foobie\\bletch)"};
+wchar_t const *const WideLiteral{L"foobie\\bletch"};
+wchar_t const *const WideRawLiteral{LR"(foobie\\bletch)"};
+
+char const *const SingleQuote{"goink\'frob"};
+// CHECK-MESSAGES: :[[@LINE-1]]:31: warning: {{.*}} can be written as a raw string literal
+// CHECK-XFIXES: {{^}}char const *const SingleQuote{R"(goink'frob)"};{{$}}
+
+char const *const DoubleQuote{"goink\"frob"};
+// CHECK-MESSAGES: :[[@LINE-1]]:31: warning: {{.*}} can be written as a raw string literal
+// CHECK-FIXES: {{^}}char const *const DoubleQuote{R"(goink"frob)"};{{$}}
+
+char const *const QuestionMark{"goink\?frob"};
+// CHECK-MESSAGES: :[[@LINE-1]]:32: warning: {{.*}} can be written as a raw string literal
+// CHECK-FIXES: {{^}}char const *const QuestionMark{R"(goink?frob)"};{{$}}
+
+char const *const RegEx{"goink\\(one|two\\)\\?.*\\nfrob"};
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: {{.*}} can be written as a raw string literal
+// CHECK-FIXES: {{^}}char const *const RegEx{R"(goink\(one|two\)\\\?.*\nfrob)"};{{$}}
+
+char const *const Path{"C:\\Program Files\\Vendor\\Application\\Application.exe"};
+// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: {{.*}} can be written as a raw string literal
+// CHECK-FIXES: {{^}}char const *const Path{R"(C:\Program Files\Vendor\Application\Application.exe)"};{{$}}
+
+char const *const ContainsSentinel{"who\\ops)\""};
+// CHECK-MESSAGES: :[[@LINE-1]]:36: warning: {{.*}} can be written as a raw string literal
+// CHECK-FIXES: {{^}}char const *const ContainsSentinel{R"lit(who\ops)")lit"};{{$}}
+
+char const *const ContainsDelim{"whoops)\")lit\""};
+// CHECK-MESSAGES: :[[@LINE-1]]:33: warning: {{.*}} can be written as a raw string literal
+// CHECK-FIXES: {{^}}char const *const ContainsDelim{R"lit1(whoops)")lit")lit1"};{{$}}
+
+char const *const
Re: [PATCH] D16529: [clang-tidy] Add modernize-raw-string-literal check
LegalizeAdulthood marked 5 inline comments as done.
Comment at: clang-tidy/modernize/RawStringLiteralCheck.cpp:96
@@ +95,3 @@
+ std::string Delimiter;
+ for (int Counter = 0; containsDelimiter(Bytes, Delimiter); ++Counter) {
+Delimiter = (Counter == 0) ? "lit" : "lit" + std::to_string(Counter);
alexfh wrote:
> LegalizeAdulthood wrote:
> > alexfh wrote:
> > > Please address my comment above that relates to this code. Specifically,
> > > I find this generic algorithm unnecessarily inefficient and too rigid,
> > > i.e. one can't configure a custom set of delimiters that don't follow the
> > > pattern. I suggest using a list of pre-concatenated
> > > pairs of strings (like `R"lit(` and `)lit"`).
> > Raw strings are new and not many people are using them because the don't
> > have a good way to automatically convert disgusting quoted strings to raw
> > strings. So I don't think it is reasonable to draw conclusions by looking
> > in existing code bases for raw strings.
> >
> > We're having the same conversation we've had before. I'm trying to do a
> > basic check and get things working properly and the review comments are
> > tending towards a desire for some kind of perfection.
> >
> > I don't see why we have to make the perfect the enemy of the good. Nothing
> > you are suggesting **must** be present now in order for this check to
> > function properly and reasonably.
> We're looking at this from different perspectives. From my point of view,
> preventing a potentially wasteful code in ClangTidy checks before it's even
> committed is much easier than tracking down performance issues when tens of
> checks run on multiple machines analyzing millions lines of code. So I'm
> asking to avoid writing code using string allocations and concatenations when
> there are good alternatives. Apart from possible performance issues, in this
> case the generic solution you suggest is targets extremely rare cases, while
> most real-world situations can be handled with a fixed set of delimiters
> (possibly, configured by the user, while I expect the preferences for the
> choice of delimiters to be very different in different teams).
I believe we agree on the following:
- In order to turn a non-raw string literal into a raw string literal I have
to surround it with `R"(` and `)"`.
- If the existing string literal contains `)"` already, then surrounding the
literal with the above will result in a syntax error. Therefore, every
potential raw string literal will have to be searched at least once for this
non-delimited form of raw string literal.
- `clang-tidy` checks should never introduce syntax errors.
Therefore, I can either not transform the string literal if it contains `)"`,
or I can come up with some delimited form of raw string literal where the
delimiter does not appear in the string. In order to not transform the
literal, I first have to search for `)"` in order to know that it should not be
transformed. Therefore, the search for `)"` must be performed, no matter what
algorithm is used to determine a delimited or non-delimited raw string literal.
Where we seem to disagree is what algorithm should be used to determine the
delimiter when a delimited raw string literal is required.
My implementation is the minimum performance impact for the typical case where
the string does not contain `)"`.
Now let's talk about the cases where searching the string repeatedly for a
delimiter would be expensive.
First, the string literal will have to contain `)"`.
Second, the string literal would have to be lengthy for the delimiter searching
to be expensive. Most of the time lengthy string literals are when someone has
transformed a text file into a giant string literal. Such text files include
newlines and in the latest version of the code, I've decided to skip any string
literal containing a newline. It simply results in too many strings being
converted to raw string literals and obfuscates the newlines. The one case
where the embedded newlines makes sense is the case of the text file converted
into a string literal.
Repeated searching of the string for the literal delimiter could be avoided by
changing the routine to search for the delimiter. If present, it could examine
the characters following the literal to make the literal more unique and then
continue searching from there to look for more occurrences of the extended
delimiter. It would proceed incrementally through the rest of the string to
create a unique delimiter in a single pass through the string. I think the
resulting literals would be even more non-sensical than the current
implementation, but it would result in a delimiter obtained by a single pass
through the string. It's a significantly more complicated implementation and
results in an even weirder delimiter to handle a very edge case.
If I follow your suggested approach of using a fixed number of string
r260066 - [analyzer] Avoid crash when attempting to evaluate binary operation on LazyCompoundVal.
Author: dcoughlin
Date: Sun Feb 7 18:28:24 2016
New Revision: 260066
URL: http://llvm.org/viewvc/llvm-project?rev=260066&view=rev
Log:
[analyzer] Avoid crash when attempting to evaluate binary operation on
LazyCompoundVal.
Instead, return UnknownValue if either operand is a nonloc::LazyCompoundVal.
This is a
spot fix for PR 24951.
rdar://problem/23682244
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
cfe/trunk/test/Analysis/string.c
Modified: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp?rev=260066&r1=260065&r2=260066&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp Sun Feb 7 18:28:24 2016
@@ -367,6 +367,11 @@ SVal SValBuilder::evalBinOp(ProgramState
if (lhs.isUnknown() || rhs.isUnknown())
return UnknownVal();
+ if (lhs.getAs() ||
+ rhs.getAs()) {
+return UnknownVal();
+ }
+
if (Optional LV = lhs.getAs()) {
if (Optional RV = rhs.getAs())
return evalBinOpLL(state, op, *LV, *RV, type);
Modified: cfe/trunk/test/Analysis/string.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/string.c?rev=260066&r1=260065&r2=260066&view=diff
==
--- cfe/trunk/test/Analysis/string.c (original)
+++ cfe/trunk/test/Analysis/string.c Sun Feb 7 18:28:24 2016
@@ -756,6 +756,20 @@ void strcmp_unknown_arg (char *unknown)
clang_analyzer_eval(strcmp(unknown, unknown) == 0); //
expected-warning{{TRUE}}
}
+union argument {
+ char *f;
+};
+
+void function_pointer_cast_helper(char **a) {
+ strcmp("Hi", *a); // PR24951 crash
+}
+
+void strcmp_union_function_pointer_cast(union argument a) {
+ void (*fPtr)(union argument *) = (void (*)(union argument
*))function_pointer_cast_helper;
+
+ fPtr(&a);
+}
+
//===--===
// strncmp()
//===--===
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r260065 - [clang-tidy] Reformatted docs + minor updates
Author: alexfh
Date: Sun Feb 7 18:19:29 2016
New Revision: 260065
URL: http://llvm.org/viewvc/llvm-project?rev=260065&view=rev
Log:
[clang-tidy] Reformatted docs + minor updates
Modified:
clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
clang-tools-extra/trunk/docs/clang-tidy/index.rst
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=260065&r1=260064&r2=260065&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp Sun Feb 7
18:19:29 2016
@@ -27,132 +27,154 @@ using namespace llvm;
static cl::OptionCategory ClangTidyCategory("clang-tidy options");
static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);
-static cl::extrahelp ClangTidyHelp(
-"Configuration files:\n"
-" clang-tidy attempts to read configuration for each source file from a\n"
-" .clang-tidy file located in the closest parent directory of the
source\n"
-" file. If any configuration options have a corresponding command-line\n"
-" option, command-line option takes precedence. The effective\n"
-" configuration can be inspected using -dump-config:\n"
-"\n"
-"$ clang-tidy -dump-config - --\n"
-"---\n"
-"Checks: '-*,some-check'\n"
-"HeaderFilterRegex: ''\n"
-"AnalyzeTemporaryDtors: false\n"
-"User:user\n"
-"CheckOptions:\n"
-" - key: some-check.SomeOption\n"
-"value: 'some value'\n"
-"...\n"
-"\n\n");
+static cl::extrahelp ClangTidyHelp(R"(
+Configuration files:
+ clang-tidy attempts to read configuration for each source file from a
+ .clang-tidy file located in the closest parent directory of the source
+ file. If any configuration options have a corresponding command-line
+ option, command-line option takes precedence. The effective
+ configuration can be inspected using -dump-config:
+
+$ clang-tidy -dump-config - --
+---
+Checks: '-*,some-check'
+WarningsAsErrors: ''
+HeaderFilterRegex: ''
+AnalyzeTemporaryDtors: false
+User:user
+CheckOptions:
+ - key: some-check.SomeOption
+value: 'some value'
+...
+
+)");
const char DefaultChecks[] = // Enable these checks:
"clang-diagnostic-*," // * compiler diagnostics
"clang-analyzer-*," // * Static Analyzer checks
"-clang-analyzer-alpha*"; // * but not alpha checks: many false positives
-static cl::opt
-Checks("checks", cl::desc("Comma-separated list of globs with optional '-'\n"
- "prefix. Globs are processed in order of
appearance\n"
- "in the list. Globs without '-' prefix add checks\n"
- "with matching names to the set, globs with the
'-'\n"
- "prefix remove checks with matching names from the\n"
- "set of enabled checks.\n"
- "This option's value is appended to the value read\n"
- "from a .clang-tidy file, if any."),
- cl::init(""), cl::cat(ClangTidyCategory));
-
-static cl::opt
-WarningsAsErrors("warnings-as-errors",
- cl::desc("Upgrades warnings to errors. "
- "Same format as '-checks'."),
- cl::init(""), cl::cat(ClangTidyCategory));
-
-static cl::opt
-HeaderFilter("header-filter",
- cl::desc("Regular expression matching the names of the\n"
- "headers to output diagnostics from. Diagnostics\n"
- "from the main file of each translation unit are\n"
- "always displayed.\n"
- "Can be used together with -line-filter.\n"
- "This option overrides the value read from a\n"
- ".clang-tidy file."),
- cl::init(""), cl::cat(ClangTidyCategory));
+static cl::opt Checks("checks", cl::desc(R"(
+Comma-separated list of globs with optional '-'
+prefix. Globs are processed in order of
+appearance in the list. Globs without '-'
+prefix add checks with matching names to the
+set, globs with the '-' prefix remove checks
+with matching names from the set of enabled
+checks. This option's value is appended to the
+value of the 'Checks' option in .clang-tidy
+file, if any.
+)"),
+ cl::init(""), cl::cat(ClangTidyCategory));
+
+static cl::opt WarningsAsErrors("warnings-as-errors", cl::desc(R"(
+Upgrades warnings to errors. Same format as
+'-checks'.
+This option's value is appended to the value of
+the 'WarningsAsErrors' option in .clang-
r260062 - [MS ABI] Don't emit RTTI descriptors for dllimport vtables
Author: majnemer
Date: Sun Feb 7 16:42:05 2016
New Revision: 260062
URL: http://llvm.org/viewvc/llvm-project?rev=260062&view=rev
Log:
[MS ABI] Don't emit RTTI descriptors for dllimport vtables
A dllimport'd vtable always points one past the RTTI data, this means
that the initializer will never end up referencing the data. Our
emission is a harmless waste.
Modified:
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp
Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=260062&r1=260061&r2=260062&view=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Sun Feb 7 16:42:05 2016
@@ -1567,7 +1567,9 @@ void MicrosoftCXXABI::emitVTableDefiniti
if (VTable->hasInitializer())
continue;
-llvm::Constant *RTTI = getContext().getLangOpts().RTTIData
+llvm::Constant *RTTI = getContext().getLangOpts().RTTIData &&
+ VTable->getDLLStorageClass() !=
+ llvm::GlobalValue::DLLImportStorageClass
? getMSCompleteObjectLocator(RD, Info)
: nullptr;
Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp?rev=260062&r1=260061&r2=260062&view=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp Sun Feb 7 16:42:05
2016
@@ -4,6 +4,8 @@
// RTTI-DAG: $"\01??_7S@@6B@" = comdat largest
// RTTI-DAG: $"\01??_7V@@6B@" = comdat largest
+// RTTI-NOT: @"\01??_R4U@@6B@"
+
struct S {
virtual ~S();
} s;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260060 - clang-format: [JS] Don't count shortened object literals as blocks.
Author: djasper
Date: Sun Feb 7 16:17:13 2016
New Revision: 260060
URL: http://llvm.org/viewvc/llvm-project?rev=260060&view=rev
Log:
clang-format: [JS] Don't count shortened object literals as blocks.
Before:
f({a},
() => {
g(); //
});
After:
f({a}, () => {
g(); //
});
Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTestJS.cpp
Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=260060&r1=260059&r2=260060&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Sun Feb 7 16:17:13 2016
@@ -423,7 +423,7 @@ private:
}
void updateParameterCount(FormatToken *Left, FormatToken *Current) {
-if (Current->is(tok::l_brace) && !Current->is(TT_DictLiteral))
+if (Current->is(tok::l_brace) && Current->BlockKind == BK_Block)
++Left->BlockParameterCount;
if (Current->is(tok::comma)) {
++Left->ParameterCount;
Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=260060&r1=260059&r2=260060&view=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Sun Feb 7 16:17:13 2016
@@ -200,6 +200,11 @@ TEST_F(FormatTestJS, ContainerLiterals)
" b: 2,\n"
" [c]: 3,\n"
"};");
+
+ // Object literals can leave out labels.
+ verifyFormat("f({a}, () => {\n"
+ " g(); //\n"
+ "});");
}
TEST_F(FormatTestJS, MethodsInObjectLiterals) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16951: [MS ABI] dllimport'd class cannot have constexpr ctors
thakis added a comment.
Cool, lgtm. Maybe we'll have to downgrade this to a warning eventually since cl
allows it, but for now let's see how this goes.
Comment at: test/SemaCXX/dllimport.cpp:1269
@@ +1268,3 @@
+ virtual ~PR26506_test2() {}
+ constexpr PR26506_test2() {} // expected-error{{constructor cannot be marked
constexpr}}
+};
majnemer wrote:
> thakis wrote:
> > nit: I feel diagnostics are easier to understand if their text is
> > stand-alone and not spread across diag and its note. That is "dllimported
> > constructors cannot be marked constexpr" "note: dllimported here" or
> > something like this (this also helps with the mythical localization of
> > diagnostics).
> I chose this style because it is most consistent with our diagnostic for a
> `constexpr` constructor for a class with virtual bases.
Hm, I suppose I feel we should change those too then :-) (but that's a
discussion for somewhere else then)
http://reviews.llvm.org/D16951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16951: [MS ABI] dllimport'd class cannot have constexpr ctors
majnemer added inline comments.
Comment at: test/SemaCXX/dllimport.cpp:1262
@@ -1261,1 +1261,3 @@
+struct __declspec(dllimport) PR26506_test1 {
+ virtual ~PR26506_test1() {}
thakis wrote:
> cl.exe seems to accept this – do you know how they do that? Do they just
> silently ignore the constexpr?
They silently ignore the constexpr:
struct __declspec(dllimport) PR26506_test1 {
virtual ~PR26506_test1() {}
constexpr PR26506_test1() = default;
};
constexpr PR26506_test1 x;
They report:
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
t.cpp
t.cpp(5): error C2127: 'x': illegal initialization of 'constexpr' entity with
a non-constant expression
Comment at: test/SemaCXX/dllimport.cpp:1269
@@ +1268,3 @@
+ virtual ~PR26506_test2() {}
+ constexpr PR26506_test2() {} // expected-error{{constructor cannot be marked
constexpr}}
+};
thakis wrote:
> nit: I feel diagnostics are easier to understand if their text is stand-alone
> and not spread across diag and its note. That is "dllimported constructors
> cannot be marked constexpr" "note: dllimported here" or something like this
> (this also helps with the mythical localization of diagnostics).
I chose this style because it is most consistent with our diagnostic for a
`constexpr` constructor for a class with virtual bases.
http://reviews.llvm.org/D16951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260058 - Make nozlibcompress.c pass and reenable it.
Author: nico Date: Sun Feb 7 15:32:17 2016 New Revision: 260058 URL: http://llvm.org/viewvc/llvm-project?rev=260058&view=rev Log: Make nozlibcompress.c pass and reenable it. Modified: cfe/trunk/test/Driver/nozlibcompress.c Modified: cfe/trunk/test/Driver/nozlibcompress.c URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/nozlibcompress.c?rev=260058&r1=260057&r2=260058&view=diff == --- cfe/trunk/test/Driver/nozlibcompress.c (original) +++ cfe/trunk/test/Driver/nozlibcompress.c Sun Feb 7 15:32:17 2016 @@ -1,10 +1,6 @@ // RUN: %clang -c %s -Wa,--compress-debug-sections 2>&1 | FileCheck %s -// RUN: %clang -c %s -Wa,--compress-debug-sections -Wa,--nocompress-debug-sections 2>&1 | FileCheck --check-prefix=NOWARN %s +// RUN: %clang -c %s -Wa,--compress-debug-sections -Wa,--nocompress-debug-sections 2>&1 | FileCheck --allow-empty --check-prefix=NOWARN %s // REQUIRES: nozlib -// FIXME: This test hasn't run until r259976 made REQUIRES: zlib work -- and -// the test has been failing since. Figure out what's up and enable this. -// XFAIL: * - // CHECK: warning: cannot compress debug sections (zlib not installed) // NOWARN-NOT: warning: cannot compress debug sections (zlib not installed) ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260057 - clang-format: [JS] Support @see annotations in JSDoc comments in Google
Author: djasper
Date: Sun Feb 7 15:22:16 2016
New Revision: 260057
URL: http://llvm.org/viewvc/llvm-project?rev=260057&view=rev
Log:
clang-format: [JS] Support @see annotations in JSDoc comments in Google
style.
Modified:
cfe/trunk/lib/Format/Format.cpp
Modified: cfe/trunk/lib/Format/Format.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=260057&r1=260056&r2=260057&view=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Sun Feb 7 15:22:16 2016
@@ -587,7 +587,7 @@ FormatStyle getGoogleStyle(FormatStyle::
GoogleStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Inline;
GoogleStyle.AlwaysBreakBeforeMultilineStrings = false;
GoogleStyle.BreakBeforeTernaryOperators = false;
-GoogleStyle.CommentPragmas = "@(export|visibility) {";
+GoogleStyle.CommentPragmas = "@(export|see|visibility) ";
GoogleStyle.MaxEmptyLinesToKeep = 3;
GoogleStyle.SpacesInContainerLiterals = false;
} else if (Language == FormatStyle::LK_Proto) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260056 - Disable failing nozlibcompress.c
Author: nico Date: Sun Feb 7 15:00:17 2016 New Revision: 260056 URL: http://llvm.org/viewvc/llvm-project?rev=260056&view=rev Log: Disable failing nozlibcompress.c This test hasn't been running after it was added until r259976 made "REQUIRES: nozlib" work, and now that the test runs it fails. Modified: cfe/trunk/test/Driver/nozlibcompress.c Modified: cfe/trunk/test/Driver/nozlibcompress.c URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/nozlibcompress.c?rev=260056&r1=260055&r2=260056&view=diff == --- cfe/trunk/test/Driver/nozlibcompress.c (original) +++ cfe/trunk/test/Driver/nozlibcompress.c Sun Feb 7 15:00:17 2016 @@ -2,5 +2,9 @@ // RUN: %clang -c %s -Wa,--compress-debug-sections -Wa,--nocompress-debug-sections 2>&1 | FileCheck --check-prefix=NOWARN %s // REQUIRES: nozlib +// FIXME: This test hasn't run until r259976 made REQUIRES: zlib work -- and +// the test has been failing since. Figure out what's up and enable this. +// XFAIL: * + // CHECK: warning: cannot compress debug sections (zlib not installed) // NOWARN-NOT: warning: cannot compress debug sections (zlib not installed) ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> I tested GCC 5.3.1 and Clang 3.5.0.
>>>
>>> GCC Clang
>>> s0 non-emptynon-empty
>>> s1 non-emptyempty
>>> s2 non-emptyempty
>>> s3 emptyempty
>>> s4 emptyempty
>>> s5 non-emptyempty
>>>
>>> I believe s3, s4, s5 are non-empty according to your rules. Why put
>>> both compilers in the wrong? That doesn't make sense to me.
>>
>> Please try testcases in
>>
>> https://llvm.org/bugs/show_bug.cgi?id=26337
>>
>> with clang on both ia32 and x86-64. Clang isn't consistent between
>> ia32 and x86-64.
>
> Okay, with -m32, I get non-empty passing for s5 from Clang as well.
> But I still don't think it makes sense to change the ABI for s3 and
> s4, and even for s5, the Clang/x86_64 behavior is arguably more
> correct.
Not really. For
struct dummy0 { };
struct dummy { struct dummy0 d[PAD_SIZE]; };
clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
on ia32.
>>> Jason already indicated he intends GCC to move towards more empty
>>> arguments, not fewer.
>>>
> How do existing C++ compilers implement empty array members (an
> extension)? Does the type of such members affect whether a class is a
> standard-layout class?
>>>
Are they "POD for the purpose of layout"? If yes, they are covered here.
>>>
>>> The C++ standard does not define this.
>>
>> GCC has
>>
>> * Nonzero means that this class type is not POD for the purpose of layout
>>(as defined in the ABI). This is different from the language's POD. */
>> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>>
>> We can use this definition for ia32, x86-64 and IA MCU psABIs.
>
> It still has to be spelled out in non-GCC terms, IMHO.
Sure. Do you care to propose a wording for "POD for the purpose of layout"?
--
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16786: [Clang-tidy] Make modernize-redundant-void-arg working with included files
Eugene.Zelenko abandoned this revision. Eugene.Zelenko added a comment. Obsoleted by http://reviews.llvm.org/D16953. Repository: rL LLVM http://reviews.llvm.org/D16786 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
* H. J. Lu: >> I tested GCC 5.3.1 and Clang 3.5.0. >> >> GCC Clang >> s0 non-emptynon-empty >> s1 non-emptyempty >> s2 non-emptyempty >> s3 emptyempty >> s4 emptyempty >> s5 non-emptyempty >> >> I believe s3, s4, s5 are non-empty according to your rules. Why put >> both compilers in the wrong? That doesn't make sense to me. > > Please try testcases in > > https://llvm.org/bugs/show_bug.cgi?id=26337 > > with clang on both ia32 and x86-64. Clang isn't consistent between > ia32 and x86-64. Okay, with -m32, I get non-empty passing for s5 from Clang as well. But I still don't think it makes sense to change the ABI for s3 and s4, and even for s5, the Clang/x86_64 behavior is arguably more correct. >> Jason already indicated he intends GCC to move towards more empty >> arguments, not fewer. >> How do existing C++ compilers implement empty array members (an extension)? Does the type of such members affect whether a class is a standard-layout class? >> >>> Are they "POD for the purpose of layout"? If yes, they are covered here. >> >> The C++ standard does not define this. > > GCC has > > * Nonzero means that this class type is not POD for the purpose of layout >(as defined in the ABI). This is different from the language's POD. */ > #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \ > > We can use this definition for ia32, x86-64 and IA MCU psABIs. It still has to be spelled out in non-GCC terms, IMHO. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 12:08 PM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> Any syntactical array argument (at the C level) is should be passed as
>>> a pointer. The language appears to change that.
>>
>> I didn't use aggregate so that array is excluded here.
>>
>>> For 2., static members and non-data members do not count.
>>
>> They do count here. That is why I used "POD for the purpose of
>> layout.
>
> Let's see what happens today.
>
> struct s0 {
> s0();
> };
>
> struct s1 {
> static int a;
> };
>
> struct s2 {
> void member();
> };
>
> struct s3 {
> int a[0];
> };
>
> struct s4 {
> s0 a[0];
> };
>
> struct s5 {
> s1 a[1];
> };
>
>
> I tested GCC 5.3.1 and Clang 3.5.0.
>
> GCC Clang
> s0 non-emptynon-empty
> s1 non-emptyempty
> s2 non-emptyempty
> s3 emptyempty
> s4 emptyempty
> s5 non-emptyempty
>
> I believe s3, s4, s5 are non-empty according to your rules. Why put
> both compilers in the wrong? That doesn't make sense to me.
Please try testcases in
https://llvm.org/bugs/show_bug.cgi?id=26337
with clang on both ia32 and x86-64. Clang isn't consistent between
ia32 and x86-64.
> Jason already indicated he intends GCC to move towards more empty
> arguments, not fewer.
>
>>> How do existing C++ compilers implement empty array members (an
>>> extension)? Does the type of such members affect whether a class is a
>>> standard-layout class?
>
>> Are they "POD for the purpose of layout"? If yes, they are covered here.
>
> The C++ standard does not define this.
GCC has
* Nonzero means that this class type is not POD for the purpose of layout
(as defined in the ABI). This is different from the language's POD. */
#define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
We can use this definition for ia32, x86-64 and IA MCU psABIs.
--
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r258524 - Merge templated static member variables, fixes http://llvm.org/pr26179.
Improve a comment.
--Vassil
On 07/02/16 20:48, Vassil Vassilev wrote:
Would this patch be any better?
--Vassil
On 05/02/16 21:49, Richard Smith wrote:
This belongs in ASTDeclReader::attachPreviousDecl[Impl]. That's where
we propagate data that's supposed to be consistent across a
redeclaration chain from earlier declarations to later ones.
There's another wrinkle here: we should only be propagating the type
from a previous declaration that's declared in the same scope (in
particular, we should skip over declarations declared as local extern
declarations within a function). This may in some cases require
walking backwards along the redeclaration chain to find the previous
declaration that was not a local extern declaration. That'd be
observable in a case like this:
modulemap:
module A { module A1 { header "a1.h" } module A2 { header "a2.h" } }
module B { header "b.h" }
a1.h:
int a[];
b.h:
void g(int(*)[], int);
void g(int(*)[1], int) = delete;
template void f(T t) {
extern int a[];
g(&a, t);
}
a2.h:
int a[1];
x.cc:
#include "a1.h"
#include "b.h"
void h() { f(0); } // should not produce an error; type of 'a' within
'f' should not have been updated
That example actually reveals another problem: we really don't want
the completed type to be visible unless there is a visible
declaration with the completed type. That suggests that propagating
the type across the redeclaration chain may be the wrong approach,
and we should instead handle this by changing isPreferredLookupResult
(in SemaLookup.cpp) to prefer a VarDecl with a complete type over one
with an incomplete type.
On Fri, Feb 5, 2016 at 12:27 PM, Vassil Vassilev
wrote:
I am not sure where else to put this logic if not in
isSameEntity... Could you point me to a better place?
--Vassil
On 05/02/16 19:56, Richard Smith wrote:
On Fri, Feb 5, 2016 at 7:04 AM, Vassil Vassilev
mailto:v.g.vassi...@gmail.com>> wrote:
Good point. Do you have in mind calling
'clang::Sema::MergeVarDeclTypes' or we to just "duplicate"
the logic in clang::ASTDeclReader::mergeRedeclarable?
It's not safe to call into Sema while we're in a
partially-deserialized state. We know the only interesting case
here is complete versus incomplete array types, so we don't need
anything like the complexity of MergeVarDeclTypes -- something
as easy as "if (new type is incomplete and old type is not) set
new type to old type" should work.
On 05/02/16 02:50, Richard Smith via cfe-commits wrote:
I suspect we'll need to do a little more than this: when we
rebuild the redeclaration chain, we should probably
propagate the complete type to later redeclarations in the
same scope. Otherwise, if we import a module that has a
complete type and one that has an incomplete type, the
declaration found by name lookup might be the one with the
incomplete type, possibly resulting in rejects-valid on
code like this:
a.h:
extern int a[5];
b.h:
extern int a[];
x.cc:
#include "a.h"
#include "b.h"
int k = sizeof(a);
On Fri, Jan 22, 2016 at 11:03 AM, Yaron Keren via
cfe-commits wrote:
Author: yrnkrn
Date: Fri Jan 22 13:03:27 2016
New Revision: 258524
URL:
http://llvm.org/viewvc/llvm-project?rev=258524&view=rev
Log:
Merge templated static member variables, fixes
http://llvm.org/pr26179.
Patch by Vassil Vassilev!
Reviewed by Richard Smith.
Added:
cfe/trunk/test/Modules/Inputs/PR26179/
cfe/trunk/test/Modules/Inputs/PR26179/A.h
cfe/trunk/test/Modules/Inputs/PR26179/B.h
cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h
cfe/trunk/test/Modules/Inputs/PR26179/module.modulemap
cfe/trunk/test/Modules/pr26179.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=258524&r1=258523&r2=258524&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
(original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Fri
Jan 22 13:03:27 2016
@@ -2595,8 +2595,24 @@ static bool
isSameEntity(NamedDecl *X, N
// Variables with the same type and linkage match.
if (VarDecl *VarX = dyn_cast(X)) {
VarDecl *VarY = cast(Y);
-return (VarX->getLinkageInternal() ==
VarY->getLinkageInternal()) &&
- VarX->getASTContext().hasSameTy
Re: r249542 - clang-format: Hopefully fix code blocks in docs.
http://lab.llvm.org:8011/builders/clang-sphinx-docs is still broken: http://lab.llvm.org:8011/builders/clang-sphinx-docs FAILED: cd /home/llvmbb/llvm-build-dir/clang-sphinx-docs/llvm/build/tools/clang/docs && /usr/bin/sphinx-build -b html -d /home/llvmbb/llvm-build-dir/clang-sphinx-docs/llvm/build/tools/clang/docs/_doctrees -q -W /home/llvmbb/llvm-build-dir/clang-sphinx-docs/llvm/src/tools/clang/docs /home/llvmbb/llvm-build-dir/clang-sphinx-docs/llvm/build/tools/clang/docs/html Warning, treated as error: /home/llvmbb/llvm-build-dir/clang-sphinx-docs/llvm/src/tools/clang/docs/ClangFormatStyleOptions.rst:449: WARNING: Could not parse literal_block as "c++". highlighting skipped. Since nobody seems to care about that bot (it's been red for close to two months), maybe we should remove it? On Wed, Oct 7, 2015 at 9:02 AM, Daniel Jasper via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: djasper > Date: Wed Oct 7 08:02:45 2015 > New Revision: 249542 > > URL: http://llvm.org/viewvc/llvm-project?rev=249542&view=rev > Log: > clang-format: Hopefully fix code blocks in docs. > > Otherwise I will have to install sphinx ;).. > > Modified: > cfe/trunk/docs/ClangFormatStyleOptions.rst > cfe/trunk/docs/tools/dump_format_style.py > > Modified: cfe/trunk/docs/ClangFormatStyleOptions.rst > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormatStyleOptions.rst?rev=249542&r1=249541&r2=249542&view=diff > > == > --- cfe/trunk/docs/ClangFormatStyleOptions.rst (original) > +++ cfe/trunk/docs/ClangFormatStyleOptions.rst Wed Oct 7 08:02:45 2015 > @@ -157,6 +157,7 @@ the configuration (without a prefix: ``A >brackets. This will result in formattings like > >.. code-block:: c++ > + > someLongFunction(argument1, > argument2); > > @@ -167,6 +168,7 @@ the configuration (without a prefix: ``A >will result in formattings like > >.. code-block:: c++ > + > int = 12; > int b= 23; > int ccc = 23; > @@ -178,6 +180,7 @@ the configuration (without a prefix: ``A >will result in formattings like > >.. code-block:: c++ > + > int = 12; > float b = 23; > std::string ccc = 23; > @@ -394,12 +397,14 @@ the configuration (without a prefix: ``A >These are expected to be macros of the form: > >.. code-block:: c++ > + > FOREACH(, ...) > > >In the .clang-format configuration file, this can be configured like: > >.. code-block:: c++ > + > ForEachMacros: ['RANGES_FOR', 'FOREACH'] > >For example: BOOST_FOREACH. > @@ -422,6 +427,7 @@ the configuration (without a prefix: ``A >To configure this in the .clang-format file, use: > >.. code-block:: c++ > + > IncludeCategories: >- Regex: '^"(llvm|llvm-c|clang|clang-c)/' > Priority:2 > > Modified: cfe/trunk/docs/tools/dump_format_style.py > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/tools/dump_format_style.py?rev=249542&r1=249541&r2=249542&view=diff > > == > --- cfe/trunk/docs/tools/dump_format_style.py (original) > +++ cfe/trunk/docs/tools/dump_format_style.py Wed Oct 7 08:02:45 2015 > @@ -87,7 +87,7 @@ class EnumValue: > > def clean_comment_line(line): >if line == '/// \\code': > -return '\n.. code-block:: c++\n' > +return '\n.. code-block:: c++\n\n' >if line == '/// \\endcode': > return '' >return line[4:] + '\n' > > > ___ > 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] D16947: [PGO] assignment operator does not get profile data
davidxl updated this revision to Diff 47150.
davidxl added a comment.
Updated test case.
Another test case in profile-rt (pending) is : http://reviews.llvm.org/D16974
http://reviews.llvm.org/D16947
Files:
lib/CodeGen/CGClass.cpp
test/Profile/def-assignop.cpp
Index: test/Profile/def-assignop.cpp
===
--- test/Profile/def-assignop.cpp
+++ test/Profile/def-assignop.cpp
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang |
FileCheck --check-prefix=PGOGEN %s
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang
-fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
+
+struct Base {
+ int B;
+ Base(int BB) : B(BB) {}
+ void operator=(const struct Base &b) { B = b.B + 10; }
+};
+
+struct A : public Base {
+ A &operator=(const A &) = default;
+ // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
+ // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
+ // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+ // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
+
+ // Check that coverage mapping includes 6 function records including the
+ // defaulted A::operator=
+ // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 }, [6 x
<{{.*}}>],
+ A(int II) : Base(II + 1), I(II) {}
+ A() : Base(0), I(0) {}
+ int I;
+};
+
+A ga(10);
+int main() {
+ A la;
+ la = ga;
+
+ if (la.I != 10 || la.B != 21)
+return 1;
+ return 0;
+}
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1608,6 +1608,7 @@
LexicalScope Scope(*this, RootCS->getSourceRange());
+ incrementProfileCounter(RootCS);
AssignmentMemcpyizer AM(*this, AssignOp, Args);
for (auto *I : RootCS->body())
AM.emitAssignment(I);
Index: test/Profile/def-assignop.cpp
===
--- test/Profile/def-assignop.cpp
+++ test/Profile/def-assignop.cpp
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang | FileCheck --check-prefix=PGOGEN %s
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang -fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
+
+struct Base {
+ int B;
+ Base(int BB) : B(BB) {}
+ void operator=(const struct Base &b) { B = b.B + 10; }
+};
+
+struct A : public Base {
+ A &operator=(const A &) = default;
+ // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
+ // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
+ // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+ // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
+
+ // Check that coverage mapping includes 6 function records including the
+ // defaulted A::operator=
+ // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 }, [6 x <{{.*}}>],
+ A(int II) : Base(II + 1), I(II) {}
+ A() : Base(0), I(0) {}
+ int I;
+};
+
+A ga(10);
+int main() {
+ A la;
+ la = ga;
+
+ if (la.I != 10 || la.B != 21)
+return 1;
+ return 0;
+}
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1608,6 +1608,7 @@
LexicalScope Scope(*this, RootCS->getSourceRange());
+ incrementProfileCounter(RootCS);
AssignmentMemcpyizer AM(*this, AssignOp, Args);
for (auto *I : RootCS->body())
AM.emitAssignment(I);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
* H. J. Lu:
>> Any syntactical array argument (at the C level) is should be passed as
>> a pointer. The language appears to change that.
>
> I didn't use aggregate so that array is excluded here.
>
>> For 2., static members and non-data members do not count.
>
> They do count here. That is why I used "POD for the purpose of
> layout.
Let's see what happens today.
struct s0 {
s0();
};
struct s1 {
static int a;
};
struct s2 {
void member();
};
struct s3 {
int a[0];
};
struct s4 {
s0 a[0];
};
struct s5 {
s1 a[1];
};
I tested GCC 5.3.1 and Clang 3.5.0.
GCC Clang
s0 non-emptynon-empty
s1 non-emptyempty
s2 non-emptyempty
s3 emptyempty
s4 emptyempty
s5 non-emptyempty
I believe s3, s4, s5 are non-empty according to your rules. Why put
both compilers in the wrong? That doesn't make sense to me.
Jason already indicated he intends GCC to move towards more empty
arguments, not fewer.
>> How do existing C++ compilers implement empty array members (an
>> extension)? Does the type of such members affect whether a class is a
>> standard-layout class?
> Are they "POD for the purpose of layout"? If yes, they are covered here.
The C++ standard does not define this.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16973: Fix ICE with constexpr and friend functions
ogoffart updated this revision to Diff 47146.
ogoffart added a comment.
Optimized by avoiding repeated call to getBody
http://reviews.llvm.org/D16973
Files:
lib/AST/ExprConstant.cpp
test/SemaCXX/constant-expression-cxx11.cpp
Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -2005,3 +2005,13 @@
constexpr int a = *f().p;
constexpr int b = *g().p;
}
+
+namespace IncompleteClass {
+ struct XX {
+static constexpr int f(XX*) { return 1; } // expected-note {{here}}
+friend constexpr int g(XX*) { return 2; } // expected-note {{here}}
+
+static constexpr int i = f(static_cast(nullptr)); // expected-error
{{constexpr variable 'i' must be initialized by a constant expression}}
expected-note {{undefined function 'f' cannot be used in a constant expression}}
+static constexpr int j = g(static_cast(nullptr)); // expected-error
{{constexpr variable 'j' must be initialized by a constant expression}}
expected-note {{undefined function 'g' cannot be used in a constant expression}}
+ };
+}
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -3736,7 +3736,8 @@
/// expression.
static bool CheckConstexprFunction(EvalInfo &Info, SourceLocation CallLoc,
const FunctionDecl *Declaration,
- const FunctionDecl *Definition) {
+ const FunctionDecl *Definition,
+ const Stmt *Body) {
// Potential constant expressions can contain calls to declared, but not yet
// defined, constexpr functions.
if (Info.checkingPotentialConstantExpression() && !Definition &&
@@ -3749,7 +3750,8 @@
return false;
// Can we evaluate this function call?
- if (Definition && Definition->isConstexpr() && !Definition->isInvalidDecl())
+ if (Definition && Definition->isConstexpr() &&
+ !Definition->isInvalidDecl() && Body)
return true;
if (Info.getLangOpts().CPlusPlus11) {
@@ -4275,7 +4277,7 @@
const FunctionDecl *Definition = nullptr;
Stmt *Body = FD->getBody(Definition);
-if (!CheckConstexprFunction(Info, E->getExprLoc(), FD, Definition) ||
+if (!CheckConstexprFunction(Info, E->getExprLoc(), FD, Definition, Body) ||
!HandleFunctionCall(E->getExprLoc(), Definition, This, Args, Body,
Info,
Result, ResultSlot))
return false;
@@ -5483,9 +5485,9 @@
}
const FunctionDecl *Definition = nullptr;
- FD->getBody(Definition);
+ auto Body = FD->getBody(Definition);
- if (!CheckConstexprFunction(Info, E->getExprLoc(), FD, Definition))
+ if (!CheckConstexprFunction(Info, E->getExprLoc(), FD, Definition, Body))
return false;
// Avoid materializing a temporary for an elidable copy/move constructor.
@@ -5971,9 +5973,9 @@
}
const FunctionDecl *Definition = nullptr;
- FD->getBody(Definition);
+ auto Body = FD->getBody(Definition);
- if (!CheckConstexprFunction(Info, E->getExprLoc(), FD, Definition))
+ if (!CheckConstexprFunction(Info, E->getExprLoc(), FD, Definition, Body))
return false;
if (ZeroInit && !HadZeroInit) {
Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -2005,3 +2005,13 @@
constexpr int a = *f().p;
constexpr int b = *g().p;
}
+
+namespace IncompleteClass {
+ struct XX {
+static constexpr int f(XX*) { return 1; } // expected-note {{here}}
+friend constexpr int g(XX*) { return 2; } // expected-note {{here}}
+
+static constexpr int i = f(static_cast(nullptr)); // expected-error {{constexpr variable 'i' must be initialized by a constant expression}} expected-note {{undefined function 'f' cannot be used in a constant expression}}
+static constexpr int j = g(static_cast(nullptr)); // expected-error {{constexpr variable 'j' must be initialized by a constant expression}} expected-note {{undefined function 'g' cannot be used in a constant expression}}
+ };
+}
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -3736,7 +3736,8 @@
/// expression.
static bool CheckConstexprFunction(EvalInfo &Info, SourceLocation CallLoc,
const FunctionDecl *Declaration,
- const FunctionDecl *Definition) {
+ const FunctionDecl *Definition,
+ const Stmt *Body) {
// Potential constant expressions can contain calls to declared, but not yet
// defined, constexpr functions
Re: r258524 - Merge templated static member variables, fixes http://llvm.org/pr26179.
Would this patch be any better?
--Vassil
On 05/02/16 21:49, Richard Smith wrote:
This belongs in ASTDeclReader::attachPreviousDecl[Impl]. That's where
we propagate data that's supposed to be consistent across a
redeclaration chain from earlier declarations to later ones.
There's another wrinkle here: we should only be propagating the type
from a previous declaration that's declared in the same scope (in
particular, we should skip over declarations declared as local extern
declarations within a function). This may in some cases require
walking backwards along the redeclaration chain to find the previous
declaration that was not a local extern declaration. That'd be
observable in a case like this:
modulemap:
module A { module A1 { header "a1.h" } module A2 { header "a2.h" } }
module B { header "b.h" }
a1.h:
int a[];
b.h:
void g(int(*)[], int);
void g(int(*)[1], int) = delete;
template void f(T t) {
extern int a[];
g(&a, t);
}
a2.h:
int a[1];
x.cc:
#include "a1.h"
#include "b.h"
void h() { f(0); } // should not produce an error; type of 'a' within
'f' should not have been updated
That example actually reveals another problem: we really don't want
the completed type to be visible unless there is a visible declaration
with the completed type. That suggests that propagating the type
across the redeclaration chain may be the wrong approach, and we
should instead handle this by changing isPreferredLookupResult (in
SemaLookup.cpp) to prefer a VarDecl with a complete type over one with
an incomplete type.
On Fri, Feb 5, 2016 at 12:27 PM, Vassil Vassilev
mailto:v.g.vassi...@gmail.com>> wrote:
I am not sure where else to put this logic if not in
isSameEntity... Could you point me to a better place?
--Vassil
On 05/02/16 19:56, Richard Smith wrote:
On Fri, Feb 5, 2016 at 7:04 AM, Vassil Vassilev
mailto:v.g.vassi...@gmail.com>> wrote:
Good point. Do you have in mind calling
'clang::Sema::MergeVarDeclTypes' or we to just "duplicate"
the logic in clang::ASTDeclReader::mergeRedeclarable?
It's not safe to call into Sema while we're in a
partially-deserialized state. We know the only interesting case
here is complete versus incomplete array types, so we don't need
anything like the complexity of MergeVarDeclTypes -- something as
easy as "if (new type is incomplete and old type is not) set new
type to old type" should work.
On 05/02/16 02:50, Richard Smith via cfe-commits wrote:
I suspect we'll need to do a little more than this: when we
rebuild the redeclaration chain, we should probably
propagate the complete type to later redeclarations in the
same scope. Otherwise, if we import a module that has a
complete type and one that has an incomplete type, the
declaration found by name lookup might be the one with the
incomplete type, possibly resulting in rejects-valid on code
like this:
a.h:
extern int a[5];
b.h:
extern int a[];
x.cc:
#include "a.h"
#include "b.h"
int k = sizeof(a);
On Fri, Jan 22, 2016 at 11:03 AM, Yaron Keren via
cfe-commits mailto:cfe-commits@lists.llvm.org>> wrote:
Author: yrnkrn
Date: Fri Jan 22 13:03:27 2016
New Revision: 258524
URL: http://llvm.org/viewvc/llvm-project?rev=258524&view=rev
Log:
Merge templated static member variables, fixes
http://llvm.org/pr26179.
Patch by Vassil Vassilev!
Reviewed by Richard Smith.
Added:
cfe/trunk/test/Modules/Inputs/PR26179/
cfe/trunk/test/Modules/Inputs/PR26179/A.h
cfe/trunk/test/Modules/Inputs/PR26179/B.h
cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h
cfe/trunk/test/Modules/Inputs/PR26179/module.modulemap
cfe/trunk/test/Modules/pr26179.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=258524&r1=258523&r2=258524&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Fri
Jan 22 13:03:27 2016
@@ -2595,8 +2595,24 @@ static bool
isSameEntity(NamedDecl *X, N
// Variables with the same type and linkage match.
if (VarDecl *VarX = dyn_cast(X)) {
VarDecl *VarY = cast(Y);
-return (VarX->getLinkageInternal() ==
VarY->getLinkageInternal()) &&
- VarX->getASTContext().hasSameType(VarX->getType(),
Re: [PATCH] D16970: scoped alloc construct: adds basic tests
frutiger updated this revision to Diff 47143.
frutiger added a comment.
Fixes include guards.
http://reviews.llvm.org/D16970
Files:
test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
test/support/instrumentingallocators.h
Index: test/support/instrumentingallocators.h
===
--- /dev/null
+++ test/support/instrumentingallocators.h
@@ -0,0 +1,75 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef INSTRUMENTINGALLOCATORS_H
+#define INSTRUMENTINGALLOCATORS_H
+
+#include
+#include
+
+struct Instrumentation {
+typedef std::unordered_map Allocations;
+
+Allocations allocs_;
+size_t numAllocs_= 0;
+size_t numDeallocs_ = 0;
+size_t numAllocsLastChecked_ = 0;
+
+~Instrumentation() {
+assert(allocs_.empty());
+}
+
+void checkAllocsIncreased() {
+assert(numAllocs_ > numAllocsLastChecked_);
+numAllocsLastChecked_ = numAllocs_;
+}
+};
+
+template
+struct IA1 {
+Instrumentation *instrumentation_;
+
+typedef T value_type;
+
+explicit IA1(Instrumentation *instrumentation) :
+instrumentation_(instrumentation) {}
+
+template
+IA1(const IA1& other) : instrumentation_(other.instrumentation_) {}
+
+T *allocate(size_t n) {
+void *result = std::malloc(sizeof(T) * n);
+assert(instrumentation_->allocs_.find(result) ==
+ instrumentation_->allocs_.end());
+instrumentation_->allocs_[result] = n;
+++instrumentation_->numAllocs_;
+return static_cast(result);
+}
+
+void deallocate(T *ptr, size_t n) {
+auto alloc = instrumentation_->allocs_.find(ptr);
+assert(alloc != instrumentation_->allocs_.end());
+assert(alloc->second == n);
+instrumentation_->allocs_.erase(alloc);
+++instrumentation_->numDeallocs_;
+std::free(ptr);
+}
+};
+
+template
+bool operator==(const IA1& lhs, const IA1& rhs) {
+return lhs.instrumentation_ == rhs.instrumentation_;
+}
+
+template
+bool operator!=(const IA1& lhs, const IA1& rhs) {
+return !(lhs == rhs);
+}
+
+#endif
Index: test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
===
--- /dev/null
+++ test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
@@ -0,0 +1,82 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+//
+
+// template
+// class scoped_allocator_adaptor
+
+// template void construct(T* p, Args&& args);
+// template
+// void construct(pair* p, piecewise_construct t, tuple x,
+//tuple y);
+// template
+// void construct(pair* p);
+// template
+// void construct(pair* p, U&& x, V&& y);
+// template
+// void construct(pair* p, const pair& x);
+// template
+// void construct(pair* p, pair&& x);
+
+#include
+#include
+#include
+#include
+
+#include "instrumentingallocators.h"
+
+namespace scoped {
+
+template
+using IA1 = std::scoped_allocator_adaptor>;
+
+template
+using List1 = std::list>;
+
+}
+
+int main()
+{
+Instrumentation instrumentation;
+{
+typedef scoped::List1 List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+{
+typedef scoped::List1> List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+{
+typedef scoped::List1> List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+}
+
___
cfe-co
Re: [PATCH] D16970: scoped alloc construct: adds basic tests
AlisdairM added a subscriber: AlisdairM.
Comment at: test/support/instrumentingallocators.h:25
@@ +24,3 @@
+~Instrumentation() {
+assert(allocs_.empty());
+}
Perhaps a loop, showing what leaked?
for (auto const& alloc : allocs_) {
std::cout << "leaked: address(" << alloc.first <<) size(" << alloc.second
<< ")\n";
}
http://reviews.llvm.org/D16970
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D16970: scoped alloc construct: adds basic tests
frutiger created this revision.
frutiger added reviewers: EricWF, mclow.lists.
frutiger added a subscriber: cfe-commits.
This commit introduces a new supporting allocator 'IA1' in
'support/instrumentingallocators.h' which tracks allocations and deallocations.
This commit also introduces a new test driver 'construct.pass.cpp' which tests
using the 'scoped_allocator_adaptor' with three types which take allocators in
different ways:
1. container-style with the allocator at the end
2. std::function-style with the allocator at the start
3. allocator-unaware types
This will provide a starting point for scenarios where argument lists need to
be adapted before being forwarded for 'pair' where 'T1' and 'T2' may be
combinations of the above three classes of types.
http://reviews.llvm.org/D16970
Files:
test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
test/support/instrumentingallocators.h
Index: test/support/instrumentingallocators.h
===
--- /dev/null
+++ test/support/instrumentingallocators.h
@@ -0,0 +1,61 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef ALLOCATORS_H
+#define ALLOCATORS_H
+
+#include
+#include
+
+struct Instrumentation {
+typedef std::unordered_map Allocations;
+
+Allocations allocs_;
+size_t numAllocs_= 0;
+size_t numDeallocs_ = 0;
+size_t numAllocsLastChecked_ = 0;
+
+void checkAllocsIncreased() {
+assert(numAllocs_ > numAllocsLastChecked_);
+numAllocsLastChecked_ = numAllocs_;
+}
+};
+
+template
+struct IA1 {
+Instrumentation *instrumentation_;
+
+typedef T value_type;
+
+explicit IA1(Instrumentation *instrumentation) :
+instrumentation_(instrumentation) {}
+
+template
+IA1(const IA1& other) : instrumentation_(other.instrumentation_) {}
+
+T *allocate(size_t n) {
+void *result = std::malloc(sizeof(T) * n);
+assert(instrumentation_->allocs_.find(result) ==
+ instrumentation_->allocs_.end());
+instrumentation_->allocs_[result] = n;
+++instrumentation_->numAllocs_;
+return static_cast(result);
+}
+
+void deallocate(T *ptr, size_t n) {
+auto alloc = instrumentation_->allocs_.find(ptr);
+assert(alloc != instrumentation_->allocs_.end());
+assert(alloc->second == n);
+instrumentation_->allocs_.erase(alloc);
+++instrumentation_->numDeallocs_;
+std::free(ptr);
+}
+};
+
+#endif
Index: test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
===
--- /dev/null
+++ test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
@@ -0,0 +1,82 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+//
+
+// template
+// class scoped_allocator_adaptor
+
+// template void construct(T* p, Args&& args);
+// template
+// void construct(pair* p, piecewise_construct t, tuple x,
+//tuple y);
+// template
+// void construct(pair* p);
+// template
+// void construct(pair* p, U&& x, V&& y);
+// template
+// void construct(pair* p, const pair& x);
+// template
+// void construct(pair* p, pair&& x);
+
+#include
+#include
+#include
+#include
+
+#include "instrumentingallocators.h"
+
+namespace scoped {
+
+template
+using IA1 = std::scoped_allocator_adaptor>;
+
+template
+using List1 = std::list>;
+
+}
+
+int main()
+{
+Instrumentation instrumentation;
+{
+typedef scoped::List1 List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+{
+typedef scoped::List1> List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+{
+typedef scoped::List1> List
Re: [PATCH] D16970: scoped alloc construct: adds basic tests
frutiger updated this revision to Diff 47141.
frutiger added a comment.
Added `operator==` and `operator!=`.
http://reviews.llvm.org/D16970
Files:
test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
test/support/instrumentingallocators.h
Index: test/support/instrumentingallocators.h
===
--- /dev/null
+++ test/support/instrumentingallocators.h
@@ -0,0 +1,75 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef ALLOCATORS_H
+#define ALLOCATORS_H
+
+#include
+#include
+
+struct Instrumentation {
+typedef std::unordered_map Allocations;
+
+Allocations allocs_;
+size_t numAllocs_= 0;
+size_t numDeallocs_ = 0;
+size_t numAllocsLastChecked_ = 0;
+
+~Instrumentation() {
+assert(allocs_.empty());
+}
+
+void checkAllocsIncreased() {
+assert(numAllocs_ > numAllocsLastChecked_);
+numAllocsLastChecked_ = numAllocs_;
+}
+};
+
+template
+struct IA1 {
+Instrumentation *instrumentation_;
+
+typedef T value_type;
+
+explicit IA1(Instrumentation *instrumentation) :
+instrumentation_(instrumentation) {}
+
+template
+IA1(const IA1& other) : instrumentation_(other.instrumentation_) {}
+
+T *allocate(size_t n) {
+void *result = std::malloc(sizeof(T) * n);
+assert(instrumentation_->allocs_.find(result) ==
+ instrumentation_->allocs_.end());
+instrumentation_->allocs_[result] = n;
+++instrumentation_->numAllocs_;
+return static_cast(result);
+}
+
+void deallocate(T *ptr, size_t n) {
+auto alloc = instrumentation_->allocs_.find(ptr);
+assert(alloc != instrumentation_->allocs_.end());
+assert(alloc->second == n);
+instrumentation_->allocs_.erase(alloc);
+++instrumentation_->numDeallocs_;
+std::free(ptr);
+}
+};
+
+template
+bool operator==(const IA1& lhs, const IA1& rhs) {
+return lhs.instrumentation_ == rhs.instrumentation_;
+}
+
+template
+bool operator!=(const IA1& lhs, const IA1& rhs) {
+return !(lhs == rhs);
+}
+
+#endif
Index: test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
===
--- /dev/null
+++ test/std/utilities/allocator.adaptor/scoped.adaptor.operators/construct.pass.cpp
@@ -0,0 +1,82 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+//
+
+// template
+// class scoped_allocator_adaptor
+
+// template void construct(T* p, Args&& args);
+// template
+// void construct(pair* p, piecewise_construct t, tuple x,
+//tuple y);
+// template
+// void construct(pair* p);
+// template
+// void construct(pair* p, U&& x, V&& y);
+// template
+// void construct(pair* p, const pair& x);
+// template
+// void construct(pair* p, pair&& x);
+
+#include
+#include
+#include
+#include
+
+#include "instrumentingallocators.h"
+
+namespace scoped {
+
+template
+using IA1 = std::scoped_allocator_adaptor>;
+
+template
+using List1 = std::list>;
+
+}
+
+int main()
+{
+Instrumentation instrumentation;
+{
+typedef scoped::List1 List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+{
+typedef scoped::List1> List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+{
+typedef scoped::List1> List;
+
+List::allocator_type alloc(&instrumentation);
+List list(alloc);
+list.emplace_back();
+instrumentation.checkAllocsIncreased();
+list.emplace_back(list.back());
+instrumentation.checkAllocsIncreased();
+}
+assert(instrumentation.allocs_.size() == 0);
+}
+
___
cfe-commits maili
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 11:36 AM, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify >>> how to pass/return empty struct: >>> >>> 1. "collection". A collection is a structure, union or C++ class. >>> 2. "empty collection". An empty collection is: >>>a. A collection without member. Or >>>b. A collection with only empty collections. Or >>>c. An array of empty collections. >>> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >>>of layout and >>>a. A collection without member. Or >>>b. A collection with only empty collections. >>> 4. No memory slot nor register should be used to pass or return an object of >>> empty collection. >> >> “Aggregate” may be the more standard term instead of collection. > > Aggregate also include array, which is excluded here. > >> I think you mean “empty record” under 4. > > Yes. I will fix it. This typo isn't in the proposed x86 psABIs: https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI which has "No memory slot nor register should be used to pass or return an object of empty record." H.J. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D16973: Fix ICE with constexpr and friend functions
ogoffart created this revision.
ogoffart added reviewers: rsmith, cfe-commits.
Fix a crash while parsing this code:
struct X {
friend constexpr int foo(X*) { return 12; }
static constexpr int j = foo(static_cast(nullptr));
};
I also added a test for the static function case because i don't think this was
tested before.
http://reviews.llvm.org/D16973
Files:
lib/AST/ExprConstant.cpp
test/SemaCXX/constant-expression-cxx11.cpp
Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -2005,3 +2005,13 @@
constexpr int a = *f().p;
constexpr int b = *g().p;
}
+
+namespace IncompleteClass {
+ struct XX {
+static constexpr int f(XX*) { return 1; } // expected-note {{here}}
+friend constexpr int g(XX*) { return 2; } // expected-note {{here}}
+
+static constexpr int i = f(static_cast(nullptr)); // expected-error
{{constexpr variable 'i' must be initialized by a constant expression}}
expected-note {{undefined function 'f' cannot be used in a constant expression}}
+static constexpr int j = g(static_cast(nullptr)); // expected-error
{{constexpr variable 'j' must be initialized by a constant expression}}
expected-note {{undefined function 'g' cannot be used in a constant expression}}
+ };
+}
\ No newline at end of file
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -3749,7 +3749,8 @@
return false;
// Can we evaluate this function call?
- if (Definition && Definition->isConstexpr() && !Definition->isInvalidDecl())
+ if (Definition && Definition->isConstexpr() && !Definition->isInvalidDecl()
+ && Definition->getBody())
return true;
if (Info.getLangOpts().CPlusPlus11) {
Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -2005,3 +2005,13 @@
constexpr int a = *f().p;
constexpr int b = *g().p;
}
+
+namespace IncompleteClass {
+ struct XX {
+static constexpr int f(XX*) { return 1; } // expected-note {{here}}
+friend constexpr int g(XX*) { return 2; } // expected-note {{here}}
+
+static constexpr int i = f(static_cast(nullptr)); // expected-error {{constexpr variable 'i' must be initialized by a constant expression}} expected-note {{undefined function 'f' cannot be used in a constant expression}}
+static constexpr int j = g(static_cast(nullptr)); // expected-error {{constexpr variable 'j' must be initialized by a constant expression}} expected-note {{undefined function 'g' cannot be used in a constant expression}}
+ };
+}
\ No newline at end of file
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -3749,7 +3749,8 @@
return false;
// Can we evaluate this function call?
- if (Definition && Definition->isConstexpr() && !Definition->isInvalidDecl())
+ if (Definition && Definition->isConstexpr() && !Definition->isInvalidDecl()
+ && Definition->getBody())
return true;
if (Info.getLangOpts().CPlusPlus11) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote: > * H. J. Lu: > >> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify >> how to pass/return empty struct: >> >> 1. "collection". A collection is a structure, union or C++ class. >> 2. "empty collection". An empty collection is: >>a. A collection without member. Or >>b. A collection with only empty collections. Or >>c. An array of empty collections. >> 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >>of layout and >>a. A collection without member. Or >>b. A collection with only empty collections. >> 4. No memory slot nor register should be used to pass or return an object of >> empty collection. > > “Aggregate” may be the more standard term instead of collection. Aggregate also include array, which is excluded here. > I think you mean “empty record” under 4. Yes. I will fix it. > Any syntactical array argument (at the C level) is should be passed as > a pointer. The language appears to change that. I didn't use aggregate so that array is excluded here. > For 2., static members and non-data members do not count. They do count here. That is why I used "POD for the purpose of layout. > Does the definition of POD vary between C++ standards? Then the > calling convention would vary as well, which is probably not what we > want. I believe that POD for the purpose of layout doesn't change between C++ standards. > How do existing C++ compilers implement empty array members (an > extension)? Does the type of such members affect whether a class is a > standard-layout class? > > Florian Are they "POD for the purpose of layout"? If yes, they are covered here. -- H.J. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260048 - [Frontend] Make the memory management of FrontendAction pointers explicit by using unique_ptr.
Author: akirtzidis
Date: Sun Feb 7 13:28:36 2016
New Revision: 260048
URL: http://llvm.org/viewvc/llvm-project?rev=260048&view=rev
Log:
[Frontend] Make the memory management of FrontendAction pointers explicit by
using unique_ptr.
Modified:
cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h
cfe/trunk/include/clang/Frontend/FrontendAction.h
cfe/trunk/include/clang/Frontend/FrontendActions.h
cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h
cfe/trunk/lib/ARCMigrate/ARCMTActions.cpp
cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
cfe/trunk/lib/Frontend/ASTMerge.cpp
cfe/trunk/lib/Frontend/FrontendAction.cpp
cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp
Modified: cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h?rev=260048&r1=260047&r2=260048&view=diff
==
--- cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h (original)
+++ cfe/trunk/include/clang/ARCMigrate/ARCMTActions.h Sun Feb 7 13:28:36 2016
@@ -22,7 +22,7 @@ protected:
bool BeginInvocation(CompilerInstance &CI) override;
public:
- CheckAction(FrontendAction *WrappedAction);
+ CheckAction(std::unique_ptr WrappedAction);
};
class ModifyAction : public WrapperFrontendAction {
@@ -30,7 +30,7 @@ protected:
bool BeginInvocation(CompilerInstance &CI) override;
public:
- ModifyAction(FrontendAction *WrappedAction);
+ ModifyAction(std::unique_ptr WrappedAction);
};
class MigrateSourceAction : public ASTFrontendAction {
@@ -49,7 +49,8 @@ protected:
bool BeginInvocation(CompilerInstance &CI) override;
public:
- MigrateAction(FrontendAction *WrappedAction, StringRef migrateDir,
+ MigrateAction(std::unique_ptr WrappedAction,
+StringRef migrateDir,
StringRef plistOut,
bool emitPremigrationARCErrors);
};
@@ -61,8 +62,8 @@ class ObjCMigrateAction : public Wrapper
FileRemapper Remapper;
CompilerInstance *CompInst;
public:
- ObjCMigrateAction(FrontendAction *WrappedAction, StringRef migrateDir,
-unsigned migrateAction);
+ ObjCMigrateAction(std::unique_ptr WrappedAction,
+StringRef migrateDir, unsigned migrateAction);
protected:
std::unique_ptr CreateASTConsumer(CompilerInstance &CI,
Modified: cfe/trunk/include/clang/Frontend/FrontendAction.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendAction.h?rev=260048&r1=260047&r2=260048&view=diff
==
--- cfe/trunk/include/clang/Frontend/FrontendAction.h (original)
+++ cfe/trunk/include/clang/Frontend/FrontendAction.h Sun Feb 7 13:28:36 2016
@@ -283,7 +283,7 @@ protected:
public:
/// Construct a WrapperFrontendAction from an existing action, taking
/// ownership of it.
- WrapperFrontendAction(FrontendAction *WrappedAction);
+ WrapperFrontendAction(std::unique_ptr WrappedAction);
bool usesPreprocessorOnly() const override;
TranslationUnitKind getTranslationUnitKind() override;
Modified: cfe/trunk/include/clang/Frontend/FrontendActions.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendActions.h?rev=260048&r1=260047&r2=260048&view=diff
==
--- cfe/trunk/include/clang/Frontend/FrontendActions.h (original)
+++ cfe/trunk/include/clang/Frontend/FrontendActions.h Sun Feb 7 13:28:36 2016
@@ -168,7 +168,7 @@ public:
*/
class ASTMergeAction : public FrontendAction {
/// \brief The action that the merge action adapts.
- FrontendAction *AdaptedAction;
+ std::unique_ptr AdaptedAction;
/// \brief The set of AST files to merge.
std::vector ASTFiles;
@@ -184,7 +184,8 @@ protected:
void EndSourceFileAction() override;
public:
- ASTMergeAction(FrontendAction *AdaptedAction, ArrayRef
ASTFiles);
+ ASTMergeAction(std::unique_ptr AdaptedAction,
+ ArrayRef ASTFiles);
~ASTMergeAction() override;
bool usesPreprocessorOnly() const override;
Modified: cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h?rev=260048&r1=260047&r2=260048&view=diff
==
--- cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h (original)
+++ cfe/trunk/include/clang/Rewrite/Frontend/FrontendActions.h Sun Feb 7
13:28:36 2016
@@ -50,8 +50,8 @@ public:
/// frontend action.
class FixItRecompile : public WrapperFrontendAction {
public:
- FixItRecompile(FrontendAction *WrappedAction)
-: WrapperFrontendAction(WrappedAction) {}
+ FixItRecompile(std::unique_ptr WrappedAction)
+: WrapperFrontendAction(std::move(WrappedAction)) {}
protected:
bool BeginInvo
Re: [PATCH] D13622: Add call to find_package to load LLVM dependencies
hintonda added a comment. ping http://reviews.llvm.org/D13622 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
* H. J. Lu: > I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify > how to pass/return empty struct: > > 1. "collection". A collection is a structure, union or C++ class. > 2. "empty collection". An empty collection is: >a. A collection without member. Or >b. A collection with only empty collections. Or >c. An array of empty collections. > 3. "empty record". An empty record is Plain Old Data (POD) for the purpose >of layout and >a. A collection without member. Or >b. A collection with only empty collections. > 4. No memory slot nor register should be used to pass or return an object of > empty collection. “Aggregate” may be the more standard term instead of collection. I think you mean “empty record” under 4. Any syntactical array argument (at the C level) is should be passed as a pointer. The language appears to change that. For 2., static members and non-data members do not count. Does the definition of POD vary between C++ standards? Then the calling convention would vary as well, which is probably not what we want. How do existing C++ compilers implement empty array members (an extension)? Does the type of such members affect whether a class is a standard-layout class? Florian ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16971: Fixed crash when partial specialization is missing required parameters
hintonda added a comment.
Here's a snippet of code that will crash:
lass DB {};
template class RemovePolicy : public T {};
template >
class Crash : T, Policy {};
template
class Crash : public DB, public Policy {
public:
Crash(){}
};
http://reviews.llvm.org/D16971
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D16971: Fixed crash when partial specialization is missing required parameters
hintonda created this revision.
hintonda added reviewers: doug.gregor, lvoufo.
hintonda added a subscriber: cfe-commits.
The code sets isPartialSpecialization = false instead of returning true, which
will cause a crash later when the missing template parameter is referenced.
http://reviews.llvm.org/D16971
Files:
lib/Sema/SemaTemplate.cpp
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -2542,7 +2542,7 @@
InstantiationDependent)) {
Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
<< VarTemplate->getDeclName();
- IsPartialSpecialization = false;
+ return true;
}
if (isSameAsPrimaryTemplate(VarTemplate->getTemplateParameters(),
@@ -6286,7 +6286,7 @@
InstantiationDependent)) {
Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
<< ClassTemplate->getDeclName();
- isPartialSpecialization = false;
+ return true;
}
}
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -2542,7 +2542,7 @@
InstantiationDependent)) {
Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
<< VarTemplate->getDeclName();
- IsPartialSpecialization = false;
+ return true;
}
if (isSameAsPrimaryTemplate(VarTemplate->getTemplateParameters(),
@@ -6286,7 +6286,7 @@
InstantiationDependent)) {
Diag(TemplateNameLoc, diag::err_partial_spec_fully_specialized)
<< ClassTemplate->getDeclName();
- isPartialSpecialization = false;
+ return true;
}
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16951: [MS ABI] dllimport'd class cannot have constexpr ctors
thakis added a comment.
Thanks for jumping on this so quickly! Hans can probably just stamp this, but I
lack the background, so I must ask:
Comment at: test/SemaCXX/dllimport.cpp:1262
@@ -1261,1 +1261,3 @@
+struct __declspec(dllimport) PR26506_test1 {
+ virtual ~PR26506_test1() {}
cl.exe seems to accept this – do you know how they do that? Do they just
silently ignore the constexpr?
Comment at: test/SemaCXX/dllimport.cpp:1269
@@ +1268,3 @@
+ virtual ~PR26506_test2() {}
+ constexpr PR26506_test2() {} // expected-error{{constructor cannot be marked
constexpr}}
+};
nit: I feel diagnostics are easier to understand if their text is stand-alone
and not spread across diag and its note. That is "dllimported constructors
cannot be marked constexpr" "note: dllimported here" or something like this
(this also helps with the mythical localization of diagnostics).
http://reviews.llvm.org/D16951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260047 - [libclang] Add missing CINDEX_LINKAGE from a function.
Author: akirtzidis Date: Sun Feb 7 12:21:28 2016 New Revision: 260047 URL: http://llvm.org/viewvc/llvm-project?rev=260047&view=rev Log: [libclang] Add missing CINDEX_LINKAGE from a function. Modified: cfe/trunk/include/clang-c/Index.h Modified: cfe/trunk/include/clang-c/Index.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=260047&r1=260046&r2=260047&view=diff == --- cfe/trunk/include/clang-c/Index.h (original) +++ cfe/trunk/include/clang-c/Index.h Sun Feb 7 12:21:28 2016 @@ -3656,8 +3656,8 @@ typedef enum CXChildVisitResult * Visits the children of a cursor using the specified block. Behaves * identically to clang_visitChildren() in all other respects. */ -unsigned clang_visitChildrenWithBlock(CXCursor parent, - CXCursorVisitorBlock block); +CINDEX_LINKAGE unsigned clang_visitChildrenWithBlock(CXCursor parent, +CXCursorVisitorBlock block); # endif #endif ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16376: clang-tidy check: rule-of-five
jbcoe added a comment. The method I'm using to insert after a function declaration is flawed. Advancing by one character is not always the right thing to do and won't handle cases where there is a space before a semi-colon. I'll add extra tests and see if I can come up with a neater way of handling the post-declaration insertion. http://reviews.llvm.org/D16376 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16966: Make -fno-math-builtin a cc1 option
mssimpso closed this revision. mssimpso added a comment. Committed in r260044. http://reviews.llvm.org/D16966 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260044 - Make -fno-math-builtin a cc1 option
Author: mssimpso Date: Sun Feb 7 11:14:03 2016 New Revision: 260044 URL: http://llvm.org/viewvc/llvm-project?rev=260044&view=rev Log: Make -fno-math-builtin a cc1 option This patch makes -fno-math-builtin a frontend only option instead of a driver option. The appropriate test case was committed in r186899 when the flag was introduced. This should fix PR26317. Contributed-by: Frank Herrmann Modified: cfe/trunk/include/clang/Driver/CC1Options.td cfe/trunk/include/clang/Driver/Options.td Modified: cfe/trunk/include/clang/Driver/CC1Options.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=260044&r1=260043&r2=260044&view=diff == --- cfe/trunk/include/clang/Driver/CC1Options.td (original) +++ cfe/trunk/include/clang/Driver/CC1Options.td Sun Feb 7 11:14:03 2016 @@ -151,6 +151,8 @@ def msave_temp_labels : Flag<["-"], "msa "on compiler-generated code.">; def mrelocation_model : Separate<["-"], "mrelocation-model">, HelpText<"The relocation model to use">; +def fno_math_builtin : Flag<["-"], "fno-math-builtin">, + HelpText<"Disable implicit builtin knowledge of math functions">; } def disable_llvm_optzns : Flag<["-"], "disable-llvm-optzns">, Modified: cfe/trunk/include/clang/Driver/Options.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=260044&r1=260043&r2=260044&view=diff == --- cfe/trunk/include/clang/Driver/Options.td (original) +++ cfe/trunk/include/clang/Driver/Options.td Sun Feb 7 11:14:03 2016 @@ -826,8 +826,6 @@ def fno_builtin : Flag<["-"], "fno-built HelpText<"Disable implicit builtin knowledge of functions">; def fno_builtin_ : Joined<["-"], "fno-builtin-">, Group, Flags<[CC1Option]>, HelpText<"Disable implicit builtin knowledge of a specific function">; -def fno_math_builtin : Flag<["-"], "fno-math-builtin">, Group, Flags<[CC1Option]>, - HelpText<"Disable implicit builtin knowledge of math functions">; def fno_caret_diagnostics : Flag<["-"], "fno-caret-diagnostics">, Group, Flags<[CC1Option]>; def fno_color_diagnostics : Flag<["-"], "fno-color-diagnostics">, Group, ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D16966: Make -fno-math-builtin a cc1 option
mssimpso created this revision. mssimpso added a reviewer: mcrosier. mssimpso added a subscriber: cfe-commits. Herald added a subscriber: mcrosier. This patch makes -fno-math-builtin a frontend only option instead of a driver option. The appropriate test case was committed in r186899 when the flag was introduced. Contributed-by: Frank Herrmann http://reviews.llvm.org/D16966 Files: include/clang/Driver/CC1Options.td include/clang/Driver/Options.td Index: include/clang/Driver/Options.td === --- include/clang/Driver/Options.td +++ include/clang/Driver/Options.td @@ -826,8 +826,6 @@ HelpText<"Disable implicit builtin knowledge of functions">; def fno_builtin_ : Joined<["-"], "fno-builtin-">, Group, Flags<[CC1Option]>, HelpText<"Disable implicit builtin knowledge of a specific function">; -def fno_math_builtin : Flag<["-"], "fno-math-builtin">, Group, Flags<[CC1Option]>, - HelpText<"Disable implicit builtin knowledge of math functions">; def fno_caret_diagnostics : Flag<["-"], "fno-caret-diagnostics">, Group, Flags<[CC1Option]>; def fno_color_diagnostics : Flag<["-"], "fno-color-diagnostics">, Group, Index: include/clang/Driver/CC1Options.td === --- include/clang/Driver/CC1Options.td +++ include/clang/Driver/CC1Options.td @@ -151,6 +151,8 @@ "on compiler-generated code.">; def mrelocation_model : Separate<["-"], "mrelocation-model">, HelpText<"The relocation model to use">; +def fno_math_builtin : Flag<["-"], "fno-math-builtin">, + HelpText<"Disable implicit builtin knowledge of math functions">; } def disable_llvm_optzns : Flag<["-"], "disable-llvm-optzns">, Index: include/clang/Driver/Options.td === --- include/clang/Driver/Options.td +++ include/clang/Driver/Options.td @@ -826,8 +826,6 @@ HelpText<"Disable implicit builtin knowledge of functions">; def fno_builtin_ : Joined<["-"], "fno-builtin-">, Group, Flags<[CC1Option]>, HelpText<"Disable implicit builtin knowledge of a specific function">; -def fno_math_builtin : Flag<["-"], "fno-math-builtin">, Group, Flags<[CC1Option]>, - HelpText<"Disable implicit builtin knowledge of math functions">; def fno_caret_diagnostics : Flag<["-"], "fno-caret-diagnostics">, Group, Flags<[CC1Option]>; def fno_color_diagnostics : Flag<["-"], "fno-color-diagnostics">, Group, Index: include/clang/Driver/CC1Options.td === --- include/clang/Driver/CC1Options.td +++ include/clang/Driver/CC1Options.td @@ -151,6 +151,8 @@ "on compiler-generated code.">; def mrelocation_model : Separate<["-"], "mrelocation-model">, HelpText<"The relocation model to use">; +def fno_math_builtin : Flag<["-"], "fno-math-builtin">, + HelpText<"Disable implicit builtin knowledge of math functions">; } def disable_llvm_optzns : Flag<["-"], "disable-llvm-optzns">, ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D16967: support/allocators: implements requirements
frutiger created this revision.
frutiger added reviewers: mclow.lists, EricWF.
frutiger added a subscriber: cfe-commits.
This commit adds the required constructor overloads and member functions to
make the supporting allocators actually valid allocators. The implementation
of 'allocate' defers to 'std::malloc', and correspondingly that of 'deallocate'
defers to 'std::free'.
This commit also changes supporting allocators 'A1' to track the number of
elements requested and 'A2' to track the hint that was requested in order to
facilitate testing.
Two (seemingly unrelated) tests seem to fail:
Failing Tests (2):
libc++ :: std/utilities/tuple/tuple.general/tuple.smartptr.pass.cpp
libc++ :: std/utilities/tuple/tuple.tuple/tuple.creation/tuple_cat.pass.cpp
http://reviews.llvm.org/D16967
Files:
test/std/utilities/allocator.adaptor/allocator.adaptor.members/allocate_size.pass.cpp
test/std/utilities/allocator.adaptor/allocator.adaptor.members/allocate_size_hint.pass.cpp
test/std/utilities/allocator.adaptor/allocator.adaptor.members/deallocate.pass.cpp
test/support/allocators.h
Index: test/support/allocators.h
===
--- test/support/allocators.h
+++ test/support/allocators.h
@@ -10,6 +10,7 @@
#ifndef ALLOCATORS_H
#define ALLOCATORS_H
+#include
#include
#include
@@ -30,7 +31,7 @@
static bool copy_called;
static bool move_called;
-static bool allocate_called;
+static std::size_t allocate_called;
static std::pair deallocate_called;
A1(const A1& a) TEST_NOEXCEPT : id_(a.id()) {copy_called = true;}
@@ -45,12 +46,13 @@
T* allocate(std::size_t n)
{
-allocate_called = true;
-return (T*)n;
+allocate_called = n;
+return static_cast(std::malloc(sizeof(T) * n));
}
void deallocate(T* p, std::size_t n)
{
+std::free(p);
deallocate_called = std::pair(p, n);
}
@@ -59,7 +61,7 @@
template bool A1::copy_called = false;
template bool A1::move_called = false;
-template bool A1::allocate_called = false;
+template std::size_t A1::allocate_called = 0;
template std::pair A1::deallocate_called;
template
@@ -94,23 +96,36 @@
static bool copy_called;
static bool move_called;
-static bool allocate_called;
+static const void *allocate_called;
A2(const A2& a) TEST_NOEXCEPT : id_(a.id()) {copy_called = true;}
A2(A2&& a) TEST_NOEXCEPT : id_(a.id()) {move_called = true;}
A2& operator=(const A2& a) TEST_NOEXCEPT { id_ = a.id(); copy_called = true; return *this;}
A2& operator=(A2&& a) TEST_NOEXCEPT { id_ = a.id(); move_called = true; return *this;}
+template
+A2(const A2& a) TEST_NOEXCEPT : id_(a.id()) {copy_called = true;}
+
+T* allocate(std::size_t n)
+{
+return static_cast(std::malloc(sizeof(T) * n));
+}
+
T* allocate(std::size_t n, const void* hint)
{
-allocate_called = true;
-return (T*)hint;
+allocate_called = hint;
+return static_cast(std::malloc(sizeof(T) * n));
+}
+
+void deallocate(T* p, std::size_t n)
+{
+std::free(p);
}
};
template bool A2::copy_called = false;
template bool A2::move_called = false;
-template bool A2::allocate_called = false;
+template const void *A2::allocate_called = (const void*)0;
template
inline
@@ -150,6 +165,19 @@
A3& operator=(const A3& a) TEST_NOEXCEPT { id_ = a.id(); copy_called = true; return *this;}
A3& operator=(A3&& a) TEST_NOEXCEPT { id_ = a.id(); move_called = true; return *this;}
+template
+A3(const A3& a) TEST_NOEXCEPT : id_(a.id()) {copy_called = true;}
+
+T* allocate(std::size_t n)
+{
+return static_cast(std::malloc(sizeof(T) * n));
+}
+
+void deallocate(T* p, std::size_t n)
+{
+std::free(p);
+}
+
template
void construct(U* p, Args&& ...args)
{
Index: test/std/utilities/allocator.adaptor/allocator.adaptor.members/deallocate.pass.cpp
===
--- test/std/utilities/allocator.adaptor/allocator.adaptor.members/deallocate.pass.cpp
+++ test/std/utilities/allocator.adaptor/allocator.adaptor.members/deallocate.pass.cpp
@@ -26,20 +26,23 @@
{
typedef std::scoped_allocator_adaptor> A;
A a;
-a.deallocate((int*)10, 20);
-assert((A1::deallocate_called == std::pair((int*)10, 20)));
+int* p = a.allocate(20);
+a.deallocate(p, 20);
+assert((A1::deallocate_called == std::pair(p, 20)));
}
{
typedef std::scoped_allocator_adaptor, A2> A;
A a;
-a.deallocate((int*)10, 20);
-assert((A1::deallocate_called == std::pair((int*)10, 20)));
+int* p = a.allocate(20);
+a.deallocate(p, 20);
+assert((A1::deallocate_called == std::pair(p, 20)));
}
{
typedef std::
[PATCH] D16965: Fix for Bug 14644 - clang confuses scope operator for global namespace giving extra qualification on member
ryee88 created this revision.
ryee88 added reviewers: doug.gregor, gribozavr, francisco.lopes.
ryee88 added a subscriber: cfe-commits.
Bug 14644 - clang confuses scope operator for global namespace giving extra
qualification on member
This is a fix for this bug: https://llvm.org/bugs/show_bug.cgi?id=14644
Essentially the diagnostic needs to distinguish between a "global-specifier
with no nested-name-specifier" and nested-name-specifier (everything else) in
order to provide a more helpful error message.
http://reviews.llvm.org/D16965
Files:
include/clang/Basic/DiagnosticSemaKinds.td
lib/Sema/SemaDecl.cpp
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -3789,6 +3789,17 @@
if (Tag && SS.isNotEmpty() && !Tag->isCompleteDefinition() &&
!IsExplicitInstantiation && !IsExplicitSpecialization &&
!isa(Tag)) {
+
+// Per C++ standard [n3485] 3.4.4 Elaborated type specifiers, section 3:
+// "Cannot introduce an qualified".
+// A clang::NestedNameSpecifier can represent many kinds of specifiers.
+// A global-specifier with no nested-name-specifier requires a different
+// diagnostic from a nested-name specifier.
+unsigned diagId = ( SS.getScopeRep()->getKind() ==
NestedNameSpecifier::Global &&
+ !SS.getScopeRep()->getPrefix() )
+ ? diag::err_standalone_class_specifier
+ : diagId = diag::err_standalone_class_nested_name_specifier;
+
// Per C++ [dcl.type.elab]p1, a class declaration cannot have a
// nested-name-specifier unless it is an explicit instantiation
// or an explicit specialization.
@@ -3797,8 +3808,9 @@
// obvious intent of DR1819.
//
// Per C++ [dcl.enum]p1, an opaque-enum-declaration can't either.
-Diag(SS.getBeginLoc(), diag::err_standalone_class_nested_name_specifier)
-<< GetDiagnosticTypeSpecifierID(DS.getTypeSpecType()) << SS.getRange();
+Diag(SS.getBeginLoc(), diagId)
+ << GetDiagnosticTypeSpecifierID(DS.getTypeSpecType()) << SS.getRange();
+
return nullptr;
}
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -5241,6 +5241,9 @@
def err_standalone_class_nested_name_specifier : Error<
"forward declaration of %select{class|struct|interface|union|enum}0 cannot "
"have a nested name specifier">;
+def err_standalone_class_specifier : Error<
+ "forward declaration of qualified
%select{class|struct|interface|union|enum}0 "
+ "not allowed">;
def err_typecheck_sclass_func : Error<"illegal storage class on function">;
def err_static_block_func : Error<
"function declared in block scope cannot have 'static' storage class">;
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -3789,6 +3789,17 @@
if (Tag && SS.isNotEmpty() && !Tag->isCompleteDefinition() &&
!IsExplicitInstantiation && !IsExplicitSpecialization &&
!isa(Tag)) {
+
+// Per C++ standard [n3485] 3.4.4 Elaborated type specifiers, section 3:
+// "Cannot introduce an qualified".
+// A clang::NestedNameSpecifier can represent many kinds of specifiers.
+// A global-specifier with no nested-name-specifier requires a different
+// diagnostic from a nested-name specifier.
+unsigned diagId = ( SS.getScopeRep()->getKind() == NestedNameSpecifier::Global &&
+ !SS.getScopeRep()->getPrefix() )
+ ? diag::err_standalone_class_specifier
+ : diagId = diag::err_standalone_class_nested_name_specifier;
+
// Per C++ [dcl.type.elab]p1, a class declaration cannot have a
// nested-name-specifier unless it is an explicit instantiation
// or an explicit specialization.
@@ -3797,8 +3808,9 @@
// obvious intent of DR1819.
//
// Per C++ [dcl.enum]p1, an opaque-enum-declaration can't either.
-Diag(SS.getBeginLoc(), diag::err_standalone_class_nested_name_specifier)
-<< GetDiagnosticTypeSpecifierID(DS.getTypeSpecType()) << SS.getRange();
+Diag(SS.getBeginLoc(), diagId)
+ << GetDiagnosticTypeSpecifierID(DS.getTypeSpecType()) << SS.getRange();
+
return nullptr;
}
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -5241,6 +5241,9 @@
def err_standalone_class_nested_name_specifier : Error<
"forward declaration of %select{class|struct|interface|union|enum}0 cannot "
"have a nested name specifier">;
+def err_standalone_class_specifier : Error<
+ "forward declaration of qualified %select{class|struct|interface|union|enum}0 "
+ "not allowed">;
def err_typecheck_sclass_func : Error<"illegal stora
[PATCH] D16963: Copy LibASTMatchersReference.html to gen'd docs
sdowney created this revision.
sdowney added a reviewer: reames.
sdowney added a subscriber: cfe-commits.
The LibASTMatchersReference documentation is an html file, not an rst
document, so is not produced by sphinx. Copy the html into the proper
location as part of the sphinx html doc generation.
Also include a link to the AST Matcher Reference in the index.
http://reviews.llvm.org/D16963
Files:
docs/CMakeLists.txt
docs/index.rst
Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -52,6 +52,7 @@
RAVFrontendAction
LibASTMatchersTutorial
LibASTMatchers
+ LibASTMatchersReference
HowToSetupToolingForLLVM
JSONCompilationDatabase
@@ -84,4 +85,3 @@
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`
-
Index: docs/CMakeLists.txt
===
--- docs/CMakeLists.txt
+++ docs/CMakeLists.txt
@@ -95,6 +95,8 @@
include(AddSphinxTarget)
if (${SPHINX_OUTPUT_HTML})
add_sphinx_target(html clang)
+ file(GLOB DOC_HTML *.html)
+ file(COPY ${DOC_HTML} DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/html)
endif()
if (${SPHINX_OUTPUT_MAN})
add_sphinx_target(man clang)
Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -52,6 +52,7 @@
RAVFrontendAction
LibASTMatchersTutorial
LibASTMatchers
+ LibASTMatchersReference
HowToSetupToolingForLLVM
JSONCompilationDatabase
@@ -84,4 +85,3 @@
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`
-
Index: docs/CMakeLists.txt
===
--- docs/CMakeLists.txt
+++ docs/CMakeLists.txt
@@ -95,6 +95,8 @@
include(AddSphinxTarget)
if (${SPHINX_OUTPUT_HTML})
add_sphinx_target(html clang)
+ file(GLOB DOC_HTML *.html)
+ file(COPY ${DOC_HTML} DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/html)
endif()
if (${SPHINX_OUTPUT_MAN})
add_sphinx_target(man clang)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r259985 - Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.
Hi Renato, This is not related with my patch, I'm afraid your buildbot won't go green with the revert. This looks to be related with r259976. My patch triggered the problem because it touched a CmakeList.txt. The code itself is completely unrelated with the failure. Dmitri Gribenko sent a follow up email to Richard Smith so he can take a look at the problem. Thanks, Samuel From: Renato Golin To: Samuel F Antao/Watson/IBM@IBMUS Cc: Clang Commits Date: 02/07/2016 10:48 AM Subject:Re: r259985 - Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices. On 6 February 2016 at 06:52, Samuel Antao via cfe-commits wrote: > Author: sfantao > Date: Sat Feb 6 00:52:48 2016 > New Revision: 259985 > > URL: http://llvm.org/viewvc/llvm-project?rev=259985&view=rev > Log: > Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices. > > This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated. Hi Samuel, This also broke an ARM self-hosting bot ( http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/4706 ) and it's still broken with the same problem. I've reverted for now until the bot goes green, so we can decide whether to re-apply or not. cheers, --renato ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0
ichesnokov added inline comments.
Comment at: test/SemaOpenCL/implicit-typedef.cl:4
@@ +3,3 @@
+
+#if defined(TEST_WARNINGS)
+typedef atomic_int atomic_flag; // expected-warning {{redefinition of OpenCL
builtin typedef 'atomic_flag'}}
Thank you, Anastasia!
I just posted new patch.
http://reviews.llvm.org/D16351
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0
ichesnokov updated this revision to Diff 47137.
ichesnokov added a comment.
Another warning text implemented for OpenCL.
Like: redefinition of OpenCL builtin typedef 'atomic_flag'
http://reviews.llvm.org/D16351
Files:
include/clang/Basic/DiagnosticSemaKinds.td
lib/Sema/SemaDecl.cpp
test/SemaOpenCL/implicit-typedef.cl
Index: test/SemaOpenCL/implicit-typedef.cl
===
--- test/SemaOpenCL/implicit-typedef.cl
+++ test/SemaOpenCL/implicit-typedef.cl
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -DTEST_WARNINGS -cl-std=CL2.0 -verify -pedantic
-fsyntax-only -Wsystem-headers
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only
+
+#if defined(TEST_WARNINGS)
+typedef atomic_int atomic_flag; // expected-warning {{redefinition of OpenCL
builtin typedef 'atomic_flag'}}
+#else
+typedef atomic_int atomic_flag;
+#endif
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -2036,6 +2036,27 @@
if (getLangOpts().Modules || getLangOpts().C11)
return;
+ // Added isImplicit() check, because implicit TypeDecl::getLocation()
+ // returns 0. The're many implicit typedefs in OpenCL, e.g. atomic_flag.
+ if (Old->isImplicit() || New->isImplicit()) {
+// Since we don't emit system header warnings for compatibility with GCC,
+// don't do this for implicit type redefinition warnings the same way.
+if (!getDiagnostics().getSuppressSystemWarnings()) {
+ if (New->getLocation().isValid()) {
+if (getLangOpts().OpenCL) {
+ Diag(New->getLocation(), diag::warn_opencl_redefinition_of_typedef)
+<< New->getDeclName();
+} else {
+ Diag(New->getLocation(), diag::ext_redefinition_of_typedef)
+<< New->getDeclName();
+}
+if (Old->getLocation().isValid())
+ Diag(Old->getLocation(), diag::note_previous_definition);
+ }
+}
+return;
+ }
+
// If we have a redefinition of a typedef in C, emit a warning. This warning
// is normally mapped to an error, but can be controlled with
// -Wtypedef-redefinition. If either the original or the redefinition is
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -7692,6 +7692,8 @@
" in the declaration statement in the program scope">;
def err_opencl_implicit_vector_conversion : Error<
"implicit conversions between vector types (%0 and %1) are not permitted">;
+def warn_opencl_redefinition_of_typedef : Warning<
+ "redefinition of OpenCL builtin typedef %0">;
// OpenCL v2.0 s6.13.6 -- Builtin Pipe Functions
def err_opencl_builtin_pipe_first_arg : Error<
Index: test/SemaOpenCL/implicit-typedef.cl
===
--- test/SemaOpenCL/implicit-typedef.cl
+++ test/SemaOpenCL/implicit-typedef.cl
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -DTEST_WARNINGS -cl-std=CL2.0 -verify -pedantic -fsyntax-only -Wsystem-headers
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only
+
+#if defined(TEST_WARNINGS)
+typedef atomic_int atomic_flag; // expected-warning {{redefinition of OpenCL builtin typedef 'atomic_flag'}}
+#else
+typedef atomic_int atomic_flag;
+#endif
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -2036,6 +2036,27 @@
if (getLangOpts().Modules || getLangOpts().C11)
return;
+ // Added isImplicit() check, because implicit TypeDecl::getLocation()
+ // returns 0. The're many implicit typedefs in OpenCL, e.g. atomic_flag.
+ if (Old->isImplicit() || New->isImplicit()) {
+// Since we don't emit system header warnings for compatibility with GCC,
+// don't do this for implicit type redefinition warnings the same way.
+if (!getDiagnostics().getSuppressSystemWarnings()) {
+ if (New->getLocation().isValid()) {
+if (getLangOpts().OpenCL) {
+ Diag(New->getLocation(), diag::warn_opencl_redefinition_of_typedef)
+<< New->getDeclName();
+} else {
+ Diag(New->getLocation(), diag::ext_redefinition_of_typedef)
+<< New->getDeclName();
+}
+if (Old->getLocation().isValid())
+ Diag(Old->getLocation(), diag::note_previous_definition);
+ }
+}
+return;
+ }
+
// If we have a redefinition of a typedef in C, emit a warning. This warning
// is normally mapped to an error, but can be controlled with
// -Wtypedef-redefinition. If either the original or the redefinition is
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -7692,6 +7692,8 @@
"
Re: [PATCH] D16966: Make -fno-math-builtin a cc1 option
mcrosier accepted this revision. mcrosier added a comment. This revision is now accepted and ready to land. LGTM. Thanks, Frank. http://reviews.llvm.org/D16966 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16963: Copy LibASTMatchersReference.html to gen'd docs
reames added a comment. This looks entirely reasonable to me, but I don't really know cmake. Can someone with cmake knowledge take a quick look? http://reviews.llvm.org/D16963 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260043 - [analyzer] Invalidate destination of std::copy() and std::copy_backward().
Author: dcoughlin
Date: Sun Feb 7 10:55:44 2016
New Revision: 260043
URL: http://llvm.org/viewvc/llvm-project?rev=260043&view=rev
Log:
[analyzer] Invalidate destination of std::copy() and std::copy_backward().
Now that the libcpp implementations of these methods has a branch that doesn't
call
memmove(), the analyzer needs to invalidate the destination for these methods
explicitly.
rdar://problem/23575656
Added:
cfe/trunk/test/Analysis/bstring.cpp
Modified:
cfe/trunk/include/clang/Analysis/AnalysisContext.h
cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
cfe/trunk/test/Analysis/Inputs/system-header-simulator-cxx.h
cfe/trunk/test/Analysis/diagnostics/explicit-suppression.cpp
Modified: cfe/trunk/include/clang/Analysis/AnalysisContext.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/AnalysisContext.h?rev=260043&r1=260042&r2=260043&view=diff
==
--- cfe/trunk/include/clang/Analysis/AnalysisContext.h (original)
+++ cfe/trunk/include/clang/Analysis/AnalysisContext.h Sun Feb 7 10:55:44 2016
@@ -201,6 +201,10 @@ public:
}
return static_cast(data);
}
+
+ /// Returns true if the root namespace of the given declaration is the 'std'
+ /// C++ namespace.
+ static bool isInStdNamespace(const Decl *D);
private:
ManagedAnalysis *&getAnalysisImpl(const void* tag);
Modified: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp?rev=260043&r1=260042&r2=260043&view=diff
==
--- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp (original)
+++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp Sun Feb 7 10:55:44 2016
@@ -317,6 +317,21 @@ AnalysisDeclContext::getBlockInvocationC
BD,
ContextData);
}
+bool AnalysisDeclContext::isInStdNamespace(const Decl *D) {
+ const DeclContext *DC = D->getDeclContext()->getEnclosingNamespaceContext();
+ const NamespaceDecl *ND = dyn_cast(DC);
+ if (!ND)
+return false;
+
+ while (const DeclContext *Parent = ND->getParent()) {
+if (!isa(Parent))
+ break;
+ND = cast(Parent);
+ }
+
+ return ND->isStdNamespace();
+}
+
LocationContextManager & AnalysisDeclContext::getLocationContextManager() {
assert(Manager &&
"Cannot create LocationContexts without an
AnalysisDeclContextManager!");
Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CStringChecker.cpp?rev=260043&r1=260042&r2=260043&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/CStringChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/CStringChecker.cpp Sun Feb 7
10:55:44 2016
@@ -118,6 +118,10 @@ public:
void evalStrsep(CheckerContext &C, const CallExpr *CE) const;
+ void evalStdCopy(CheckerContext &C, const CallExpr *CE) const;
+ void evalStdCopyBackward(CheckerContext &C, const CallExpr *CE) const;
+ void evalStdCopyCommon(CheckerContext &C, const CallExpr *CE) const;
+
// Utility methods
std::pair
static assumeZero(CheckerContext &C,
@@ -1950,7 +1954,57 @@ void CStringChecker::evalStrsep(CheckerC
C.addTransition(State);
}
+// These should probably be moved into a C++ standard library checker.
+void CStringChecker::evalStdCopy(CheckerContext &C, const CallExpr *CE) const {
+ evalStdCopyCommon(C, CE);
+}
+
+void CStringChecker::evalStdCopyBackward(CheckerContext &C,
+ const CallExpr *CE) const {
+ evalStdCopyCommon(C, CE);
+}
+
+void CStringChecker::evalStdCopyCommon(CheckerContext &C,
+ const CallExpr *CE) const {
+ if (CE->getNumArgs() < 3)
+return;
+ ProgramStateRef State = C.getState();
+
+ const LocationContext *LCtx = C.getLocationContext();
+
+ // template
+ // _OutputIterator
+ // copy(_InputIterator __first, _InputIterator __last,
+ //_OutputIterator __result)
+
+ // Invalidate the destination buffer
+ const Expr *Dst = CE->getArg(2);
+ SVal DstVal = State->getSVal(Dst, LCtx);
+ State = InvalidateBuffer(C, State, Dst, DstVal, /*IsSource=*/false,
+ /*Size=*/nullptr);
+
+ SValBuilder &SVB = C.getSValBuilder();
+
+ SVal ResultVal = SVB.conjureSymbolVal(nullptr, CE, LCtx, C.blockCount());
+ State = State->BindExpr(CE, LCtx, ResultVal);
+
+ C.addTransition(State);
+}
+
+static bool isCPPStdLibraryFunction(const FunctionDecl *FD, StringRef Name) {
+ IdentifierInfo *II = FD->getIdentifier();
+ if (!II)
+
[PATCH] D16964: Make sure the projects subdirectory doesn't contain the clang or clang-tools-extra projects
hintonda created this revision.
hintonda added reviewers: beanz, mclow.lists.
hintonda added a subscriber: cfe-commits.
A common error for new users it to checkout subprojects, like clang or
clang-tools-extra, into the wrong subdirectory. This change helps prevent
this, since the resulting build would otherwise be unusable.
http://reviews.llvm.org/D16964
Files:
projects/CMakeLists.txt
Index: projects/CMakeLists.txt
===
--- projects/CMakeLists.txt
+++ projects/CMakeLists.txt
@@ -4,6 +4,14 @@
file(GLOB entries *)
foreach(entry ${entries})
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
+# Do not allow tools like clang or clang-tools-extra in the projects
directory
+if(${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/clang)
+ message(FATAL_ERROR "clang must be placed under llvm/tools, not
llvm/projects")
+endif()
+if((${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/extra) OR
+ (${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/clang-tools-extra))
+ message(FATAL_ERROR "clang-tools-extra (extra) must be placed under
llvm/tools/clang/tools, not llvm/projects")
+endif()
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
Index: projects/CMakeLists.txt
===
--- projects/CMakeLists.txt
+++ projects/CMakeLists.txt
@@ -4,6 +4,14 @@
file(GLOB entries *)
foreach(entry ${entries})
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
+# Do not allow tools like clang or clang-tools-extra in the projects directory
+if(${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/clang)
+ message(FATAL_ERROR "clang must be placed under llvm/tools, not llvm/projects")
+endif()
+if((${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/extra) OR
+ (${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/clang-tools-extra))
+ message(FATAL_ERROR "clang-tools-extra (extra) must be placed under llvm/tools/clang/tools, not llvm/projects")
+endif()
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r259985 - Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.
On 6 February 2016 at 06:52, Samuel Antao via cfe-commits wrote: > Author: sfantao > Date: Sat Feb 6 00:52:48 2016 > New Revision: 259985 > > URL: http://llvm.org/viewvc/llvm-project?rev=259985&view=rev > Log: > Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code > generation for different devices. > > This was reverted due to a failure in a buildbot, but it turned out the > failure was unrelated. Hi Samuel, This also broke an ARM self-hosting bot (http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/4706) and it's still broken with the same problem. I've reverted for now until the bot goes green, so we can decide whether to re-apply or not. cheers, --renato ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260036 - Revert "Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices."
Author: rengolin
Date: Sun Feb 7 09:43:09 2016
New Revision: 260036
URL: http://llvm.org/viewvc/llvm-project?rev=260036&view=rev
Log:
Revert "Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code
generation for different devices."
This reverts commit r259985, as it still fails one buildbot.
Removed:
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/lib/CodeGen/CMakeLists.txt
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/OpenMP/target_messages.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=260036&r1=260035&r2=260036&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Sun Feb 7 09:43:09
2016
@@ -132,9 +132,7 @@ def err_drv_no_neon_modifier : Error<"[n
def err_drv_invalid_omp_target : Error<"OpenMP target is invalid: '%0'">;
def err_drv_omp_host_ir_file_not_found : Error<
"The provided host compiler IR file '%0' is required to generate code for
OpenMP target regions but cannot be found.">;
-def err_drv_omp_host_target_not_supported : Error<
- "The target '%0' is not a supported OpenMP host target.">;
-
+
def warn_O4_is_O3 : Warning<"-O4 is equivalent to -O3">, InGroup;
def warn_drv_lto_libpath : Warning<"libLTO.dylib relative to clang installed
dir not found; using 'ld' default search path instead">,
InGroup;
Removed: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp?rev=260035&view=auto
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp (removed)
@@ -1,21 +0,0 @@
-//=== CGOpenMPRuntimeNVPTX.cpp - Interface to OpenMP NVPTX Runtimes
---===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This provides a class for OpenMP runtime code generation specialized to
NVPTX
-// targets.
-//
-//===--===//
-
-#include "CGOpenMPRuntimeNVPTX.h"
-
-using namespace clang;
-using namespace CodeGen;
-
-CGOpenMPRuntimeNVPTX::CGOpenMPRuntimeNVPTX(CodeGenModule &CGM)
-: CGOpenMPRuntime(CGM) {}
Removed: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h?rev=260035&view=auto
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h (removed)
@@ -1,31 +0,0 @@
-//===- CGOpenMPRuntimeNVPTX.h - Interface to OpenMP NVPTX Runtimes
===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This provides a class for OpenMP runtime code generation specialized to
NVPTX
-// targets.
-//
-//===--===//
-
-#ifndef LLVM_CLANG_LIB_CODEGEN_CGOPENMPRUNTIMENVPTX_H
-#define LLVM_CLANG_LIB_CODEGEN_CGOPENMPRUNTIMENVPTX_H
-
-#include "CGOpenMPRuntime.h"
-
-namespace clang {
-namespace CodeGen {
-
-class CGOpenMPRuntimeNVPTX : public CGOpenMPRuntime {
-public:
- explicit CGOpenMPRuntimeNVPTX(CodeGenModule &CGM);
-};
-
-} // CodeGen namespace.
-} // clang namespace.
-
-#endif // LLVM_CLANG_LIB_CODEGEN_CGOPENMPRUNTIMENVPTX_H
Modified: cfe/trunk/lib/CodeGen/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CMakeLists.txt?rev=260036&r1=260035&r2=260036&view=diff
==
--- cfe/trunk/lib/CodeGen/CMakeLists.txt (original)
+++ cfe/trunk/lib/CodeGen/CMakeLists.txt Sun Feb 7 09:43:09 2016
@@ -57,7 +57,6 @@ add_clang_library(clangCodeGen
CGObjCRuntime.cpp
CGOpenCLRuntime.cpp
CGOpenMPRuntime.cpp
- CGOpenMPRuntimeNVPTX.cpp
CGRecordLayoutBuilder.cpp
CGStmt.cpp
CGStmtOpenMP.cpp
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=260036&r1=260035&r2=260036&view=diff
==
Re: [PATCH] D16460: Bug 10002 - [opencl] Wrongfully assuming RHS is always unsigned
ichesnokov added inline comments.
Comment at: lib/CodeGen/CGExprScalar.cpp:2716
@@ +2715,3 @@
+ if (Ops.LHS->getType() != RHS->getType()) {
+bool isSigned =
dyn_cast(Ops.E)->getRHS()->getType().getTypePtr()->isSignedIntegerType();
+RHS = Builder.CreateIntCast(RHS, Ops.LHS->getType(), isSigned, "sh_prom");
The OpenCL 2.0 standard does not say anything about right operand sign of shift
operators.
C standard says the behavior is undefined:
http://www.coding-guidelines.com/cbook/cbook1_0b.pdf, 1175
"If the value of the right operand is negative or is greater than or equal to
the width of the promoted left
operand, the behavior is undefined."
In C++11 standard said the same:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf, 5.8
"The behavior is undefined if the right operand
is negative, or greater than or equal to the length in bits of the promoted
left operand"
I.e., we can close this bug as NAB and do not apply patch.
However, I believe that passing right operand, preserving it's sign, gives more
flexibility to developers. It makes opportunity to developers use signed right
operator, not only unsigned (if development is working for specific platform
where developer knows what happens when right operand is signed).
Repository:
rL LLVM
http://reviews.llvm.org/D16460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Empty struct value is passed differently in C and C++ on Intel386 and x86-64. Different compilers use different calling conventions on the same platform: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 The same compiler behaves different on different platforms: https://llvm.org/bugs/show_bug.cgi?id=26337 In some case, empty struct can't be passed in C++ at all: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify how to pass/return empty struct: 1. "collection". A collection is a structure, union or C++ class. 2. "empty collection". An empty collection is: a. A collection without member. Or b. A collection with only empty collections. Or c. An array of empty collections. 3. "empty record". An empty record is Plain Old Data (POD) for the purpose of layout and a. A collection without member. Or b. A collection with only empty collections. 4. No memory slot nor register should be used to pass or return an object of empty collection. The proposed Intel386, x86-64 and IA MCU psABIs are at https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI Any comments? Thanks. -- H.J. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D16962: clang-tidy: avoid std::bind
jbcoe created this revision.
jbcoe added reviewers: aaron.ballman, alexfh, djasper.
jbcoe added a subscriber: cfe-commits.
jbcoe set the repository for this revision to rL LLVM.
Replace std::bind with a lambda.
Not yet working for member functions.
Repository:
rL LLVM
http://reviews.llvm.org/D16962
Files:
clang-tidy/misc/AvoidStdBindCheck.cpp
clang-tidy/misc/AvoidStdBindCheck.h
clang-tidy/misc/CMakeLists.txt
clang-tidy/misc/MiscTidyModule.cpp
docs/clang-tidy/checks/list.rst
docs/clang-tidy/checks/misc-avoid-std-bind.rst
test/clang-tidy/misc-avoid-std-bind.cpp
Index: test/clang-tidy/misc-avoid-std-bind.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-avoid-std-bind.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s misc-avoid-std-bind %t
+
+namespace std {
+inline namespace impl {
+template
+class bind_rt {};
+
+template
+bind_rt bind(Fp&&, Arguments&& ...);
+}
+}
+
+int add(int x, int y) { return x + y; }
+
+void f()
+{
+ auto clj = std::bind(add,2,2);
+ // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: avoid using std::bind [misc-avoid-std-bind]
+}
+
+// CHECK-FIXES: auto clj = [] { return add(2, 2); };
+
+void g()
+{
+ int x = 2;
+ int y = 2;
+ auto clj = std::bind(add,x,y);
+ // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: avoid using std::bind [misc-avoid-std-bind]
+}
+
+// CHECK-FIXES: auto clj = [=] { return add(x, y); };
+
+struct placeholder {};
+placeholder _1;
+placeholder _2;
+
+void h()
+{
+ int x = 2;
+ auto clj = std::bind(add,x,_1);
+ // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: avoid using std::bind [misc-avoid-std-bind]
+}
+
+// CHECK-FIXES: auto clj = [=](int arg1) { return add(x, arg1); };
+
+struct A;
+struct B;
+bool ABTest(const A&, const B&);
+
+void i()
+{
+ auto BATest = std::bind(ABTest, _2, _1);
+ // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: avoid using std::bind [misc-avoid-std-bind]
+}
+
+// CHECK-FIXES: auto BATest = [](const struct B & arg1, const struct A & arg2) { return ABTest(arg2, arg1); };
+
+void j()
+{
+ auto clj = std::bind(add, 2, 2, 2);
+ // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: avoid using std::bind [misc-avoid-std-bind]
+}
+// No fix is applied for argument mismatches.
+// CHECK-FIXES: auto clj = std::bind(add, 2, 2, 2);
Index: docs/clang-tidy/checks/misc-avoid-std-bind.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-avoid-std-bind.rst
@@ -0,0 +1,13 @@
+.. title:: clang-tidy - misc-avoid-std-bind
+
+misc-avoid-std-bind
+===
+
+Find uses of std::bind. Replace simple uses of std::bind with lambdas. Lambdas
+will use value-capture where required.
+
+Right now it only handles free functions not member functions.
+
+std::bind can result in larger object files and binaries due to type
+information that will not be produced by equivalent lambdas.
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -46,6 +46,7 @@
misc-argument-comment
misc-assert-side-effect
misc-assign-operator-signature
+ misc-avoid-std-bind
misc-bool-pointer-implicit-conversion
misc-definitions-in-headers
misc-inaccurate-erase
Index: clang-tidy/misc/MiscTidyModule.cpp
===
--- clang-tidy/misc/MiscTidyModule.cpp
+++ clang-tidy/misc/MiscTidyModule.cpp
@@ -13,6 +13,7 @@
#include "ArgumentCommentCheck.h"
#include "AssertSideEffectCheck.h"
#include "AssignOperatorSignatureCheck.h"
+#include "AvoidStdBindCheck.h"
#include "BoolPointerImplicitConversionCheck.h"
#include "DefinitionsInHeadersCheck.h"
#include "InaccurateEraseCheck.h"
@@ -48,6 +49,8 @@
"misc-assert-side-effect");
CheckFactories.registerCheck(
"misc-assign-operator-signature");
+CheckFactories.registerCheck(
+"misc-avoid-std-bind");
CheckFactories.registerCheck(
"misc-bool-pointer-implicit-conversion");
CheckFactories.registerCheck(
Index: clang-tidy/misc/CMakeLists.txt
===
--- clang-tidy/misc/CMakeLists.txt
+++ clang-tidy/misc/CMakeLists.txt
@@ -4,6 +4,7 @@
ArgumentCommentCheck.cpp
AssertSideEffectCheck.cpp
AssignOperatorSignatureCheck.cpp
+ AvoidStdBindCheck.cpp
BoolPointerImplicitConversionCheck.cpp
DefinitionsInHeadersCheck.cpp
InaccurateEraseCheck.cpp
Index: clang-tidy/misc/AvoidStdBindCheck.h
===
--- /dev/null
+++ clang-tidy/misc/AvoidStdBindCheck.h
@@ -0,0 +1,59 @@
+//===--- AvoidStdBindCheck.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--
Re: [PATCH] D16539: [FIX] 26194 - LLVM crash in CXXNameMangler::mangleType
ichesnokov added a comment. Please review the last version of patch. http://reviews.llvm.org/D16539 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16682: 19957 - OpenCL incorrectly accepts implicit address space conversion with ternary operator
ichesnokov added inline comments.
Comment at: test/SemaOpenCL/ternary-implicit-casts.cl:10-11
@@ +9,4 @@
+kernel void implicit_cast_generic(global int* gint, local int* lint, int cond)
{
+ // will compile, ptr is generic and can accept global and local
+ int* ptr = cond ? gint : lint; // expected-warning {{pointer type
mismatch ('__global int *' and '__local int *')}}
+}
bader wrote:
> Note that test doesn't specify OpenCL version. By default it's 1.0, so ptr
> points to private AS and it's illegal to cast pointers from different address
> spaces in OpenCL v1.x.
Let's discuss in https://llvm.org/bugs/show_bug.cgi?id=19957
http://reviews.llvm.org/D16682
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16682: 19957 - OpenCL incorrectly accepts implicit address space conversion with ternary operator
ichesnokov added a comment. It looks like there's more todo to close this bug. Let's go back to bug discussion at: https://llvm.org/bugs/show_bug.cgi?id=19957 http://reviews.llvm.org/D16682 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r260028 - Use CodeGenModule::addReplacement() instead of directly accessing Replacements[].
Author: yrnkrn Date: Sun Feb 7 06:44:35 2016 New Revision: 260028 URL: http://llvm.org/viewvc/llvm-project?rev=260028&view=rev Log: Use CodeGenModule::addReplacement() instead of directly accessing Replacements[]. This helps when trying to debug who inserted into Replacements. Modified: cfe/trunk/lib/CodeGen/CGCXX.cpp Modified: cfe/trunk/lib/CodeGen/CGCXX.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCXX.cpp?rev=260028&r1=260027&r2=260028&view=diff == --- cfe/trunk/lib/CodeGen/CGCXX.cpp (original) +++ cfe/trunk/lib/CodeGen/CGCXX.cpp Sun Feb 7 06:44:35 2016 @@ -164,7 +164,7 @@ bool CodeGenModule::TryEmitDefinitionAsA // members with attribute "AlwaysInline" and expect no reference to // be generated. It is desirable to reenable this optimisation after // corresponding LLVM changes. -Replacements[MangledName] = Aliasee; +addReplacement(MangledName, Aliasee); return false; } ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH]: git-clang-format
On 12/14/2015 10:03 PM, Alexander Shukaev wrote: On 12/11/2015 04:40 PM, Daniel Jasper wrote: Please submit patches to clang-format to reviews.llvm.org. Also, any change no matter how easy it is to deduce from the code itself deserves a proper change description :-). Bullet points are fine. Thanks for the quick reply. I've submitted the patch for review [1] as requested. Just let me know if anything else is needed. Regards, Alexander [1] http://reviews.llvm.org/D15465 Hello, I am wondering whether I can expect this patch to be reviewed and included into the upcoming 3.8 release? I didn't receive any feedback ever since it was submitted. Apologies, I don't want to annoy anybody but seeing no reaction at all within a couple months feels rude. Kind regards, Alexander ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
