[PATCH] D45719: [clang-Format] Fix indentation of member call after block
ank added inline comments.
Comment at: unittests/Format/FormatTest.cpp:4359
+ "return 3;\n"
+ " }).as("");\n"
+ "}");
klimek wrote:
> ank wrote:
> > klimek wrote:
> > > ank wrote:
> > > > klimek wrote:
> > > > > What would be interesting is tests that:
> > > > > a) have another value after the closing }; doesn't really make sense
> > > > > in this test, but usually these are in calls
> > > > > f([]() { ... }, foo, bar).call(...)
> > > > >
> > > > > b) make .as("") have paramters that go beyond the limit
> > > > >
> > > > > c) add another chained call behind .as("").
> > > > Hello, sorry for the late follow up on this!
> > > >
> > > > Indeed an interesting thing to test, and so I did, the patterns you
> > > > describe seems to give strange indentation as far back as release_36
> > > > and probably has always done so. The case I'm testing here worked in
> > > > release_40 but stopped working somewhere before release_50
> > > >
> > > > maybe fixing those other cases can be done in another patch
> > > >
> > > > cheers,
> > > > Anders
> > > I meant: please add these tests :)
> > I need to clarify, those tests will not be correctly indented by this
> > commit, I could add those tests but then they would verify a faulty
> > behaviour, this is how they will be indented even with this patch applied:
> >
> >
> > ```
> > // Dont break if only closing statements before member call
> > verifyFormat("test() {\n"
> > " ([]() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " }).foo();\n"
> > "}");
> > verifyFormat("test() {\n"
> > " (\n"
> > " []() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " },\n"
> > " foo, bar)\n"
> > " .foo();\n"
> > "}");
> > verifyFormat("test() {\n"
> > " ([]() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " })\n"
> > " .foo()\n"
> > " .bar();\n"
> > "}");
> > verifyFormat("test() {\n"
> > " ([]() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " })\n"
> > "
> > .foo(\"aaa\"\n"
> > " \"bb\");\n"
> > "}");
> >
> > verifyFormat("test() {\n"
> > " foo([]() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " }).foo();\n"
> > "}");
> > verifyFormat("test() {\n"
> > " foo(\n"
> > " []() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " },\n"
> > " foo, bar)\n"
> > " .as();\n"
> > "}");
> > verifyFormat("test() {\n"
> > " foo([]() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " })\n"
> > " .foo()\n"
> > " .bar();\n"
> > "}");
> > verifyFormat("test() {\n"
> > " foo([]() -> {\n"
> > "int b = 32;\n"
> > "return 3;\n"
> > " })\n"
> > "
> > .as(\"\"\n"
> > " \"bb\");\n"
> > "}");
> > ```
> I'm not sure we agree that the behavior is "faulty" - I do believe it was an
> intentional change :)
> This is an indent of 4 from the start of the expression that call belongs to.
> For example, in example (2), having the .foo() at the end of line after a
> potentially complex parameter strongly de-emphasizes the parameter.
> In example (3), how would you want to layout a chain of calls?
I see! I think your argument makes perfect sense, I think example 3 should be
as is, considering that it is consistent with the other behaviour :) thanks for
taking the time to explain!
Repository:
rC Clang
https://reviews.llvm.org/D45719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D45719: [clang-Format] Fix indentation of member call after block
ank updated this revision to Diff 152842.
Repository:
rC Clang
https://reviews.llvm.org/D45719
Files:
lib/Format/ContinuationIndenter.cpp
lib/Format/FormatToken.h
unittests/Format/FormatTest.cpp
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -4416,6 +4416,71 @@
verifyFormat(".(\n"
"aa)\n"
".aa();");
+
+ // Dont break if only closing statements before member call
+ verifyFormat("test() {\n"
+ " ([]() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " }).foo();\n"
+ "}");
+ verifyFormat("test() {\n"
+ " (\n"
+ " []() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " },\n"
+ " foo, bar)\n"
+ " .foo();\n"
+ "}");
+ verifyFormat("test() {\n"
+ " ([]() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " })\n"
+ " .foo()\n"
+ " .bar();\n"
+ "}");
+ verifyFormat("test() {\n"
+ " ([]() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " })\n"
+ " .foo(\"aaa\"\n"
+ " \"bb\");\n"
+ "}");
+
+ verifyFormat("test() {\n"
+ " foo([]() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " }).foo();\n"
+ "}");
+ verifyFormat("test() {\n"
+ " foo(\n"
+ " []() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " },\n"
+ " foo, bar)\n"
+ " .as();\n"
+ "}");
+ verifyFormat("test() {\n"
+ " foo([]() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " })\n"
+ " .foo()\n"
+ " .bar();\n"
+ "}");
+ verifyFormat("test() {\n"
+ " foo([]() -> {\n"
+ "int b = 32;\n"
+ "return 3;\n"
+ " })\n"
+ " .as(\"\"\n"
+ " \"bb\");\n"
+ "}");
}
TEST_F(FormatTest, BreaksAccordingToOperatorPrecedence) {
Index: lib/Format/FormatToken.h
===
--- lib/Format/FormatToken.h
+++ lib/Format/FormatToken.h
@@ -319,6 +319,14 @@
}
template bool isNot(T Kind) const { return !is(Kind); }
+ bool closesScopeAfterBlock() const {
+if(BlockKind == BK_Block)
+ return true;
+if(closesScope())
+ return Previous->closesScopeAfterBlock();
+return false;
+ }
+
/// \c true if this token starts a sequence with the given tokens in order,
/// following the ``Next`` pointers, ignoring comments.
template
Index: lib/Format/ContinuationIndenter.cpp
===
--- lib/Format/ContinuationIndenter.cpp
+++ lib/Format/ContinuationIndenter.cpp
@@ -399,7 +399,9 @@
// }.bind(...));
// FIXME: We should find a more generic solution to this problem.
!(State.Column <= NewLineColumn &&
-Style.Language == FormatStyle::LK_JavaScript))
+Style.Language == FormatStyle::LK_JavaScript) &&
+ !(Previous.closesScopeAfterBlock() &&
+State.Column <= NewLineColumn))
return true;
// If the template declaration spans multiple lines, force wrap before the
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335577 - Fix an ambiguous overload issue pointed out by MSVC
Author: vedantk
Date: Mon Jun 25 20:53:06 2018
New Revision: 335577
URL: http://llvm.org/viewvc/llvm-project?rev=335577&view=rev
Log:
Fix an ambiguous overload issue pointed out by MSVC
Log:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11390
Modified:
cfe/trunk/include/clang/Basic/Specifiers.h
cfe/trunk/lib/Sema/SemaLambda.cpp
Modified: cfe/trunk/include/clang/Basic/Specifiers.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Specifiers.h?rev=335577&r1=335576&r2=335577&view=diff
==
--- cfe/trunk/include/clang/Basic/Specifiers.h (original)
+++ cfe/trunk/include/clang/Basic/Specifiers.h Mon Jun 25 20:53:06 2018
@@ -296,7 +296,7 @@ namespace clang {
/// Return true if \p L has a weaker nullability annotation than \p R. The
/// ordering is: Unspecified < Nullable < NonNull.
- inline bool operator<(NullabilityKind L, NullabilityKind R) {
+ inline bool hasWeakerNullability(NullabilityKind L, NullabilityKind R) {
return uint8_t(L) > uint8_t(R);
}
Modified: cfe/trunk/lib/Sema/SemaLambda.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLambda.cpp?rev=335577&r1=335576&r2=335577&view=diff
==
--- cfe/trunk/lib/Sema/SemaLambda.cpp (original)
+++ cfe/trunk/lib/Sema/SemaLambda.cpp Mon Jun 25 20:53:06 2018
@@ -712,7 +712,8 @@ void Sema::deduceClosureReturnType(Captu
auto RetTyNullability = ReturnType->getNullability(Ctx);
auto BlockNullability = CSI.ReturnType->getNullability(Ctx);
if (BlockNullability &&
- (!RetTyNullability || *RetTyNullability < *BlockNullability))
+ (!RetTyNullability ||
+ hasWeakerNullability(*RetTyNullability, *BlockNullability)))
CSI.ReturnType = ReturnType;
continue;
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335571 - Modernize a function, NFC.
Author: vedantk
Date: Mon Jun 25 19:50:01 2018
New Revision: 335571
URL: http://llvm.org/viewvc/llvm-project?rev=335571&view=rev
Log:
Modernize a function, NFC.
Modified:
cfe/trunk/lib/Sema/SemaLambda.cpp
Modified: cfe/trunk/lib/Sema/SemaLambda.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLambda.cpp?rev=335571&r1=335570&r2=335571&view=diff
==
--- cfe/trunk/lib/Sema/SemaLambda.cpp (original)
+++ cfe/trunk/lib/Sema/SemaLambda.cpp Mon Jun 25 19:50:01 2018
@@ -692,9 +692,7 @@ void Sema::deduceClosureReturnType(Captu
}
// Third case: only one return statement. Don't bother doing extra work!
- SmallVectorImpl::iterator I = CSI.Returns.begin(),
- E = CSI.Returns.end();
- if (I+1 == E)
+ if (CSI.Returns.size() == 1)
return;
// General case: many return statements.
@@ -703,8 +701,7 @@ void Sema::deduceClosureReturnType(Captu
// We require the return types to strictly match here.
// Note that we've already done the required promotions as part of
// processing the return statement.
- for (; I != E; ++I) {
-const ReturnStmt *RS = *I;
+ for (const ReturnStmt *RS : CSI.Returns) {
const Expr *RetE = RS->getRetValue();
QualType ReturnType =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335572 - [ubsan] Relax nullability-return for blocks with deduced types
Author: vedantk
Date: Mon Jun 25 19:50:04 2018
New Revision: 335572
URL: http://llvm.org/viewvc/llvm-project?rev=335572&view=rev
Log:
[ubsan] Relax nullability-return for blocks with deduced types
When the return type of an ObjC-style block literals is deduced, pick
the candidate type with the strictest nullability annotation applicable
to every other candidate.
This suppresses a UBSan false-positive in situations where a too-strict
nullability would be deduced, despite the fact that the returned value
would be implicitly cast to _Nullable.
rdar://41317163
Modified:
cfe/trunk/include/clang/Basic/Specifiers.h
cfe/trunk/lib/Sema/SemaLambda.cpp
cfe/trunk/test/CodeGenObjC/ubsan-nullability.m
Modified: cfe/trunk/include/clang/Basic/Specifiers.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Specifiers.h?rev=335572&r1=335571&r2=335572&view=diff
==
--- cfe/trunk/include/clang/Basic/Specifiers.h (original)
+++ cfe/trunk/include/clang/Basic/Specifiers.h Mon Jun 25 19:50:04 2018
@@ -294,6 +294,12 @@ namespace clang {
Unspecified
};
+ /// Return true if \p L has a weaker nullability annotation than \p R. The
+ /// ordering is: Unspecified < Nullable < NonNull.
+ inline bool operator<(NullabilityKind L, NullabilityKind R) {
+return uint8_t(L) > uint8_t(R);
+ }
+
/// Retrieve the spelling of the given nullability kind.
llvm::StringRef getNullabilitySpelling(NullabilityKind kind,
bool isContextSensitive = false);
Modified: cfe/trunk/lib/Sema/SemaLambda.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLambda.cpp?rev=335572&r1=335571&r2=335572&view=diff
==
--- cfe/trunk/lib/Sema/SemaLambda.cpp (original)
+++ cfe/trunk/lib/Sema/SemaLambda.cpp Mon Jun 25 19:50:04 2018
@@ -707,8 +707,15 @@ void Sema::deduceClosureReturnType(Captu
QualType ReturnType =
(RetE ? RetE->getType() : Context.VoidTy).getUnqualifiedType();
if (Context.getCanonicalFunctionResultType(ReturnType) ==
- Context.getCanonicalFunctionResultType(CSI.ReturnType))
+ Context.getCanonicalFunctionResultType(CSI.ReturnType)) {
+ // Use the return type with the strictest possible nullability
annotation.
+ auto RetTyNullability = ReturnType->getNullability(Ctx);
+ auto BlockNullability = CSI.ReturnType->getNullability(Ctx);
+ if (BlockNullability &&
+ (!RetTyNullability || *RetTyNullability < *BlockNullability))
+CSI.ReturnType = ReturnType;
continue;
+}
// FIXME: This is a poor diagnostic for ReturnStmts without expressions.
// TODO: It's possible that the *first* return is the divergent one.
Modified: cfe/trunk/test/CodeGenObjC/ubsan-nullability.m
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/ubsan-nullability.m?rev=335572&r1=335571&r2=335572&view=diff
==
--- cfe/trunk/test/CodeGenObjC/ubsan-nullability.m (original)
+++ cfe/trunk/test/CodeGenObjC/ubsan-nullability.m Mon Jun 25 19:50:04 2018
@@ -1,6 +1,6 @@
// REQUIRES: asserts
-// RUN: %clang_cc1 -x objective-c -emit-llvm -triple
x86_64-apple-macosx10.10.0
-fsanitize=nullability-arg,nullability-assign,nullability-return -w %s -o - |
FileCheck %s
-// RUN: %clang_cc1 -x objective-c++ -emit-llvm -triple
x86_64-apple-macosx10.10.0
-fsanitize=nullability-arg,nullability-assign,nullability-return -w %s -o - |
FileCheck %s
+// RUN: %clang_cc1 -x objective-c -emit-llvm -triple
x86_64-apple-macosx10.10.0 -fblocks -fobjc-arc
-fsanitize=nullability-arg,nullability-assign,nullability-return -w %s -o - |
FileCheck %s
+// RUN: %clang_cc1 -x objective-c++ -emit-llvm -triple
x86_64-apple-macosx10.10.0 -fblocks -fobjc-arc
-fsanitize=nullability-arg,nullability-assign,nullability-return -w %s -o - |
FileCheck %s
// CHECK: [[NONNULL_RV_LOC1:@.*]] = private unnamed_addr global {{.*}} i32
100, i32 6
// CHECK: [[NONNULL_ARG_LOC:@.*]] = private unnamed_addr global {{.*}} i32
204, i32 15 {{.*}} i32 190, i32 23
@@ -177,6 +177,37 @@ void call_A(A *a, int *p) {
void dont_crash(int *_Nonnull p, ...) {}
+@protocol NSObject
+- (id)init;
+@end
+@interface NSObject {}
+@end
+
+#pragma clang assume_nonnull begin
+
+/// Create a "NSObject * _Nonnull" instance.
+NSObject *get_nonnull_error() {
+ // Use nil for convenience. The actual object doesn't matter.
+ return (NSObject *)NULL;
+}
+
+NSObject *_Nullable no_null_return_value_diagnostic(int flag) {
+// CHECK-LABEL: define internal
{{.*}}no_null_return_value_diagnostic{{i?}}_block_invoke
+// CHECK-NOT: @__ubsan_handle_nullability_return
+ NSObject *_Nullable (^foo)() = ^() {
+if (flag) {
+ // Clang should not infer a nonnull return value for this block when this
+ // call is present.
r335569 - Implement CFI for indirect calls via a member function pointer.
Author: pcc Date: Mon Jun 25 19:15:47 2018 New Revision: 335569 URL: http://llvm.org/viewvc/llvm-project?rev=335569&view=rev Log: Implement CFI for indirect calls via a member function pointer. Similarly to CFI on virtual and indirect calls, this implementation tries to use program type information to make the checks as precise as possible. The basic way that it works is as follows, where `C` is the name of the class being defined or the target of a call and the function type is assumed to be `void()`. For virtual calls: - Attach type metadata to the addresses of function pointers in vtables (not the functions themselves) of type `void (B::*)()` for each `B` that is a recursive dynamic base class of `C`, including `C` itself. This type metadata has an annotation that the type is for virtual calls (to distinguish it from the non-virtual case). - At the call site, check that the computed address of the function pointer in the vtable has type `void (C::*)()`. For non-virtual calls: - Attach type metadata to each non-virtual member function whose address can be taken with a member function pointer. The type of a function in class `C` of type `void()` is each of the types `void (B::*)()` where `B` is a most-base class of `C`. A most-base class of `C` is defined as a recursive base class of `C`, including `C` itself, that does not have any bases. - At the call site, check that the function pointer has one of the types `void (B::*)()` where `B` is a most-base class of `C`. Differential Revision: https://reviews.llvm.org/D47567 Added: cfe/trunk/test/CodeGenCXX/cfi-mfcall-incomplete.cpp cfe/trunk/test/CodeGenCXX/cfi-mfcall.cpp cfe/trunk/test/CodeGenCXX/type-metadata-memfun.cpp Modified: cfe/trunk/docs/ControlFlowIntegrity.rst cfe/trunk/docs/LTOVisibility.rst cfe/trunk/include/clang/Basic/Sanitizers.def cfe/trunk/lib/CodeGen/CGClass.cpp cfe/trunk/lib/CodeGen/CGVTables.cpp cfe/trunk/lib/CodeGen/CodeGenFunction.h cfe/trunk/lib/CodeGen/CodeGenModule.cpp cfe/trunk/lib/CodeGen/CodeGenModule.h cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp cfe/trunk/lib/Driver/SanitizerArgs.cpp cfe/trunk/lib/Driver/ToolChains/MSVC.cpp cfe/trunk/test/CodeGenCXX/type-metadata.cpp cfe/trunk/test/Driver/fsanitize.c Modified: cfe/trunk/docs/ControlFlowIntegrity.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrity.rst?rev=335569&r1=335568&r2=335569&view=diff == --- cfe/trunk/docs/ControlFlowIntegrity.rst (original) +++ cfe/trunk/docs/ControlFlowIntegrity.rst Mon Jun 25 19:15:47 2018 @@ -66,6 +66,8 @@ Available schemes are: wrong dynamic type. - ``-fsanitize=cfi-icall``: Indirect call of a function with wrong dynamic type. + - ``-fsanitize=cfi-mfcall``: Indirect call via a member function pointer with + wrong dynamic type. You can use ``-fsanitize=cfi`` to enable all the schemes and use ``-fno-sanitize`` flag to narrow down the set of schemes as desired. @@ -255,6 +257,34 @@ the identity of function pointers is mai library boundaries are no different from calls within a single program or shared library. +Member Function Pointer Call Checking += + +This scheme checks that indirect calls via a member function pointer +take place using an object of the correct dynamic type. Specifically, we +check that the dynamic type of the member function referenced by the member +function pointer matches the "function pointer" part of the member function +pointer, and that the member function's class type is related to the base +type of the member function. This CFI scheme can be enabled on its own using +``-fsanitize=cfi-mfcall``. + +The compiler will only emit a full CFI check if the member function pointer's +base type is complete. This is because the complete definition of the base +type contains information that is necessary to correctly compile the CFI +check. To ensure that the compiler always emits a full CFI check, it is +recommended to also pass the flag ``-fcomplete-member-pointers``, which +enables a non-conforming language extension that requires member pointer +base types to be complete if they may be used for a call. + +For this scheme to work, all translation units containing the definition +of a virtual member function (whether inline or not), other than members +of :ref:`blacklisted ` types or types with public :doc:`LTO +visibility `, must be compiled with ``-flto`` or ``-flto=thin`` +enabled and be statically linked into the program. + +This scheme is currently not compatible with cross-DSO CFI or the +Microsoft ABI. + .. _cfi-blacklist: Blacklist Modified: cfe/trunk/docs/LTOVisibility.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LTOVisibility.rst?rev=335569&r1=335568&r2=335569&view=diff == -
[PATCH] D47567: Implement CFI for indirect calls via a member function pointer.
This revision was automatically updated to reflect the committed changes.
Closed by commit rC335569: Implement CFI for indirect calls via a member
function pointer. (authored by pcc, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D47567?vs=151272&id=152819#toc
Repository:
rC Clang
https://reviews.llvm.org/D47567
Files:
docs/ControlFlowIntegrity.rst
docs/LTOVisibility.rst
include/clang/Basic/Sanitizers.def
lib/CodeGen/CGClass.cpp
lib/CodeGen/CGVTables.cpp
lib/CodeGen/CodeGenFunction.h
lib/CodeGen/CodeGenModule.cpp
lib/CodeGen/CodeGenModule.h
lib/CodeGen/ItaniumCXXABI.cpp
lib/Driver/SanitizerArgs.cpp
lib/Driver/ToolChains/MSVC.cpp
test/CodeGenCXX/cfi-mfcall-incomplete.cpp
test/CodeGenCXX/cfi-mfcall.cpp
test/CodeGenCXX/type-metadata-memfun.cpp
test/CodeGenCXX/type-metadata.cpp
test/Driver/fsanitize.c
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -2688,7 +2688,9 @@
SSK = llvm::SanStat_CFI_UnrelatedCast;
break;
case CFITCK_ICall:
-llvm_unreachable("not expecting CFITCK_ICall");
+ case CFITCK_NVMFCall:
+ case CFITCK_VMFCall:
+llvm_unreachable("unexpected sanitizer kind");
}
std::string TypeName = RD->getQualifiedNameAsString();
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -1132,6 +1132,34 @@
return true;
}
+static bool requiresMemberFunctionPointerTypeMetadata(CodeGenModule &CGM,
+ const CXXMethodDecl *MD) {
+ // Check that the type metadata can ever actually be used by a call.
+ if (!CGM.getCodeGenOpts().LTOUnit ||
+ !CGM.HasHiddenLTOVisibility(MD->getParent()))
+return false;
+
+ // Only functions whose address can be taken with a member function pointer
+ // need this sort of type metadata.
+ return !MD->isStatic() && !MD->isVirtual() && !isa(MD) &&
+ !isa(MD);
+}
+
+std::vector
+CodeGenModule::getMostBaseClasses(const CXXRecordDecl *RD) {
+ llvm::SetVector MostBases;
+
+ std::function CollectMostBases;
+ CollectMostBases = [&](const CXXRecordDecl *RD) {
+if (RD->getNumBases() == 0)
+ MostBases.insert(RD);
+for (const CXXBaseSpecifier &B : RD->bases())
+ CollectMostBases(B.getType()->getAsCXXRecordDecl());
+ };
+ CollectMostBases(RD);
+ return MostBases.takeVector();
+}
+
void CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
llvm::Function *F) {
llvm::AttrBuilder B;
@@ -1257,7 +1285,20 @@
// In the cross-dso CFI mode, we want !type attributes on definitions only.
if (CodeGenOpts.SanitizeCfiCrossDso)
if (auto *FD = dyn_cast(D))
- CreateFunctionTypeMetadata(FD, F);
+ CreateFunctionTypeMetadataForIcall(FD, F);
+
+ // Emit type metadata on member functions for member function pointer checks.
+ // These are only ever necessary on definitions; we're guaranteed that the
+ // definition will be present in the LTO unit as a result of LTO visibility.
+ auto *MD = dyn_cast(D);
+ if (MD && requiresMemberFunctionPointerTypeMetadata(*this, MD)) {
+for (const CXXRecordDecl *Base : getMostBaseClasses(MD->getParent())) {
+ llvm::Metadata *Id =
+ CreateMetadataIdentifierForType(Context.getMemberPointerType(
+ MD->getType(), Context.getRecordType(Base).getTypePtr()));
+ F->addTypeMetadata(0, Id);
+}
+ }
}
void CodeGenModule::SetCommonAttributes(GlobalDecl GD, llvm::GlobalValue *GV) {
@@ -1378,13 +1419,14 @@
GV->setLinkage(llvm::GlobalValue::ExternalWeakLinkage);
}
-void CodeGenModule::CreateFunctionTypeMetadata(const FunctionDecl *FD,
- llvm::Function *F) {
+void CodeGenModule::CreateFunctionTypeMetadataForIcall(const FunctionDecl *FD,
+ llvm::Function *F) {
// Only if we are checking indirect calls.
if (!LangOpts.Sanitize.has(SanitizerKind::CFIICall))
return;
- // Non-static class methods are handled via vtable pointer checks elsewhere.
+ // Non-static class methods are handled via vtable or member function pointer
+ // checks elsewhere.
if (isa(FD) && !cast(FD)->isStatic())
return;
@@ -1476,7 +1518,7 @@
// Don't emit entries for function declarations in the cross-DSO mode. This
// is handled with better precision by the receiving DSO.
if (!CodeGenOpts.SanitizeCfiCrossDso)
-CreateFunctionTypeMetadata(FD, F);
+CreateFunctionTypeMetadataForIcall(FD, F);
if (getLangOpts().OpenMP && FD->hasAttr())
getOpenMPRuntime().emitDeclareSimdFunction(FD, F);
@@ -4925,15 +4967,18 @@
}
}
-llvm::Metadata *CodeGenModule::CreateMetadataIdentifierForType(QualType T) {
- llvm::Metadata *&InternalId =
r335564 - [X86] Redefine avx512 packed fpclass intrinsics to return a vXi1 mask and implement the mask input argument using an 'and' IR instruction.
Author: ctopper
Date: Mon Jun 25 17:44:02 2018
New Revision: 335564
URL: http://llvm.org/viewvc/llvm-project?rev=335564&view=rev
Log:
[X86] Redefine avx512 packed fpclass intrinsics to return a vXi1 mask and
implement the mask input argument using an 'and' IR instruction.
Additional IR is emitted to convert between scalar and vXi1 type to match the
expected software inferface for the builtin that clang exposes.
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=335564&r1=335563&r2=335564&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Mon Jun 25 17:44:02 2018
@@ -10120,6 +10120,43 @@ Value *CodeGenFunction::EmitX86BuiltinEx
return Builder.CreateExtractValue(Call, 1);
}
+ case X86::BI__builtin_ia32_fpclassps128_mask:
+ case X86::BI__builtin_ia32_fpclassps256_mask:
+ case X86::BI__builtin_ia32_fpclassps512_mask:
+ case X86::BI__builtin_ia32_fpclasspd128_mask:
+ case X86::BI__builtin_ia32_fpclasspd256_mask:
+ case X86::BI__builtin_ia32_fpclasspd512_mask: {
+unsigned NumElts = Ops[0]->getType()->getVectorNumElements();
+Value *MaskIn = Ops[2];
+Ops.erase(&Ops[2]);
+
+Intrinsic::ID ID;
+switch (BuiltinID) {
+default: llvm_unreachable("Unsupported intrinsic!");
+case X86::BI__builtin_ia32_fpclassps128_mask:
+ ID = Intrinsic::x86_avx512_mask_fpclass_ps_128;
+ break;
+case X86::BI__builtin_ia32_fpclassps256_mask:
+ ID = Intrinsic::x86_avx512_mask_fpclass_ps_256;
+ break;
+case X86::BI__builtin_ia32_fpclassps512_mask:
+ ID = Intrinsic::x86_avx512_mask_fpclass_ps_512;
+ break;
+case X86::BI__builtin_ia32_fpclasspd128_mask:
+ ID = Intrinsic::x86_avx512_mask_fpclass_pd_128;
+ break;
+case X86::BI__builtin_ia32_fpclasspd256_mask:
+ ID = Intrinsic::x86_avx512_mask_fpclass_pd_256;
+ break;
+case X86::BI__builtin_ia32_fpclasspd512_mask:
+ ID = Intrinsic::x86_avx512_mask_fpclass_pd_512;
+ break;
+}
+
+Value *Fpclass = Builder.CreateCall(CGM.getIntrinsic(ID), Ops);
+return EmitX86MaskedCompareResult(*this, Fpclass, NumElts, MaskIn);
+ }
+
// packed comparison intrinsics
case X86::BI__builtin_ia32_cmpeqps:
case X86::BI__builtin_ia32_cmpeqpd:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r335084 - Append new attributes to the end of an AttributeList.
(Sorry for the late reply...)
On Mon, Jun 25, 2018 at 2:45 PM Michael Kruse via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> I just revert if to have further discussions (r335516)
>
> Michael
>
> 2018-06-25 14:58 GMT-05:00 Eric Christopher :
> >
> >
> > On Mon, Jun 25, 2018 at 12:21 PM Richard Smith via cfe-commits
> > wrote:
> >>
> >> On 23 June 2018 at 22:34, Michael Kruse via cfe-commits
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> multiple comments in the code indicate that the attribute order was
> >>> surprising and probably has lead to bugs, and will lead to bugs in the
> >>> future. The order had to be explicitly reversed to avoid those. This
> >>> alone for me this seems a good reason to have the attributes in the
> >>> order in which they appear in the source.
> >>>
> >>> It would be nice it you could send a reproducer. At a glance, your
> >>> case does not seem related since the format strings are function
> >>> arguments, not attributes.
>
Well, there is a nested function call, but the format warning applies to
two different parameters: a singular phrasing string, and a plural one. A
reproducer would look like this, which is almost verbatim from the link:
$ cat /tmp/repro.cc
#include
#include
void foo(){ printf(ngettext("one frobber", "%lu frobbers", 0UL), 0UL); }
$ /bin/clang -Wall -c -o /dev/null /tmp/repro.cc
/tmp/repro.cc:4:66: warning: data argument not used by format string
[-Wformat-extra-args]
void foo(){ printf(ngettext("one frobber", "%lu frobbers", 0UL), 0UL); }
~^
1 warning generated.
Swapping the string params works, and an older revision yields inverse
results.
> >>> 2018-06-23 17:17 GMT-05:00 David Jones :
> >>> > Since the semantics of the ordering of multiple format args seems
> >>> > somewhat
> >>> > ill-defined, it seems to me like reverting may be the best near-term
> >>> > choice.
> >>> > I can imagine other ways to fix the diagnostic, but the only
> behaviour
> >>> > that
> >>> > I would believe to be expected by existing code is the old one, so a
> >>> > change
> >>> > like this one probably needs to be more carefully vetted before being
> >>> > (re-)committed.
> >>>
> >>> Could you give more details about your concerns?
>
Multiple format strings (or repeating or reordering other attributes) seems
like it lacks clear semantics. I can't find any particularly
well-documented explanation of Clang's behaviour in these cases, which
makes me suspect that most people would just "fix it until it works" and
move on. GCC's documentation doesn't seem to be very decisive, either.
For example, you mentioned that multiple format attributes may be invalid;
if so, then rejecting such cases should probably be a part of the fix. But
that would require some vetting, since this (pretty clearly) doesn't mirror
the current reality.
>> (I'm not sure what the problem is, but as a data point, Sema::checkCall
> >> iterates over the FormatAttrs in order, so it's possible that changing
> the
> >> order may have triggered a new warning. That may be due to a
> pre-existing
> >> order-dependence bug, or it may be that we're losing an attribute here.)
>
It's arguably a pre-existing order dependence bug in ngettext, but it would
be ... well, a fairly prevalent bug, since it could churn any such calls
through libintl/gettext/etc.
> >>> > Please let me know your plan. (If I don't hear back in a day or so,
> >>> > I'll go
> >>> > ahead and revert for you as the safe default course of action.)
> >>>
> >>> On a weekend?
> >>
> >>
> >> Yes; our policy is generally to revert to green if a patch causes
> >> regressions that aren't going to be fixed in a few hours. This is
> generally
> >> good for the committer, because it lets you figure out what's wrong and
> deal
> >> with it on your own schedule rather than being pressured to fix it
> urgently
> >> because you're blocking the work of others.
Well, the bug did repro on a weekend, so there's that. ;-)
My main goal was to give a tighter response timeout to account for any
timezone drift (with a target of Monday ~everywhere).
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48459: Respect CMAKE_SYSROOT and CMAKE_CROSSCOMPILING when searching for libxml2.
smeenai added a comment. Okay, upon playing with this further, the following seems to do what I want (for a custom sysroot), and seems to be a pretty common pattern as well: set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) Repository: rC Clang https://reviews.llvm.org/D48459 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48459: Respect CMAKE_SYSROOT and CMAKE_CROSSCOMPILING when searching for libxml2.
smeenai added a comment. Ah, the documentation is confusing, but CMAKE_FIND_ROOT_PATH and CMAKE_FIND_ROOT_PATH_MODE_PACKAGE only have an effect when using the config mode of find_package, whereas this invocation is using the module mode. That's a bummer, and definitely makes custom sysroots and cross-compilation harder than it should be. Sorry for the noise. Repository: rC Clang https://reviews.llvm.org/D48459 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48204: [analyzer] Make getDerefExpr() skip cleanups.
This revision was automatically updated to reflect the committed changes.
Closed by commit rC335559: [analyzer] Track null and undef values through
expressions with cleanups. (authored by dergachev, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D48204?vs=151450&id=152810#toc
Repository:
rC Clang
https://reviews.llvm.org/D48204
Files:
lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
test/Analysis/inlining/inline-defensive-checks.cpp
Index: test/Analysis/inlining/inline-defensive-checks.cpp
===
--- test/Analysis/inlining/inline-defensive-checks.cpp
+++ test/Analysis/inlining/inline-defensive-checks.cpp
@@ -84,3 +84,20 @@
int &x = b->x; // no-warning
x = 5;
}
+
+namespace get_deref_expr_with_cleanups {
+struct S {
+~S();
+};
+S *conjure();
+// The argument won't be used, but it'll cause cleanups
+// to appear around the call site.
+S *get_conjured(S _) {
+ S *s = conjure();
+ if (s) {}
+ return s;
+}
+void test_conjured() {
+ S &s = *get_conjured(S()); // no-warning
+}
+} // namespace get_deref_expr_with_cleanups
Index: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -141,6 +141,8 @@
E = AE->getBase();
} else if (const auto *PE = dyn_cast(E)) {
E = PE->getSubExpr();
+} else if (const auto *EWC = dyn_cast(E)) {
+ E = EWC->getSubExpr();
} else {
// Other arbitrary stuff.
break;
Index: test/Analysis/inlining/inline-defensive-checks.cpp
===
--- test/Analysis/inlining/inline-defensive-checks.cpp
+++ test/Analysis/inlining/inline-defensive-checks.cpp
@@ -84,3 +84,20 @@
int &x = b->x; // no-warning
x = 5;
}
+
+namespace get_deref_expr_with_cleanups {
+struct S {
+~S();
+};
+S *conjure();
+// The argument won't be used, but it'll cause cleanups
+// to appear around the call site.
+S *get_conjured(S _) {
+ S *s = conjure();
+ if (s) {}
+ return s;
+}
+void test_conjured() {
+ S &s = *get_conjured(S()); // no-warning
+}
+} // namespace get_deref_expr_with_cleanups
Index: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -141,6 +141,8 @@
E = AE->getBase();
} else if (const auto *PE = dyn_cast(E)) {
E = PE->getSubExpr();
+} else if (const auto *EWC = dyn_cast(E)) {
+ E = EWC->getSubExpr();
} else {
// Other arbitrary stuff.
break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335559 - [analyzer] Track null and undef values through expressions with cleanups.
Author: dergachev
Date: Mon Jun 25 16:55:07 2018
New Revision: 335559
URL: http://llvm.org/viewvc/llvm-project?rev=335559&view=rev
Log:
[analyzer] Track null and undef values through expressions with cleanups.
ExprWithCleanups wraps full-expressions that require temporary destructors
and highlights the moment of time in which these destructors need to be called
(i.e., "at the end of the full-expression...").
Such expressions don't necessarily return an object; they may return anything,
including a null or undefined value.
When the analyzer tries to understand where the null or undefined value came
from in order to present better diagnostics to the user, it will now skip
any ExprWithCleanups it encounters and look into the expression itself.
Differential Revision: https://reviews.llvm.org/D48204
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
cfe/trunk/test/Analysis/inlining/inline-defensive-checks.cpp
Modified: cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp?rev=335559&r1=335558&r2=335559&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp Mon Jun 25
16:55:07 2018
@@ -141,6 +141,8 @@ const Expr *bugreporter::getDerefExpr(co
E = AE->getBase();
} else if (const auto *PE = dyn_cast(E)) {
E = PE->getSubExpr();
+} else if (const auto *EWC = dyn_cast(E)) {
+ E = EWC->getSubExpr();
} else {
// Other arbitrary stuff.
break;
Modified: cfe/trunk/test/Analysis/inlining/inline-defensive-checks.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/inlining/inline-defensive-checks.cpp?rev=335559&r1=335558&r2=335559&view=diff
==
--- cfe/trunk/test/Analysis/inlining/inline-defensive-checks.cpp (original)
+++ cfe/trunk/test/Analysis/inlining/inline-defensive-checks.cpp Mon Jun 25
16:55:07 2018
@@ -84,3 +84,20 @@ void testRefToField(Bar *b) {
int &x = b->x; // no-warning
x = 5;
}
+
+namespace get_deref_expr_with_cleanups {
+struct S {
+~S();
+};
+S *conjure();
+// The argument won't be used, but it'll cause cleanups
+// to appear around the call site.
+S *get_conjured(S _) {
+ S *s = conjure();
+ if (s) {}
+ return s;
+}
+void test_conjured() {
+ S &s = *get_conjured(S()); // no-warning
+}
+} // namespace get_deref_expr_with_cleanups
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47953: [builtin] Add bitfield support for __builtin_dump_struct
dblaikie added a comment.
This doesn't seem to build for me - so hard to debug/probe it:
llvm/src/tools/clang/lib/CodeGen/CGBuiltin.cpp:1264:65: error: no viable
conversion from 'clang::QualType' to 'llvm::Type *'
CGF.CGM.getDataLayout().getTypeSizeInBits(CanonicalType),
^
llvm/src/include/llvm/IR/DataLayout.h:560:53: note: passing argument to
parameter 'Ty' here
inline uint64_t DataLayout::getTypeSizeInBits(Type *Ty) const {
^
1 error generated.
Repository:
rC Clang
https://reviews.llvm.org/D47953
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48205: [analyzer] Assert that nonloc::SymbolVal always wraps a non-Loc-type symbol.
NoQ added inline comments. Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:1241 if (const llvm::APSInt *I = - SVB.getKnownValue(State, nonloc::SymbolVal(S))) + SVB.getKnownValue(State, SVB.makeSymbolVal(S))) return Loc::isLocType(S->getType()) ? (SVal)SVB.makeIntLocVal(*I) NoQ wrote: > george.karpenkov wrote: > > So what is the difference here? That `SVB.makeSymbolVal` is not always a > > nonloc? > That's right; it will be a symbolic region instead. > > It won't affect the result of the calculation though (hopefully) (in the > current implementation). I mean, it will *sometimes* be a symbolic region (when the symbol is of pointer type). Repository: rC Clang https://reviews.llvm.org/D48205 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48205: [analyzer] Assert that nonloc::SymbolVal always wraps a non-Loc-type symbol.
NoQ added inline comments. Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:1241 if (const llvm::APSInt *I = - SVB.getKnownValue(State, nonloc::SymbolVal(S))) + SVB.getKnownValue(State, SVB.makeSymbolVal(S))) return Loc::isLocType(S->getType()) ? (SVal)SVB.makeIntLocVal(*I) george.karpenkov wrote: > So what is the difference here? That `SVB.makeSymbolVal` is not always a > nonloc? That's right; it will be a symbolic region instead. It won't affect the result of the calculation though (hopefully) (in the current implementation). Repository: rC Clang https://reviews.llvm.org/D48205 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335555 - [analyzer] Fix invalidation on C++ const methods with arrow syntax.
Author: dergachev
Date: Mon Jun 25 16:43:45 2018
New Revision: 33
URL: http://llvm.org/viewvc/llvm-project?rev=33&view=rev
Log:
[analyzer] Fix invalidation on C++ const methods with arrow syntax.
Conservative evaluation of a C++ method call would invalidate the object,
as long as the method is not const or the object has mutable fields.
When checking for mutable fields, we need to scan the type of the object on
which the method is called, which may be more specific than the type of the
object on which the method is defined, hence we look up the type from the
this-argument expression.
If arrow syntax or implicit-this syntax is used, this-argument expression
has pointer type, not record type, and lookup accidentally failed for that
reason. Obtain object type correctly.
Differential Revision: https://reviews.llvm.org/D48460
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
cfe/trunk/test/Analysis/const-method-call.cpp
Modified: cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp?rev=33&r1=335554&r2=33&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp Mon Jun 25 16:43:45 2018
@@ -534,9 +534,14 @@ void CXXInstanceCall::getExtraInvalidate
// Get the record decl for the class of 'This'. D->getParent() may return a
// base class decl, rather than the class of the instance which needs to be
// checked for mutable fields.
+// TODO: We might as well look at the dynamic type of the object.
const Expr *Ex = getCXXThisExpr()->ignoreParenBaseCasts();
-const CXXRecordDecl *ParentRecord = Ex->getType()->getAsCXXRecordDecl();
-if (!ParentRecord || ParentRecord->hasMutableFields())
+QualType T = Ex->getType();
+if (T->isPointerType()) // Arrow or implicit-this syntax?
+ T = T->getPointeeType();
+const CXXRecordDecl *ParentRecord = T->getAsCXXRecordDecl();
+assert(ParentRecord);
+if (ParentRecord->hasMutableFields())
return;
// Preserve CXXThis.
const MemRegion *ThisRegion = ThisVal.getAsRegion();
Modified: cfe/trunk/test/Analysis/const-method-call.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/const-method-call.cpp?rev=33&r1=335554&r2=33&view=diff
==
--- cfe/trunk/test/Analysis/const-method-call.cpp (original)
+++ cfe/trunk/test/Analysis/const-method-call.cpp Mon Jun 25 16:43:45 2018
@@ -6,6 +6,14 @@ struct A {
int x;
void foo() const;
void bar();
+
+ void testImplicitThisSyntax() {
+x = 3;
+foo();
+clang_analyzer_eval(x == 3); // expected-warning{{TRUE}}
+bar();
+clang_analyzer_eval(x == 3); // expected-warning{{UNKNOWN}}
+ }
};
struct B {
@@ -108,6 +116,22 @@ void checkThatContainedConstMethodDoesNo
clang_analyzer_eval(t.in.x == 2); // expected-warning{{TRUE}}
}
+void checkPointerTypedThisExpression(A *a) {
+ a->x = 3;
+ a->foo();
+ clang_analyzer_eval(a->x == 3); // expected-warning{{TRUE}}
+ a->bar();
+ clang_analyzer_eval(a->x == 3); // expected-warning{{UNKNOWN}}
+}
+
+void checkReferenceTypedThisExpression(A &a) {
+ a.x = 3;
+ a.foo();
+ clang_analyzer_eval(a.x == 3); // expected-warning{{TRUE}}
+ a.bar();
+ clang_analyzer_eval(a.x == 3); // expected-warning{{UNKNOWN}}
+}
+
// --- Versions of the above tests where the const method is inherited --- //
struct B1 {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48460: [analyzer] Fix invalidation on C++ const methods.
This revision was automatically updated to reflect the committed changes.
Closed by commit rC33: [analyzer] Fix invalidation on C++ const methods
with arrow syntax. (authored by dergachev, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D48460?vs=152391&id=152805#toc
Repository:
rC Clang
https://reviews.llvm.org/D48460
Files:
lib/StaticAnalyzer/Core/CallEvent.cpp
test/Analysis/const-method-call.cpp
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -534,9 +534,14 @@
// Get the record decl for the class of 'This'. D->getParent() may return a
// base class decl, rather than the class of the instance which needs to be
// checked for mutable fields.
+// TODO: We might as well look at the dynamic type of the object.
const Expr *Ex = getCXXThisExpr()->ignoreParenBaseCasts();
-const CXXRecordDecl *ParentRecord = Ex->getType()->getAsCXXRecordDecl();
-if (!ParentRecord || ParentRecord->hasMutableFields())
+QualType T = Ex->getType();
+if (T->isPointerType()) // Arrow or implicit-this syntax?
+ T = T->getPointeeType();
+const CXXRecordDecl *ParentRecord = T->getAsCXXRecordDecl();
+assert(ParentRecord);
+if (ParentRecord->hasMutableFields())
return;
// Preserve CXXThis.
const MemRegion *ThisRegion = ThisVal.getAsRegion();
Index: test/Analysis/const-method-call.cpp
===
--- test/Analysis/const-method-call.cpp
+++ test/Analysis/const-method-call.cpp
@@ -6,6 +6,14 @@
int x;
void foo() const;
void bar();
+
+ void testImplicitThisSyntax() {
+x = 3;
+foo();
+clang_analyzer_eval(x == 3); // expected-warning{{TRUE}}
+bar();
+clang_analyzer_eval(x == 3); // expected-warning{{UNKNOWN}}
+ }
};
struct B {
@@ -108,6 +116,22 @@
clang_analyzer_eval(t.in.x == 2); // expected-warning{{TRUE}}
}
+void checkPointerTypedThisExpression(A *a) {
+ a->x = 3;
+ a->foo();
+ clang_analyzer_eval(a->x == 3); // expected-warning{{TRUE}}
+ a->bar();
+ clang_analyzer_eval(a->x == 3); // expected-warning{{UNKNOWN}}
+}
+
+void checkReferenceTypedThisExpression(A &a) {
+ a.x = 3;
+ a.foo();
+ clang_analyzer_eval(a.x == 3); // expected-warning{{TRUE}}
+ a.bar();
+ clang_analyzer_eval(a.x == 3); // expected-warning{{UNKNOWN}}
+}
+
// --- Versions of the above tests where the const method is inherited --- //
struct B1 {
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -534,9 +534,14 @@
// Get the record decl for the class of 'This'. D->getParent() may return a
// base class decl, rather than the class of the instance which needs to be
// checked for mutable fields.
+// TODO: We might as well look at the dynamic type of the object.
const Expr *Ex = getCXXThisExpr()->ignoreParenBaseCasts();
-const CXXRecordDecl *ParentRecord = Ex->getType()->getAsCXXRecordDecl();
-if (!ParentRecord || ParentRecord->hasMutableFields())
+QualType T = Ex->getType();
+if (T->isPointerType()) // Arrow or implicit-this syntax?
+ T = T->getPointeeType();
+const CXXRecordDecl *ParentRecord = T->getAsCXXRecordDecl();
+assert(ParentRecord);
+if (ParentRecord->hasMutableFields())
return;
// Preserve CXXThis.
const MemRegion *ThisRegion = ThisVal.getAsRegion();
Index: test/Analysis/const-method-call.cpp
===
--- test/Analysis/const-method-call.cpp
+++ test/Analysis/const-method-call.cpp
@@ -6,6 +6,14 @@
int x;
void foo() const;
void bar();
+
+ void testImplicitThisSyntax() {
+x = 3;
+foo();
+clang_analyzer_eval(x == 3); // expected-warning{{TRUE}}
+bar();
+clang_analyzer_eval(x == 3); // expected-warning{{UNKNOWN}}
+ }
};
struct B {
@@ -108,6 +116,22 @@
clang_analyzer_eval(t.in.x == 2); // expected-warning{{TRUE}}
}
+void checkPointerTypedThisExpression(A *a) {
+ a->x = 3;
+ a->foo();
+ clang_analyzer_eval(a->x == 3); // expected-warning{{TRUE}}
+ a->bar();
+ clang_analyzer_eval(a->x == 3); // expected-warning{{UNKNOWN}}
+}
+
+void checkReferenceTypedThisExpression(A &a) {
+ a.x = 3;
+ a.foo();
+ clang_analyzer_eval(a.x == 3); // expected-warning{{TRUE}}
+ a.bar();
+ clang_analyzer_eval(a.x == 3); // expected-warning{{UNKNOWN}}
+}
+
// --- Versions of the above tests where the const method is inherited --- //
struct B1 {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48459: Respect CMAKE_SYSROOT and CMAKE_CROSSCOMPILING when searching for libxml2.
smeenai added a comment. Actually, I would imagine that if you're cross-compiling or using a custom sysroot, you should probably also specify CMAKE_FIND_ROOT_PATH and set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY, to limit all these searches to the desired directories? (I'm actually playing around with a bunch of this stuff myself right now. I'm curious about your CMake setup for a custom sysroot or cross-compilation and what issues you've come across.) Repository: rC Clang https://reviews.llvm.org/D48459 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48524: [ODRHash] Do not put elaborated types in the TypeMap
rtrieu added a comment. Running this, I see that it causes a regression in one of the other ODR Hash tests. Specifically, the diagnostics on line 1150 & 1151 of test/Modules/odr_hash.cpp are not seen. Was that an expected side-effect of this patch? Repository: rC Clang https://reviews.llvm.org/D48524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335546 - Add an option to support debug fission on implicit ThinLTO.
Author: yunlian
Date: Mon Jun 25 16:05:27 2018
New Revision: 335546
URL: http://llvm.org/viewvc/llvm-project?rev=335546&view=rev
Log:
Add an option to support debug fission on implicit ThinLTO.
Summary:
This adds an option -gsplit-dwarf=. LLVM can create .dwo files in the
given directory
during the implicit ThinLTO link stage.
Reviewers: tejohnson, dblaikie, pcc
Reviewed By: pcc
Subscribers: steven_wu, aprantl, JDevlieghere, yunlian, probinson, mehdi_amini,
inglorion, cfe-commits
Differential Revision: https://reviews.llvm.org/D44788
Added:
cfe/trunk/test/Driver/lto-dwo.c
Modified:
cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
Modified: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp?rev=335546&r1=335545&r2=335546&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp Mon Jun 25 16:05:27 2018
@@ -416,6 +416,12 @@ void tools::AddGoldPlugin(const ToolChai
CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=O") + OOpt));
}
+ if (Args.hasArg(options::OPT_gsplit_dwarf)) {
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") +
+Output.getFilename() + "_dwo"));
+ }
+
if (IsThinLTO)
CmdArgs.push_back("-plugin-opt=thinlto");
Added: cfe/trunk/test/Driver/lto-dwo.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/lto-dwo.c?rev=335546&view=auto
==
--- cfe/trunk/test/Driver/lto-dwo.c (added)
+++ cfe/trunk/test/Driver/lto-dwo.c Mon Jun 25 16:05:27 2018
@@ -0,0 +1,6 @@
+// Confirm that -gsplit-dwarf=DIR is passed to linker
+
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -gsplit-dwarf
-o a.out 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-DWO-DIR-DEFAULT < %t %s
+//
+// CHECK-LINK-DWO-DIR-DEFAULT: "-plugin-opt=dwo_dir=a.out_dwo"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335549 - [MachineOutliner] NFC - simplify -moutline/-mno-outline logic
Author: paquette
Date: Mon Jun 25 16:20:18 2018
New Revision: 335549
URL: http://llvm.org/viewvc/llvm-project?rev=335549&view=rev
Log:
[MachineOutliner] NFC - simplify -moutline/-mno-outline logic
It's a bit cleaner to use `hasFlag` instead of nested ifs. This
just refactors the -moutline/-mno-outline logic to use that.
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=335549&r1=335548&r2=335549&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Jun 25 16:20:18 2018
@@ -1477,19 +1477,16 @@ void Clang::AddAArch64TargetArgs(const A
CmdArgs.push_back("-aarch64-enable-global-merge=true");
}
- if (Arg *A = Args.getLastArg(options::OPT_moutline,
- options::OPT_mno_outline)) {
-if (A->getOption().matches(options::OPT_moutline)) {
- CmdArgs.push_back("-mllvm");
- CmdArgs.push_back("-enable-machine-outliner");
+ if (Args.hasFlag(options::OPT_moutline, options::OPT_mno_outline, false)) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-enable-machine-outliner");
- // The outliner shouldn't compete with linkers that dedupe linkonceodr
- // functions in LTO. Enable that behaviour by default when compiling with
- // LTO.
- if (getToolChain().getDriver().isUsingLTO()) {
-CmdArgs.push_back("-mllvm");
-CmdArgs.push_back("-enable-linkonceodr-outlining");
- }
+// The outliner shouldn't compete with linkers that dedupe linkonceodr
+// functions in LTO. Enable that behaviour by default when compiling with
+// LTO.
+if (getToolChain().getDriver().isUsingLTO()) {
+ CmdArgs.push_back("-mllvm");
+ CmdArgs.push_back("-enable-linkonceodr-outlining");
}
}
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D45454: Make __gcov_flush visible outside a shared library
I don't have an objection having another interface which is just a simple wrapper to __gcov_flush but with default visibility. Also clearly document its usage and behavior. David On Mon, Jun 25, 2018 at 10:12 AM, Chih-Hung Hsieh via Phabricator via llvm-commits wrote: > chh added a comment. > > In https://reviews.llvm.org/D45454#1142197, @marco-c wrote: > > > In https://reviews.llvm.org/D45454#1070884, @belleyb wrote: > > > > > @chh I had a chance to try out your proposed changes. It's not causing > us any trouble. In fact, `__gcov_flush()` is not even used at all (at least > in LLVM 5.0.1).. I can recompile llvm, compiler_rt and clang and re-run all > the tests with `__gcov_flush` commented out! No problem. > > > > > > I would suggest adding a bit more documentation to `__gcov_flush()`, > thus describing what those "special cases" are... > > > > > > __gcov_flush is only used if you actually call it (it's needed for > example if you want to profile only part of your program). > > > > In GCC, __gcov_flush is not hidden, so perhaps we should do the same to > keep the same behavior? I've also submitted https://reviews.llvm.org/ > D48538, which is making __gcov_flush flush counters for all shared > libraries (like GCC does, with the same caveat: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879). > > > I have no problem keeping these functions compatible with GCC. > My earlier proposal and David's comment in the mailing list seemed to be > lost and not showing here. > So, let me summarize the case here. This change should make `__gcov_flush` > not hidden as before in GCC, > but earlier change made it hidden as well as other `llvm_gov_*` functions. > Could we have both `__gov_flush` and `llvm_gov_flush` functions, one > unhidden and one hidden? > > > https://reviews.llvm.org/D45454 > > > > ___ > llvm-commits mailing list > llvm-comm...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335546: Add an option to support debug fission on implicit
ThinLTO. (authored by yunlian, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D44788?vs=152794&id=152797#toc
Repository:
rL LLVM
https://reviews.llvm.org/D44788
Files:
cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
cfe/trunk/test/Driver/lto-dwo.c
Index: cfe/trunk/test/Driver/lto-dwo.c
===
--- cfe/trunk/test/Driver/lto-dwo.c
+++ cfe/trunk/test/Driver/lto-dwo.c
@@ -0,0 +1,6 @@
+// Confirm that -gsplit-dwarf=DIR is passed to linker
+
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -gsplit-dwarf
-o a.out 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-DWO-DIR-DEFAULT < %t %s
+//
+// CHECK-LINK-DWO-DIR-DEFAULT: "-plugin-opt=dwo_dir=a.out_dwo"
Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -416,6 +416,12 @@
CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=O") + OOpt));
}
+ if (Args.hasArg(options::OPT_gsplit_dwarf)) {
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") +
+Output.getFilename() + "_dwo"));
+ }
+
if (IsThinLTO)
CmdArgs.push_back("-plugin-opt=thinlto");
Index: cfe/trunk/test/Driver/lto-dwo.c
===
--- cfe/trunk/test/Driver/lto-dwo.c
+++ cfe/trunk/test/Driver/lto-dwo.c
@@ -0,0 +1,6 @@
+// Confirm that -gsplit-dwarf=DIR is passed to linker
+
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -gsplit-dwarf -o a.out 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-DWO-DIR-DEFAULT < %t %s
+//
+// CHECK-LINK-DWO-DIR-DEFAULT: "-plugin-opt=dwo_dir=a.out_dwo"
Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -416,6 +416,12 @@
CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=O") + OOpt));
}
+ if (Args.hasArg(options::OPT_gsplit_dwarf)) {
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") +
+Output.getFilename() + "_dwo"));
+ }
+
if (IsThinLTO)
CmdArgs.push_back("-plugin-opt=thinlto");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48100: Append new attributes to the end of an AttributeList.
Meinersbur added a comment. In https://reviews.llvm.org/D48100#1142866, @erichkeane wrote: > I'm currently attempting to remove the AttributeList's linked-listness. Thank you. This should also resolve the non-optimal asymptotic execution time to append new attributes at the end of the list. Repository: rC Clang https://reviews.llvm.org/D48100 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48570: [Driver] Do not add -lpthread & -lrt with -static-libsan on Android
srhines accepted this revision. srhines added a comment. Agree. This is the first time anyone is linking against static sanitizers on Android, so this is just something that we missed updating in the past. Repository: rC Clang https://reviews.llvm.org/D48570 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.
pcc accepted this revision. pcc added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D44788 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.
yunlian updated this revision to Diff 152794.
https://reviews.llvm.org/D44788
Files:
lib/Driver/ToolChains/CommonArgs.cpp
test/Driver/lto-dwo.c
Index: test/Driver/lto-dwo.c
===
--- /dev/null
+++ test/Driver/lto-dwo.c
@@ -0,0 +1,6 @@
+// Confirm that -gsplit-dwarf=DIR is passed to linker
+
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -gsplit-dwarf
-o a.out 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-DWO-DIR-DEFAULT < %t %s
+//
+// CHECK-LINK-DWO-DIR-DEFAULT: "-plugin-opt=dwo_dir=a.out_dwo"
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -416,6 +416,12 @@
CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=O") + OOpt));
}
+ if (Args.hasArg(options::OPT_gsplit_dwarf)) {
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") +
+Output.getFilename() + "_dwo"));
+ }
+
if (IsThinLTO)
CmdArgs.push_back("-plugin-opt=thinlto");
Index: test/Driver/lto-dwo.c
===
--- /dev/null
+++ test/Driver/lto-dwo.c
@@ -0,0 +1,6 @@
+// Confirm that -gsplit-dwarf=DIR is passed to linker
+
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -gsplit-dwarf -o a.out 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-DWO-DIR-DEFAULT < %t %s
+//
+// CHECK-LINK-DWO-DIR-DEFAULT: "-plugin-opt=dwo_dir=a.out_dwo"
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -416,6 +416,12 @@
CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=O") + OOpt));
}
+ if (Args.hasArg(options::OPT_gsplit_dwarf)) {
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") +
+Output.getFilename() + "_dwo"));
+ }
+
if (IsThinLTO)
CmdArgs.push_back("-plugin-opt=thinlto");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.
vsapsai added a comment. Ping. https://reviews.llvm.org/D48342 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47341: [Sema] Fix infinite typo correction loop.
vsapsai added a comment. Ping. https://reviews.llvm.org/D47341 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47301: Warning for framework include violation from Headers to PrivateHeaders
bruno closed this revision. bruno added a comment. Committed r335542 https://reviews.llvm.org/D47301 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335543 - Fix tests from r335542 to use %hmaptool
Author: bruno Date: Mon Jun 25 15:25:48 2018 New Revision: 335543 URL: http://llvm.org/viewvc/llvm-project?rev=335543&view=rev Log: Fix tests from r335542 to use %hmaptool Modified: cfe/trunk/test/Modules/framework-public-includes-private.m Modified: cfe/trunk/test/Modules/framework-public-includes-private.m URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/framework-public-includes-private.m?rev=335543&r1=335542&r2=335543&view=diff == --- cfe/trunk/test/Modules/framework-public-includes-private.m (original) +++ cfe/trunk/test/Modules/framework-public-includes-private.m Mon Jun 25 15:25:48 2018 @@ -3,8 +3,8 @@ // RUN: rm -rf %t // RUN: mkdir %t -// RUN: hmaptool write %S/Inputs/framework-public-includes-private/a.hmap.json %t/a.hmap -// RUN: hmaptool write %S/Inputs/framework-public-includes-private/z.hmap.json %t/z.hmap +// RUN: %hmaptool write %S/Inputs/framework-public-includes-private/a.hmap.json %t/a.hmap +// RUN: %hmaptool write %S/Inputs/framework-public-includes-private/z.hmap.json %t/z.hmap // RUN: sed -e "s:TEST_DIR:%S/Inputs/framework-public-includes-private:g" \ // RUN: %S/Inputs/framework-public-includes-private/z.yaml > %t/z.yaml ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48574: OpenBSD driver needs ld.lld in sanitiser context
devnexen created this revision.
devnexen added a reviewer: dberris.
devnexen created this object with visibility "All Users".
Herald added a subscriber: cfe-commits.
- Base GNU ld is pretty old and does not support --dynamic-list flag.
- For conveniency we can add it automatically when compile with ubsan sanitiser.
Repository:
rC Clang
https://reviews.llvm.org/D48574
Files:
lib/Driver/ToolChains/OpenBSD.cpp
Index: lib/Driver/ToolChains/OpenBSD.cpp
===
--- lib/Driver/ToolChains/OpenBSD.cpp
+++ lib/Driver/ToolChains/OpenBSD.cpp
@@ -230,7 +230,9 @@
Args.MakeArgString(getToolChain().GetFilePath("crtendS.o")));
}
- const char *Exec = Args.MakeArgString(getToolChain().GetLinkerPath());
+ const char *Exec = Args.MakeArgString(
+ !NeedsSanitizerDeps ? getToolChain().GetLinkerPath()
+ : getToolChain().GetProgramPath("ld.lld"));
C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
}
Index: lib/Driver/ToolChains/OpenBSD.cpp
===
--- lib/Driver/ToolChains/OpenBSD.cpp
+++ lib/Driver/ToolChains/OpenBSD.cpp
@@ -230,7 +230,9 @@
Args.MakeArgString(getToolChain().GetFilePath("crtendS.o")));
}
- const char *Exec = Args.MakeArgString(getToolChain().GetLinkerPath());
+ const char *Exec = Args.MakeArgString(
+ !NeedsSanitizerDeps ? getToolChain().GetLinkerPath()
+ : getToolChain().GetProgramPath("ld.lld"));
C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335542 - Warning for framework include violation from Headers to PrivateHeaders
Author: bruno
Date: Mon Jun 25 15:24:17 2018
New Revision: 335542
URL: http://llvm.org/viewvc/llvm-project?rev=335542&view=rev
Log:
Warning for framework include violation from Headers to PrivateHeaders
Framework vendors usually layout their framework headers in the
following way:
Foo.framework/Headers -> "public" headers
Foo.framework/PrivateHeader -> "private" headers
Since both headers in both directories can be found with #import
, it's easy to make mistakes and include headers in
Foo.framework/PrivateHeader from headers in Foo.framework/Headers, which
usually configures a layering violation on Darwin ecosystems. One of the
problem this causes is dep cycles when modules are used, since it's very
common for "private" modules to include from the "public" ones; adding
an edge the other way around will trigger cycles.
Add a warning to catch those cases such that:
./A.framework/Headers/A.h:1:10: warning: public framework header includes
private framework header 'A/APriv.h'
#include
^
rdar://problem/38712182
Added:
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/Headers/
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/Headers/A.h
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/Modules/
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/Modules/module.modulemap
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/Modules/module.private.modulemap
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/PrivateHeaders/
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/PrivateHeaders/APriv.h
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/A.framework/PrivateHeaders/APriv2.h
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/a.hmap.json
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/flat-header-path/
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/flat-header-path/Z.h
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/flat-header-path/Z.modulemap
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/flat-header-path/Z.private.modulemap
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/flat-header-path/ZPriv.h
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/z.hmap.json
cfe/trunk/test/Modules/Inputs/framework-public-includes-private/z.yaml
cfe/trunk/test/Modules/framework-public-includes-private.m
Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
cfe/trunk/lib/Lex/HeaderSearch.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=335542&r1=335541&r2=335542&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Jun 25 15:24:17 2018
@@ -32,6 +32,8 @@ def Availability : DiagGroup<"availabili
def Section : DiagGroup<"section">;
def AutoImport : DiagGroup<"auto-import">;
def FrameworkHdrQuotedInclude :
DiagGroup<"quoted-include-in-framework-header">;
+def FrameworkIncludePrivateFromPublic :
+ DiagGroup<"framework-include-private-from-public">;
def CXX14BinaryLiteral : DiagGroup<"c++14-binary-literal">;
def CXXPre14CompatBinaryLiteral :
DiagGroup<"c++98-c++11-compat-binary-literal">;
def GNUBinaryLiteral : DiagGroup<"gnu-binary-literal">;
Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=335542&r1=335541&r2=335542&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Mon Jun 25 15:24:17 2018
@@ -718,6 +718,9 @@ def warn_quoted_include_in_framework_hea
"double-quoted include \"%0\" in framework header, "
"expected angle-bracketed instead"
>, InGroup, DefaultIgnore;
+def warn_framework_include_private_from_public : Warning<
+ "public framework header includes private framework header '%0'"
+ >, InGroup;
def warn_auto_module_import : Warning<
"treating #%select{include|import|include_next|__include_macros}0 as an "
Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=335542&r1=335541&r2=335542&view=diff
==
--- cfe/trunk/lib/
[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called
ahatanak added a comment. Yes, that is the case. It doesn't change overloading resolution, it is just producing a diagnostic. Repository: rC Clang https://reviews.llvm.org/D47757 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.
yunlian marked 2 inline comments as done. yunlian added a comment. ping? https://reviews.llvm.org/D44788 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called
jlebar added a comment. In https://reviews.llvm.org/D47757#1142886, @ahatanak wrote: > I mean ToT clang (without my patch applied) seems to select the non-sized > host version 'T::operator delete(void*)'. OK, if this is just making an error out of something which previously silently didn't work (and should result in a compile error further down the line when we try to and can't resolve that function), then this is totally fine. Repository: rC Clang https://reviews.llvm.org/D47757 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r335022 - Revert r335019 "Update NRVO logic to support early return (Attempt 2)"
Whenever possible, do include context for why a patch is being reverted in
the commit message - buildbot links, but also potentially
describing/copy-pasting inline whatever the problem(s) are. This makes it
easier for people tracking the state of upstream to know whether they may
need to pull in this patch revert/whether it might be the source of a bug
they're investigating. (& also in the future if someone else is interested
in pulling this patch back in, they'll have an idea of where to start, in
terms of fixing the issue before recommitting)
On Mon, Jun 18, 2018 at 10:39 PM Taiju Tsuiki via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: tzik
> Date: Mon Jun 18 22:35:30 2018
> New Revision: 335022
>
> URL: http://llvm.org/viewvc/llvm-project?rev=335022&view=rev
> Log:
> Revert r335019 "Update NRVO logic to support early return (Attempt 2)"
>
> Removed:
> cfe/trunk/test/CodeGenCXX/nrvo-noopt.cpp
> cfe/trunk/test/SemaCXX/nrvo-ast.cpp
> Modified:
> cfe/trunk/include/clang/AST/Decl.h
> cfe/trunk/include/clang/Sema/Scope.h
> cfe/trunk/lib/Sema/Scope.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaStmt.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
> cfe/trunk/test/CodeGenCXX/nrvo.cpp
>
> Modified: cfe/trunk/include/clang/AST/Decl.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=335022&r1=335021&r2=335022&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Decl.h (original)
> +++ cfe/trunk/include/clang/AST/Decl.h Mon Jun 18 22:35:30 2018
> @@ -879,12 +879,6 @@ protected:
> DAK_Normal
>};
>
> - enum NRVOMode {
> -NRVO_Candidate,
> -NRVO_Disabled,
> -NRVO_Enabled,
> - };
> -
>class ParmVarDeclBitfields {
> friend class ASTDeclReader;
> friend class ParmVarDecl;
> @@ -937,7 +931,7 @@ protected:
> /// Whether this local variable could be allocated in the return
> /// slot of its function, enabling the named return value optimization
> /// (NRVO).
> -unsigned NRVOMode : 2;
> +unsigned NRVOVariable : 1;
>
> /// Whether this variable is the for-range-declaration in a C++0x
> /// for-range statement.
> @@ -1325,20 +1319,12 @@ public:
>/// return slot when returning from the function. Within the function
> body,
>/// each return that returns the NRVO object will have this variable as
> its
>/// NRVO candidate.
> - NRVOMode getNRVOMode() const {
> -if (isa(this))
> - return NRVO_Disabled;
> -return static_cast(NonParmVarDeclBits.NRVOMode);
> - }
> - bool isNRVOCandidate() const {
> -return isa(this) ? false : NonParmVarDeclBits.NRVOMode
> == NRVO_Candidate;
> - }
>bool isNRVOVariable() const {
> -return isa(this) ? false : NonParmVarDeclBits.NRVOMode
> == NRVO_Enabled;
> +return isa(this) ? false :
> NonParmVarDeclBits.NRVOVariable;
>}
>void setNRVOVariable(bool NRVO) {
> assert(!isa(this));
> -NonParmVarDeclBits.NRVOMode = NRVO ? NRVO_Enabled : NRVO_Disabled;
> +NonParmVarDeclBits.NRVOVariable = NRVO;
>}
>
>/// Determine whether this variable is the for-range-declaration in
>
> Modified: cfe/trunk/include/clang/Sema/Scope.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Scope.h?rev=335022&r1=335021&r2=335022&view=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Scope.h (original)
> +++ cfe/trunk/include/clang/Sema/Scope.h Mon Jun 18 22:35:30 2018
> @@ -201,6 +201,10 @@ private:
>/// Used to determine if errors occurred in this scope.
>DiagnosticErrorTrap ErrorTrap;
>
> + /// A lattice consisting of undefined, a single NRVO candidate variable
> in
> + /// this scope, or over-defined. The bit is true when over-defined.
> + llvm::PointerIntPair NRVO;
> +
>void setFlags(Scope *Parent, unsigned F);
>
> public:
> @@ -462,7 +466,23 @@ public:
>UsingDirectives.end());
>}
>
> - void setNRVOCandidate(VarDecl *Candidate);
> + void addNRVOCandidate(VarDecl *VD) {
> +if (NRVO.getInt())
> + return;
> +if (NRVO.getPointer() == nullptr) {
> + NRVO.setPointer(VD);
> + return;
> +}
> +if (NRVO.getPointer() != VD)
> + setNoNRVO();
> + }
> +
> + void setNoNRVO() {
> +NRVO.setInt(true);
> +NRVO.setPointer(nullptr);
> + }
> +
> + void mergeNRVOIntoParent();
>
>/// Init - This is used by the parser to implement scope caching.
>void Init(Scope *parent, unsigned flags);
>
> Modified: cfe/trunk/lib/Sema/Scope.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Scope.cpp?rev=335022&r1=335021&r2=335022&view=diff
>
> ===
[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called
ahatanak added a comment. I mean ToT clang (without my patch applied) seems to select the non-sized host version 'T::operator delete(void*)'. Repository: rC Clang https://reviews.llvm.org/D47757 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48571: improve diagnostics for missing 'template' keyword
rsmith created this revision.
rsmith added a reviewer: dblaikie.
Herald added a subscriber: eraman.
We track when we see a name-shaped expression followed by a `<` token that we
parse as a comparison. Then:
- if we see a token sequence that cannot possibly be an expression but can be a
template argument (in particular, a //type-id//) that follows either a `,` or
the `<`, diagnose that the `<` was supposed to start a template argument list
- if we see `<>`, diagnose that the `<>` was supposed to be a template argument
list
- if we see `>()`, diagnose that the `<`[...]`>` was supposed to be a template
argument list
This only changes the diagnostic for error cases, and in practice appears to
catch the most common cases where a missing `template` keyword leads to parse
errors within a template.
Repository:
rC Clang
https://reviews.llvm.org/D48571
Files:
include/clang/Basic/BitmaskEnum.h
include/clang/Parse/Parser.h
include/clang/Parse/RAIIObjectsForParser.h
include/clang/Sema/Sema.h
lib/CodeGen/CGOpenMPRuntime.cpp
lib/Parse/ParseCXXInlineMethods.cpp
lib/Parse/ParseDeclCXX.cpp
lib/Parse/ParseExpr.cpp
lib/Parse/ParseExprCXX.cpp
lib/Parse/ParseStmt.cpp
lib/Sema/SemaTemplate.cpp
test/SemaTemplate/dependent-template-recover.cpp
Index: test/SemaTemplate/dependent-template-recover.cpp
===
--- test/SemaTemplate/dependent-template-recover.cpp
+++ test/SemaTemplate/dependent-template-recover.cpp
@@ -5,18 +5,59 @@
t->f0(); // expected-error{{use 'template' keyword to treat 'f0' as a dependent template name}}
t->f0(); // expected-error{{use 'template' keyword to treat 'f0' as a dependent template name}}
-t->operator+(); // expected-error{{use 'template' keyword to treat 'operator +' as a dependent template name}}
-t->f1(); // expected-error{{use 'template' keyword to treat 'f1' as a dependent template name}}
+t->operator+(1); // expected-error{{use 'template' keyword to treat 'operator +' as a dependent template name}}
+t->f1(1); // expected-error{{use 'template' keyword to treat 'f1' as a dependent template name}}
+t->f1<3, int const>(1); // expected-error{{missing 'template' keyword prior to dependent template name 'f1'}}
T::getAs(); // expected-error{{use 'template' keyword to treat 'getAs' as a dependent template name}}
t->T::getAs(); // expected-error{{use 'template' keyword to treat 'getAs' as a dependent template name}}
-// FIXME: We can't recover from these yet
-(*t).f2(); // expected-error{{expected expression}}
-(*t).f2<0>(); // expected-error{{expected expression}}
+(*t).f2(); // expected-error{{missing 'template' keyword prior to dependent template name 'f2'}}
+(*t).f2<0>(); // expected-error{{missing 'template' keyword prior to dependent template name 'f2'}}
+T::f2<0>(); // expected-error{{missing 'template' keyword prior to dependent template name 'f2'}}
+T::f2<0, int>(0); // expected-error{{missing 'template' keyword prior to dependent template name 'f2'}}
+
+T::foo= 4>(); // expected-error{{missing 'template' keyword prior to dependent template name 'foo'}}
+
+// If there are multiple potential template names, pick the one where there
+// is no whitespace between the name and the '<'.
+T::foo(); // expected-error{{missing 'template' keyword prior to dependent template name 'foo'}}
+T::foo < T::bar<1>(); // expected-error{{missing 'template' keyword prior to dependent template name 'bar'}}
+
+// Prefer to diagonse a missing 'template' keyword rather than finding a non-template name.
+xyz < T::foo < 1 > (); // expected-error{{missing 'template' keyword prior to dependent template name 'foo'}}
+T::foo < xyz < 1 > (); // expected-error{{missing 'template' keyword prior to dependent template name 'foo'}}
+
+// ... even if the whitespace suggests the other name is the template name.
+// FIXME: Is this the right heuristic?
+xyz(); // expected-error{{missing 'template' keyword prior to dependent template name 'foo'}}
+T::foo < xyz<1>(); // expected-error{{missing 'template' keyword prior to dependent template name 'foo'}}
}
+
+ int xyz;
};
+template void not_missing_template(T t) {
+ (T::n < 0) > (
+ ) // expected-error {{expected expression}}
+;
+
+ int a = T::x < 3;
+ int b = T::y > (); // expected-error {{expected expression}}
+
+ void c(int = T::x < 3);
+ void d(int = T::y > ()); // expected-error {{expected expression}}
+
+ for (int x = t < 3 ? 1 : 2; t > (); ++t) { // expected-error {{expected expression}}
+ }
+
+ // FIXME: We shouldn't treat 'T::t' as a potential template-name here,
+ // because that would leave a '?' with no matching ':'.
+ // We should probably generally treat '?' ... ':' as a bracket-like
+ // construct.
+ bool k = T::t < 3 ? 1 > () : false; // expected-error {{missing 'template' keyword}} expected-error +{{}} expected-note +{{}}
+}
+
s
[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called
ahatanak added a comment.
The original comment said "call sized device delete even though host has
preferable non-sized version", but it seems that the non-sized host version
'T::operator delete(void*)' is being called in the IR, not the sized device
version of delete. Is that a bug in overload resolution?
This is the command I used:
"clang -cc1 -internal-isystem --std=c++11 -triple nvptx-unknown-unknown
-fcuda-is-device-emit-llvm -o - test.cu"
$ cat test.cu
#define __constant__ __attribute__((constant))
#define __device__ __attribute__((device))
#define __host__ __attribute__((host))
typedef __SIZE_TYPE__ size_t;
struct T {
__host__ void operator delete(void*);
__device__ void operator delete(void*, size_t);
};
__host__ __device__ void class_specific_delete(T *t) {
delete t;
}
Repository:
rC Clang
https://reviews.llvm.org/D47757
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] r335540 - Creating release candidate final from release_601 branch
Author: tstellar Date: Mon Jun 25 14:50:42 2018 New Revision: 335540 URL: http://llvm.org/viewvc/llvm-project?rev=335540&view=rev Log: Creating release candidate final from release_601 branch Added: libunwind/tags/RELEASE_601/final/ - copied from r335539, libunwind/branches/release_60/ ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxxabi] r335534 - Creating release candidate final from release_601 branch
Author: tstellar Date: Mon Jun 25 14:50:14 2018 New Revision: 335534 URL: http://llvm.org/viewvc/llvm-project?rev=335534&view=rev Log: Creating release candidate final from release_601 branch Added: libcxxabi/tags/RELEASE_601/final/ - copied from r335533, libcxxabi/branches/release_60/ ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r335533 - Creating release candidate final from release_601 branch
Author: tstellar Date: Mon Jun 25 14:50:10 2018 New Revision: 335533 URL: http://llvm.org/viewvc/llvm-project?rev=335533&view=rev Log: Creating release candidate final from release_601 branch Added: libcxx/tags/RELEASE_601/final/ (props changed) - copied from r335532, libcxx/branches/release_60/ Propchange: libcxx/tags/RELEASE_601/final/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Mon Jun 25 14:50:10 2018 @@ -0,0 +1,2 @@ +/libcxx/branches/apple:136569-137939 +/libcxx/trunk:321963,324153,324855,325147 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48570: [Driver] Do not add -lpthread & -lrt with -static-libsan on Android
eugenis accepted this revision. eugenis added a comment. This revision is now accepted and ready to land. LGTM This has always been the case. Repository: rC Clang https://reviews.llvm.org/D48570 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48100: Append new attributes to the end of an AttributeList.
erichkeane added a comment. In https://reviews.llvm.org/D48100#1142842, @rsmith wrote: > This patch appears to have at least caused us to process attributes too many > times in some cases. For example: > > __attribute__((noreturn,noinline,unused)) void f(); > > > before your patch gives this with `clang -Xclang -ast-dump`: > > `-FunctionDecl 0xccef1e0 <:1:1, col:50> col:48 f 'void () > __attribute__((noreturn))' > |-UnusedAttr 0xccef280 unused > `-NoInlineAttr 0xccef2c8 > > > and after your patch gives this: > > `-FunctionDecl 0xb913740 <:1:1, col:50> col:48 f 'void () > __attribute__((noreturn))' > |-NoInlineAttr 0xb9137e0 > |-UnusedAttr 0xb913828 unused > |-NoInlineAttr 0xb913838 > `-UnusedAttr 0xb913848 unused > Yep, this is a symptom of the bug I was discussing earlier. This isn't a problem with this patch per-se, but it exposes it by having certain attributes (of which calling conventions, abis, and noreturn are some) cause some linked-list rewriting. I'm currently attempting to remove the AttributeList's linked-listness. Repository: rC Clang https://reviews.llvm.org/D48100 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48100: Append new attributes to the end of an AttributeList.
Meinersbur added inline comments.
Comment at: test/Sema/attr-micromips.c:9
-__attribute__((micromips,mips16)) void foo5(); // expected-error
{{'micromips' and 'mips16' attributes are not compatible}} \
+__attribute__((micromips,mips16)) void foo5(); // expected-error {{'mips16'
and 'micromips' attributes are not compatible}} \
// expected-note {{conflicting
attribute is here}}
echristo wrote:
> This seems to reverse? What's going on here? There are other occurrences too.
This is caused by the same phenomenon as the 'previous' marker changing to the
attribute that is textually after the main marker. The order within the same
message seems less important to me.
For following happens when attributes are merged:
1. If the attributes are of the same declaration, compatibility is checked with
the existing attributes. With the current order: textually later attributes are
already in the list of accepted attributes and textually earlier attributes are
added to it.
2. If the attributes are in two different declarations, the new (textually
later) `clang::Decl` with its attributes is taken and the attributes of the old
(textually earlier) clang::Decl are added to it while checking for
compatibility.
That is, in both cases the textually earlier attribute is added to the existing
list of textually later attributes. The diagnostics are printed with the
exiting attribute on the right and the attribute-to-be added on the left (at
least in this case. `test/Sema/attr-swiftcall.c:12` is a counterexample where
this patch changes it to the textual order).
Conflicts are resolved by throwing away the conflicting attribute in the list
(i.e. textually later) to make room for the new (textually earlier) attribute.
This does not seem to have evolved intentionally when picking in which order to
print to two conflicting attributes. I would prefer if the the AST represents
the source as accurately as possible, including ordering of attributes (e.g.
`test/Sema/attr-print.c`), which in some cases carry semantic meaning:
`EnableIfAttr` and `LoopHintAttr`. Today, when dumping the AST, these are just
incorrect.
I spent some time trying to reverse the order in which the attributes appear in
the diagnostic messages (including `previous occurance here`), but this would
also require changing case 2., which is more difficult.
Repository:
rC Clang
https://reviews.llvm.org/D48100
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D44143: [clang-tidy] Create properly seeded random generator check
boga95 updated this revision to Diff 152778.
boga95 marked 3 inline comments as done.
boga95 added a comment.
Add std::srand check to C++ tests. Format patch.
https://reviews.llvm.org/D44143
Files:
clang-tidy/cert/CERTTidyModule.cpp
clang-tidy/cert/CMakeLists.txt
clang-tidy/cert/ProperlySeededRandomGeneratorCheck.cpp
clang-tidy/cert/ProperlySeededRandomGeneratorCheck.h
docs/ReleaseNotes.rst
docs/clang-tidy/checks/cert-msc32-c.rst
docs/clang-tidy/checks/cert-msc51-cpp.rst
test/clang-tidy/cert-msc32-c.c
test/clang-tidy/cert-msc51-cpp.cpp
Index: test/clang-tidy/cert-msc51-cpp.cpp
===
--- /dev/null
+++ test/clang-tidy/cert-msc51-cpp.cpp
@@ -0,0 +1,210 @@
+// RUN: %check_clang_tidy %s cert-msc51-cpp %t -- -config="{CheckOptions: [{key: cert-msc51-cpp.DisallowedSeedTypes, value: 'some_type,time_t'}]}" -- -std=c++11
+
+namespace std {
+
+void srand(int seed);
+
+template
+struct linear_congruential_engine {
+ linear_congruential_engine(int _ = 0);
+ void seed(int _ = 0);
+};
+using default_random_engine = linear_congruential_engine;
+
+using size_t = int;
+template
+struct mersenne_twister_engine {
+ mersenne_twister_engine(int _ = 0);
+ void seed(int _ = 0);
+};
+using mt19937 = mersenne_twister_engine;
+
+template
+struct subtract_with_carry_engine {
+ subtract_with_carry_engine(int _ = 0);
+ void seed(int _ = 0);
+};
+using ranlux24_base = subtract_with_carry_engine;
+
+template
+struct discard_block_engine {
+ discard_block_engine();
+ discard_block_engine(int _);
+ void seed();
+ void seed(int _);
+};
+using ranlux24 = discard_block_engine;
+
+template
+struct independent_bits_engine {
+ independent_bits_engine();
+ independent_bits_engine(int _);
+ void seed();
+ void seed(int _);
+};
+using independent_bits = independent_bits_engine;
+
+template
+struct shuffle_order_engine {
+ shuffle_order_engine();
+ shuffle_order_engine(int _);
+ void seed();
+ void seed(int _);
+};
+using shuffle_order = shuffle_order_engine;
+
+struct random_device {
+ random_device();
+ int operator()();
+};
+} // namespace std
+
+using time_t = unsigned int;
+time_t time(time_t *t);
+
+void f() {
+ const int seed = 2;
+ time_t t;
+
+ std::srand(0);
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: random number generator seeded with a constant value will generate a predictable sequence of values [cert-msc51-cpp]
+ std::srand(seed);
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: random number generator seeded with a constant value will generate a predictable sequence of values [cert-msc51-cpp]
+ std::srand(time(&t));
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: random number generator seeded with a disallowed source of seed value will generate a predictable sequence of values [cert-msc51-cpp]
+
+ // One instantiation for every engine
+ std::default_random_engine engine1;
+ // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: random number generator seeded with a default argument will generate a predictable sequence of values [cert-msc51-cpp]
+ std::default_random_engine engine2(1);
+ // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: random number generator seeded with a constant value will generate a predictable sequence of values [cert-msc51-cpp]
+ std::default_random_engine engine3(seed);
+ // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: random number generator seeded with a constant value will generate a predictable sequence of values [cert-msc51-cpp]
+ std::default_random_engine engine4(time(&t));
+ // CHECK-MESSAGES: :[[@LINE-1]]:30: warning: random number generator seeded with a disallowed source of seed value will generate a predictable sequence of values [cert-msc51-cpp]
+ engine1.seed();
+ // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: random number generator seeded with a default argument will generate a predictable sequence of values [cert-msc51-cpp]
+ engine1.seed(1);
+ // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: random number generator seeded with a constant value will generate a predictable sequence of values [cert-msc51-cpp]
+ engine1.seed(seed);
+ // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: random number generator seeded with a constant value will generate a predictable sequence of values [cert-msc51-cpp]
+ engine1.seed(time(&t));
+ // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: random number generator seeded with a disallowed source of seed value will generate a predictable sequence of values [cert-msc51-cpp]
+
+ std::mt19937 engine5;
+ // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: random number generator seeded with a default argument will generate a predictable sequence of values [cert-msc51-cpp]
+ std::mt19937 engine6(1);
+ // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: random number generator seeded with a constant value will generate a predictable sequence of values [cert-msc51-cpp]
+ std::mt19937 engine7(seed);
+ // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: random number generator seeded with
[PATCH] D48570: [Driver] Do not add -lpthread & -lrt with -static-libsan on Android
cryptoad created this revision.
cryptoad added reviewers: eugenis, pirama, srhines.
I am not sure anyone has tried to compile an application with sanitizers on
Android with `-static-libsan`, and a recent NDK, but it fails with:
.../i686-linux-android/bin/ld.gold: error: cannot find -lpthread
.../i686-linux-android/bin/ld.gold: error: cannot find -lrt
My understanding is that both are included in Bionic and as such are not needed,
and actually error out.
So remove the addition of those two in `linkSanitizerRuntimeDeps` when dealing
with Android, and update the tests.
I am unfamiliar with the evolution of the NDK and I am not sure if this has
always been the case or if this is somewhat of a recent evolution. I'll let
Android people chime in.
Repository:
rC Clang
https://reviews.llvm.org/D48570
Files:
lib/Driver/ToolChains/CommonArgs.cpp
test/Driver/sanitizer-ld.c
Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -153,7 +153,8 @@
//
// CHECK-ASAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
// CHECK-ASAN-ANDROID-STATICLIBASAN: libclang_rt.asan-arm-android.a"
-// CHECK-ASAN-ANDROID-STATICLIBASAN: "-lpthread"
+// CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
+// CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target arm-linux-androideabi -fuse-ld=ld -fsanitize=undefined \
@@ -175,7 +176,8 @@
//
// CHECK-UBSAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
// CHECK-UBSAN-ANDROID-STATICLIBASAN:
libclang_rt.ubsan_standalone-arm-android.a"
-// CHECK-UBSAN-ANDROID-STATICLIBASAN: "-lpthread"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
@@ -735,7 +737,8 @@
// CHECK-SCUDO-ANDROID-STATIC: "-pie"
// CHECK-SCUDO-ANDROID-STATIC: "--whole-archive"
"{{.*}}libclang_rt.scudo-arm-android.a" "--no-whole-archive"
// CHECK-SCUDO-ANDROID-STATIC-NOT: "-lstdc++"
-// CHECK-SCUDO-ANDROID-STATIC: "-lpthread"
+// CHECK-SCUDO-ANDROID-STATIC-NOT: "-lpthread"
+// CHECK-SCUDO-ANDROID-STATIC-NOT: "-lrt"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress \
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -558,8 +558,9 @@
// Force linking against the system libraries sanitizers depends on
// (see PR15823 why this is necessary).
CmdArgs.push_back("--no-as-needed");
- // There's no libpthread or librt on RTEMS.
- if (TC.getTriple().getOS() != llvm::Triple::RTEMS) {
+ // There's no libpthread or librt on RTEMS & Android.
+ if (TC.getTriple().getOS() != llvm::Triple::RTEMS &&
+ !TC.getTriple().isAndroid()) {
CmdArgs.push_back("-lpthread");
if (TC.getTriple().getOS() != llvm::Triple::OpenBSD)
CmdArgs.push_back("-lrt");
Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -153,7 +153,8 @@
//
// CHECK-ASAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
// CHECK-ASAN-ANDROID-STATICLIBASAN: libclang_rt.asan-arm-android.a"
-// CHECK-ASAN-ANDROID-STATICLIBASAN: "-lpthread"
+// CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
+// CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target arm-linux-androideabi -fuse-ld=ld -fsanitize=undefined \
@@ -175,7 +176,8 @@
//
// CHECK-UBSAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
// CHECK-UBSAN-ANDROID-STATICLIBASAN: libclang_rt.ubsan_standalone-arm-android.a"
-// CHECK-UBSAN-ANDROID-STATICLIBASAN: "-lpthread"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
@@ -735,7 +737,8 @@
// CHECK-SCUDO-ANDROID-STATIC: "-pie"
// CHECK-SCUDO-ANDROID-STATIC: "--whole-archive" "{{.*}}libclang_rt.scudo-arm-android.a" "--no-whole-archive"
// CHECK-SCUDO-ANDROID-STATIC-NOT: "-lstdc++"
-// CHECK-SCUDO-ANDROID-STATIC: "-lpthread"
+// CHECK-SCUDO-ANDROID-STATIC-NOT: "-lpthread"
+// CHECK-SCUDO-ANDROID-STATIC-NOT: "-lrt"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress \
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -558,8 +558,9 @@
// Force linking against the system libraries sanitizers depends on
r335516 - Revert "Append new attributes to the end of an AttributeList."
Author: meinersbur
Date: Mon Jun 25 13:06:13 2018
New Revision: 335516
URL: http://llvm.org/viewvc/llvm-project?rev=335516&view=rev
Log:
Revert "Append new attributes to the end of an AttributeList."
This reverts commit r335084 as requested by David Jones and
Eric Christopher because of differences of emitted warnings.
Modified:
cfe/trunk/include/clang/Sema/AttributeList.h
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/test/Index/annotate-comments-availability-attrs.cpp
cfe/trunk/test/Index/complete-with-annotations.cpp
cfe/trunk/test/Misc/ast-print-pragmas.cpp
cfe/trunk/test/PCH/pragma-loop.cpp
cfe/trunk/test/Parser/pragma-loop-safety.cpp
cfe/trunk/test/Parser/pragma-loop.cpp
cfe/trunk/test/Parser/pragma-unroll.cpp
cfe/trunk/test/Sema/attr-availability-tvos.c
cfe/trunk/test/Sema/attr-availability.c
cfe/trunk/test/Sema/attr-coldhot.c
cfe/trunk/test/Sema/attr-disable-tail-calls.c
cfe/trunk/test/Sema/attr-long-call.c
cfe/trunk/test/Sema/attr-micromips.c
cfe/trunk/test/Sema/attr-notail.c
cfe/trunk/test/Sema/attr-ownership.c
cfe/trunk/test/Sema/attr-ownership.cpp
cfe/trunk/test/Sema/attr-print.c
cfe/trunk/test/Sema/attr-swiftcall.c
cfe/trunk/test/Sema/attr-target-mv.c
cfe/trunk/test/Sema/attr-visibility.c
cfe/trunk/test/Sema/internal_linkage.c
cfe/trunk/test/Sema/mips-interrupt-attr.c
cfe/trunk/test/Sema/ms_abi-sysv_abi.c
cfe/trunk/test/Sema/nullability.c
cfe/trunk/test/Sema/stdcall-fastcall.c
cfe/trunk/test/SemaCXX/attr-print.cpp
cfe/trunk/test/SemaCXX/attr-swiftcall.cpp
cfe/trunk/test/SemaCXX/decl-microsoft-call-conv.cpp
cfe/trunk/test/SemaCXX/ms-uuid.cpp
cfe/trunk/test/SemaOpenCL/address-spaces.cl
cfe/trunk/test/SemaTemplate/attributes.cpp
Modified: cfe/trunk/include/clang/Sema/AttributeList.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?rev=335516&r1=335515&r2=335516&view=diff
==
--- cfe/trunk/include/clang/Sema/AttributeList.h (original)
+++ cfe/trunk/include/clang/Sema/AttributeList.h Mon Jun 25 13:06:13 2018
@@ -764,11 +764,8 @@ public:
void add(AttributeList *newAttr) {
assert(newAttr);
assert(newAttr->getNext() == nullptr);
-
-// FIXME: AttributeList is a singly linked list, i.e. appending to the end
-// requires walking to the last element. For adding n attributes, this
-// requires O(n^2) time. However, AttributeLists should be very short.
-addAllAtEnd(newAttr);
+newAttr->setNext(list);
+list = newAttr;
}
void addAll(AttributeList *newList) {
Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=335516&r1=335515&r2=335516&view=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Mon Jun 25 13:06:13 2018
@@ -707,8 +707,10 @@ void CXXNameMangler::mangleFunctionEncod
if (FD->hasAttr()) {
FunctionTypeDepthState Saved = FunctionTypeDepth.push();
Out << "Ua9enable_ifI";
-for (AttrVec::const_iterator I = FD->getAttrs().begin(),
- E = FD->getAttrs().end();
+// FIXME: specific_attr_iterator iterates in reverse order. Fix that and
use
+// it here.
+for (AttrVec::const_reverse_iterator I = FD->getAttrs().rbegin(),
+ E = FD->getAttrs().rend();
I != E; ++I) {
EnableIfAttr *EIA = dyn_cast(*I);
if (!EIA)
Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=335516&r1=335515&r2=335516&view=diff
==
--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Mon Jun 25 13:06:13 2018
@@ -1649,7 +1649,9 @@ void Parser::stripTypeAttributesOffDeclS
}
// Find end of type attributes Attrs and add NewTypeAttributes in the same
- // order they were in originally.
+ // order they were in originally. (Remember, in AttributeList things earlier
+ // in source order are later in the list, since new attributes are added to
+ // the front of the list.)
Attrs.addAllAtEnd(TypeAttrHead);
}
Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=335516&r1=335515&r2=335516&view=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Mon Jun 25 13:06:13 2018
@@ -6189,6 +6189,24 @@ Sema::SelectBestMethod(Selector Sel, Mul
r
[PATCH] D48367: [modules] Fix 37878; Autoload subdirectory modulemaps with specific LangOpts
bruno added inline comments.
Comment at: clang/lib/Lex/HeaderSearch.cpp:285
// directory.
-loadSubdirectoryModuleMaps(SearchDirs[Idx]);
+if (ModMap.getLangOpts().ObjC1 || ModMap.getLangOpts().ObjC2)
+ loadSubdirectoryModuleMaps(SearchDirs[Idx]);
yamaguchi wrote:
> bruno wrote:
> > yamaguchi wrote:
> > > bruno wrote:
> > > > aprantl wrote:
> > > > > Are these flags also enabled in Objective-C++ mode?
> > > > Looks like all this logic was introduced in r177621 to allow the names
> > > > of modules to differ from the name of their subdirectory in the include
> > > > path.
> > > >
> > > > Instead of having this to be based on the language, it's probably
> > > > better if we have it based on @import name lookup, which is the
> > > > scenario where we actually currently look more aggressively, did you
> > > > try that path?
> > > >
> > > > This is also lacking a testcase, can you create one?
> > > > Are these flags also enabled in Objective-C++ mode?
> > > I think so from FrontendOptions.h:190
> > > `bool isObjectiveC() const { return Lang == ObjC || Lang == ObjCXX; }`
> > >
> > > > it's probably better if we have it based on @import name lookup
> > > I don't think I understood what you're saying, could you explain a bit
> > > more?
> > >
> > > > This is also lacking a testcase, can you create one?
> > > Sure!
> > > I don't think I understood what you're saying, could you explain a bit
> > > more?
> >
> > This extra call to `loadSubdirectoryModuleMaps` was introduced in r177621
> > to allow `@import SomeName` to work even if `SomeName` doesn't match a
> > subdirectory name. See the original commit for more details.
> >
> > This means that it was never supposed to be called when the module is built
> > via `#include` or `#import`, which is what you are getting. That said, I
> > believe it's better if the condition for calling
> > `loadSubdirectoryModuleMaps` checks somehow if the lookup is coming from of
> > an `@import` instead of checking the language (we too don't want it to be
> > called for ObjC when `#include` or `#import` are used).
> > we too don't want it to be called for ObjC when #include or #import are used
> https://gist.github.com/yamaguchi1024/27caba1897eb813b297a8c4785adc11d
> This is one thing I could think of, it excludes `#include` but `#import` and
> `@import` are still treated in the same way. Do you have any idea how to do
> this? Is Clang differenciating the module behavior based on `#import` or
> `@import` in ObjC?
> https://gist.github.com/yamaguchi1024/27caba1897eb813b297a8c4785adc11d
Something along these lines seems fine. I'd reverse the condition of
`IsInclusionDirective` to be true by default (which is the most common case),
and you pass false when coming from `@import`s. Maybe also rename it to
something more meaningful for the change in question, around the lines of
`AllowExtraModuleMapSearch`.
> This is one thing I could think of, it excludes #include but #import and
> @import are still treated in the same way.
`#import` and `#include` should be treated the same way (extra searches
shouldn't happen for both), `@import` is the only one different.
> Do you have any idea how to do this? Is Clang differenciating the module
> behavior based on #import or @import in ObjC?
`#import` works very much like `#include`, the difference is that `#import`'s
have implicit `#pragma once` like behavior.
https://reviews.llvm.org/D48367
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r335084 - Append new attributes to the end of an AttributeList.
I just revert if to have further discussions (r335516) Michael 2018-06-25 14:58 GMT-05:00 Eric Christopher : > > > On Mon, Jun 25, 2018 at 12:21 PM Richard Smith via cfe-commits > wrote: >> >> On 23 June 2018 at 22:34, Michael Kruse via cfe-commits >> wrote: >>> >>> Hi, >>> >>> multiple comments in the code indicate that the attribute order was >>> surprising and probably has lead to bugs, and will lead to bugs in the >>> future. The order had to be explicitly reversed to avoid those. This >>> alone for me this seems a good reason to have the attributes in the >>> order in which they appear in the source. >>> >>> It would be nice it you could send a reproducer. At a glance, your >>> case does not seem related since the format strings are function >>> arguments, not attributes. >>> >>> Michael >>> >>> >>> 2018-06-23 17:17 GMT-05:00 David Jones : >>> > This commit seems to have some substantial downsides... for example, it >>> > now >>> > flags calls like this as warnings: >>> > >>> > http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/src/msgl-check.c?id=05ecefa943f339019b7127aa92cbb09f6fd49ed3#n478 >>> > >>> > Previously, the reverse order meant that the plural format string was >>> > examined, but now it is only the singular string. Since the singular >>> > string >>> > doesn't include a substitution, the unused format variable warning >>> > fires >>> > after this revision. >>> > >>> > I don't see a strong argument for why one order is more correct than >>> > the >>> > other; however, given that this is in conflict with real code found in >>> > the >>> > wild, I think this needs to be addressed. >>> > >>> > Since the semantics of the ordering of multiple format args seems >>> > somewhat >>> > ill-defined, it seems to me like reverting may be the best near-term >>> > choice. >>> > I can imagine other ways to fix the diagnostic, but the only behaviour >>> > that >>> > I would believe to be expected by existing code is the old one, so a >>> > change >>> > like this one probably needs to be more carefully vetted before being >>> > (re-)committed. >>> >>> Could you give more details about your concerns? >> >> >> (I'm not sure what the problem is, but as a data point, Sema::checkCall >> iterates over the FormatAttrs in order, so it's possible that changing the >> order may have triggered a new warning. That may be due to a pre-existing >> order-dependence bug, or it may be that we're losing an attribute here.) >> > > FWIW I just replied to the original review thread as well - there appear to > be some warnings that are now missing that previously worked and some that > are now in reverse order from the source. I think more work might need to > happen before this patch should go back in. > > -eric > >>> >>> > Please let me know your plan. (If I don't hear back in a day or so, >>> > I'll go >>> > ahead and revert for you as the safe default course of action.) >>> >>> On a weekend? >> >> >> Yes; our policy is generally to revert to green if a patch causes >> regressions that aren't going to be fixed in a few hours. This is generally >> good for the committer, because it lets you figure out what's wrong and deal >> with it on your own schedule rather than being pressured to fix it urgently >> because you're blocking the work of others. >> ___ >> 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: r335084 - Append new attributes to the end of an AttributeList.
2018-06-25 14:20 GMT-05:00 Richard Smith :
> (I'm not sure what the problem is, but as a data point, Sema::checkCall
> iterates over the FormatAttrs in order, so it's possible that changing the
> order may have triggered a new warning. That may be due to a pre-existing
> order-dependence bug, or it may be that we're losing an attribute here.)
In this case the following patch should fix this.
diff --git a/lib/Sema/SemaChecking.cpp b/lib/Sema/SemaChecking.cpp
index 12a599b4f1..aeb7a83fa6 100644
--- a/lib/Sema/SemaChecking.cpp
+++ b/lib/Sema/SemaChecking.cpp
@@ -3172,7 +3172,8 @@ void Sema::checkCall(NamedDecl *FDecl, const
FunctionProtoType *Proto,
// Printf and scanf checking.
llvm::SmallBitVector CheckedVarArgs;
if (FDecl) {
-for (const auto *I : FDecl->specific_attrs()) {
+SmallVector
FormatAttrs(FDecl->specific_attrs());
+for (const auto *I : llvm::reverse(FormatAttrs)) {
// Only create vector if there are format attributes.
CheckedVarArgs.resize(Args.size());
However, if I understand __attribute__((format(...))) correctly,
there should be just one FormatAttr.
>> > Please let me know your plan. (If I don't hear back in a day or so, I'll
>> > go
>> > ahead and revert for you as the safe default course of action.)
>>
>> On a weekend?
>
>
> Yes; our policy is generally to revert to green if a patch causes
> regressions that aren't going to be fixed in a few hours. This is generally
> good for the committer, because it lets you figure out what's wrong and deal
> with it on your own schedule rather than being pressured to fix it urgently
> because you're blocking the work of others.
Should I revert the commit then?
Michael
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called
jlebar added a comment. > @jlebar, is the change I made to call-host-fn-from-device.cu correct? I don't think so -- that's a change in overloading behavior afaict. Repository: rC Clang https://reviews.llvm.org/D47757 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called
ahatanak added a reviewer: jlebar. ahatanak added a subscriber: jlebar. ahatanak added a comment. ping. @jlebar, is the change I made to call-host-fn-from-device.cu correct? Repository: rC Clang https://reviews.llvm.org/D47757 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48459: Respect CMAKE_SYSROOT and CMAKE_CROSSCOMPILING when searching for libxml2.
smeenai added reviewers: beanz, phosek. smeenai added a comment. I think it might be more appropriate to pass NO_SYSTEM_ENVIRONMENT_PATH to find_package in case CMAKE_SYSROOT or CMAKE_CROSSCOMPILING are set? That way, we won't search the host system for libxml2 in those cases, but we'll still be able to find it in the custom sysroot or cross-compilation SDK if it's present. Repository: rC Clang https://reviews.llvm.org/D48459 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48100: Append new attributes to the end of an AttributeList.
rsmith added a comment. This patch appears to have at least caused us to process attributes too many times in some cases. For example: __attribute__((noreturn,noinline,unused)) void f(); before your patch gives this with `clang -Xclang -ast-dump`: `-FunctionDecl 0xccef1e0 <:1:1, col:50> col:48 f 'void () __attribute__((noreturn))' |-UnusedAttr 0xccef280 unused `-NoInlineAttr 0xccef2c8 and after your patch gives this: `-FunctionDecl 0xb913740 <:1:1, col:50> col:48 f 'void () __attribute__((noreturn))' |-NoInlineAttr 0xb9137e0 |-UnusedAttr 0xb913828 unused |-NoInlineAttr 0xb913838 `-UnusedAttr 0xb913848 unused Repository: rC Clang https://reviews.llvm.org/D48100 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48100: Append new attributes to the end of an AttributeList.
erichkeane added inline comments.
Comment at: test/Sema/attr-target-mv.c:98
int __attribute__((target("sse4.2"))) diff_cc(void);
-// expected-error@+1 {{multiversioned function declaration has a different
calling convention}}
+// expected-error@+1 {{attribute 'target' multiversioning cannot be combined
with other attributes}}
__vectorcall int __attribute__((target("arch=sandybridge"))) diff_cc(void);
echristo wrote:
> This appears to have broken a particular error message?
Yeah, I actually noticed this last week, and @aaron.ballman and I have been
discussing it. Unfortunately, a small list of attributes (including all
calling conventions) cause some redistributing of attributes between DeclSpec
and Declarators. Due to a bug in that area, linked-list pointers are being
rewritten in a fairly mean fashion (it was previously not noticeable since
these were at the end).
It is going to take a pretty good sized effort to fix (basically, remove the
attributelist linked list-ness), but Aaron and I have been working on it for a
few days.
Reverting this won't change my effort so I'll try to fix this in the meantime.
Repository:
rC Clang
https://reviews.llvm.org/D48100
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r335491 - Revert "[ASTImporter] Import the whole redecl chain of functions"
Hi Nico,
Yes, I reverted because it broke one of the lldb build bots.
Next time I'll include the reason in the revert commit.
Gábor
On Mon, 25 Jun 2018, 22:50 Nico Weber, wrote:
> When reverting things, please say why in the commit message. (In this
> case, apparently because it broke the lldb buildbots?)
>
> On Mon, Jun 25, 2018 at 12:30 PM Gabor Marton via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: martong
>> Date: Mon Jun 25 09:25:30 2018
>> New Revision: 335491
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=335491&view=rev
>> Log:
>> Revert "[ASTImporter] Import the whole redecl chain of functions"
>>
>> This reverts commit r335480.
>>
>> Modified:
>> cfe/trunk/include/clang/AST/ASTImporter.h
>> cfe/trunk/lib/AST/ASTImporter.cpp
>> cfe/trunk/lib/AST/DeclBase.cpp
>> cfe/trunk/test/ASTMerge/class/test.cpp
>> cfe/trunk/unittests/AST/ASTImporterTest.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/ASTImporter.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTImporter.h?rev=335491&r1=335490&r2=335491&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/ASTImporter.h (original)
>> +++ cfe/trunk/include/clang/AST/ASTImporter.h Mon Jun 25 09:25:30 2018
>> @@ -43,15 +43,6 @@ class TagDecl;
>> class TypeSourceInfo;
>> class Attr;
>>
>> - // \brief Returns with a list of declarations started from the
>> canonical decl
>> - // then followed by subsequent decls in the translation unit.
>> - // This gives a canonical list for each entry in the redecl chain.
>> - // `Decl::redecls()` gives a list of decls which always start from the
>> - // previous decl and the next item is actually the previous item in
>> the order
>> - // of source locations. Thus, `Decl::redecls()` gives different lists
>> for
>> - // the different entries in a given redecl chain.
>> - llvm::SmallVector getCanonicalForwardRedeclChain(Decl* D);
>> -
>>/// Imports selected nodes from one AST context into another context,
>>/// merging AST nodes where appropriate.
>>class ASTImporter {
>>
>> Modified: cfe/trunk/lib/AST/ASTImporter.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTImporter.cpp?rev=335491&r1=335490&r2=335491&view=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/ASTImporter.cpp (original)
>> +++ cfe/trunk/lib/AST/ASTImporter.cpp Mon Jun 25 09:25:30 2018
>> @@ -71,25 +71,6 @@
>>
>> namespace clang {
>>
>> - template
>> - SmallVector
>> - getCanonicalForwardRedeclChain(Redeclarable* D) {
>> -SmallVector Redecls;
>> -for (auto *R : D->getFirstDecl()->redecls()) {
>> - if (R != D->getFirstDecl())
>> -Redecls.push_back(R);
>> -}
>> -Redecls.push_back(D->getFirstDecl());
>> -std::reverse(Redecls.begin(), Redecls.end());
>> -return Redecls;
>> - }
>> -
>> - SmallVector getCanonicalForwardRedeclChain(Decl* D) {
>> -// Currently only FunctionDecl is supported
>> -auto FD = cast(D);
>> -return getCanonicalForwardRedeclChain(FD);
>> - }
>> -
>>class ASTNodeImporter : public TypeVisitor,
>>public DeclVisitor,
>>public StmtVisitor {
>> @@ -214,12 +195,6 @@ namespace clang {
>> const InContainerTy &Container,
>> TemplateArgumentListInfo
>> &Result);
>>
>> -using TemplateArgsTy = SmallVector;
>> -using OptionalTemplateArgsTy = Optional;
>> -std::tuple
>> -ImportFunctionTemplateWithTemplateArgsFromSpecialization(
>> -FunctionDecl *FromFD);
>> -
>> bool ImportTemplateInformation(FunctionDecl *FromFD, FunctionDecl
>> *ToFD);
>>
>> bool IsStructuralMatch(RecordDecl *FromRecord, RecordDecl *ToRecord,
>> @@ -433,8 +408,6 @@ namespace clang {
>>
>> // Importing overrides.
>> void ImportOverrides(CXXMethodDecl *ToMethod, CXXMethodDecl
>> *FromMethod);
>> -
>> -FunctionDecl *FindFunctionTemplateSpecialization(FunctionDecl
>> *FromFD);
>>};
>>
>> template
>> @@ -464,25 +437,6 @@ bool ASTNodeImporter::ImportTemplateArgu
>> From.arguments(), Result);
>> }
>>
>> -std::tuple> ASTNodeImporter::OptionalTemplateArgsTy>
>>
>> -ASTNodeImporter::ImportFunctionTemplateWithTemplateArgsFromSpecialization(
>> -FunctionDecl *FromFD) {
>> - assert(FromFD->getTemplatedKind() ==
>> - FunctionDecl::TK_FunctionTemplateSpecialization);
>> - auto *FTSInfo = FromFD->getTemplateSpecializationInfo();
>> - auto *Template = cast_or_null(
>> - Importer.Import(FTSInfo->getTemplate()));
>> -
>> - // Import template arguments.
>> - auto TemplArgs = FTSInfo->TemplateArguments->asArray();
>> - TemplateArgsTy ToTemplArgs;
>> - if (ImportTemplateArguments(TemplArgs.data(), TemplArgs.size(),
>> -
Re: r335491 - Revert "[ASTImporter] Import the whole redecl chain of functions"
When reverting things, please say why in the commit message. (In this case,
apparently because it broke the lldb buildbots?)
On Mon, Jun 25, 2018 at 12:30 PM Gabor Marton via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: martong
> Date: Mon Jun 25 09:25:30 2018
> New Revision: 335491
>
> URL: http://llvm.org/viewvc/llvm-project?rev=335491&view=rev
> Log:
> Revert "[ASTImporter] Import the whole redecl chain of functions"
>
> This reverts commit r335480.
>
> Modified:
> cfe/trunk/include/clang/AST/ASTImporter.h
> cfe/trunk/lib/AST/ASTImporter.cpp
> cfe/trunk/lib/AST/DeclBase.cpp
> cfe/trunk/test/ASTMerge/class/test.cpp
> cfe/trunk/unittests/AST/ASTImporterTest.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTImporter.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTImporter.h?rev=335491&r1=335490&r2=335491&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTImporter.h (original)
> +++ cfe/trunk/include/clang/AST/ASTImporter.h Mon Jun 25 09:25:30 2018
> @@ -43,15 +43,6 @@ class TagDecl;
> class TypeSourceInfo;
> class Attr;
>
> - // \brief Returns with a list of declarations started from the
> canonical decl
> - // then followed by subsequent decls in the translation unit.
> - // This gives a canonical list for each entry in the redecl chain.
> - // `Decl::redecls()` gives a list of decls which always start from the
> - // previous decl and the next item is actually the previous item in the
> order
> - // of source locations. Thus, `Decl::redecls()` gives different lists
> for
> - // the different entries in a given redecl chain.
> - llvm::SmallVector getCanonicalForwardRedeclChain(Decl* D);
> -
>/// Imports selected nodes from one AST context into another context,
>/// merging AST nodes where appropriate.
>class ASTImporter {
>
> Modified: cfe/trunk/lib/AST/ASTImporter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTImporter.cpp?rev=335491&r1=335490&r2=335491&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ASTImporter.cpp (original)
> +++ cfe/trunk/lib/AST/ASTImporter.cpp Mon Jun 25 09:25:30 2018
> @@ -71,25 +71,6 @@
>
> namespace clang {
>
> - template
> - SmallVector
> - getCanonicalForwardRedeclChain(Redeclarable* D) {
> -SmallVector Redecls;
> -for (auto *R : D->getFirstDecl()->redecls()) {
> - if (R != D->getFirstDecl())
> -Redecls.push_back(R);
> -}
> -Redecls.push_back(D->getFirstDecl());
> -std::reverse(Redecls.begin(), Redecls.end());
> -return Redecls;
> - }
> -
> - SmallVector getCanonicalForwardRedeclChain(Decl* D) {
> -// Currently only FunctionDecl is supported
> -auto FD = cast(D);
> -return getCanonicalForwardRedeclChain(FD);
> - }
> -
>class ASTNodeImporter : public TypeVisitor,
>public DeclVisitor,
>public StmtVisitor {
> @@ -214,12 +195,6 @@ namespace clang {
> const InContainerTy &Container,
> TemplateArgumentListInfo &Result);
>
> -using TemplateArgsTy = SmallVector;
> -using OptionalTemplateArgsTy = Optional;
> -std::tuple
> -ImportFunctionTemplateWithTemplateArgsFromSpecialization(
> -FunctionDecl *FromFD);
> -
> bool ImportTemplateInformation(FunctionDecl *FromFD, FunctionDecl
> *ToFD);
>
> bool IsStructuralMatch(RecordDecl *FromRecord, RecordDecl *ToRecord,
> @@ -433,8 +408,6 @@ namespace clang {
>
> // Importing overrides.
> void ImportOverrides(CXXMethodDecl *ToMethod, CXXMethodDecl
> *FromMethod);
> -
> -FunctionDecl *FindFunctionTemplateSpecialization(FunctionDecl
> *FromFD);
>};
>
> template
> @@ -464,25 +437,6 @@ bool ASTNodeImporter::ImportTemplateArgu
> From.arguments(), Result);
> }
>
> -std::tuple ASTNodeImporter::OptionalTemplateArgsTy>
> -ASTNodeImporter::ImportFunctionTemplateWithTemplateArgsFromSpecialization(
> -FunctionDecl *FromFD) {
> - assert(FromFD->getTemplatedKind() ==
> - FunctionDecl::TK_FunctionTemplateSpecialization);
> - auto *FTSInfo = FromFD->getTemplateSpecializationInfo();
> - auto *Template = cast_or_null(
> - Importer.Import(FTSInfo->getTemplate()));
> -
> - // Import template arguments.
> - auto TemplArgs = FTSInfo->TemplateArguments->asArray();
> - TemplateArgsTy ToTemplArgs;
> - if (ImportTemplateArguments(TemplArgs.data(), TemplArgs.size(),
> - ToTemplArgs)) // Error during import.
> -return std::make_tuple(Template, OptionalTemplateArgsTy());
> -
> - return std::make_tuple(Template, ToTemplArgs);
> -}
> -
> } // namespace clang
>
>
>
> //
> @@ -2298,17 +2252,23 @@ bool A
[PATCH] D48459: Respect CMAKE_SYSROOT and CMAKE_CROSSCOMPILING when searching for libxml2.
srhines added a comment. Rui, I added you to this review (and the other corresponding one), as you reviewed ecbeckmann's original work here. Can you take a quick look at these? Thanks. Repository: rC Clang https://reviews.llvm.org/D48459 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48562: [clangd] XPC transport layer
arphaman added inline comments. Comment at: xpc/test-client/ClangdXPCTestClient.cpp:51 + dlHandle, "clangd_xpc_get_bundle_identifier"); + xpc_connection_t conn = + xpc_connection_create(clangd_xpc_get_bundle_identifier(), NULL); We should probably use the main queue here too to ensure that we don't get bit by concurrent handler invocations. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D48562 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48559: [clangd] refactoring for XPC transport layer [NFCI]
jkorous added a comment. Followed by these two patches: [clangd] JSON <-> XPC conversions https://reviews.llvm.org/D48560 [clangd] XPC transport layer https://reviews.llvm.org/D48562 Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D48559 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48564: [CMake] Support passing FUCHSIA_SDK as the only variable
phosek created this revision.
phosek added reviewers: mcgrathr, juliehockett, jakehehrlich.
Herald added subscribers: cfe-commits, mgorny.
Now that the structure of Fuchsia SDK has been formalized, we no
longer need to pass all the different CFLAGS/LDFLAGS to the CMake
build separately, we can simply set the FUCHSIA_SDK variable and
derive all the necessary variables from that one inside the cache
file.
Repository:
rC Clang
https://reviews.llvm.org/D48564
Files:
clang/cmake/caches/Fuchsia-stage2.cmake
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -31,18 +31,26 @@
set(FUCHSIA_RUNTIMES_BUILD_TYPE Release CACHE STRING "")
set(FUCHSIA_RUNTIMES_ENABLE_ASSERTIONS ON CACHE BOOL "")
+set(FUCHSIA_aarch64_NAME arm64)
+set(FUCHSIA_x86_64_NAME x64)
+foreach(target x86_64;aarch64)
+ set(FUCHSIA_${target}_COMPILER_FLAGS "-I${FUCHSIA_SDK}/pkg/fdio/include")
+ set(FUCHSIA_${target}_LINKER_FLAGS
"-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
+ set(FUCHSIA_${target}_SYSROOT
"${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
+endforeach()
+
set(LLVM_BUILTIN_TARGETS "default;x86_64-fuchsia;aarch64-fuchsia" CACHE STRING
"")
# Set the per-target builtins options.
foreach(target x86_64;aarch64)
set(BUILTINS_${target}-fuchsia_CMAKE_SYSTEM_NAME Fuchsia CACHE STRING "")
set(BUILTINS_${target}-fuchsia_CMAKE_BUILD_TYPE
${FUCHSIA_BUILTINS_BUILD_TYPE} CACHE STRING "")
- set(BUILTINS_${target}-fuchsia_CMAKE_ASM_FLAGS ${FUCHSIA_${target}_C_FLAGS}
CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_C_FLAGS ${FUCHSIA_${target}_C_FLAGS}
CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_CXX_FLAGS
${FUCHSIA_${target}_CXX_FLAGS} CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_EXE_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
+ set(BUILTINS_${target}-fuchsia_CMAKE_ASM_FLAGS
${FUCHSIA_${target}_COMPILER_FLAGS} CACHE PATH "")
+ set(BUILTINS_${target}-fuchsia_CMAKE_C_FLAGS
${FUCHSIA_${target}_COMPILER_FLAGS} CACHE PATH "")
+ set(BUILTINS_${target}-fuchsia_CMAKE_CXX_FLAGS
${FUCHSIA_${target}_COMPILER_FLAGS} CACHE PATH "")
set(BUILTINS_${target}-fuchsia_CMAKE_SHARED_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
set(BUILTINS_${target}-fuchsia_CMAKE_MODULE_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
+ set(BUILTINS_${target}-fuchsia_CMAKE_EXE_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
set(BUILTINS_${target}-fuchsia_CMAKE_SYSROOT ${FUCHSIA_${target}_SYSROOT}
CACHE PATH "")
endforeach()
@@ -68,12 +76,12 @@
set(RUNTIMES_${target}-fuchsia_CMAKE_SYSTEM_NAME Fuchsia CACHE STRING "")
set(RUNTIMES_${target}-fuchsia_CMAKE_BUILD_TYPE
${FUCHSIA_RUNTIMES_BUILD_TYPE} CACHE STRING "")
set(RUNTIMES_${target}-fuchsia_CMAKE_BUILD_WITH_INSTALL_RPATH ON CACHE
STRING "")
- set(RUNTIMES_${target}-fuchsia_CMAKE_ASM_FLAGS ${FUCHSIA_${target}_C_FLAGS}
CACHE PATH "")
- set(RUNTIMES_${target}-fuchsia_CMAKE_C_FLAGS ${FUCHSIA_${target}_C_FLAGS}
CACHE PATH "")
- set(RUNTIMES_${target}-fuchsia_CMAKE_CXX_FLAGS
${FUCHSIA_${target}_CXX_FLAGS} CACHE PATH "")
- set(RUNTIMES_${target}-fuchsia_CMAKE_EXE_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
+ set(RUNTIMES_${target}-fuchsia_CMAKE_ASM_FLAGS
${FUCHSIA_${target}_COMPILER_FLAGS} CACHE PATH "")
+ set(RUNTIMES_${target}-fuchsia_CMAKE_C_FLAGS
${FUCHSIA_${target}_COMPILER_FLAGS} CACHE PATH "")
+ set(RUNTIMES_${target}-fuchsia_CMAKE_CXX_FLAGS
${FUCHSIA_${target}_COMPILER_FLAGS} CACHE PATH "")
set(RUNTIMES_${target}-fuchsia_CMAKE_SHARED_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
set(RUNTIMES_${target}-fuchsia_CMAKE_MODULE_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
+ set(RUNTIMES_${target}-fuchsia_CMAKE_EXE_LINKER_FLAGS
${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
set(RUNTIMES_${target}-fuchsia_CMAKE_SYSROOT ${FUCHSIA_${target}_SYSROOT}
CACHE PATH "")
set(RUNTIMES_${target}-fuchsia_LLVM_ENABLE_ASSERTIONS
${FUCHSIA_RUNTIMES_ENABLE_ASSERTIONS} CACHE BOOL "")
set(RUNTIMES_${target}-fuchsia_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -31,18 +31,26 @@
set(FUCHSIA_RUNTIMES_BUILD_TYPE Release CACHE STRING "")
set(FUCHSIA_RUNTIMES_ENABLE_ASSERTIONS ON CACHE BOOL "")
+set(FUCHSIA_aarch64_NAME arm64)
+set(FUCHSIA_x86_64_NAME x64)
+foreach(target x86_64;aarch64)
+ set(FUCHSIA_${target}_COMPILER_FLAGS "-I${FUCHSIA_SDK}/pkg/fdio/include")
+ set(FUCHSIA_${target}_LINKER_FLAGS "-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
+ set(FUCHSIA_${target}_SYSROOT "${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
+endforeach()
[PATCH] D48563: [CMake] Use explicit targets for building Linux runtimes
phosek created this revision.
phosek added a reviewer: mcgrathr.
Herald added subscribers: cfe-commits, mgorny.
Previously we were using default logic when building Linux runtimes
in Fuchsia toolchain, but that leads to various issues due to how
the CMake logic in compiler-rt for determining the platform support
is implemented. With this change, we will use explicit target for
every provided Linux sysroot.
Repository:
rC Clang
https://reviews.llvm.org/D48563
Files:
clang/cmake/caches/Fuchsia-stage2.cmake
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -27,67 +27,82 @@
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-O3 -gline-tables-only -DNDEBUG" CACHE STRING "")
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O3 -gline-tables-only -DNDEBUG" CACHE STRING "")
-set(FUCHSIA_BUILTINS_BUILD_TYPE Release CACHE STRING "")
-set(FUCHSIA_RUNTIMES_BUILD_TYPE Release CACHE STRING "")
-set(FUCHSIA_RUNTIMES_ENABLE_ASSERTIONS ON CACHE BOOL "")
+if(APPLE)
+ list(APPEND builtin_targets "default")
+ list(APPEND runtime_targets "default")
+endif()
-set(LLVM_BUILTIN_TARGETS "default;x86_64-fuchsia;aarch64-fuchsia" CACHE STRING "")
+foreach(target i386;x86_64;armhf;aarch64)
+ if(LINUX_${target}_SYSROOT)
+# Set the per-target builtins options.
+list(APPEND builtin_targets "${target}-linux-gnu")
+set(BUILTINS_${target}-linux-gnu_CMAKE_SYSTEM_NAME Linux CACHE STRING "")
+set(BUILTINS_${target}-linux-gnu_CMAKE_BUILD_TYPE Release CACHE STRING "")
+set(BUILTINS_${target}-linux-gnu_CMAKE_SYSROOT ${LINUX_${target}_SYSROOT} CACHE STRING "")
-# Set the per-target builtins options.
-foreach(target x86_64;aarch64)
- set(BUILTINS_${target}-fuchsia_CMAKE_SYSTEM_NAME Fuchsia CACHE STRING "")
- set(BUILTINS_${target}-fuchsia_CMAKE_BUILD_TYPE ${FUCHSIA_BUILTINS_BUILD_TYPE} CACHE STRING "")
- set(BUILTINS_${target}-fuchsia_CMAKE_ASM_FLAGS ${FUCHSIA_${target}_C_FLAGS} CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_C_FLAGS ${FUCHSIA_${target}_C_FLAGS} CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_CXX_FLAGS ${FUCHSIA_${target}_CXX_FLAGS} CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_EXE_LINKER_FLAGS ${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_SHARED_LINKER_FLAGS ${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_MODULE_LINKER_FLAGS ${FUCHSIA_${target}_LINKER_FLAGS} CACHE PATH "")
- set(BUILTINS_${target}-fuchsia_CMAKE_SYSROOT ${FUCHSIA_${target}_SYSROOT} CACHE PATH "")
+# Set the per-target runtimes options.
+list(APPEND runtime_targets "${target}-linux-gnu")
+set(RUNTIMES_${target}-linux-gnu_CMAKE_SYSTEM_NAME Linux CACHE STRING "")
+set(RUNTIMES_${target}-linux-gnu_CMAKE_BUILD_TYPE Release CACHE STRING "")
+set(RUNTIMES_${target}-linux-gnu_CMAKE_SYSROOT ${LINUX_${target}_SYSROOT} CACHE STRING "")
+set(RUNTIMES_${target}-linux-gnu_LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_INSTALL_LIBRARY OFF CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
+set(RUNTIMES_${target}-linux-gnu_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
+ endif()
endforeach()
-set(LLVM_RUNTIME_TARGETS "default;x86_64-fuchsia;aarch64-fuchsia;x86_64-fuchsia-asan:x86_64-fuchsia;aarch64-fuchsia-asan:aarch64-fuchsia" CACHE STRING "")
-
-# Set the default target runtimes options.
-if(NOT APPLE)
- set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
- set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
- set(LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
- set(LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
- set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
- set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
- set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "")
- set(LIBCXXABI_INSTALL_LIBRARY OFF CACHE BOOL "")
- set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
- set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
- set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
-endif()
-
-# Set the per-target runtimes options.
foreach(target x86_64;aarch64)
- set(RUNTIMES_${target}-fuchsia_CMAKE_SYSTEM_NAME Fuchsia CACHE STRING "")
- set(RUNTIMES_${targ
[PATCH] D48562: [clangd] XPC transport layer
jkorous created this revision.
jkorous added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, MaskRay, ioeric, ilya-biryukov, mgorny.
Implementation of alternative transport layer for macOS based on XPC.
Based on these two other patches:
https://reviews.llvm.org/D48559
https://reviews.llvm.org/D48560
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D48562
Files:
CMakeLists.txt
Features.inc.in
ProtocolHandlers.h
clangd/CMakeLists.txt
clangd/xpc/initialize.test
lit.cfg
lit.site.cfg.in
tool/CMakeLists.txt
tool/ClangdMain.cpp
xpc/CMakeLists.txt
xpc/README.txt
xpc/XPCDispatcher.cpp
xpc/XPCDispatcher.h
xpc/cmake/Info.plist.in
xpc/cmake/XPCServiceInfo.plist.in
xpc/cmake/modules/CreateClangdXPCFramework.cmake
xpc/framework/CMakeLists.txt
xpc/framework/ClangdXPC.cpp
xpc/test-client/CMakeLists.txt
xpc/test-client/ClangdXPCTestClient.cpp
Index: clangd/CMakeLists.txt
===
--- clangd/CMakeLists.txt
+++ clangd/CMakeLists.txt
@@ -52,3 +52,7 @@
LLVMSupport
LLVMTestingSupport
)
+
+if (CLANGD_BUILD_XPC_SUPPORT)
+ add_subdirectory(xpc)
+endif ()
Index: lit.site.cfg.in
===
--- lit.site.cfg.in
+++ lit.site.cfg.in
@@ -11,6 +11,7 @@
config.python_executable = "@PYTHON_EXECUTABLE@"
config.target_triple = "@TARGET_TRIPLE@"
config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
+config.clangd_xpc_support = @CLANGD_BUILD_XPC_SUPPORT@
# Support substitution of the tools and libs dirs with user parameters. This is
# used when we can't determine the tool dir at configuration time.
Index: lit.cfg
===
--- lit.cfg
+++ lit.cfg
@@ -117,6 +117,10 @@
if platform.system() not in ['Windows']:
config.available_features.add('ansi-escape-sequences')
+# XPC support for Clangd.
+if config.clangd_xpc_support:
+config.available_features.add('clangd-xpc-support')
+
if config.clang_staticanalyzer:
config.available_features.add('static-analyzer')
check_clang_tidy = os.path.join(
Index: clangd/xpc/initialize.test
===
--- /dev/null
+++ clangd/xpc/initialize.test
@@ -0,0 +1,10 @@
+# RUN: clangd-xpc-test-client < %s | FileCheck %s
+# REQUIRES: clangd-xpc-support
+
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootUri":"test:///workspace","capabilities":{},"trace":"off"}}
+# CHECK: {"id":0,"jsonrpc":"2.0","result":{"capabilities":{"codeActionProvider":true,"completionProvider":{"resolveProvider":false,"triggerCharacters":[".",">",":"]},"definitionProvider":true,"documentFormattingProvider":true,"documentHighlightProvider":true,"documentOnTypeFormattingProvider":{"firstTriggerCharacter":"}","moreTriggerCharacter":[]},"documentRangeFormattingProvider":true,"executeCommandProvider":{"commands":["clangd.applyFix"]},"hoverProvider":true,"renameProvider":true,"signatureHelpProvider":{"triggerCharacters":["(",","]},"textDocumentSync":2,"workspaceSymbolProvider":true}}}
+
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+# CHECK: {"id":3,"jsonrpc":"2.0","result":null}
+
+{"jsonrpc":"2.0","method":"exit"}
Index: xpc/test-client/ClangdXPCTestClient.cpp
===
--- /dev/null
+++ xpc/test-client/ClangdXPCTestClient.cpp
@@ -0,0 +1,100 @@
+#include "xpc/XPCJSONConversions.h"
+#include "clang/Basic/LLVM.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/LineIterator.h"
+#include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/raw_ostream.h"
+#include
+#include
+#include
+#include
+
+typedef const char *(*clangd_xpc_get_bundle_identifier_t)(void);
+
+using namespace llvm;
+using namespace clang;
+
+std::string getLibraryPath() {
+ Dl_info info;
+ if (dladdr((void *)(uintptr_t)getLibraryPath, &info) == 0)
+llvm_unreachable("Call to dladdr() failed");
+ llvm::SmallString<128> LibClangPath;
+ LibClangPath = llvm::sys::path::parent_path(
+ llvm::sys::path::parent_path(info.dli_fname));
+ llvm::sys::path::append(LibClangPath, "lib", "ClangdXPC.framework",
+ "ClangdXPC");
+ return LibClangPath.str();
+}
+
+static void dumpXPCObject(xpc_object_t Object, llvm::raw_ostream &OS) {
+ xpc_type_t Type = xpc_get_type(Object);
+ if (Type == XPC_TYPE_DICTIONARY) {
+clang::clangd::json::Expr Json = clang::clangd::xpcToJson(Object);
+OS << Json;
+ } else {
+OS << "";
+ }
+}
+
+int main(int argc, char *argv[]) {
+ // Open the ClangdXPC dylib in the framework.
+ std::string LibPath = getLibraryPath();
+ void *dlHandle = dlopen(LibPath.c_str(), RTLD_LOCAL | RTLD_FIRST);
+ if (!dlHandle)
+return 1;
+
+ // Lookup the XPC service bundle name, and launch it.
+ clangd_xpc_get_bundle_identifier_t clangd_xpc_get_bundle_identifie
[PATCH] D48036: [CUDA] Make min/max shims host+device.
jlebar added a comment. @rsmith friendly ping on this one. https://reviews.llvm.org/D48036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48560: [clangd] JSON <-> XPC conversions
jkorous created this revision.
jkorous added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, MaskRay, ioeric, ilya-biryukov, mgorny.
This is a self-contained pair of utility functions for the XPC transport layer.
It's not dependent on but following the refactoring patch:
https://reviews.llvm.org/D48559
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D48560
Files:
clangd/xpc/CMakeLists.txt
clangd/xpc/XPCJSONConversionTests.cpp
xpc/XPCJSONConversions.cpp
xpc/XPCJSONConversions.h
Index: clangd/xpc/XPCJSONConversionTests.cpp
===
--- /dev/null
+++ clangd/xpc/XPCJSONConversionTests.cpp
@@ -0,0 +1,452 @@
+//===-- XPCJSONConversion.cpp *- C++ -*---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "xpc/XPCJSONConversions.h"
+#include "gtest/gtest.h"
+
+#include
+
+namespace clang {
+namespace clangd {
+namespace {
+
+TEST(JsonXpcConversionTest, Null) {
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(nullptr)),
+ xpc_null_create()
+)
+ );
+ EXPECT_TRUE(
+json::Expr(nullptr) == xpcToJson(xpc_null_create())
+ );
+}
+
+TEST(JsonXpcConversionTest, Bool) {
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(true)),
+ xpc_bool_create(true)
+)
+ );
+ EXPECT_TRUE(
+json::Expr(false) == xpcToJson(xpc_bool_create(false))
+ );
+}
+
+TEST(JsonXpcConversionTest, Number) {
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(3.14)),
+ xpc_double_create(3.14)
+)
+ );
+ EXPECT_TRUE(
+json::Expr(3.14) == xpcToJson(xpc_double_create(3.14))
+ );
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(42)),
+ xpc_double_create(42)
+)
+ );
+ EXPECT_TRUE(
+json::Expr(42) == xpcToJson(xpc_double_create(42))
+ );
+ EXPECT_TRUE(
+json::Expr(42) == xpcToJson(xpc_int64_create(42))
+ );
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(-100)),
+ xpc_double_create(-100)
+)
+ );
+ EXPECT_TRUE(
+json::Expr(-100) == xpcToJson(xpc_double_create(-100))
+ );
+
+ unsigned long long bigPositiveValue = std::numeric_limits::max();
+ ++bigPositiveValue;
+ unsigned long long bigNegativeValue = std::numeric_limits::min();
+ --bigNegativeValue;
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(bigPositiveValue)),
+ xpc_double_create(bigPositiveValue)
+)
+ );
+ EXPECT_TRUE(
+json::Expr(bigPositiveValue) == xpcToJson(xpc_double_create(bigPositiveValue))
+ );
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(bigNegativeValue)),
+ xpc_double_create(bigNegativeValue)
+)
+ );
+ EXPECT_TRUE(
+json::Expr(bigNegativeValue) == xpcToJson(xpc_double_create(bigNegativeValue))
+ );
+}
+
+TEST(JsonXpcConversionTest, String) {
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr("foo")),
+ xpc_string_create("foo")
+)
+ );
+ EXPECT_TRUE(
+json::Expr("foo") == xpcToJson(xpc_string_create("foo"))
+ );
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr("")),
+ xpc_string_create("")
+)
+ );
+ EXPECT_TRUE(
+json::Expr("") == xpcToJson(xpc_string_create(""))
+ );
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr("123")),
+ xpc_string_create("123")
+)
+ );
+ EXPECT_TRUE(
+json::Expr("123") == xpcToJson(xpc_string_create("123"))
+ );
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(" ")),
+ xpc_string_create(" ")
+)
+ );
+ EXPECT_TRUE(
+json::Expr(" ") == xpcToJson(xpc_string_create(" "))
+ );
+
+ // Testing two different "patterns" just in case.
+ std::string kBStringOfAs("A", 1024);
+ std::string kBStringOfBs("B", 1024);
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(kBStringOfAs.c_str())),
+ xpc_string_create(kBStringOfAs.c_str())
+)
+ );
+ EXPECT_TRUE(
+json::Expr(kBStringOfAs.c_str()) == xpcToJson(xpc_string_create(kBStringOfAs.c_str()))
+ );
+
+ EXPECT_TRUE(
+xpc_equal(
+ jsonToXpc(json::Expr(kBStringOfBs.c_str())),
+ xpc_string_create(kBStringOfBs.c_str())
+)
+ );
+ EXPECT_TRUE(
+json::Expr(kBStringOfBs.c_str()) == xpcToJson(xpc_string_create(kBStringOfBs.c_str()))
+ );
+}
+
+TEST(JsonXpcConversionTest, Array) {
+ json::Expr JsonArray{true, "foo", nullptr, 42};
+
+ xpc_object_t XpcArray = []() {
+std::vector XpcArrayElements;
+XpcArrayElements.emplace_back(xpc_bool_create(true));
+XpcArrayElements.emplace_back(xpc_string_create("foo"));
+XpcArrayElements.emplace_back(xpc_null_create());
+XpcArrayElements.emplace_back(xpc_double_create(42));
+
+return xpc_array_create(XpcArrayElements.data(), XpcArrayElements.size());
+ }();
[PATCH] D47567: Implement CFI for indirect calls via a member function pointer.
pcc added inline comments.
Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1413
+ FD->getType(), Context.getRecordType(Base).getTypePtr()));
+ F->addTypeMetadata(0, Id);
+}
vlad.tsyrklevich wrote:
> It'd be nice to have a test that reaches this.
I'll add one.
Comment at: clang/lib/CodeGen/CodeGenModule.h:1256
+ std::vector
+ getMostBaseClasses(const CXXRecordDecl *RD);
vlad.tsyrklevich wrote:
> Could be helpful to have a comment here to ensure there is no confusion
> interpreting this as 'the most-base classes' and not 'most of the base
> classes'.
Will do.
Comment at: clang/lib/Driver/SanitizerArgs.cpp:233
+ options::OPT_fno_sanitize_cfi_cross_dso, false);
+ if (CfiCrossDso)
+Supported &= ~CFIMFCall;
vlad.tsyrklevich wrote:
> This will cause supplying both options to fail with `clang: error:
> unsupported option '-fsanitize=cfi-mfcall' for target ...`. Having it error
> out the same way as type generalization below where it states that
> cfi-cross-dso is unsupported with cfi-mfcall seems like a more helpful error.
The issue with that is that it would cause the flag combination `-fsanitize=cfi
-fsanitize-cfi-cross-dso` to fail with an unsupported error. So I think it
would need to work in a similar way as with the supported sanitizers. I guess I
could add something after line 293 below instead.
Comment at: clang/test/CodeGenCXX/type-metadata.cpp:281
// ITANIUM: [[FA_ID]] = distinct !{}
// MS: [[A8]] = !{i64 8, !"?AUA@@"}
vlad.tsyrklevich wrote:
> Any reason not to include AF64/CF64/FAF16 here?
No, I just forgot to add them. I'll do that.
Comment at: compiler-rt/lib/ubsan/ubsan_handlers.cc:645
+ const char *CheckKindStr = Data->CheckKind == CFITCK_NVMFCall
+ ? "non-virtual member function call"
+ : "indirect function call";
vlad.tsyrklevich wrote:
> s/member/pointer to member/ ?
Makes sense.
Comment at: compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc:126
+ case CFITCK_VMFCall:
+CheckKindStr = "virtual member function call";
+break;
vlad.tsyrklevich wrote:
> s/member/pointer to member/ ?
Ditto
https://reviews.llvm.org/D47567
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48559: [clangd] refactoring for XPC transport layer [NFCI]
jkorous created this revision.
jkorous added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, MaskRay, ioeric, ilya-biryukov, mgorny.
Hi all,
We finally finished a self-contained first version of our implementation of
alternative transport layer for macOS based on XPC.
To enable this I did couple of changes to current clangd design. Generally I
aimed for small amount of disruption and tried to keep it simple.
The notable changes are:
- enabled registration of request handlers to different dispatchers by
templatizing registerCallbackHandlers()
- factored out parts of JsonDispatcher that could be reused (created
DispatcherCommon.h/cpp)
- created abstraction over JsonOutput (class LSPOutput)
- removed of ClangdLSPServer::run() method so server can be run with different
dispatcher
- published IsDone and ShutdownRequestReceived through methods in
ClangdLSPServer class interface to support new dispatcher
We are also putting up the transport layer implementation itself for a review
soon so it will be more obvious where are we going to and what motivated some
of these changes.
Big thanks in advance to all reviewers!
Jan
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D48559
Files:
CMakeLists.txt
ClangdLSPServer.cpp
ClangdLSPServer.h
DispatcherCommon.cpp
DispatcherCommon.h
JSONRPCDispatcher.cpp
JSONRPCDispatcher.h
LSPOutput.h
ProtocolHandlers.cpp
ProtocolHandlers.h
tool/ClangdMain.cpp
Index: tool/ClangdMain.cpp
===
--- tool/ClangdMain.cpp
+++ tool/ClangdMain.cpp
@@ -19,7 +19,6 @@
#include "llvm/Support/Signals.h"
#include "llvm/Support/raw_ostream.h"
#include
-#include
#include
#include
#include
@@ -207,12 +206,6 @@
if (Tracer)
TracingSession.emplace(*Tracer);
- JSONOutput Out(llvm::outs(), llvm::errs(),
- InputMirrorStream ? InputMirrorStream.getPointer() : nullptr,
- PrettyPrint);
-
- clangd::LoggingSession LoggingSession(Out);
-
// If --compile-commands-dir arg was invoked, check value and override default
// path.
llvm::Optional CompileCommandsDirPath;
@@ -252,11 +245,27 @@
CCOpts.Limit = LimitResults;
CCOpts.BundleOverloads = CompletionStyle != Detailed;
- // Initialize and run ClangdLSPServer.
- ClangdLSPServer LSPServer(Out, CCOpts, CompileCommandsDirPath, Opts);
- constexpr int NoShutdownRequestErrorCode = 1;
+ ClangdLSPServer LSPServer(CCOpts, CompileCommandsDirPath, Opts);
+
llvm::set_thread_name("clangd.main");
// Change stdin to binary to not lose \r\n on windows.
llvm::sys::ChangeStdinToBinary();
- return LSPServer.run(stdin, InputStyle) ? 0 : NoShutdownRequestErrorCode;
+ {
+JSONRPCDispatcher Dispatcher([](const json::Expr &Params) {
+ replyError(ErrorCode::MethodNotFound, "method not found");
+});
+registerCallbackHandlers(Dispatcher, /*Callbacks=*/LSPServer);
+
+
+JSONOutput Out(llvm::outs(), llvm::errs(),
+ InputMirrorStream ? InputMirrorStream.getPointer() : nullptr,
+ PrettyPrint);
+
+clangd::LoggingSession LoggingSession(Out);
+
+runJSONRPCServerLoop(stdin, Out, InputStyle, Dispatcher, LSPServer.getIsDone());
+ }
+
+ constexpr int NoShutdownRequestErrorCode = 1;
+ return LSPServer.getShutdownRequestReceived() ? 0 : NoShutdownRequestErrorCode;
}
Index: ProtocolHandlers.h
===
--- ProtocolHandlers.h
+++ ProtocolHandlers.h
@@ -56,8 +56,63 @@
virtual void onChangeConfiguration(DidChangeConfigurationParams &Params) = 0;
};
-void registerCallbackHandlers(JSONRPCDispatcher &Dispatcher,
- ProtocolCallbacks &Callbacks);
+// Helper for attaching ProtocolCallbacks methods to a JSONRPCDispatcher.
+// Invoke like: Registerer("foo", &ProtocolCallbacks::onFoo)
+// onFoo should be: void onFoo(Ctx &C, FooParams &Params)
+// FooParams should have a fromJSON function.
+template
+struct HandlerRegisterer {
+ template
+ void operator()(StringRef Method, void (ProtocolCallbacks::*Handler)(Param)) {
+// Capture pointers by value, as the lambda will outlive this object.
+auto *Callbacks = this->Callbacks;
+Dispatcher.registerHandler(Method, [=](const json::Expr &RawParams) {
+ typename std::remove_reference::type P;
+ if (fromJSON(RawParams, P)) {
+(Callbacks->*Handler)(P);
+ } else {
+log("Failed to decode " + Method + " request.");
+ }
+});
+ }
+
+ DispatcherType &Dispatcher;
+ ProtocolCallbacks *Callbacks;
+};
+
+template
+void registerCallbackHandlers(DispatcherType &Dispatcher,
+ ProtocolCallbacks &Callbacks) {
+ HandlerRegisterer Register{Dispatcher, &Callbacks};
+
+ Register("initialize", &ProtocolCallbacks::onInitialize);
+ Register("shutdown", &ProtocolCallbacks::onShutdown);
+ Register("exit", &ProtocolCallbacks::onExit);
+ Register("t
Re: r335084 - Append new attributes to the end of an AttributeList.
On Mon, Jun 25, 2018 at 12:21 PM Richard Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On 23 June 2018 at 22:34, Michael Kruse via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Hi, >> >> multiple comments in the code indicate that the attribute order was >> surprising and probably has lead to bugs, and will lead to bugs in the >> future. The order had to be explicitly reversed to avoid those. This >> alone for me this seems a good reason to have the attributes in the >> order in which they appear in the source. >> > It would be nice it you could send a reproducer. At a glance, your >> case does not seem related since the format strings are function >> arguments, not attributes. >> >> Michael >> >> >> 2018-06-23 17:17 GMT-05:00 David Jones : >> > This commit seems to have some substantial downsides... for example, it >> now >> > flags calls like this as warnings: >> > >> http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/src/msgl-check.c?id=05ecefa943f339019b7127aa92cbb09f6fd49ed3#n478 >> > >> > Previously, the reverse order meant that the plural format string was >> > examined, but now it is only the singular string. Since the singular >> string >> > doesn't include a substitution, the unused format variable warning fires >> > after this revision. >> > >> > I don't see a strong argument for why one order is more correct than the >> > other; however, given that this is in conflict with real code found in >> the >> > wild, I think this needs to be addressed. >> > >> > Since the semantics of the ordering of multiple format args seems >> somewhat >> > ill-defined, it seems to me like reverting may be the best near-term >> choice. >> > I can imagine other ways to fix the diagnostic, but the only behaviour >> that >> > I would believe to be expected by existing code is the old one, so a >> change >> > like this one probably needs to be more carefully vetted before being >> > (re-)committed. >> >> Could you give more details about your concerns? > > > (I'm not sure what the problem is, but as a data point, Sema::checkCall > iterates over the FormatAttrs in order, so it's possible that changing the > order may have triggered a new warning. That may be due to a pre-existing > order-dependence bug, or it may be that we're losing an attribute here.) > > FWIW I just replied to the original review thread as well - there appear to be some warnings that are now missing that previously worked and some that are now in reverse order from the source. I think more work might need to happen before this patch should go back in. -eric > > Please let me know your plan. (If I don't hear back in a day or so, I'll >> go >> > ahead and revert for you as the safe default course of action.) >> >> On a weekend? > > > Yes; our policy is generally to revert to green if a patch causes > regressions that aren't going to be fixed in a few hours. This is generally > good for the committer, because it lets you figure out what's wrong and > deal with it on your own schedule rather than being pressured to fix it > urgently because you're blocking the work of others. > ___ > 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
[PATCH] D48100: Append new attributes to the end of an AttributeList.
echristo added subscribers: dlj, echristo.
echristo added a comment.
I've added a couple of inline comments here - between this and the comments in
the post-commit review from dlj it seems like we might want to revert this for
now and figure out the best way forward.
Thanks!
-eric
Comment at: test/Sema/attr-micromips.c:9
-__attribute__((micromips,mips16)) void foo5(); // expected-error
{{'micromips' and 'mips16' attributes are not compatible}} \
+__attribute__((micromips,mips16)) void foo5(); // expected-error {{'mips16'
and 'micromips' attributes are not compatible}} \
// expected-note {{conflicting
attribute is here}}
This seems to reverse? What's going on here? There are other occurrences too.
Comment at: test/Sema/attr-target-mv.c:98
int __attribute__((target("sse4.2"))) diff_cc(void);
-// expected-error@+1 {{multiversioned function declaration has a different
calling convention}}
+// expected-error@+1 {{attribute 'target' multiversioning cannot be combined
with other attributes}}
__vectorcall int __attribute__((target("arch=sandybridge"))) diff_cc(void);
This appears to have broken a particular error message?
Repository:
rC Clang
https://reviews.llvm.org/D48100
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D35110: [Analyzer] Constraint Manager Negates Difference
baloghadamsoftware updated this revision to Diff 152752.
baloghadamsoftware added a comment.
Comment fixed, assertions inserted, new tests added.
https://reviews.llvm.org/D35110
Files:
include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
test/Analysis/constraint_manager_negate_difference.c
test/Analysis/ptr-arith.c
Index: test/Analysis/ptr-arith.c
===
--- test/Analysis/ptr-arith.c
+++ test/Analysis/ptr-arith.c
@@ -265,49 +265,26 @@
clang_analyzer_eval((rhs - lhs) > 0); // expected-warning{{TRUE}}
}
-//---
-// False positives
-//---
-
void zero_implies_reversed_equal(int *lhs, int *rhs) {
clang_analyzer_eval((rhs - lhs) == 0); // expected-warning{{UNKNOWN}}
if ((rhs - lhs) == 0) {
-#ifdef ANALYZER_CM_Z3
clang_analyzer_eval(rhs != lhs); // expected-warning{{FALSE}}
clang_analyzer_eval(rhs == lhs); // expected-warning{{TRUE}}
-#else
-clang_analyzer_eval(rhs != lhs); // expected-warning{{UNKNOWN}}
-clang_analyzer_eval(rhs == lhs); // expected-warning{{UNKNOWN}}
-#endif
return;
}
clang_analyzer_eval((rhs - lhs) == 0); // expected-warning{{FALSE}}
-#ifdef ANALYZER_CM_Z3
clang_analyzer_eval(rhs == lhs); // expected-warning{{FALSE}}
clang_analyzer_eval(rhs != lhs); // expected-warning{{TRUE}}
-#else
- clang_analyzer_eval(rhs == lhs); // expected-warning{{UNKNOWN}}
- clang_analyzer_eval(rhs != lhs); // expected-warning{{UNKNOWN}}
-#endif
}
void canonical_equal(int *lhs, int *rhs) {
clang_analyzer_eval(lhs == rhs); // expected-warning{{UNKNOWN}}
if (lhs == rhs) {
-#ifdef ANALYZER_CM_Z3
clang_analyzer_eval(rhs == lhs); // expected-warning{{TRUE}}
-#else
-clang_analyzer_eval(rhs == lhs); // expected-warning{{UNKNOWN}}
-#endif
return;
}
clang_analyzer_eval(lhs == rhs); // expected-warning{{FALSE}}
-
-#ifdef ANALYZER_CM_Z3
clang_analyzer_eval(rhs == lhs); // expected-warning{{FALSE}}
-#else
- clang_analyzer_eval(rhs == lhs); // expected-warning{{UNKNOWN}}
-#endif
}
void compare_element_region_and_base(int *p) {
Index: test/Analysis/constraint_manager_negate_difference.c
===
--- /dev/null
+++ test/Analysis/constraint_manager_negate_difference.c
@@ -0,0 +1,98 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.ExprInspection,core.builtin -analyzer-config aggressive-relational-comparison-simplification=true -verify %s
+
+void clang_analyzer_eval(int);
+
+void exit(int);
+
+#define UINT_MAX (~0U)
+#define INT_MAX (UINT_MAX & (UINT_MAX >> 1))
+#define INT_MIN (UINT_MAX & ~(UINT_MAX >> 1))
+
+extern void __assert_fail (__const char *__assertion, __const char *__file,
+unsigned int __line, __const char *__function)
+ __attribute__ ((__noreturn__));
+#define assert(expr) \
+ ((expr) ? (void)(0) : __assert_fail (#expr, __FILE__, __LINE__, __func__))
+
+void assert_in_range(int x) {
+ assert(x <= ((int)INT_MAX / 4));
+ assert(x >= -(((int)INT_MAX) / 4));
+}
+
+void assert_in_wide_range(int x) {
+ assert(x <= ((int)INT_MAX / 2));
+ assert(x >= -(((int)INT_MAX) / 2));
+}
+
+void assert_in_range_2(int m, int n) {
+ assert_in_range(m);
+ assert_in_range(n);
+}
+
+void equal(int m, int n) {
+ assert_in_range_2(m, n);
+ if (m != n)
+return;
+ assert_in_wide_range(m - n);
+ clang_analyzer_eval(n == m); // expected-warning{{TRUE}}
+}
+
+void non_equal(int m, int n) {
+ assert_in_range_2(m, n);
+ if (m == n)
+return;
+ assert_in_wide_range(m - n);
+ clang_analyzer_eval(n != m); // expected-warning{{TRUE}}
+}
+
+void less_or_equal(int m, int n) {
+ assert_in_range_2(m, n);
+ if (m < n)
+return;
+ assert_in_wide_range(m - n);
+ clang_analyzer_eval(n <= m); // expected-warning{{TRUE}}
+}
+
+void less(int m, int n) {
+ assert_in_range_2(m, n);
+ if (m <= n)
+return;
+ assert_in_wide_range(m - n);
+ clang_analyzer_eval(n < m); // expected-warning{{TRUE}}
+}
+
+void greater_or_equal(int m, int n) {
+ assert_in_range_2(m, n);
+ if (m > n)
+return;
+ assert_in_wide_range(m - n);
+ clang_analyzer_eval(n >= m); // expected-warning{{TRUE}}
+}
+
+void greater(int m, int n) {
+ assert_in_range_2(m, n);
+ if (m >= n)
+return;
+ assert_in_wide_range(m - n);
+ clang_analyzer_eval(n > m); // expected-warning{{TRUE}}
+}
+
+void negate_positive_range(int m, int n) {
+ if (m - n <= 0)
+return;
+ clang_analyzer_eval(n - m < 0); // expected-warning{{TRUE}}
+ clang_analyzer_eval(n - m > INT_MIN); // expected-warning{{TRUE}}
+ clang_analyzer_eval(n - m == INT_MIN); // expected-warning{{FALSE}}
+}
+
+void negate_int_min(int m, int n) {
+ if (m - n != INT_MIN)
+return;
+ clang_analyzer_eval(n - m == INT_MIN); // expected-warning{{TRUE}}
+}
+
+void negate_mixed(int m, int n) {
+ if (m -n > INT_MIN && m - n <= 0)
+return;
+ clang
[PATCH] D47567: Implement CFI for indirect calls via a member function pointer.
vlad.tsyrklevich accepted this revision.
vlad.tsyrklevich added a comment.
This revision is now accepted and ready to land.
I think it would be clearer to replace uses of 'member function pointer' with
'pointer to member function'; however, a google search shows that the usage of
both terms is basically the same so not this might be just be my own bias
coming through.
Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1413
+ FD->getType(), Context.getRecordType(Base).getTypePtr()));
+ F->addTypeMetadata(0, Id);
+}
It'd be nice to have a test that reaches this.
Comment at: clang/lib/CodeGen/CodeGenModule.h:1256
+ std::vector
+ getMostBaseClasses(const CXXRecordDecl *RD);
Could be helpful to have a comment here to ensure there is no confusion
interpreting this as 'the most-base classes' and not 'most of the base classes'.
Comment at: clang/lib/Driver/SanitizerArgs.cpp:233
+ options::OPT_fno_sanitize_cfi_cross_dso, false);
+ if (CfiCrossDso)
+Supported &= ~CFIMFCall;
This will cause supplying both options to fail with `clang: error: unsupported
option '-fsanitize=cfi-mfcall' for target ...`. Having it error out the same
way as type generalization below where it states that cfi-cross-dso is
unsupported with cfi-mfcall seems like a more helpful error.
Comment at: clang/test/CodeGenCXX/type-metadata.cpp:281
// ITANIUM: [[FA_ID]] = distinct !{}
// MS: [[A8]] = !{i64 8, !"?AUA@@"}
Any reason not to include AF64/CF64/FAF16 here?
Comment at: compiler-rt/lib/ubsan/ubsan_handlers.cc:645
+ const char *CheckKindStr = Data->CheckKind == CFITCK_NVMFCall
+ ? "non-virtual member function call"
+ : "indirect function call";
s/member/pointer to member/ ?
Comment at: compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc:126
+ case CFITCK_VMFCall:
+CheckKindStr = "virtual member function call";
+break;
s/member/pointer to member/ ?
https://reviews.llvm.org/D47567
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r335084 - Append new attributes to the end of an AttributeList.
On 23 June 2018 at 22:34, Michael Kruse via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hi, > > multiple comments in the code indicate that the attribute order was > surprising and probably has lead to bugs, and will lead to bugs in the > future. The order had to be explicitly reversed to avoid those. This > alone for me this seems a good reason to have the attributes in the > order in which they appear in the source. > > It would be nice it you could send a reproducer. At a glance, your > case does not seem related since the format strings are function > arguments, not attributes. > > Michael > > > 2018-06-23 17:17 GMT-05:00 David Jones : > > This commit seems to have some substantial downsides... for example, it > now > > flags calls like this as warnings: > > http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext- > tools/src/msgl-check.c?id=05ecefa943f339019b7127aa92cbb09f6fd49ed3#n478 > > > > Previously, the reverse order meant that the plural format string was > > examined, but now it is only the singular string. Since the singular > string > > doesn't include a substitution, the unused format variable warning fires > > after this revision. > > > > I don't see a strong argument for why one order is more correct than the > > other; however, given that this is in conflict with real code found in > the > > wild, I think this needs to be addressed. > > > > Since the semantics of the ordering of multiple format args seems > somewhat > > ill-defined, it seems to me like reverting may be the best near-term > choice. > > I can imagine other ways to fix the diagnostic, but the only behaviour > that > > I would believe to be expected by existing code is the old one, so a > change > > like this one probably needs to be more carefully vetted before being > > (re-)committed. > > Could you give more details about your concerns? (I'm not sure what the problem is, but as a data point, Sema::checkCall iterates over the FormatAttrs in order, so it's possible that changing the order may have triggered a new warning. That may be due to a pre-existing order-dependence bug, or it may be that we're losing an attribute here.) > Please let me know your plan. (If I don't hear back in a day or so, I'll > go > > ahead and revert for you as the safe default course of action.) > > On a weekend? Yes; our policy is generally to revert to green if a patch causes regressions that aren't going to be fixed in a few hours. This is generally good for the committer, because it lets you figure out what's wrong and deal with it on your own schedule rather than being pressured to fix it urgently because you're blocking the work of others. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48532: [analyzer] Add support for std::basic_string::data() in DanglingInternalBufferChecker
rnkovacs added inline comments. Comment at: test/Analysis/dangling-internal-buffer.cpp:10 const CharT *c_str(); + const CharT *data(); }; xazax.hun wrote: > Note that these methods are const according to the standard. Even if it does > not make any difference for this check we should follow the signatures. Also, > from c++17 there is a non-const overload of data. Oh, right, thanks. Fixed here and in D48522. https://reviews.llvm.org/D48532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48532: [analyzer] Add support for std::basic_string::data() in DanglingInternalBufferChecker
rnkovacs updated this revision to Diff 152737.
rnkovacs marked an inline comment as done.
https://reviews.llvm.org/D48532
Files:
lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
test/Analysis/dangling-internal-buffer.cpp
Index: test/Analysis/dangling-internal-buffer.cpp
===
--- test/Analysis/dangling-internal-buffer.cpp
+++ test/Analysis/dangling-internal-buffer.cpp
@@ -7,6 +7,8 @@
public:
~basic_string();
const CharT *c_str() const;
+ const CharT *data() const;
+ CharT *data();
};
typedef basic_string string;
@@ -21,63 +23,105 @@
void consume(const char16_t *) {}
void consume(const char32_t *) {}
-void deref_after_scope_char() {
+void deref_after_scope_char_cstr() {
const char *c;
{
std::string s;
c = s.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
+ std::string s;
+ const char *c2 = s.c_str();
consume(c); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
}
-void deref_after_scope_char2() {
+void deref_after_scope_char_data() {
const char *c;
{
std::string s;
-c = s.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
+c = s.data(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
std::string s;
- const char *c2 = s.c_str();
+ const char *c2 = s.data();
+ consume(c); // expected-warning {{Use of memory after it is freed}}
+ // expected-note@-1 {{Use of memory after it is freed}}
+}
+
+void deref_after_scope_char_data_non_const() {
+ char *c;
+ {
+std::string s;
+c = s.data(); // expected-note {{Pointer to dangling buffer was obtained here}}
+ } // expected-note {{Internal buffer is released because the object was destroyed}}
+ std::string s;
+ char *c2 = s.data();
consume(c); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
}
-void deref_after_scope_wchar_t() {
+
+void deref_after_scope_wchar_t_cstr() {
const wchar_t *w;
{
std::wstring ws;
w = ws.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
+ std::wstring ws;
+ const wchar_t *w2 = ws.c_str();
+ consume(w); // expected-warning {{Use of memory after it is freed}}
+ // expected-note@-1 {{Use of memory after it is freed}}
+}
+
+void deref_after_scope_wchar_t_data() {
+ const wchar_t *w;
+ {
+std::wstring ws;
+w = ws.data(); // expected-note {{Pointer to dangling buffer was obtained here}}
+ } // expected-note {{Internal buffer is released because the object was destroyed}}
+ std::wstring ws;
+ const wchar_t *w2 = ws.data();
consume(w); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
}
-void deref_after_scope_char16_t() {
+void deref_after_scope_char16_t_cstr() {
const char16_t *c16;
{
std::u16string s16;
c16 = s16.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
+ std::u16string s16;
+ const char16_t *c16_2 = s16.c_str();
consume(c16); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
}
-void deref_after_scope_char32_t() {
+void deref_after_scope_char32_t_data() {
const char32_t *c32;
{
std::u32string s32;
-c32 = s32.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
+c32 = s32.data(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
+ std::u32string s32;
+ const char32_t *c32_2 = s32.data();
consume(c32); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
}
-void deref_after_scope_ok() {
+void deref_after_scope_cstr_ok() {
const char *c;
std::string s;
{
c = s.c_str();
}
consume(c); // no-warning
}
+
+void deref_after_scope_data_ok() {
+ const char *c;
+ std::string s;
+ {
+c = s.data();
+ }
+ consume(c); // no-warning
+}
Index: lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
+++ lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
@@ -24,15 +24,16 @@
using namespace clang;
using namespace ento;
-// FIXME: c_str() may be called on a string object many times, so it should
-// have a list of symbols associate
r335510 - [WebAssembly] Add no-prototype attribute to prototype-less C functions
Author: sbc
Date: Mon Jun 25 11:47:32 2018
New Revision: 335510
URL: http://llvm.org/viewvc/llvm-project?rev=335510&view=rev
Log:
[WebAssembly] Add no-prototype attribute to prototype-less C functions
The WebAssembly backend in particular benefits from being
able to distinguish between varargs functions (...) and prototype-less
C functions.
Differential Revision: https://reviews.llvm.org/D48443
Added:
cfe/trunk/test/CodeGen/no-prototype.c (with props)
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=335510&r1=335509&r2=335510&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Jun 25 11:47:32 2018
@@ -747,6 +747,15 @@ class WebAssemblyTargetCodeGenInfo final
public:
explicit WebAssemblyTargetCodeGenInfo(CodeGen::CodeGenTypes &CGT)
: TargetCodeGenInfo(new WebAssemblyABIInfo(CGT)) {}
+
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ CodeGen::CodeGenModule &CGM) const override {
+if (auto *FD = dyn_cast_or_null(D)) {
+ llvm::Function *Fn = cast(GV);
+ if (!FD->doesThisDeclarationHaveABody() && !FD->hasPrototype())
+Fn->addFnAttr("no-prototype");
+}
+ }
};
/// Classify argument of given type \p Ty.
Added: cfe/trunk/test/CodeGen/no-prototype.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/no-prototype.c?rev=335510&view=auto
==
--- cfe/trunk/test/CodeGen/no-prototype.c (added)
+++ cfe/trunk/test/CodeGen/no-prototype.c Mon Jun 25 11:47:32 2018
@@ -0,0 +1,20 @@
+// REQUIRES: webassembly-registered-target
+// RUN: %clang_cc1 -triple wasm32 -emit-llvm %s -o - | FileCheck %s
+
+int foo();
+
+int bar(int a) {
+ return foo();
+}
+
+int baz() {
+ return foo();
+}
+
+// CHECK: define i32 @bar(i32 %a) [[BAR_ATTR:#[0-9]+]] {
+// CHECK: declare i32 @foo(...) [[FOO_ATTR:#[0-9]+]]
+// CHECK: define i32 @baz() [[BAZ_ATTR:#[0-9]+]] {
+
+// CHECK: attributes [[FOO_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
+// CHECK-NOT: attributes [[BAR_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
+// CHECK-NOT: attributes [[BAZ_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
Propchange: cfe/trunk/test/CodeGen/no-prototype.c
--
svn:eol-style = LF
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48443: [WebAssembly] Add no-prototype attribute to prototype-less C functions
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335510: [WebAssembly] Add no-prototype attribute to
prototype-less C functions (authored by sbc, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D48443
Files:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/no-prototype.c
Index: cfe/trunk/test/CodeGen/no-prototype.c
===
--- cfe/trunk/test/CodeGen/no-prototype.c
+++ cfe/trunk/test/CodeGen/no-prototype.c
@@ -0,0 +1,20 @@
+// REQUIRES: webassembly-registered-target
+// RUN: %clang_cc1 -triple wasm32 -emit-llvm %s -o - | FileCheck %s
+
+int foo();
+
+int bar(int a) {
+ return foo();
+}
+
+int baz() {
+ return foo();
+}
+
+// CHECK: define i32 @bar(i32 %a) [[BAR_ATTR:#[0-9]+]] {
+// CHECK: declare i32 @foo(...) [[FOO_ATTR:#[0-9]+]]
+// CHECK: define i32 @baz() [[BAZ_ATTR:#[0-9]+]] {
+
+// CHECK: attributes [[FOO_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
+// CHECK-NOT: attributes [[BAR_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
+// CHECK-NOT: attributes [[BAZ_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
Index: cfe/trunk/lib/CodeGen/TargetInfo.cpp
===
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp
@@ -747,6 +747,15 @@
public:
explicit WebAssemblyTargetCodeGenInfo(CodeGen::CodeGenTypes &CGT)
: TargetCodeGenInfo(new WebAssemblyABIInfo(CGT)) {}
+
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ CodeGen::CodeGenModule &CGM) const override {
+if (auto *FD = dyn_cast_or_null(D)) {
+ llvm::Function *Fn = cast(GV);
+ if (!FD->doesThisDeclarationHaveABody() && !FD->hasPrototype())
+Fn->addFnAttr("no-prototype");
+}
+ }
};
/// Classify argument of given type \p Ty.
Index: cfe/trunk/test/CodeGen/no-prototype.c
===
--- cfe/trunk/test/CodeGen/no-prototype.c
+++ cfe/trunk/test/CodeGen/no-prototype.c
@@ -0,0 +1,20 @@
+// REQUIRES: webassembly-registered-target
+// RUN: %clang_cc1 -triple wasm32 -emit-llvm %s -o - | FileCheck %s
+
+int foo();
+
+int bar(int a) {
+ return foo();
+}
+
+int baz() {
+ return foo();
+}
+
+// CHECK: define i32 @bar(i32 %a) [[BAR_ATTR:#[0-9]+]] {
+// CHECK: declare i32 @foo(...) [[FOO_ATTR:#[0-9]+]]
+// CHECK: define i32 @baz() [[BAZ_ATTR:#[0-9]+]] {
+
+// CHECK: attributes [[FOO_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
+// CHECK-NOT: attributes [[BAR_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
+// CHECK-NOT: attributes [[BAZ_ATTR]] = { {{.*}}"no-prototype"{{.*}} }
Index: cfe/trunk/lib/CodeGen/TargetInfo.cpp
===
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp
@@ -747,6 +747,15 @@
public:
explicit WebAssemblyTargetCodeGenInfo(CodeGen::CodeGenTypes &CGT)
: TargetCodeGenInfo(new WebAssemblyABIInfo(CGT)) {}
+
+ void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+ CodeGen::CodeGenModule &CGM) const override {
+if (auto *FD = dyn_cast_or_null(D)) {
+ llvm::Function *Fn = cast(GV);
+ if (!FD->doesThisDeclarationHaveABody() && !FD->hasPrototype())
+Fn->addFnAttr("no-prototype");
+}
+ }
};
/// Classify argument of given type \p Ty.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D45679: [clang-tidy] Add ExprMutationAnalyzer, that analyzes whether an expression is mutated within a statement.
shuaiwang added a comment. Could someone help commit this now that the build issue with header include is fixed? Thanks a lot! (meanwhile I'm requesting commit access) In https://reviews.llvm.org/D45679#1132327, @alexfh wrote: > In https://reviews.llvm.org/D45679#1132086, @JonasToth wrote: > > > It might be the case, that the test is run with -no-stdinc (or similar), > > so the standard library is not available. > > > Tests should be self-contained and must not depend on any system headers. > Standard library implementations may differ, which would make tests brittle. > Instead, tests should mock implementations of the APIs they work with (if > necessary, multiple times - once for every distinct standard library version > the check supports). Yep. It doesn't include any headers anymore :) Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D45679 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47814: Teach libc++ to use native NetBSD's max_align_t
krytarowski added a comment. ping^2 Repository: rL LLVM https://reviews.llvm.org/D47814 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r335507 - [CMake] Fix install-cxx target.
Author: morehouse
Date: Mon Jun 25 11:01:51 2018
New Revision: 335507
URL: http://llvm.org/viewvc/llvm-project?rev=335507&view=rev
Log:
[CMake] Fix install-cxx target.
Was broken by r334477.
Modified:
libcxx/trunk/include/CMakeLists.txt
Modified: libcxx/trunk/include/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=335507&r1=335506&r2=335507&view=diff
==
--- libcxx/trunk/include/CMakeLists.txt (original)
+++ libcxx/trunk/include/CMakeLists.txt Mon Jun 25 11:01:51 2018
@@ -255,7 +255,7 @@ if (LIBCXX_INSTALL_HEADERS)
if (NOT CMAKE_CONFIGURATION_TYPES)
add_custom_target(install-cxx-headers
- DEPENDS cxx-headers ${generated_config_deps}
+ DEPENDS cxx_headers ${generated_config_deps}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=cxx-headers
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335504 - [MachineOutliner] Outline from linkonceodrs by default in LTO when -moutline is passed
Author: paquette
Date: Mon Jun 25 10:36:05 2018
New Revision: 335504
URL: http://llvm.org/viewvc/llvm-project?rev=335504&view=rev
Log:
[MachineOutliner] Outline from linkonceodrs by default in LTO when -moutline is
passed
Pass -enable-linkonceodr-outlining by default when LTO is enabled.
The outliner shouldn't compete with any sort of linker deduplication
on linkonceodr functions when LTO is enabled. Therefore, this behaviour
should be the default.
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/aarch64-outliner.c
Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=335504&r1=335503&r2=335504&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Jun 25 10:36:05 2018
@@ -1482,6 +1482,14 @@ void Clang::AddAArch64TargetArgs(const A
if (A->getOption().matches(options::OPT_moutline)) {
CmdArgs.push_back("-mllvm");
CmdArgs.push_back("-enable-machine-outliner");
+
+ // The outliner shouldn't compete with linkers that dedupe linkonceodr
+ // functions in LTO. Enable that behaviour by default when compiling with
+ // LTO.
+ if (getToolChain().getDriver().isUsingLTO()) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-enable-linkonceodr-outlining");
+ }
}
}
}
Modified: cfe/trunk/test/Driver/aarch64-outliner.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/aarch64-outliner.c?rev=335504&r1=335503&r2=335504&view=diff
==
--- cfe/trunk/test/Driver/aarch64-outliner.c (original)
+++ cfe/trunk/test/Driver/aarch64-outliner.c Mon Jun 25 10:36:05 2018
@@ -3,3 +3,7 @@
// ON: "-mllvm" "-enable-machine-outliner"
// RUN: %clang -target aarch64 -moutline -mno-outline -S %s -### 2>&1 |
FileCheck %s -check-prefix=OFF
// OFF-NOT: "-mllvm" "-enable-machine-outliner"
+// RUN: %clang -target aarch64 -moutline -flto=thin -S %s -### 2>&1 |
FileCheck %s -check-prefix=FLTO
+// FLTO: "-mllvm" "-enable-linkonceodr-outlining"
+// RUN: %clang -target aarch64 -moutline -flto=full -S %s -### 2>&1 |
FileCheck %s -check-prefix=TLTO
+// TLTO: "-mllvm" "-enable-linkonceodr-outlining"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335503 - [MachineOutliner] Make last of -moutline/-mno-outline win
Author: paquette
Date: Mon Jun 25 10:27:51 2018
New Revision: 335503
URL: http://llvm.org/viewvc/llvm-project?rev=335503&view=rev
Log:
[MachineOutliner] Make last of -moutline/-mno-outline win
The expected behaviour of command-line flags to clang is to have
the last of -m(whatever) and -mno-(whatever) win. The outliner
didn't do that. This fixes that and updates the test.
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/aarch64-outliner.c
Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=335503&r1=335502&r2=335503&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Jun 25 10:27:51 2018
@@ -1477,10 +1477,12 @@ void Clang::AddAArch64TargetArgs(const A
CmdArgs.push_back("-aarch64-enable-global-merge=true");
}
- if (!Args.hasArg(options::OPT_mno_outline) &&
- Args.getLastArg(options::OPT_moutline)) {
-CmdArgs.push_back("-mllvm");
-CmdArgs.push_back("-enable-machine-outliner");
+ if (Arg *A = Args.getLastArg(options::OPT_moutline,
+ options::OPT_mno_outline)) {
+if (A->getOption().matches(options::OPT_moutline)) {
+ CmdArgs.push_back("-mllvm");
+ CmdArgs.push_back("-enable-machine-outliner");
+}
}
}
Modified: cfe/trunk/test/Driver/aarch64-outliner.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/aarch64-outliner.c?rev=335503&r1=335502&r2=335503&view=diff
==
--- cfe/trunk/test/Driver/aarch64-outliner.c (original)
+++ cfe/trunk/test/Driver/aarch64-outliner.c Mon Jun 25 10:27:51 2018
@@ -1,9 +1,5 @@
// REQUIRES: aarch64-registered-target
-
// RUN: %clang -target aarch64 -moutline -S %s -### 2>&1 | FileCheck %s
-check-prefix=ON
// ON: "-mllvm" "-enable-machine-outliner"
-
-// RUN: %clang -target aarch64 -moutline -mno-outline -S %s -### 2>&1 |
FileCheck %s -check-prefix=OFF1
-// RUN: %clang -target aarch64 -mno-outline -moutline -S %s -### 2>&1 |
FileCheck %s -check-prefix=OFF2
-// OFF1-NOT: "-mllvm" "-enable-machine-outliner"
-// OFF2-NOT: "-mllvm" "-enable-machine-outliner"
+// RUN: %clang -target aarch64 -moutline -mno-outline -S %s -### 2>&1 |
FileCheck %s -check-prefix=OFF
+// OFF-NOT: "-mllvm" "-enable-machine-outliner"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48522: [analyzer] Highlight c_str() call in DanglingInternalBuffer checker
rnkovacs updated this revision to Diff 152719.
rnkovacs added a comment.
Fixed the constness of `c_str()` in the test file.
https://reviews.llvm.org/D48522
Files:
lib/StaticAnalyzer/Checkers/AllocationState.h
lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
lib/StaticAnalyzer/Checkers/MallocChecker.cpp
test/Analysis/dangling-internal-buffer.cpp
Index: test/Analysis/dangling-internal-buffer.cpp
===
--- test/Analysis/dangling-internal-buffer.cpp
+++ test/Analysis/dangling-internal-buffer.cpp
@@ -6,7 +6,7 @@
class basic_string {
public:
~basic_string();
- const CharT *c_str();
+ const CharT *c_str() const;
};
typedef basic_string string;
@@ -25,17 +25,29 @@
const char *c;
{
std::string s;
-c = s.c_str();
+c = s.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
+ } // expected-note {{Internal buffer is released because the object was destroyed}}
+ consume(c); // expected-warning {{Use of memory after it is freed}}
+ // expected-note@-1 {{Use of memory after it is freed}}
+}
+
+void deref_after_scope_char2() {
+ const char *c;
+ {
+std::string s;
+c = s.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
+ std::string s;
+ const char *c2 = s.c_str();
consume(c); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
}
void deref_after_scope_wchar_t() {
const wchar_t *w;
{
std::wstring ws;
-w = ws.c_str();
+w = ws.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
consume(w); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
@@ -45,7 +57,7 @@
const char16_t *c16;
{
std::u16string s16;
-c16 = s16.c_str();
+c16 = s16.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
consume(c16); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
@@ -55,7 +67,7 @@
const char32_t *c32;
{
std::u32string s32;
-c32 = s32.c_str();
+c32 = s32.c_str(); // expected-note {{Pointer to dangling buffer was obtained here}}
} // expected-note {{Internal buffer is released because the object was destroyed}}
consume(c32); // expected-warning {{Use of memory after it is freed}}
// expected-note@-1 {{Use of memory after it is freed}}
Index: lib/StaticAnalyzer/Checkers/MallocChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MallocChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MallocChecker.cpp
@@ -1994,6 +1994,11 @@
R->markInteresting(Sym);
R->addRange(Range);
R->addVisitor(llvm::make_unique(Sym));
+
+const RefState *RS = C.getState()->get(Sym);
+if (RS->getAllocationFamily() == AF_InternalBuffer)
+ R->addVisitor(allocation_state::getDanglingBufferBRVisitor(Sym));
+
C.emitReport(std::move(R));
}
}
Index: lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
+++ lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
@@ -7,30 +7,67 @@
//
//===--===//
//
-// This file defines a check that marks a raw pointer to a C++ standard library
-// container's inner buffer released when the object is destroyed. This
-// information can be used by MallocChecker to detect use-after-free problems.
+// This file defines a check that marks a raw pointer to a C++ container's
+// inner buffer released when the object is destroyed. This information can
+// be used by MallocChecker to detect use-after-free problems.
//
//===--===//
+#include "AllocationState.h"
#include "ClangSACheckers.h"
#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
#include "clang/StaticAnalyzer/Core/BugReporter/CommonBugCategories.h"
#include "clang/StaticAnalyzer/Core/Checker.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
-#include "AllocationState.h"
using namespace clang;
using namespace ento;
+// FIXME: c_str() may be called on a string object many times, so it should
+// have a list of symbols associated with it.
+REGISTER_MAP_WITH_PROGRAMSTATE(RawPtrMap, const MemRegion *, SymbolRef)
+
namespace {
-class DanglingInternalBufferChecker : public Checker {
+cl
[PATCH] D45454: Make __gcov_flush visible outside a shared library
chh added a comment. In https://reviews.llvm.org/D45454#1142197, @marco-c wrote: > In https://reviews.llvm.org/D45454#1070884, @belleyb wrote: > > > @chh I had a chance to try out your proposed changes. It's not causing us > > any trouble. In fact, `__gcov_flush()` is not even used at all (at least in > > LLVM 5.0.1).. I can recompile llvm, compiler_rt and clang and re-run all > > the tests with `__gcov_flush` commented out! No problem. > > > > I would suggest adding a bit more documentation to `__gcov_flush()`, thus > > describing what those "special cases" are... > > > __gcov_flush is only used if you actually call it (it's needed for example if > you want to profile only part of your program). > > In GCC, __gcov_flush is not hidden, so perhaps we should do the same to keep > the same behavior? I've also submitted https://reviews.llvm.org/D48538, which > is making __gcov_flush flush counters for all shared libraries (like GCC > does, with the same caveat: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879). I have no problem keeping these functions compatible with GCC. My earlier proposal and David's comment in the mailing list seemed to be lost and not showing here. So, let me summarize the case here. This change should make `__gcov_flush` not hidden as before in GCC, but earlier change made it hidden as well as other `llvm_gov_*` functions. Could we have both `__gov_flush` and `llvm_gov_flush` functions, one unhidden and one hidden? https://reviews.llvm.org/D45454 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335495 - Use Triple::isMIPS() instead of enumerating all Triples. NFC
Author: arichardson
Date: Mon Jun 25 09:49:52 2018
New Revision: 335495
URL: http://llvm.org/viewvc/llvm-project?rev=335495&view=rev
Log:
Use Triple::isMIPS() instead of enumerating all Triples. NFC
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D48549
Modified:
cfe/trunk/lib/Basic/Targets/Mips.cpp
cfe/trunk/lib/Basic/Targets/Mips.h
cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
cfe/trunk/lib/Driver/ToolChains/Arch/Mips.h
cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/lib/Driver/ToolChains/Linux.cpp
cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
cfe/trunk/lib/Driver/ToolChains/OpenBSD.cpp
Modified: cfe/trunk/lib/Basic/Targets/Mips.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/Mips.cpp?rev=335495&r1=335494&r2=335495&view=diff
==
--- cfe/trunk/lib/Basic/Targets/Mips.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/Mips.cpp Mon Jun 25 09:49:52 2018
@@ -200,9 +200,7 @@ ArrayRef MipsTargetInfo::
bool MipsTargetInfo::validateTarget(DiagnosticsEngine &Diags) const {
// microMIPS64R6 backend was removed.
- if ((getTriple().getArch() == llvm::Triple::mips64 ||
- getTriple().getArch() == llvm::Triple::mips64el) &&
- IsMicromips && (ABI == "n32" || ABI == "n64")) {
+ if (getTriple().isMIPS64() && IsMicromips && (ABI == "n32" || ABI == "n64"))
{
Diags.Report(diag::err_target_unsupported_cpu_for_micromips) << CPU;
return false;
}
@@ -222,9 +220,7 @@ bool MipsTargetInfo::validateTarget(Diag
// FIXME: It's valid to use O32 on a mips64/mips64el triple but the backend
//can't handle this yet. It's better to fail here than on the
//backend assertion.
- if ((getTriple().getArch() == llvm::Triple::mips64 ||
- getTriple().getArch() == llvm::Triple::mips64el) &&
- ABI == "o32") {
+ if (getTriple().isMIPS64() && ABI == "o32") {
Diags.Report(diag::err_target_unsupported_abi_for_triple)
<< ABI << getTriple().str();
return false;
@@ -233,9 +229,7 @@ bool MipsTargetInfo::validateTarget(Diag
// FIXME: It's valid to use N32/N64 on a mips/mipsel triple but the backend
//can't handle this yet. It's better to fail here than on the
//backend assertion.
- if ((getTriple().getArch() == llvm::Triple::mips ||
- getTriple().getArch() == llvm::Triple::mipsel) &&
- (ABI == "n32" || ABI == "n64")) {
+ if (getTriple().isMIPS32() && (ABI == "n32" || ABI == "n64")) {
Diags.Report(diag::err_target_unsupported_abi_for_triple)
<< ABI << getTriple().str();
return false;
Modified: cfe/trunk/lib/Basic/Targets/Mips.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/Mips.h?rev=335495&r1=335494&r2=335495&view=diff
==
--- cfe/trunk/lib/Basic/Targets/Mips.h (original)
+++ cfe/trunk/lib/Basic/Targets/Mips.h Mon Jun 25 09:49:52 2018
@@ -69,10 +69,7 @@ public:
UseIndirectJumpHazard(false), HasFP64(false) {
TheCXXABI.set(TargetCXXABI::GenericMIPS);
-setABI((getTriple().getArch() == llvm::Triple::mips ||
-getTriple().getArch() == llvm::Triple::mipsel)
- ? "o32"
- : "n64");
+setABI(getTriple().isMIPS32() ? "o32" : "n64");
CPU = ABI == "o32" ? "mips32r2" : "mips64r2";
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp?rev=335495&r1=335494&r2=335495&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp Mon Jun 25 09:49:52 2018
@@ -20,11 +20,6 @@ using namespace clang::driver::tools;
using namespace clang;
using namespace llvm::opt;
-bool tools::isMipsArch(llvm::Triple::ArchType Arch) {
- return Arch == llvm::Triple::mips || Arch == llvm::Triple::mipsel ||
- Arch == llvm::Triple::mips64 || Arch == llvm::Triple::mips64el;
-}
-
// Get CPU and ABI names. They are not independent
// so we have to calculate them together.
void mips::getMipsCPUAndABI(const ArgList &Args, const llvm::Triple &Triple,
@@ -106,11 +101,7 @@ void mips::getMipsCPUAndABI(const ArgLis
if (ABIName.empty()) {
// Deduce ABI name from the target triple.
-if (Triple.getArch() == llvm::Triple::mips ||
-Triple.getArch() == llvm::Triple::mipsel)
- ABIName = "o32";
-else
- ABIName = "n64";
+ABIName = Triple.isMIPS32() ? "o32" : "n64";
}
if (CPUName.empty()) {
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/Mips.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/Mips.h?rev=335495&r1=335494&r2=335495&view=diff
=
[PATCH] D48549: Use Triple::isMIPS() instead of enumerating all Triples. NFC
This revision was automatically updated to reflect the committed changes.
Closed by commit rC335495: Use Triple::isMIPS() instead of enumerating all
Triples. NFC (authored by arichardson, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D48549?vs=152696&id=152713#toc
Repository:
rC Clang
https://reviews.llvm.org/D48549
Files:
lib/Basic/Targets/Mips.cpp
lib/Basic/Targets/Mips.h
lib/Driver/ToolChains/Arch/Mips.cpp
lib/Driver/ToolChains/Arch/Mips.h
lib/Driver/ToolChains/CommonArgs.cpp
lib/Driver/ToolChains/FreeBSD.cpp
lib/Driver/ToolChains/Gnu.cpp
lib/Driver/ToolChains/Linux.cpp
lib/Driver/ToolChains/NetBSD.cpp
lib/Driver/ToolChains/OpenBSD.cpp
Index: lib/Basic/Targets/Mips.h
===
--- lib/Basic/Targets/Mips.h
+++ lib/Basic/Targets/Mips.h
@@ -69,10 +69,7 @@
UseIndirectJumpHazard(false), HasFP64(false) {
TheCXXABI.set(TargetCXXABI::GenericMIPS);
-setABI((getTriple().getArch() == llvm::Triple::mips ||
-getTriple().getArch() == llvm::Triple::mipsel)
- ? "o32"
- : "n64");
+setABI(getTriple().isMIPS32() ? "o32" : "n64");
CPU = ABI == "o32" ? "mips32r2" : "mips64r2";
Index: lib/Basic/Targets/Mips.cpp
===
--- lib/Basic/Targets/Mips.cpp
+++ lib/Basic/Targets/Mips.cpp
@@ -200,9 +200,7 @@
bool MipsTargetInfo::validateTarget(DiagnosticsEngine &Diags) const {
// microMIPS64R6 backend was removed.
- if ((getTriple().getArch() == llvm::Triple::mips64 ||
- getTriple().getArch() == llvm::Triple::mips64el) &&
- IsMicromips && (ABI == "n32" || ABI == "n64")) {
+ if (getTriple().isMIPS64() && IsMicromips && (ABI == "n32" || ABI == "n64")) {
Diags.Report(diag::err_target_unsupported_cpu_for_micromips) << CPU;
return false;
}
@@ -222,20 +220,16 @@
// FIXME: It's valid to use O32 on a mips64/mips64el triple but the backend
//can't handle this yet. It's better to fail here than on the
//backend assertion.
- if ((getTriple().getArch() == llvm::Triple::mips64 ||
- getTriple().getArch() == llvm::Triple::mips64el) &&
- ABI == "o32") {
+ if (getTriple().isMIPS64() && ABI == "o32") {
Diags.Report(diag::err_target_unsupported_abi_for_triple)
<< ABI << getTriple().str();
return false;
}
// FIXME: It's valid to use N32/N64 on a mips/mipsel triple but the backend
//can't handle this yet. It's better to fail here than on the
//backend assertion.
- if ((getTriple().getArch() == llvm::Triple::mips ||
- getTriple().getArch() == llvm::Triple::mipsel) &&
- (ABI == "n32" || ABI == "n64")) {
+ if (getTriple().isMIPS32() && (ABI == "n32" || ABI == "n64")) {
Diags.Report(diag::err_target_unsupported_abi_for_triple)
<< ABI << getTriple().str();
return false;
Index: lib/Driver/ToolChains/FreeBSD.cpp
===
--- lib/Driver/ToolChains/FreeBSD.cpp
+++ lib/Driver/ToolChains/FreeBSD.cpp
@@ -57,11 +57,10 @@
CmdArgs.push_back("-mabi");
CmdArgs.push_back(mips::getGnuCompatibleMipsABIName(ABIName).data());
-if (getToolChain().getArch() == llvm::Triple::mips ||
-getToolChain().getArch() == llvm::Triple::mips64)
- CmdArgs.push_back("-EB");
-else
+if (getToolChain().getTriple().isLittleEndian())
CmdArgs.push_back("-EL");
+else
+ CmdArgs.push_back("-EB");
if (Arg *A = Args.getLastArg(options::OPT_G)) {
StringRef v = A->getValue();
@@ -179,10 +178,7 @@
}
if (Arg *A = Args.getLastArg(options::OPT_G)) {
-if (ToolChain.getArch() == llvm::Triple::mips ||
- ToolChain.getArch() == llvm::Triple::mipsel ||
- ToolChain.getArch() == llvm::Triple::mips64 ||
- ToolChain.getArch() == llvm::Triple::mips64el) {
+if (ToolChain.getTriple().isMIPS()) {
StringRef v = A->getValue();
CmdArgs.push_back(Args.MakeArgString("-G" + v));
A->claim();
@@ -322,9 +318,7 @@
// When targeting 32-bit platforms, look for '/usr/lib32/crt1.o' and fall
// back to '/usr/lib' if it doesn't exist.
- if ((Triple.getArch() == llvm::Triple::x86 ||
- Triple.getArch() == llvm::Triple::mips ||
- Triple.getArch() == llvm::Triple::mipsel ||
+ if ((Triple.getArch() == llvm::Triple::x86 || Triple.isMIPS32() ||
Triple.getArch() == llvm::Triple::ppc) &&
D.getVFS().exists(getDriver().SysRoot + "/usr/lib32/crt1.o"))
getFilePaths().push_back(getDriver().SysRoot + "/usr/lib32");
@@ -389,8 +383,7 @@
SanitizerMask FreeBSD::getSupportedSanitizers() const {
const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
- const bool IsMIPS64 = getTriple().getArch() == llvm::Triple::mips64 ||
-getTriple().getArch() == llvm
[PATCH] D48492: [clang-format] Add a default format style that can be used by users of `getStyle`
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335492: [clang-format] Add a default format style that can
be used by users of… (authored by ioeric, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D48492
Files:
cfe/trunk/include/clang/Format/Format.h
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/tools/clang-format/ClangFormat.cpp
Index: cfe/trunk/tools/clang-format/ClangFormat.cpp
===
--- cfe/trunk/tools/clang-format/ClangFormat.cpp
+++ cfe/trunk/tools/clang-format/ClangFormat.cpp
@@ -60,17 +60,18 @@
"Can only be used with one input file."),
cl::cat(ClangFormatCategory));
static cl::opt
-Style("style",
- cl::desc(clang::format::StyleOptionHelpDescription),
- cl::init("file"), cl::cat(ClangFormatCategory));
+Style("style", cl::desc(clang::format::StyleOptionHelpDescription),
+ cl::init(clang::format::DefaultFormatStyle),
+ cl::cat(ClangFormatCategory));
static cl::opt
-FallbackStyle("fallback-style",
- cl::desc("The name of the predefined style used as a\n"
- "fallback in case clang-format is invoked with\n"
- "-style=file, but can not find the .clang-format\n"
- "file to use.\n"
- "Use -fallback-style=none to skip formatting."),
- cl::init("LLVM"), cl::cat(ClangFormatCategory));
+FallbackStyle("fallback-style",
+ cl::desc("The name of the predefined style used as a\n"
+ "fallback in case clang-format is invoked with\n"
+ "-style=file, but can not find the .clang-format\n"
+ "file to use.\n"
+ "Use -fallback-style=none to skip formatting."),
+ cl::init(clang::format::DefaultFallbackStyle),
+ cl::cat(ClangFormatCategory));
static cl::opt
AssumeFileName("assume-filename",
Index: cfe/trunk/include/clang/Format/Format.h
===
--- cfe/trunk/include/clang/Format/Format.h
+++ cfe/trunk/include/clang/Format/Format.h
@@ -1963,6 +1963,15 @@
/// of ``getStyle()``.
extern const char *StyleOptionHelpDescription;
+/// The suggested format style to use by default. This allows tools using
+/// `getStyle` to have a consistent default style.
+/// Different builds can modify the value to the preferred styles.
+extern const char *DefaultFormatStyle;
+
+/// The suggested predefined style to use as the fallback style in `getStyle`.
+/// Different builds can modify the value to the preferred styles.
+extern const char *DefaultFallbackStyle;
+
/// Construct a FormatStyle based on ``StyleName``.
///
/// ``StyleName`` can take several forms:
Index: cfe/trunk/lib/Format/Format.cpp
===
--- cfe/trunk/lib/Format/Format.cpp
+++ cfe/trunk/lib/Format/Format.cpp
@@ -2144,6 +2144,10 @@
return GuessedLanguage;
}
+const char *DefaultFormatStyle = "file";
+
+const char *DefaultFallbackStyle = "LLVM";
+
llvm::Expected getStyle(StringRef StyleName, StringRef FileName,
StringRef FallbackStyleName,
StringRef Code, vfs::FileSystem *FS) {
Index: cfe/trunk/tools/clang-format/ClangFormat.cpp
===
--- cfe/trunk/tools/clang-format/ClangFormat.cpp
+++ cfe/trunk/tools/clang-format/ClangFormat.cpp
@@ -60,17 +60,18 @@
"Can only be used with one input file."),
cl::cat(ClangFormatCategory));
static cl::opt
-Style("style",
- cl::desc(clang::format::StyleOptionHelpDescription),
- cl::init("file"), cl::cat(ClangFormatCategory));
+Style("style", cl::desc(clang::format::StyleOptionHelpDescription),
+ cl::init(clang::format::DefaultFormatStyle),
+ cl::cat(ClangFormatCategory));
static cl::opt
-FallbackStyle("fallback-style",
- cl::desc("The name of the predefined style used as a\n"
- "fallback in case clang-format is invoked with\n"
- "-style=file, but can not find the .clang-format\n"
- "file to use.\n"
- "Use -fallback-style=none to skip formatting."),
- cl::init("LLVM"), cl::cat(ClangFormatCategory));
+FallbackStyle("fallback-style",
+ cl::desc("The name of the predefined style used as a\n"
+ "fallback in case clang-format is invoked with\n"
+ "-style=file, but can not find the .clang-format\n"
+ "file to use.\n"
+ "Use -fallback-style=non
r335492 - [clang-format] Add a default format style that can be used by users of `getStyle`
Author: ioeric
Date: Mon Jun 25 09:29:19 2018
New Revision: 335492
URL: http://llvm.org/viewvc/llvm-project?rev=335492&view=rev
Log:
[clang-format] Add a default format style that can be used by users of
`getStyle`
Summary:
Tools that reformat code often call `getStyle` to decide the format style
to use on a certain source file. In practice, "file" style is widely used. As a
result, many tools hardcode "file" when calling `getStyle`, which makes it hard
to control the default style in tools across a codebase when needed. This change
introduces a `DefaultFormatStyle` constant (default to "file" in upstream),
which
can be modified downstream if wanted, so that all users/tools built from the
same
source tree can have a consistent default format style.
This also adds an DefaultFallbackStyle that is recommended to be used by tools
and can be modified downstream.
Reviewers: sammccall, djasper
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48492
Modified:
cfe/trunk/include/clang/Format/Format.h
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/tools/clang-format/ClangFormat.cpp
Modified: cfe/trunk/include/clang/Format/Format.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?rev=335492&r1=335491&r2=335492&view=diff
==
--- cfe/trunk/include/clang/Format/Format.h (original)
+++ cfe/trunk/include/clang/Format/Format.h Mon Jun 25 09:29:19 2018
@@ -1963,6 +1963,15 @@ LangOptions getFormattingLangOpts(const
/// of ``getStyle()``.
extern const char *StyleOptionHelpDescription;
+/// The suggested format style to use by default. This allows tools using
+/// `getStyle` to have a consistent default style.
+/// Different builds can modify the value to the preferred styles.
+extern const char *DefaultFormatStyle;
+
+/// The suggested predefined style to use as the fallback style in `getStyle`.
+/// Different builds can modify the value to the preferred styles.
+extern const char *DefaultFallbackStyle;
+
/// Construct a FormatStyle based on ``StyleName``.
///
/// ``StyleName`` can take several forms:
Modified: cfe/trunk/lib/Format/Format.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=335492&r1=335491&r2=335492&view=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Mon Jun 25 09:29:19 2018
@@ -2144,6 +2144,10 @@ FormatStyle::LanguageKind guessLanguage(
return GuessedLanguage;
}
+const char *DefaultFormatStyle = "file";
+
+const char *DefaultFallbackStyle = "LLVM";
+
llvm::Expected getStyle(StringRef StyleName, StringRef FileName,
StringRef FallbackStyleName,
StringRef Code, vfs::FileSystem *FS) {
Modified: cfe/trunk/tools/clang-format/ClangFormat.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/ClangFormat.cpp?rev=335492&r1=335491&r2=335492&view=diff
==
--- cfe/trunk/tools/clang-format/ClangFormat.cpp (original)
+++ cfe/trunk/tools/clang-format/ClangFormat.cpp Mon Jun 25 09:29:19 2018
@@ -60,17 +60,18 @@ LineRanges("lines", cl::desc("
-Style("style",
- cl::desc(clang::format::StyleOptionHelpDescription),
- cl::init("file"), cl::cat(ClangFormatCategory));
+Style("style", cl::desc(clang::format::StyleOptionHelpDescription),
+ cl::init(clang::format::DefaultFormatStyle),
+ cl::cat(ClangFormatCategory));
static cl::opt
-FallbackStyle("fallback-style",
- cl::desc("The name of the predefined style used as a\n"
- "fallback in case clang-format is invoked with\n"
- "-style=file, but can not find the .clang-format\n"
- "file to use.\n"
- "Use -fallback-style=none to skip formatting."),
- cl::init("LLVM"), cl::cat(ClangFormatCategory));
+FallbackStyle("fallback-style",
+ cl::desc("The name of the predefined style used as a\n"
+ "fallback in case clang-format is invoked with\n"
+ "-style=file, but can not find the .clang-format\n"
+ "file to use.\n"
+ "Use -fallback-style=none to skip formatting."),
+ cl::init(clang::format::DefaultFallbackStyle),
+ cl::cat(ClangFormatCategory));
static cl::opt
AssumeFileName("assume-filename",
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47532: [ASTImporter] Import the whole redecl chain of functions
martong added a comment. This is not trivial to fix. Reverting until we can reproduce and fix it. Reverted with commit: r335491 Repository: rC Clang https://reviews.llvm.org/D47532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335491 - Revert "[ASTImporter] Import the whole redecl chain of functions"
Author: martong
Date: Mon Jun 25 09:25:30 2018
New Revision: 335491
URL: http://llvm.org/viewvc/llvm-project?rev=335491&view=rev
Log:
Revert "[ASTImporter] Import the whole redecl chain of functions"
This reverts commit r335480.
Modified:
cfe/trunk/include/clang/AST/ASTImporter.h
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/lib/AST/DeclBase.cpp
cfe/trunk/test/ASTMerge/class/test.cpp
cfe/trunk/unittests/AST/ASTImporterTest.cpp
Modified: cfe/trunk/include/clang/AST/ASTImporter.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTImporter.h?rev=335491&r1=335490&r2=335491&view=diff
==
--- cfe/trunk/include/clang/AST/ASTImporter.h (original)
+++ cfe/trunk/include/clang/AST/ASTImporter.h Mon Jun 25 09:25:30 2018
@@ -43,15 +43,6 @@ class TagDecl;
class TypeSourceInfo;
class Attr;
- // \brief Returns with a list of declarations started from the canonical decl
- // then followed by subsequent decls in the translation unit.
- // This gives a canonical list for each entry in the redecl chain.
- // `Decl::redecls()` gives a list of decls which always start from the
- // previous decl and the next item is actually the previous item in the order
- // of source locations. Thus, `Decl::redecls()` gives different lists for
- // the different entries in a given redecl chain.
- llvm::SmallVector getCanonicalForwardRedeclChain(Decl* D);
-
/// Imports selected nodes from one AST context into another context,
/// merging AST nodes where appropriate.
class ASTImporter {
Modified: cfe/trunk/lib/AST/ASTImporter.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTImporter.cpp?rev=335491&r1=335490&r2=335491&view=diff
==
--- cfe/trunk/lib/AST/ASTImporter.cpp (original)
+++ cfe/trunk/lib/AST/ASTImporter.cpp Mon Jun 25 09:25:30 2018
@@ -71,25 +71,6 @@
namespace clang {
- template
- SmallVector
- getCanonicalForwardRedeclChain(Redeclarable* D) {
-SmallVector Redecls;
-for (auto *R : D->getFirstDecl()->redecls()) {
- if (R != D->getFirstDecl())
-Redecls.push_back(R);
-}
-Redecls.push_back(D->getFirstDecl());
-std::reverse(Redecls.begin(), Redecls.end());
-return Redecls;
- }
-
- SmallVector getCanonicalForwardRedeclChain(Decl* D) {
-// Currently only FunctionDecl is supported
-auto FD = cast(D);
-return getCanonicalForwardRedeclChain(FD);
- }
-
class ASTNodeImporter : public TypeVisitor,
public DeclVisitor,
public StmtVisitor {
@@ -214,12 +195,6 @@ namespace clang {
const InContainerTy &Container,
TemplateArgumentListInfo &Result);
-using TemplateArgsTy = SmallVector;
-using OptionalTemplateArgsTy = Optional;
-std::tuple
-ImportFunctionTemplateWithTemplateArgsFromSpecialization(
-FunctionDecl *FromFD);
-
bool ImportTemplateInformation(FunctionDecl *FromFD, FunctionDecl *ToFD);
bool IsStructuralMatch(RecordDecl *FromRecord, RecordDecl *ToRecord,
@@ -433,8 +408,6 @@ namespace clang {
// Importing overrides.
void ImportOverrides(CXXMethodDecl *ToMethod, CXXMethodDecl *FromMethod);
-
-FunctionDecl *FindFunctionTemplateSpecialization(FunctionDecl *FromFD);
};
template
@@ -464,25 +437,6 @@ bool ASTNodeImporter::ImportTemplateArgu
From.arguments(), Result);
}
-std::tuple
-ASTNodeImporter::ImportFunctionTemplateWithTemplateArgsFromSpecialization(
-FunctionDecl *FromFD) {
- assert(FromFD->getTemplatedKind() ==
- FunctionDecl::TK_FunctionTemplateSpecialization);
- auto *FTSInfo = FromFD->getTemplateSpecializationInfo();
- auto *Template = cast_or_null(
- Importer.Import(FTSInfo->getTemplate()));
-
- // Import template arguments.
- auto TemplArgs = FTSInfo->TemplateArguments->asArray();
- TemplateArgsTy ToTemplArgs;
- if (ImportTemplateArguments(TemplArgs.data(), TemplArgs.size(),
- ToTemplArgs)) // Error during import.
-return std::make_tuple(Template, OptionalTemplateArgsTy());
-
- return std::make_tuple(Template, ToTemplArgs);
-}
-
} // namespace clang
//
@@ -2298,17 +2252,23 @@ bool ASTNodeImporter::ImportTemplateInfo
}
case FunctionDecl::TK_FunctionTemplateSpecialization: {
-FunctionTemplateDecl* Template;
-OptionalTemplateArgsTy ToTemplArgs;
-std::tie(Template, ToTemplArgs) =
-ImportFunctionTemplateWithTemplateArgsFromSpecialization(FromFD);
-if (!Template || !ToTemplArgs)
+auto *FTSInfo = FromFD->getTemplateSpecializationInfo();
+auto *Template = cast_or_null(
+Importer.Import(FTSInfo->getTemplate()));
+if (!Template)
+
LLVM buildmaster will be restarted tonight
Hello everyone, LLVM buildmaster will be updated and restarted after 6PM Pacific time today. Thanks Galina ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47532: [ASTImporter] Import the whole redecl chain of functions
martong added a comment. @labath Sure, looking into it. Repository: rC Clang https://reviews.llvm.org/D47532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48027: [analyzer] Improve `CallDescription` to handle c++ method.
MTC updated this revision to Diff 152702.
MTC added a comment.
Sorry for the long long delay, I was on the Dragon Boat Festival a few days ago.
This update has two parts:
- Use the `matchesName` to match the AST node with the specified name,
`matchesName` use regex to match the specified name.
- Use `std::vector` to record the list of qualified name, user can provide
information as much as possible to improve matching accuracy. But can also
provide only the function name.
There are two remain issues:
- There is possible match the wrong AST node, e.g. for the NamedDecl `foo()`,
if the function body has the `a::b::x`, when we match `a::b::X()`, we will
match `foo()` . Because I'm not familiar with ASTMatcher, my bad, I can't think
of a perfect way to match only the specified nodes.
- The `std::vector` to record the information provide by the users may be not
the best data structure.
- I'm not the regex expert, the regex used in this patch definitely has the
chance to improve.
And I am not good at English writing, if any comments are not very clear,
please correct me. Thanks for the help!
Repository:
rC Clang
https://reviews.llvm.org/D48027
Files:
include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
lib/StaticAnalyzer/Checkers/BlockInCriticalSectionChecker.cpp
lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp
lib/StaticAnalyzer/Checkers/MmapWriteExecChecker.cpp
lib/StaticAnalyzer/Checkers/SimpleStreamChecker.cpp
lib/StaticAnalyzer/Checkers/ValistChecker.cpp
lib/StaticAnalyzer/Core/CallEvent.cpp
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -28,6 +28,7 @@
#include "clang/Analysis/AnalysisDeclContext.h"
#include "clang/Analysis/CFG.h"
#include "clang/Analysis/ProgramPoint.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
#include "clang/CrossTU/CrossTranslationUnit.h"
#include "clang/Basic/IdentifierTable.h"
#include "clang/Basic/LLVM.h"
@@ -65,6 +66,7 @@
using namespace clang;
using namespace ento;
+using namespace clang::ast_matchers;
QualType CallEvent::getResultType() const {
ASTContext &Ctx = getState()->getStateManager().getContext();
@@ -256,11 +258,28 @@
return false;
if (!CD.IsLookupDone) {
CD.IsLookupDone = true;
-CD.II = &getState()->getStateManager().getContext().Idents.get(CD.FuncName);
+CD.II = &getState()->getStateManager().getContext().Idents.get(
+CD.getFunctionName());
}
const IdentifierInfo *II = getCalleeIdentifier();
if (!II || II != CD.II)
return false;
+
+ if (CD.QualifiedName.size() > 1) {
+const NamedDecl *ND = dyn_cast_or_null(getDecl());
+if (!ND)
+ return false;
+
+std::string Regex = "^::(.*)?";
+Regex += llvm::join(CD.QualifiedName, "(.*)?::(.*)?") + "(.*)?$";
+
+auto Matches = match(namedDecl(matchesName(Regex)).bind("Regex"), *ND,
+ LCtx->getAnalysisDeclContext()->getASTContext());
+
+if (Matches.empty())
+ return false;
+ }
+
return (CD.RequiredArgs == CallDescription::NoArgRequirement ||
CD.RequiredArgs == getNumArgs());
}
Index: lib/StaticAnalyzer/Checkers/ValistChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/ValistChecker.cpp
+++ lib/StaticAnalyzer/Checkers/ValistChecker.cpp
@@ -103,24 +103,24 @@
const SmallVector
ValistChecker::VAListAccepters = {
-{{"vfprintf", 3}, 2},
-{{"vfscanf", 3}, 2},
-{{"vprintf", 2}, 1},
-{{"vscanf", 2}, 1},
-{{"vsnprintf", 4}, 3},
-{{"vsprintf", 3}, 2},
-{{"vsscanf", 3}, 2},
-{{"vfwprintf", 3}, 2},
-{{"vfwscanf", 3}, 2},
-{{"vwprintf", 2}, 1},
-{{"vwscanf", 2}, 1},
-{{"vswprintf", 4}, 3},
+{{{"vfprintf"}, 3}, 2},
+{{{"vfscanf"}, 3}, 2},
+{{{"vprintf"}, 2}, 1},
+{{{"vscanf"}, 2}, 1},
+{{{"vsnprintf"}, 4}, 3},
+{{{"vsprintf"}, 3}, 2},
+{{{"vsscanf"}, 3}, 2},
+{{{"vfwprintf"}, 3}, 2},
+{{{"vfwscanf"}, 3}, 2},
+{{{"vwprintf"}, 2}, 1},
+{{{"vwscanf"}, 2}, 1},
+{{{"vswprintf"}, 4}, 3},
// vswprintf is the wide version of vsnprintf,
// vsprintf has no wide version
-{{"vswscanf", 3}, 2}};
-const CallDescription ValistChecker::VaStart("__builtin_va_start", 2),
-ValistChecker::VaCopy("__builtin_va_copy", 2),
-ValistChecker::VaEnd("__builtin_va_end", 1);
+{{{"vswscanf"}, 3}, 2}};
+const CallDescription ValistChecker::VaStart({"__builtin_va_start"}, 2),
+ValistChecker::VaCopy({"__builtin_va_copy"}, 2),
+ValistChecker::VaEnd({"__builtin_va_end"}, 1);
} // end anonymous namespace
void ValistChecker::checkPreCall(const CallEvent &Call,
Index: lib/StaticAnalyzer/Checkers/SimpleStreamChecker.cpp
[PATCH] D47632: [ASTImporter] Refactor Decl creation
martong updated this revision to Diff 152703.
martong added a comment.
- Rebase from master.
Repository:
rC Clang
https://reviews.llvm.org/D47632
Files:
include/clang/AST/ASTImporter.h
include/clang/AST/DeclBase.h
lib/AST/ASTImporter.cpp
lib/AST/ExternalASTMerger.cpp
Index: lib/AST/ExternalASTMerger.cpp
===
--- lib/AST/ExternalASTMerger.cpp
+++ lib/AST/ExternalASTMerger.cpp
@@ -154,7 +154,7 @@
ToContainer->setMustBuildLookupTable();
assert(Parent.CanComplete(ToContainer));
}
-return ASTImporter::Imported(From, To);
+return To;
}
ASTImporter &GetReverse() { return Reverse; }
};
@@ -229,7 +229,7 @@
SourceTag->getASTContext().getExternalSource()->CompleteType(SourceTag);
if (!SourceTag->getDefinition())
return false;
-Forward.Imported(SourceTag, Tag);
+Forward.MapImported(SourceTag, Tag);
Forward.ImportDefinition(SourceTag);
Tag->setCompleteDefinition(SourceTag->isCompleteDefinition());
return true;
@@ -248,7 +248,7 @@
SourceInterface);
if (!SourceInterface->getDefinition())
return false;
-Forward.Imported(SourceInterface, Interface);
+Forward.MapImported(SourceInterface, Interface);
Forward.ImportDefinition(SourceInterface);
return true;
});
@@ -304,7 +304,7 @@
void ExternalASTMerger::RecordOriginImpl(const DeclContext *ToDC, DCOrigin Origin,
ASTImporter &Importer) {
Origins[ToDC] = Origin;
- Importer.ASTImporter::Imported(cast(Origin.DC), const_cast(cast(ToDC)));
+ Importer.ASTImporter::MapImported(cast(Origin.DC), const_cast(cast(ToDC)));
}
ExternalASTMerger::ExternalASTMerger(const ImporterTarget &Target,
Index: lib/AST/ASTImporter.cpp
===
--- lib/AST/ASTImporter.cpp
+++ lib/AST/ASTImporter.cpp
@@ -95,6 +95,58 @@
public StmtVisitor {
ASTImporter &Importer;
+// Wrapper for an overload set.
+template struct CallOverloadedCreateFun {
+ template
+ auto operator()(Args &&... args)
+ -> decltype(ToDeclT::Create(std::forward(args)...)) {
+return ToDeclT::Create(std::forward(args)...);
+ }
+};
+
+// Always use this function to create a Decl during import. There are
+// certain tasks which must be done after the Decl was created, e.g. we
+// must immediately register that as an imported Decl.
+// Returns a pair consisting of a pointer to the new or the already imported
+// Decl and a bool value set to true if the `FromD` had been imported
+// before.
+template
+std::pair CreateDecl(FromDeclT *FromD, Args &&... args) {
+ // There may be several overloads of ToDeclT::Create. We must make sure
+ // to call the one which would be chosen by the arguments, thus we use a
+ // wrapper for the overload set.
+ CallOverloadedCreateFun OC;
+ return CreateDecl(OC, FromD, std::forward(args)...);
+}
+// Use this overload directly only if a special create function must be
+// used, e.g. CXXRecordDecl::CreateLambda .
+template
+auto CreateDecl(CreateFunT CreateFun, FromDeclT *FromD, Args &&... args)
+-> std::pair(args)...)), bool> {
+ using ToDeclT = typename std::remove_pointer(args)...))>::type;
+ ToDeclT *AlreadyImported =
+ cast_or_null(Importer.GetAlreadyImportedOrNull(FromD));
+ if (AlreadyImported) {
+return std::make_pair(AlreadyImported, /*AlreadyImported=*/true);
+ }
+ ToDeclT *ToD = CreateFun(std::forward(args)...);
+ InitializeImportedDecl(FromD, ToD);
+ return std::make_pair(ToD, /*AlreadyImported=*/false);
+}
+
+void InitializeImportedDecl(Decl *FromD, Decl *ToD) {
+ Importer.MapImported(FromD, ToD);
+ ToD->IdentifierNamespace = FromD->IdentifierNamespace;
+ if (FromD->hasAttrs())
+for (const Attr *FromAttr : FromD->getAttrs())
+ ToD->addAttr(Importer.Import(FromAttr));
+ if (FromD->isUsed())
+ToD->setIsUsed();
+ if (FromD->isImplicit())
+ToD->setImplicit();
+}
+
public:
explicit ASTNodeImporter(ASTImporter &Importer) : Importer(Importer) {}
@@ -1572,18 +1624,23 @@
// Import the location of this declaration.
SourceLocation Loc = Importer.Import(D->getLocation());
- EmptyDecl *ToD = EmptyDecl::Create(Importer.getToContext(), DC, Loc);
+ bool AlreadyImported;
+ EmptyDecl *ToD;
+ std::tie(ToD, AlreadyImported) =
+ CreateDecl(D, Importer.getToContext(), DC, Loc);
+ if (AlreadyImported)
+return ToD;
+
ToD->setLexicalDeclContext(LexicalDC);
- Importer.Imported(D, ToD);
LexicalDC->addDeclInternal(ToD);
return ToD;
}
Decl *ASTNodeImporter::VisitTranslationUnitDecl(TranslationUnitDecl *D) {
TranslationUnitDecl *ToD =
Importer.getToContext().getTra
[PATCH] D45719: [clang-Format] Fix indentation of member call after block
klimek added inline comments.
Comment at: unittests/Format/FormatTest.cpp:4359
+ "return 3;\n"
+ " }).as("");\n"
+ "}");
ank wrote:
> klimek wrote:
> > ank wrote:
> > > klimek wrote:
> > > > What would be interesting is tests that:
> > > > a) have another value after the closing }; doesn't really make sense in
> > > > this test, but usually these are in calls
> > > > f([]() { ... }, foo, bar).call(...)
> > > >
> > > > b) make .as("") have paramters that go beyond the limit
> > > >
> > > > c) add another chained call behind .as("").
> > > Hello, sorry for the late follow up on this!
> > >
> > > Indeed an interesting thing to test, and so I did, the patterns you
> > > describe seems to give strange indentation as far back as release_36 and
> > > probably has always done so. The case I'm testing here worked in
> > > release_40 but stopped working somewhere before release_50
> > >
> > > maybe fixing those other cases can be done in another patch
> > >
> > > cheers,
> > > Anders
> > I meant: please add these tests :)
> I need to clarify, those tests will not be correctly indented by this commit,
> I could add those tests but then they would verify a faulty behaviour, this
> is how they will be indented even with this patch applied:
>
>
> ```
> // Dont break if only closing statements before member call
> verifyFormat("test() {\n"
> " ([]() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " }).foo();\n"
> "}");
> verifyFormat("test() {\n"
> " (\n"
> " []() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " },\n"
> " foo, bar)\n"
> " .foo();\n"
> "}");
> verifyFormat("test() {\n"
> " ([]() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " })\n"
> " .foo()\n"
> " .bar();\n"
> "}");
> verifyFormat("test() {\n"
> " ([]() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " })\n"
> "
> .foo(\"aaa\"\n"
> " \"bb\");\n"
> "}");
>
> verifyFormat("test() {\n"
> " foo([]() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " }).foo();\n"
> "}");
> verifyFormat("test() {\n"
> " foo(\n"
> " []() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " },\n"
> " foo, bar)\n"
> " .as();\n"
> "}");
> verifyFormat("test() {\n"
> " foo([]() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " })\n"
> " .foo()\n"
> " .bar();\n"
> "}");
> verifyFormat("test() {\n"
> " foo([]() -> {\n"
> "int b = 32;\n"
> "return 3;\n"
> " })\n"
> "
> .as(\"\"\n"
> " \"bb\");\n"
> "}");
> ```
I'm not sure we agree that the behavior is "faulty" - I do believe it was an
intentional change :)
This is an indent of 4 from the start of the expression that call belongs to.
For example, in example (2), having the .foo() at the end of line after a
potentially complex parameter strongly de-emphasizes the parameter.
In example (3), how would you want to layout a chain of calls?
Repository:
rC Clang
https://reviews.llvm.org/D45719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48532: [analyzer] Add support for std::basic_string::data() in DanglingInternalBufferChecker
xazax.hun added inline comments. Comment at: test/Analysis/dangling-internal-buffer.cpp:10 const CharT *c_str(); + const CharT *data(); }; Note that these methods are const according to the standard. Even if it does not make any difference for this check we should follow the signatures. Also, from c++17 there is a non-const overload of data. Repository: rC Clang https://reviews.llvm.org/D48532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D48532: [analyzer] Add support for std::basic_string::data() in DanglingInternalBufferChecker
xazax.hun accepted this revision. xazax.hun added a comment. This revision is now accepted and ready to land. LG! Repository: rC Clang https://reviews.llvm.org/D48532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335483 - [OPENMP] Do not consider address constant vars as possibly
Author: abataev
Date: Mon Jun 25 08:32:05 2018
New Revision: 335483
URL: http://llvm.org/viewvc/llvm-project?rev=335483&view=rev
Log:
[OPENMP] Do not consider address constant vars as possibly
threadprivate.
Do not delay emission of the address constant variables in OpenMP mode
as they cannot be defined as threadprivate.
Added:
cfe/trunk/test/OpenMP/constexpr_codegen.cpp
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=335483&r1=335482&r2=335483&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Jun 25 08:32:05 2018
@@ -1914,7 +1914,8 @@ bool CodeGenModule::MayBeEmittedEagerly(
// If OpenMP is enabled and threadprivates must be generated like TLS, delay
// codegen for global variables, because they may be marked as threadprivate.
if (LangOpts.OpenMP && LangOpts.OpenMPUseTLS &&
- getContext().getTargetInfo().isTLSSupported() && isa(Global))
+ getContext().getTargetInfo().isTLSSupported() && isa(Global) &&
+ !isTypeConstant(Global->getType(), false))
return false;
return true;
Added: cfe/trunk/test/OpenMP/constexpr_codegen.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/constexpr_codegen.cpp?rev=335483&view=auto
==
--- cfe/trunk/test/OpenMP/constexpr_codegen.cpp (added)
+++ cfe/trunk/test/OpenMP/constexpr_codegen.cpp Mon Jun 25 08:32:05 2018
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -verify -fopenmp -std=c++11 -triple x86_64-unknown-unknown
-x c++ -emit-llvm %s -fexceptions -fcxx-exceptions -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple x86_64-unknown-unknown
-fexceptions -fcxx-exceptions -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-unknown-unknown -fexceptions
-fcxx-exceptions -debug-info-kind=limited -std=c++11 -include-pch %t -verify %s
-emit-llvm -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -std=c++11 -triple
x86_64-unknown-unknown -x c++ -emit-llvm %s -fexceptions -fcxx-exceptions -o -
| FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -fopenmp-simd -x c++ -std=c++11 -triple
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -x c++ -triple x86_64-unknown-unknown
-fexceptions -fcxx-exceptions -debug-info-kind=limited -std=c++11 -include-pch
%t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// SIMD-ONLY1-NOT: {{__kmpc|__tgt}}
+
+// expected-no-diagnostics
+//
+#ifndef HEADER
+#define HEADER
+
+// CHECK: @{{.*}}Foo{{.*}}bar{{.*}} = constant i32 1,
+
+// Section A - Define a class with a static constexpr data member.
+struct Foo {
+ static constexpr int bar = 1;
+};
+
+// Section B - ODR-use the data member.
+void F(const int &);
+void Test() { F(Foo::bar); }
+
+// Section C - Define the data member.
+constexpr int Foo::bar;
+#endif
+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
