[PATCH] D52973: Add type_info predefined decl

2019-01-25 Thread Matt Asplund via Phabricator via cfe-commits
mwasplund abandoned this revision.
mwasplund added a comment.

I completely forgot this was open. I have been making incremental improvements 
to modules ts and this has gotten pulled into that change.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52973/new/

https://reviews.llvm.org/D52973



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


[PATCH] D54438: [analyzer] Reimplement dependencies between checkers

2019-01-25 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.

*gets hyped for the upcoming patchlanding party*

In D54438#1329425 , @Szelethus wrote:

> Hmmm, I left plenty of room for improvement in the tblgen generation, we 
> could generate compile-time errors on cycles within the dependency graph, try 
> to include the generated file only once, but these clearly are very low-prio 
> issues, so I'll do it later. I'll have to revisit the entire thing soon 
> enough.


Hmm. The dependency cycle check sounds cool as long as we do actually have 
problems with dependency cycles. I guess we could just enable/disable the whole 
cycle of checkers all together? This might even be a useful feature.

What do you mean by "include the generated file only once"?




Comment at: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp:225-229
+if (!deps) {
+  // If we failed to enable any of the dependencies, don't enable this
+  // checker.
+  continue;
+}

Aha, ok, so the current approach to conflict resolution is to only enable the 
checker if none of its dependencies were disabled on the command line. So if, 
say, `DependentChecker` depends on `BaseChecker`, once an 
`-analyzer-disable-checker BaseChecker` flag is passed, it needs to be reverted 
via `-analyzer-checker BaseChecker` before the `-analyzer-checker 
DependentChecker` directive would take effect, regardless of in which order it 
is with respect to the `BaseChecker`-enabling/disabling directives.

So we kinda choose to err on the side of disabling in ambiguous situations. 
Which kinda makes sense because the disable-argument is more rare and indicates 
an irritation of the user. But it is also kinda inconsistent with how the 
options interact in absence of dependencies: "the flag that was passed last 
overrides all previous flags". And we can kinda fix this inconsistency by 
introducing a different behavior:

- whenever an `-analyzer-checker` flag is passed, remove the "disabled" marks 
from all checkers it depends on;
- whenever an `-analyzer-disable-checker` flag is passed, remove the "enabled" 
marks from all checkers that depend on it.

This approach still ensures that the set of enabled checkers is consistent 
(i.e., users are still not allowed to shoot themselves in the foot by running a 
checker without its dependencies), but it also looks respects every flag in an 
intuitive manner. WDYT?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54438/new/

https://reviews.llvm.org/D54438



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


r352267 - [X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics.

2019-01-25 Thread Craig Topper via cfe-commits
Author: ctopper
Date: Fri Jan 25 18:42:01 2019
New Revision: 352267

URL: http://llvm.org/viewvc/llvm-project?rev=352267=rev
Log:
[X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops 
intrinsics.

Summary:
The 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics all have 
the possibility of taking an explicit rounding mode argument. If the rounding 
mode is CUR_DIRECTION we'd like to emit a sitofp/uitofp instruction and a 
select like we do for 256-bit intrinsics.

For cvt(u)qqtopd and cvt(u)dqtops we do this when the form of the software 
intrinsics that doesn't take a rounding mode argument is used. This is done by 
using convertvector in the header with the select builtin. But if the explicit 
rounding mode form of the intrinsic is used and CUR_DIRECTION is passed, we 
don't do this. We shouldn't have this inconsistency.

For cvt(u)qqtops nothing is done because we can't use the select builtin in the 
header without avx512vl. So we need to use custom codegen for this.

Even when the rounding mode isn't CUR_DIRECTION we should also use select in IR 
for consistency. And it will remove another scalar integer mask from our 
intrinsics.

To accomplish all of these goals I've taken a slightly unusual approach. I've 
added two new X86 specific intrinsics for sitofp/uitofp with rounding. These 
intrinsics are variadic on the input and output type so we only need 2 instead 
of 6. This avoids the need for a switch to map them in CGBuiltin.cpp. We just 
need to check signed vs unsigned. I believe other targets also use variadic 
intrinsics like this.

So if the rounding mode is CUR_DIRECTION we'll use an sitofp/uitofp 
instruction. Otherwise we'll use one of the new intrinsics. After that we'll 
emit a select instruction if needed.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/avx512dq-builtins.c
cfe/trunk/test/CodeGen/avx512f-builtins.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=352267=352266=352267=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Jan 25 18:42:01 2019
@@ -9328,6 +9328,25 @@ static Value *EmitX86ConvertToMask(CodeG
   return EmitX86MaskedCompare(CGF, 1, true, { In, Zero });
 }
 
+static Value *EmitX86ConvertIntToFp(CodeGenFunction ,
+ArrayRef Ops, bool IsSigned) {
+  unsigned Rnd = cast(Ops[3])->getZExtValue();
+  llvm::Type *Ty = Ops[1]->getType();
+
+  Value *Res;
+  if (Rnd != 4) {
+Intrinsic::ID IID = IsSigned ? Intrinsic::x86_avx512_sitofp_round
+ : Intrinsic::x86_avx512_uitofp_round;
+Function *F = CGF.CGM.getIntrinsic(IID, { Ty, Ops[0]->getType() });
+Res = CGF.Builder.CreateCall(F, { Ops[0], Ops[3] });
+  } else {
+Res = IsSigned ? CGF.Builder.CreateSIToFP(Ops[0], Ty)
+   : CGF.Builder.CreateUIToFP(Ops[0], Ty);
+  }
+
+  return EmitX86Select(CGF, Ops[2], Res, Ops[1]);
+}
+
 static Value *EmitX86Abs(CodeGenFunction , ArrayRef Ops) {
 
   llvm::Type *Ty = Ops[0]->getType();
@@ -9989,6 +10008,15 @@ Value *CodeGenFunction::EmitX86BuiltinEx
   case X86::BI__builtin_ia32_cvtq2mask512:
 return EmitX86ConvertToMask(*this, Ops[0]);
 
+  case X86::BI__builtin_ia32_cvtdq2ps512_mask:
+  case X86::BI__builtin_ia32_cvtqq2ps512_mask:
+  case X86::BI__builtin_ia32_cvtqq2pd512_mask:
+return EmitX86ConvertIntToFp(*this, Ops, /*IsSigned*/true);
+  case X86::BI__builtin_ia32_cvtudq2ps512_mask:
+  case X86::BI__builtin_ia32_cvtuqq2ps512_mask:
+  case X86::BI__builtin_ia32_cvtuqq2pd512_mask:
+return EmitX86ConvertIntToFp(*this, Ops, /*IsSigned*/false);
+
   case X86::BI__builtin_ia32_vfmaddss3:
   case X86::BI__builtin_ia32_vfmaddsd3:
   case X86::BI__builtin_ia32_vfmaddss3_mask:

Modified: cfe/trunk/test/CodeGen/avx512dq-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512dq-builtins.c?rev=352267=352266=352267=diff
==
--- cfe/trunk/test/CodeGen/avx512dq-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx512dq-builtins.c Fri Jan 25 18:42:01 2019
@@ -613,55 +613,61 @@ __m512d test_mm512_maskz_cvtepi64_pd(__m
 
 __m512d test_mm512_cvt_roundepi64_pd(__m512i __A) {
   // CHECK-LABEL: @test_mm512_cvt_roundepi64_pd
-  // CHECK: @llvm.x86.avx512.mask.cvtqq2pd.512
+  // CHECK: @llvm.x86.avx512.sitofp.round.v8f64.v8i64
   return _mm512_cvt_roundepi64_pd(__A, _MM_FROUND_TO_NEAREST_INT | 
_MM_FROUND_NO_EXC); 
 }
 
 __m512d test_mm512_mask_cvt_roundepi64_pd(__m512d __W, __mmask8 __U, __m512i 
__A) {
   // CHECK-LABEL: @test_mm512_mask_cvt_roundepi64_pd
-  // CHECK: 

[PATCH] D56998: [X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics.

2019-01-25 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL352267: [X86] Custom codegen 512-bit cvt(u)qq2tops, 
cvt(u)qqtopd, and cvt(u)dqtops… (authored by ctopper, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56998/new/

https://reviews.llvm.org/D56998

Files:
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/test/CodeGen/avx512dq-builtins.c
  cfe/trunk/test/CodeGen/avx512f-builtins.c

Index: cfe/trunk/test/CodeGen/avx512f-builtins.c
===
--- cfe/trunk/test/CodeGen/avx512f-builtins.c
+++ cfe/trunk/test/CodeGen/avx512f-builtins.c
@@ -5022,42 +5022,46 @@
 __m512 test_mm512_cvt_roundepi32_ps( __m512i __A)
 {
   // CHECK-LABEL: @test_mm512_cvt_roundepi32_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtdq2ps.512
+  // CHECK: @llvm.x86.avx512.sitofp.round.v16f32.v16i32
   return _mm512_cvt_roundepi32_ps(__A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_mask_cvt_roundepi32_ps(__m512 __W, __mmask16 __U, __m512i __A)
 {
   // CHECK-LABEL: @test_mm512_mask_cvt_roundepi32_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtdq2ps.512
+  // CHECK: @llvm.x86.avx512.sitofp.round.v16f32.v16i32
+  // CHECK: select <16 x i1> %{{.*}}, <16 x float> %{{.*}}, <16 x float> %{{.*}}
   return _mm512_mask_cvt_roundepi32_ps(__W,__U,__A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_maskz_cvt_roundepi32_ps(__mmask16 __U, __m512i __A)
 {
   // CHECK-LABEL: @test_mm512_maskz_cvt_roundepi32_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtdq2ps.512
+  // CHECK: @llvm.x86.avx512.sitofp.round.v16f32.v16i32
+  // CHECK: select <16 x i1> %{{.*}}, <16 x float> %{{.*}}, <16 x float> %{{.*}}
   return _mm512_maskz_cvt_roundepi32_ps(__U,__A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_cvt_roundepu32_ps(__m512i __A)
 {
   // CHECK-LABEL: @test_mm512_cvt_roundepu32_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtudq2ps.512
+  // CHECK: @llvm.x86.avx512.uitofp.round.v16f32.v16i32
   return _mm512_cvt_roundepu32_ps(__A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_mask_cvt_roundepu32_ps(__m512 __W, __mmask16 __U,__m512i __A)
 {
   // CHECK-LABEL: @test_mm512_mask_cvt_roundepu32_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtudq2ps.512
+  // CHECK: @llvm.x86.avx512.uitofp.round.v16f32.v16i32
+  // CHECK: select <16 x i1> %{{.*}}, <16 x float> %{{.*}}, <16 x float> %{{.*}}
   return _mm512_mask_cvt_roundepu32_ps(__W,__U,__A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC);
 }
 
 __m512 test_mm512_maskz_cvt_roundepu32_ps(__mmask16 __U,__m512i __A)
 {
   // CHECK-LABEL: @test_mm512_maskz_cvt_roundepu32_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtudq2ps.512
+  // CHECK: @llvm.x86.avx512.uitofp.round.v16f32.v16i32
+  // CHECK: select <16 x i1> %{{.*}}, <16 x float> %{{.*}}, <16 x float> %{{.*}}
   return _mm512_maskz_cvt_roundepu32_ps(__U,__A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC);
 }
 
Index: cfe/trunk/test/CodeGen/avx512dq-builtins.c
===
--- cfe/trunk/test/CodeGen/avx512dq-builtins.c
+++ cfe/trunk/test/CodeGen/avx512dq-builtins.c
@@ -613,55 +613,61 @@
 
 __m512d test_mm512_cvt_roundepi64_pd(__m512i __A) {
   // CHECK-LABEL: @test_mm512_cvt_roundepi64_pd
-  // CHECK: @llvm.x86.avx512.mask.cvtqq2pd.512
+  // CHECK: @llvm.x86.avx512.sitofp.round.v8f64.v8i64
   return _mm512_cvt_roundepi64_pd(__A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC); 
 }
 
 __m512d test_mm512_mask_cvt_roundepi64_pd(__m512d __W, __mmask8 __U, __m512i __A) {
   // CHECK-LABEL: @test_mm512_mask_cvt_roundepi64_pd
-  // CHECK: @llvm.x86.avx512.mask.cvtqq2pd.512
+  // CHECK: @llvm.x86.avx512.sitofp.round.v8f64.v8i64
+  // CHECK: select <8 x i1> %{{.*}}, <8 x double> %{{.*}}, <8 x double> %{{.*}}
   return _mm512_mask_cvt_roundepi64_pd(__W, __U, __A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC); 
 }
 
 __m512d test_mm512_maskz_cvt_roundepi64_pd(__mmask8 __U, __m512i __A) {
   // CHECK-LABEL: @test_mm512_maskz_cvt_roundepi64_pd
-  // CHECK: @llvm.x86.avx512.mask.cvtqq2pd.512
+  // CHECK: @llvm.x86.avx512.sitofp.round.v8f64.v8i64
+  // CHECK: select <8 x i1> %{{.*}}, <8 x double> %{{.*}}, <8 x double> %{{.*}}
   return _mm512_maskz_cvt_roundepi64_pd(__U, __A, _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC); 
 }
 
 __m256 test_mm512_cvtepi64_ps(__m512i __A) {
   // CHECK-LABEL: @test_mm512_cvtepi64_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtqq2ps.512
+  // CHECK: sitofp <8 x i64> %{{.*}} to <8 x float>
   return _mm512_cvtepi64_ps(__A); 
 }
 
 __m256 test_mm512_mask_cvtepi64_ps(__m256 __W, __mmask8 __U, __m512i __A) {
   // CHECK-LABEL: @test_mm512_mask_cvtepi64_ps
-  // CHECK: @llvm.x86.avx512.mask.cvtqq2ps.512
+  // CHECK: sitofp <8 x i64> %{{.*}} to <8 x float>
+  // CHECK: select <8 x i1> %{{.*}}, <8 x float> %{{.*}}, <8 x float> %{{.*}}
   return 

[PATCH] D56561: [Preprocessor] For missing file in framework add note about framework location.

2019-01-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai marked 2 inline comments as done.
vsapsai added inline comments.



Comment at: clang/include/clang/Lex/DirectoryLookup.h:175
+  /// \param [out] IsFrameworkFound For a framework directory set to true if
+  /// specified '.framework' directory is found.
+  ///

jkorous wrote:
> We might make this easier to understand by explaining where/how the 
> '.framework' directory is specified.
This is a method in `DirectoryLookup` which has a method `isFramework` and 
constructor parameter `isFramework`. I think at this point users of 
`DirectoryLookup` should be aware of framework-style header lookup and this is 
not the right place to describe it.



Comment at: clang/include/clang/Lex/HeaderSearch.h:396
+  /// \param IsFrameworkFound If non-null, will be set to true for a framework
+  /// include and if corresponding '.framework' directory was found. Doesn't
+  /// guarantee the requested file is found.

jkorous wrote:
> We might try to explain what exactly is meant by corresponding .framework 
> directory.
Tweaked the comment.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56561/new/

https://reviews.llvm.org/D56561



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


[PATCH] D56561: [Preprocessor] For missing file in framework add note about framework location.

2019-01-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai updated this revision to Diff 183678.
vsapsai added a comment.

- Tweak doxygen comment to express IsFrameworkFound in terms of 
IsFrameworkFound returned by DirectoryLookup.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56561/new/

https://reviews.llvm.org/D56561

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/DirectoryLookup.h
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
  clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/Preprocessor/include-header-missing-in-framework.c

Index: clang/test/Preprocessor/include-header-missing-in-framework.c
===
--- /dev/null
+++ clang/test/Preprocessor/include-header-missing-in-framework.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -fsyntax-only -F %S/Inputs -verify %s
+// RUN: %clang_cc1 -fsyntax-only -F %S/Inputs -DTYPO_CORRECTION -verify %s
+
+// After finding a requested framework, we don't look for the same framework in
+// a different location even if requested header is not found in the framework.
+// It can be confusing when there is a framework with required header later in
+// header search paths. Mention in diagnostics where the header lookup stopped.
+
+#ifndef TYPO_CORRECTION
+#include 
+// expected-error@-1 {{'TestFramework/NotExistingHeader.h' file not found}}
+// expected-note@-2 {{framework 'TestFramework' without a header 'NotExistingHeader.h' found at}}
+
+#else
+// Don't emit extra note for unsuccessfully typo-corrected include.
+#include <#TestFramework/NotExistingHeader.h>
+// expected-error@-1 {{'#TestFramework/NotExistingHeader.h' file not found}}
+#endif // TYPO_CORRECTION
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -567,7 +567,8 @@
 SourceLocation(), PPOpts->PCHThroughHeader,
 /*isAngled=*/false, /*FromDir=*/nullptr, /*FromFile=*/nullptr, CurDir,
 /*SearchPath=*/nullptr, /*RelativePath=*/nullptr,
-/*SuggestedModule=*/nullptr, /*IsMapped=*/nullptr);
+/*SuggestedModule=*/nullptr, /*IsMapped=*/nullptr,
+/*IsFrameworkFound=*/nullptr);
 if (!File) {
   Diag(SourceLocation(), diag::err_pp_through_header_not_found)
   << PPOpts->PCHThroughHeader;
Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -507,7 +507,7 @@
   const DirectoryLookup *CurDir;
   const FileEntry *File =
   LookupFile(FilenameTok.getLocation(), Filename, isAngled, nullptr,
- nullptr, CurDir, nullptr, nullptr, nullptr, nullptr);
+ nullptr, CurDir, nullptr, nullptr, nullptr, nullptr, nullptr);
   if (!File) {
 if (!SuppressIncludeNotFoundError)
   Diag(FilenameTok, diag::err_pp_file_not_found) << Filename;
Index: clang/lib/Lex/PPMacroExpansion.cpp
===
--- clang/lib/Lex/PPMacroExpansion.cpp
+++ clang/lib/Lex/PPMacroExpansion.cpp
@@ -1236,7 +1236,7 @@
   const DirectoryLookup *CurDir;
   const FileEntry *File =
   PP.LookupFile(FilenameLoc, Filename, isAngled, LookupFrom, LookupFromFile,
-CurDir, nullptr, nullptr, nullptr, nullptr);
+CurDir, nullptr, nullptr, nullptr, nullptr, nullptr);
 
   if (PPCallbacks *Callbacks = PP.getPPCallbacks()) {
 SrcMgr::CharacteristicKind FileType = SrcMgr::C_User;
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -660,7 +660,8 @@
 const DirectoryLookup *FromDir, const FileEntry *FromFile,
 const DirectoryLookup *, SmallVectorImpl *SearchPath,
 SmallVectorImpl *RelativePath,
-ModuleMap::KnownHeader *SuggestedModule, bool *IsMapped, bool SkipCache) {
+ModuleMap::KnownHeader *SuggestedModule, bool *IsMapped,
+bool *IsFrameworkFound, bool SkipCache) {
   Module *RequestingModule = getModuleForLocation(FilenameLoc);
   bool RequestingModuleIsModuleInterface = !SourceMgr.isInMainFile(FilenameLoc);
 
@@ -718,7 +719,8 @@
 while (const FileEntry *FE = HeaderInfo.LookupFile(
Filename, FilenameLoc, isAngled, TmpFromDir, TmpCurDir,
Includers, SearchPath, RelativePath, RequestingModule,
-   SuggestedModule, /*IsMapped=*/nullptr, SkipCache)) {
+   SuggestedModule, /*IsMapped=*/nullptr,
+   /*IsFrameworkFound=*/nullptr, SkipCache)) {
   // Keep looking as if this file did a 

[PATCH] D56989: [analyzer][NFC] Keep track of whether enabling a checker was explictly specified in command line arguments

2019-01-25 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Cool!

I guess we still need to think how exactly do we want to resolve conflicts 
between dependencies.




Comment at: include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h:152
 
+  // FIXME: This *really* should be added to the frontend flag descriptions.
   /// Initializes a CheckerManager by calling the initialization functions for

Indeed! And, which is probably even more important, to `scan-build`'s help 
(assuming that the respective flags of `scan-build` do actually work in a 
similar manner).



Comment at: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp:143
+  // Would it be better to name it '~experimental' or something else
+  // that's ASCIIbetically last?
+  llvm::sort(Checkers, checkerNameLT);

I learned a new word today :) :)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56989/new/

https://reviews.llvm.org/D56989



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


[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

2019-01-25 Thread Julian Lettner via Phabricator via cfe-commits
yln abandoned this revision.
yln added a comment.

Created new revision for this change: https://reviews.llvm.org/D57278


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56624/new/

https://reviews.llvm.org/D56624



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


[PATCH] D56988: [analyzer][NFC] Supply CheckerRegistry with AnalyzerOptions

2019-01-25 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Yup, totally.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56988/new/

https://reviews.llvm.org/D56988



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


[PATCH] D57230: [analyzer] Toning down invalidation a bit

2019-01-25 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Thanks! A surprise, to be sure :) I'll try to test this on my set of projects 
as well :)

> Most of the extra results are not false positive due to the less invalidation 
> but other reasons, so we could focus on those problems instead of them being 
> hidden.

Could you share reproducible examples for these, probably in the form of FIXME 
tests? Given that they are "regressions", they are easy to creduce down to a 
small repro by using the test "there is still a change in behavior on this 
file".




Comment at: lib/StaticAnalyzer/Core/CallEvent.cpp:320-321
+ETraits.setTrait(
+UseBaseRegion ? MR->getBaseRegion() : MR,
+RegionAndSymbolInvalidationTraits::TK_PreserveContents);
+}

I suspect that the trait for non-base `MR` would never be read. The only place 
where this trait is accessed is in RegionStore.cpp where it asks whether the 
trait is applied to a cluster base, which is always a base region.



Comment at: test/Analysis/call-invalidation.cpp:146
   useAnything(&(s1.y));
-  clang_analyzer_eval(s1.x == 1); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(s1.x == 1); // expected-warning{{TRUE}}
 }

Let's leave at least one positive check around, eg. demonstrate that 
invalidation does happen for `s1.y` here.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57230/new/

https://reviews.llvm.org/D57230



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


[PATCH] D57075: [ObjC] For type substitution in generics use a regular recursive type visitor.

2019-01-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai updated this revision to Diff 183668.
vsapsai added a comment.

Rebase on top of https://reviews.llvm.org/D57270


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57075/new/

https://reviews.llvm.org/D57075

Files:
  clang/lib/AST/Type.cpp

Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -722,25 +722,30 @@
   return ctx.getObjCObjectPointerType(obj)->castAs();
 }
 
-template
-static QualType simpleTransform(ASTContext , QualType type, F &);
-
 namespace {
 
-/// Visitor used by simpleTransform() to perform the transformation.
-template
-struct SimpleTransformVisitor
- : public TypeVisitor, QualType> {
+/// Visitor used to perform a simple type transformation that does not change
+/// the semantics of the type.
+template 
+struct SimpleTransformVisitor : public TypeVisitor {
   ASTContext 
-  F &
 
   QualType recurse(QualType type) {
-return simpleTransform(Ctx, type, std::move(TheFunc));
+// Split out the qualifiers from the type.
+SplitQualType splitType = type.split();
+
+// Visit the type itself.
+QualType result = static_cast(this)->Visit(splitType.Ty);
+if (result.isNull())
+  return result;
+
+// Reconstruct the transformed type by applying the local qualifiers
+// from the split type.
+return Ctx.getQualifiedType(result, splitType.Quals);
   }
 
 public:
-  SimpleTransformVisitor(ASTContext , F &)
-  : Ctx(ctx), TheFunc(std::move(f)) {}
+  explicit SimpleTransformVisitor(ASTContext ) : Ctx(ctx) {}
 
   // None of the clients of this transformation can occur where
   // there are dependent types, so skip dependent types.
@@ -1120,220 +1125,205 @@
 #undef SUGARED_TYPE_CLASS
 };
 
-} // namespace
+struct SubstObjCTypeArgsVisitor
+: public SimpleTransformVisitor {
+  using BaseType = SimpleTransformVisitor;
 
-/// Perform a simple type transformation that does not change the
-/// semantics of the type.
-template
-static QualType simpleTransform(ASTContext , QualType type, F &) {
-  // Transform the type. If it changed, return the transformed result.
-  QualType transformed = f(type);
-  if (transformed.getAsOpaquePtr() != type.getAsOpaquePtr())
-return transformed;
-
-  // Split out the qualifiers from the type.
-  SplitQualType splitType = type.split();
-
-  // Visit the type itself.
-  SimpleTransformVisitor visitor(ctx, std::forward(f));
-  QualType result = visitor.Visit(splitType.Ty);
-  if (result.isNull())
-return result;
-
-  // Reconstruct the transformed type by applying the local qualifiers
-  // from the split type.
-  return ctx.getQualifiedType(result, splitType.Quals);
-}
+  ArrayRef TypeArgs;
+  ObjCSubstitutionContext SubstContext;
 
-/// Substitute the given type arguments for Objective-C type
-/// parameters within the given type, recursively.
-QualType QualType::substObjCTypeArgs(
-   ASTContext ,
-   ArrayRef typeArgs,
-   ObjCSubstitutionContext context) const {
-  return simpleTransform(ctx, *this,
- [&](QualType type) -> QualType {
-SplitQualType splitType = type.split();
+  SubstObjCTypeArgsVisitor(ASTContext , ArrayRef typeArgs,
+   ObjCSubstitutionContext context)
+  : BaseType(ctx), TypeArgs(typeArgs), SubstContext(context) {}
 
+  QualType VisitObjCTypeParamType(const ObjCTypeParamType *OTPTy) {
 // Replace an Objective-C type parameter reference with the corresponding
 // type argument.
-if (const auto *OTPTy = dyn_cast(splitType.Ty)) {
-  ObjCTypeParamDecl *typeParam = OTPTy->getDecl();
-  // If we have type arguments, use them.
-  if (!typeArgs.empty()) {
-QualType argType = typeArgs[typeParam->getIndex()];
-if (OTPTy->qual_empty())
-  return ctx.getQualifiedType(argType, splitType.Quals);
-
-// Apply protocol lists if exists.
-bool hasError;
-SmallVector protocolsVec;
-protocolsVec.append(OTPTy->qual_begin(),
-OTPTy->qual_end());
-ArrayRef protocolsToApply = protocolsVec;
-QualType resultTy = ctx.applyObjCProtocolQualifiers(argType,
-protocolsToApply, hasError, true/*allowOnPointerType*/);
-
-return ctx.getQualifiedType(resultTy, splitType.Quals);
-  }
+ObjCTypeParamDecl *typeParam = OTPTy->getDecl();
+// If we have type arguments, use them.
+if (!TypeArgs.empty()) {
+  QualType argType = TypeArgs[typeParam->getIndex()];
+  if (OTPTy->qual_empty())
+return argType;
+
+  // Apply protocol lists if exists.
+  bool hasError;
+  SmallVector protocolsVec;
+  protocolsVec.append(OTPTy->qual_begin(), OTPTy->qual_end());
+  ArrayRef protocolsToApply = protocolsVec;
+  return Ctx.applyObjCProtocolQualifiers(
+  argType, protocolsToApply, hasError, true/*allowOnPointerType*/);
+}
 
-  switch (context) {
-   

[PATCH] D57270: [ObjC] Fix non-canonical types preventing type arguments substitution.

2019-01-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai created this revision.
vsapsai added reviewers: ahatanak, erik.pilkington.
Herald added subscribers: dexonsmith, jkorous.

`QualType::substObjCTypeArgs` doesn't go past non-canonical types and as
the result misses some of the substitutions like `ObjCTypeParamType`.

Update `SimpleTransformVisitor` to traverse past the type sugar.


https://reviews.llvm.org/D57270

Files:
  clang/lib/AST/Type.cpp
  clang/test/SemaObjC/parameterized_classes_subst.m

Index: clang/test/SemaObjC/parameterized_classes_subst.m
===
--- clang/test/SemaObjC/parameterized_classes_subst.m
+++ clang/test/SemaObjC/parameterized_classes_subst.m
@@ -104,6 +104,12 @@
 @property (nonatomic,retain) ViewType view;
 @end
 
+@interface TypedefTypeParam : NSObject
+typedef T AliasT;
+- (void)test:(AliasT)object;
+// expected-note@-1 {{parameter 'object' here}}
+@end
+
 // --
 // Nullability
 // --
@@ -190,6 +196,7 @@
MutableSetOfArrays *mutStringArraySet,
NSMutableSet *mutSet,
MutableSetOfArrays *mutArraySet,
+   TypedefTypeParam *typedefTypeParam,
void (^block)(void)) {
   Window *window;
 
@@ -199,6 +206,7 @@
   [mutStringArraySet addObject: window]; // expected-warning{{parameter of type 'NSArray *'}}
   [mutSet addObject: window]; // expected-warning{{parameter of incompatible type 'id'}}
   [mutArraySet addObject: window]; // expected-warning{{parameter of incompatible type 'id'}}
+  [typedefTypeParam test: window]; // expected-warning{{parameter of type 'NSString *'}}
   [block addObject: window]; // expected-warning{{parameter of incompatible type 'id'}}
 }
 
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -751,6 +751,17 @@
 
 #define TRIVIAL_TYPE_CLASS(Class) \
   QualType Visit##Class##Type(const Class##Type *T) { return QualType(T, 0); }
+#define SUGARED_TYPE_CLASS(Class) \
+  QualType Visit##Class##Type(const Class##Type *T) { \
+if (!T->isSugared()) \
+  return QualType(T, 0); \
+QualType desugaredType = recurse(T->desugar()); \
+if (desugaredType.isNull()) \
+  return {}; \
+if (desugaredType.getAsOpaquePtr() == T->desugar().getAsOpaquePtr()) \
+  return QualType(T, 0); \
+return desugaredType; \
+  }
 
   TRIVIAL_TYPE_CLASS(Builtin)
 
@@ -954,8 +965,8 @@
 return Ctx.getParenType(innerType);
   }
 
-  TRIVIAL_TYPE_CLASS(Typedef)
-  TRIVIAL_TYPE_CLASS(ObjCTypeParam)
+  SUGARED_TYPE_CLASS(Typedef)
+  SUGARED_TYPE_CLASS(ObjCTypeParam)
 
   QualType VisitAdjustedType(const AdjustedType *T) {
 QualType originalType = recurse(T->getOriginalType());
@@ -986,15 +997,15 @@
 return Ctx.getDecayedType(originalType);
   }
 
-  TRIVIAL_TYPE_CLASS(TypeOfExpr)
-  TRIVIAL_TYPE_CLASS(TypeOf)
-  TRIVIAL_TYPE_CLASS(Decltype)
-  TRIVIAL_TYPE_CLASS(UnaryTransform)
+  SUGARED_TYPE_CLASS(TypeOfExpr)
+  SUGARED_TYPE_CLASS(TypeOf)
+  SUGARED_TYPE_CLASS(Decltype)
+  SUGARED_TYPE_CLASS(UnaryTransform)
   TRIVIAL_TYPE_CLASS(Record)
   TRIVIAL_TYPE_CLASS(Enum)
 
   // FIXME: Non-trivial to implement, but important for C++
-  TRIVIAL_TYPE_CLASS(Elaborated)
+  SUGARED_TYPE_CLASS(Elaborated)
 
   QualType VisitAttributedType(const AttributedType *T) {
 QualType modifiedType = recurse(T->getModifiedType());
@@ -1029,7 +1040,7 @@
   }
 
   // FIXME: Non-trivial to implement, but important for C++
-  TRIVIAL_TYPE_CLASS(TemplateSpecialization)
+  SUGARED_TYPE_CLASS(TemplateSpecialization)
 
   QualType VisitAutoType(const AutoType *T) {
 if (!T->isDeduced())
@@ -1048,7 +1059,7 @@
   }
 
   // FIXME: Non-trivial to implement, but important for C++
-  TRIVIAL_TYPE_CLASS(PackExpansion)
+  SUGARED_TYPE_CLASS(PackExpansion)
 
   QualType VisitObjCObjectType(const ObjCObjectType *T) {
 QualType baseType = recurse(T->getBaseType());
@@ -1106,6 +1117,7 @@
   }
 
 #undef TRIVIAL_TYPE_CLASS
+#undef SUGARED_TYPE_CLASS
 };
 
 } // namespace
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57268: [dllimport] Don't use RAV to check inlinability

2019-01-25 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

Yes, it's a little bit unfortunate that the code needs to get more complicated 
due to this. The RecursiveStmtVisitor idea that you mention sounds like it 
might be a good idea (but if it turns out not to be, I'm not entirely opposed 
to this patch either).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57268/new/

https://reviews.llvm.org/D57268



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


[PATCH] D57265: [PM/CC1] Add -f[no-]split-cold-code CC1 options to toggle splitting

2019-01-25 Thread Vedant Kumar via Phabricator via cfe-commits
vsk updated this revision to Diff 183661.
vsk added a comment.

- Fix a think-o in a comment.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57265/new/

https://reviews.llvm.org/D57265

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/CC1Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/split-cold-code.c
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Transforms/IPO/PassManagerBuilder.cpp

Index: llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
===
--- llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
+++ llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
@@ -168,6 +168,7 @@
 VerifyInput = false;
 VerifyOutput = false;
 MergeFunctions = false;
+SplitColdCode = false;
 PrepareForLTO = false;
 EnablePGOInstrGen = false;
 PGOInstrGen = "";
@@ -519,7 +520,7 @@
 
   // Split out cold code before inlining. See comment in the new PM
   // (\ref buildModuleSimplificationPipeline).
-  if (EnableHotColdSplit && DefaultOrPreLinkPipeline)
+  if ((EnableHotColdSplit || SplitColdCode) && DefaultOrPreLinkPipeline)
 MPM.add(createHotColdSplittingPass());
 
   addInstructionCombiningPass(MPM); // Clean up after IPCP & DAE
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -663,7 +663,7 @@
   // not grow after inlining, and 2) inhibiting inlining of cold code improves
   // code size & compile time. Split after Mem2Reg to make code model estimates
   // more accurate, but before InstCombine to allow it to clean things up.
-  if (EnableHotColdSplit && Phase != ThinLTOPhase::PostLink)
+  if ((EnableHotColdSplit || SplitColdCode) && Phase != ThinLTOPhase::PostLink)
 MPM.addPass(HotColdSplittingPass());
 
   // Create a small function pass pipeline to cleanup after all the global
@@ -2079,3 +2079,7 @@
 
   return Error::success();
 }
+
+void PassBuilder::setEnableHotColdSplitting(bool Enabled) {
+  SplitColdCode = Enabled;
+}
Index: llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
===
--- llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
+++ llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
@@ -152,6 +152,7 @@
   bool VerifyInput;
   bool VerifyOutput;
   bool MergeFunctions;
+  bool SplitColdCode;
   bool PrepareForLTO;
   bool PrepareForThinLTO;
   bool PerformThinLTO;
Index: llvm/include/llvm/Passes/PassBuilder.h
===
--- llvm/include/llvm/Passes/PassBuilder.h
+++ llvm/include/llvm/Passes/PassBuilder.h
@@ -577,6 +577,10 @@
 TopLevelPipelineParsingCallbacks.push_back(C);
   }
 
+  /// Enable or disable the hot/cold splitting optimization. By default, it is
+  /// disabled.
+  void setEnableHotColdSplitting(bool Enabled);
+
 private:
   static Optional>
   parsePipelineText(StringRef Text);
@@ -664,6 +668,8 @@
   // AA callbacks
   SmallVector, 2>
   AAParsingCallbacks;
+  // Tunable passes
+  bool SplitColdCode = false;
 };
 
 /// This utility template takes care of adding require<> and invalidate<>
Index: clang/test/CodeGen/split-cold-code.c
===
--- /dev/null
+++ clang/test/CodeGen/split-cold-code.c
@@ -0,0 +1,81 @@
+// === Old PM ===
+// No splitting at -O0.
+// RUN: %clang_cc1 -O0 -fsplit-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// No splitting at -Oz.
+// RUN: %clang_cc1 -Oz -fsplit-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// No splitting by default, even at -O3.
+// RUN: %clang_cc1 -O3 -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// No splitting when it's explicitly disabled.
+// RUN: %clang_cc1 -O3 -fno-split-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// No splitting when LLVM passes are disabled.
+// RUN: %clang_cc1 -O3 -fsplit-cold-code -disable-llvm-passes -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// Split at -O1.
+// RUN: %clang_cc1 -O1 -fsplit-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-SPLIT %s
+//
+// Split at -Os.
+// RUN: %clang_cc1 -Os -fsplit-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-SPLIT %s
+//
+// Split at 

[PATCH] D57268: [dllimport] Don't use RAV to check inlinability

2019-01-25 Thread Reid Kleckner via Phabricator via cfe-commits
rnk created this revision.
rnk added a reviewer: hans.

I don't like this change, because I had to copy a fair amount of logic
from RAV into the dllimport visitor. However, the build time and size
results were still impressive, so I wanted to upload this and get a
second opinion. Here's the data:

| metric   | before | after | diff  |
| time (s) | 38.7   | 25.3  | -13.4 |
| obj (kb) | 12012  | 9428  | -2584 |
| exe (kb) | 86000  | 85924 | -76   |
|

Do you think I should land this as is? I'm considering factoring some of
this stuff up into a "RecursiveStmtVisitor" that tries to visit "code
that executes in a particular function scope". It could be used for
availability diagnostics that search for use of particular local
variables, etc. That seems to be the main use case we have for RAVs:
given a predicate, find all referenced decls, and check some predicate.


https://reviews.llvm.org/D57268

Files:
  clang/lib/CodeGen/CodeGenModule.cpp

Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -32,7 +32,6 @@
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Mangle.h"
 #include "clang/AST/RecordLayout.h"
-#include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/AST/StmtVisitor.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Basic/CharInfo.h"
@@ -2317,64 +2316,95 @@
 
   // Make sure we're not referencing non-imported vars or functions.
   struct DLLImportFunctionVisitor
-  : public RecursiveASTVisitor {
-bool SafeToInline = true;
-
-bool shouldVisitImplicitCode() const { return true; }
-
-bool VisitVarDecl(VarDecl *VD) {
-  if (VD->getTLSKind()) {
-// A thread-local variable cannot be imported.
-SafeToInline = false;
-return SafeToInline;
+  : public ConstStmtVisitor {
+bool VisitDeclStmt(const DeclStmt *E) {
+  for (const Decl *D : E->decls()) {
+if (const auto *VD = dyn_cast(D)) {
+  if (!VisitVarDecl(VD))
+return false;
+  // Traverse variable initializers, which are common sources of
+  // function references.
+  if (!VisitStmt(VD->getInit()))
+return false;
+}
   }
+  return true;
+}
+
+bool VisitVarDecl(const VarDecl *VD) {
+  // A thread-local variable cannot be imported.
+  if (VD->getTLSKind())
+return false;
 
   // A variable definition might imply a destructor call.
   if (VD->isThisDeclarationADefinition())
-SafeToInline = !HasNonDllImportDtor(VD->getType());
+if (HasNonDllImportDtor(VD->getType()))
+  return false;
 
-  return SafeToInline;
+  return true;
 }
 
-bool VisitCXXBindTemporaryExpr(CXXBindTemporaryExpr *E) {
+bool VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
+  bool SafeToInline = true;
   if (const auto *D = E->getTemporary()->getDestructor())
 SafeToInline = D->hasAttr();
   return SafeToInline;
 }
 
-bool VisitDeclRefExpr(DeclRefExpr *E) {
-  ValueDecl *VD = E->getDecl();
+bool VisitDeclRefExpr(const DeclRefExpr *E) {
+  const ValueDecl *VD = E->getDecl();
+  bool SafeToInline = true;
   if (isa(VD))
 SafeToInline = VD->hasAttr();
-  else if (VarDecl *V = dyn_cast(VD))
+  else if (const VarDecl *V = dyn_cast(VD))
 SafeToInline = !V->hasGlobalStorage() || V->hasAttr();
   return SafeToInline;
 }
 
-bool VisitCXXConstructExpr(CXXConstructExpr *E) {
-  SafeToInline = E->getConstructor()->hasAttr();
-  return SafeToInline;
+bool VisitCXXConstructExpr(const CXXConstructExpr *E) {
+  return E->getConstructor()->hasAttr();
 }
 
-bool VisitCXXMemberCallExpr(CXXMemberCallExpr *E) {
-  CXXMethodDecl *M = E->getMethodDecl();
-  if (!M) {
-// Call through a pointer to member function. This is safe to inline.
-SafeToInline = true;
-  } else {
+bool VisitCXXMemberCallExpr(const CXXMemberCallExpr *E) {
+  // If M is null, this is a call through a pointer to member function. This
+  // is safe to inline.
+  const CXXMethodDecl *M = E->getMethodDecl();
+  bool SafeToInline = true;
+  if (M)
 SafeToInline = M->hasAttr();
-  }
   return SafeToInline;
 }
 
-bool VisitCXXDeleteExpr(CXXDeleteExpr *E) {
-  SafeToInline = E->getOperatorDelete()->hasAttr();
-  return SafeToInline;
+bool VisitCXXDeleteExpr(const CXXDeleteExpr *E) {
+  return E->getOperatorDelete()->hasAttr();
 }
 
-bool VisitCXXNewExpr(CXXNewExpr *E) {
-  SafeToInline = E->getOperatorNew()->hasAttr();
-  return SafeToInline;
+bool VisitCXXNewExpr(const CXXNewExpr *E) {
+  return E->getOperatorNew()->hasAttr();
+}
+
+bool VisitStmt(const Stmt *S) {
+  if (!S)
+return true;
+  for (const Stmt *Child : S->children())
+  

[PATCH] D57106: [AST] Introduce GenericSelectionExpr::Association

2019-01-25 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno updated this revision to Diff 183658.
riccibruno added a comment.

Update the comment in the iterator as per Aaron's comments.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57106/new/

https://reviews.llvm.org/D57106

Files:
  include/clang/AST/Expr.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/StmtDataCollectors.td
  lib/AST/ASTDumper.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Sema/SemaExprObjC.cpp
  lib/Sema/SemaPseudoObject.cpp
  lib/Sema/TreeTransform.h

Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -9071,10 +9071,10 @@
 
   SmallVector AssocExprs;
   SmallVector AssocTypes;
-  for (unsigned i = 0; i != E->getNumAssocs(); ++i) {
-TypeSourceInfo *TS = E->getAssocTypeSourceInfo(i);
-if (TS) {
-  TypeSourceInfo *AssocType = getDerived().TransformType(TS);
+  for (const GenericSelectionExpr::Association  : E->associations()) {
+TypeSourceInfo *TSI = Assoc.getTypeSourceInfo();
+if (TSI) {
+  TypeSourceInfo *AssocType = getDerived().TransformType(TSI);
   if (!AssocType)
 return ExprError();
   AssocTypes.push_back(AssocType);
@@ -9082,7 +9082,8 @@
   AssocTypes.push_back(nullptr);
 }
 
-ExprResult AssocExpr = getDerived().TransformExpr(E->getAssocExpr(i));
+ExprResult AssocExpr =
+getDerived().TransformExpr(Assoc.getAssociationExpr());
 if (AssocExpr.isInvalid())
   return ExprError();
 AssocExprs.push_back(AssocExpr.get());
Index: lib/Sema/SemaPseudoObject.cpp
===
--- lib/Sema/SemaPseudoObject.cpp
+++ lib/Sema/SemaPseudoObject.cpp
@@ -140,19 +140,23 @@
 unsigned resultIndex = gse->getResultIndex();
 unsigned numAssocs = gse->getNumAssocs();
 
-SmallVector assocs(numAssocs);
-SmallVector assocTypes(numAssocs);
-
-for (unsigned i = 0; i != numAssocs; ++i) {
-  Expr *assoc = gse->getAssocExpr(i);
-  if (i == resultIndex) assoc = rebuild(assoc);
-  assocs[i] = assoc;
-  assocTypes[i] = gse->getAssocTypeSourceInfo(i);
+SmallVector assocExprs;
+SmallVector assocTypes;
+assocExprs.reserve(numAssocs);
+assocTypes.reserve(numAssocs);
+
+for (const GenericSelectionExpr::Association  :
+ gse->associations()) {
+  Expr *assocExpr = assoc.getAssociationExpr();
+  if (assoc.isSelected())
+assocExpr = rebuild(assocExpr);
+  assocExprs.push_back(assocExpr);
+  assocTypes.push_back(assoc.getTypeSourceInfo());
 }
 
 return GenericSelectionExpr::Create(
 S.Context, gse->getGenericLoc(), gse->getControllingExpr(),
-assocTypes, assocs, gse->getDefaultLoc(), gse->getRParenLoc(),
+assocTypes, assocExprs, gse->getDefaultLoc(), gse->getRParenLoc(),
 gse->containsUnexpandedParameterPack(), resultIndex);
   }
 
Index: lib/Sema/SemaExprObjC.cpp
===
--- lib/Sema/SemaExprObjC.cpp
+++ lib/Sema/SemaExprObjC.cpp
@@ -4332,14 +4332,16 @@
 assert(!gse->isResultDependent());
 
 unsigned n = gse->getNumAssocs();
-SmallVector subExprs(n);
-SmallVector subTypes(n);
-for (unsigned i = 0; i != n; ++i) {
-  subTypes[i] = gse->getAssocTypeSourceInfo(i);
-  Expr *sub = gse->getAssocExpr(i);
-  if (i == gse->getResultIndex())
+SmallVector subExprs;
+SmallVector subTypes;
+subExprs.reserve(n);
+subTypes.reserve(n);
+for (const GenericSelectionExpr::Association  : gse->associations()) {
+  subTypes.push_back(assoc.getTypeSourceInfo());
+  Expr *sub = assoc.getAssociationExpr();
+  if (assoc.isSelected())
 sub = stripARCUnbridgedCast(sub);
-  subExprs[i] = sub;
+  subExprs.push_back(sub);
 }
 
 return GenericSelectionExpr::Create(
Index: lib/AST/StmtProfile.cpp
===
--- lib/AST/StmtProfile.cpp
+++ lib/AST/StmtProfile.cpp
@@ -1259,13 +1259,14 @@
 
 void StmtProfiler::VisitGenericSelectionExpr(const GenericSelectionExpr *S) {
   VisitExpr(S);
-  for (unsigned i = 0; i != S->getNumAssocs(); ++i) {
-QualType T = S->getAssocType(i);
+  for (const GenericSelectionExpr::ConstAssociation  :
+   S->associations()) {
+QualType T = Assoc.getType();
 if (T.isNull())
   ID.AddPointer(nullptr);
 else
   VisitType(T);
-VisitExpr(S->getAssocExpr(i));
+VisitExpr(Assoc.getAssociationExpr());
   }
 }
 
Index: lib/AST/StmtPrinter.cpp
===
--- lib/AST/StmtPrinter.cpp
+++ lib/AST/StmtPrinter.cpp
@@ -1261,15 +1261,15 @@
 void StmtPrinter::VisitGenericSelectionExpr(GenericSelectionExpr *Node) {
   OS << 

[PATCH] D56928: Support attribute used in member funcs of class templates

2019-01-25 Thread Rafael Auler via Phabricator via cfe-commits
rafauler updated this revision to Diff 183657.
rafauler added a comment.

No problem, thanks for your suggestions!


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56928/new/

https://reviews.llvm.org/D56928

Files:
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp


Index: test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp
===
--- /dev/null
+++ test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp
@@ -0,0 +1,20 @@
+// Check that PR17480 is fixed: __attribute__((used)) ignored in templated
+// classes
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -O0 -o - %s \
+// RUN:  | FileCheck %s
+
+namespace InstantiateUsedMemberDefinition {
+  template  struct S {
+int __attribute__((used)) f() {
+  return 0;
+}
+  };
+
+  void test() {
+// Check that InstantiateUsedMemberDefinition::S::f() is defined
+// as a result of the S class template implicit instantiation
+// CHECK: define linkonce_odr i32 
@_ZN31InstantiateUsedMemberDefinition1SIiE1fEv
+S inst;
+  }
+}
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -2176,6 +2176,22 @@
 Owner->addDecl(Method);
   }
 
+  // PR17480: Honor the used attribute to instantiate member function
+  // definitions
+  if (Method->hasAttr()) {
+if (auto *A = dyn_cast(Owner)) {
+  SourceLocation Loc;
+  if (MemberSpecializationInfo *MSInfo = A->getMemberSpecializationInfo()) 
{
+Loc = MSInfo->getPointOfInstantiation();
+  } else if (ClassTemplateSpecializationDecl *Spec =
+ dyn_cast(A)) {
+Loc = Spec->getPointOfInstantiation();
+  }
+
+  SemaRef.MarkFunctionReferenced(Loc, Method, /*MightBeOdrUse=*/true);
+}
+  }
+
   return Method;
 }
 


Index: test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp
===
--- /dev/null
+++ test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp
@@ -0,0 +1,20 @@
+// Check that PR17480 is fixed: __attribute__((used)) ignored in templated
+// classes
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -O0 -o - %s \
+// RUN:  | FileCheck %s
+
+namespace InstantiateUsedMemberDefinition {
+  template  struct S {
+int __attribute__((used)) f() {
+  return 0;
+}
+  };
+
+  void test() {
+// Check that InstantiateUsedMemberDefinition::S::f() is defined
+// as a result of the S class template implicit instantiation
+// CHECK: define linkonce_odr i32 @_ZN31InstantiateUsedMemberDefinition1SIiE1fEv
+S inst;
+  }
+}
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -2176,6 +2176,22 @@
 Owner->addDecl(Method);
   }
 
+  // PR17480: Honor the used attribute to instantiate member function
+  // definitions
+  if (Method->hasAttr()) {
+if (auto *A = dyn_cast(Owner)) {
+  SourceLocation Loc;
+  if (MemberSpecializationInfo *MSInfo = A->getMemberSpecializationInfo()) {
+Loc = MSInfo->getPointOfInstantiation();
+  } else if (ClassTemplateSpecializationDecl *Spec =
+ dyn_cast(A)) {
+Loc = Spec->getPointOfInstantiation();
+  }
+
+  SemaRef.MarkFunctionReferenced(Loc, Method, /*MightBeOdrUse=*/true);
+}
+  }
+
   return Method;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57267: [AST] Factor out the logic of the various Expr::Ignore*

2019-01-25 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno created this revision.
riccibruno added a reviewer: aaron.ballman.
riccibruno added a project: clang.
Herald added a subscriber: cfe-commits.

Now that the implementation of all of the `Expr::Ignore*` is in `Expr.cpp` we 
can try to remove some duplication. Do this by separating the logic of the 
`Expr::Ignore*` from the iterative loop.

This is NFC, except for one change: `IgnoreParenImpCasts` now skips, among 
other things, everything that `IgnoreImpCasts` skips. This means `FullExpr` are 
now skipped by `IgnoreParenImpCasts`. This was likely an oversight when 
`FullExpr` was added to the nodes skipped by `IgnoreParenImpCasts`.


Repository:
  rC Clang

https://reviews.llvm.org/D57267

Files:
  include/clang/AST/Expr.h
  lib/AST/Expr.cpp

Index: lib/AST/Expr.cpp
===
--- lib/AST/Expr.cpp
+++ lib/AST/Expr.cpp
@@ -2556,192 +2556,182 @@
   return QualType();
 }
 
-Expr *Expr::IgnoreImpCasts() {
-  Expr *E = this;
-  while (true)
-if (ImplicitCastExpr *ICE = dyn_cast(E))
-  E = ICE->getSubExpr();
-else if (FullExpr *FE = dyn_cast(E))
-  E = FE->getSubExpr();
-else
-  break;
+/* Logic for the various Expr::Ignore* /
+
+static Expr *IgnoreImpCastsSingleStep(Expr *E) {
+  if (auto *ICE = dyn_cast_or_null(E))
+return ICE->getSubExpr();
+
+  else if (auto *FE = dyn_cast_or_null(E))
+return FE->getSubExpr();
+
   return E;
 }
 
-Expr *Expr::IgnoreImplicit() {
-  Expr *E = this;
-  Expr *LastE = nullptr;
-  while (E != LastE) {
-LastE = E;
+static Expr *IgnoreImpCastsExtraSingleStep(Expr *E) {
+  // FIXME: Skip what IgnoreImpCastsSingleStep plus MaterializeTemporaryExpr
+  // and SubstNonTypeTemplateParmExpr to account for the current behaviour of
+  // IgnoreParenImpCasts().
+  E = IgnoreImpCastsSingleStep(E);
 
-if (auto *ICE = dyn_cast(E))
-  E = ICE->getSubExpr();
+  if (auto *MTE = dyn_cast_or_null(E))
+return MTE->GetTemporaryExpr();
 
-if (auto *FE = dyn_cast(E))
-  E = FE->getSubExpr();
+  else if (auto *NTTP = dyn_cast_or_null(E))
+return NTTP->getReplacement();
 
-if (auto *MTE = dyn_cast(E))
-  E = MTE->GetTemporaryExpr();
+  return E;
+}
+
+static Expr *IgnoreCastsSingleStep(Expr *E) {
+  if (auto *CE = dyn_cast_or_null(E))
+return CE->getSubExpr();
+
+  else if (auto *FE = dyn_cast_or_null(E))
+return FE->getSubExpr();
+
+  else if (auto *MTE = dyn_cast_or_null(E))
+return MTE->GetTemporaryExpr();
+
+  else if (auto *NTTP = dyn_cast_or_null(E))
+return NTTP->getReplacement();
 
-if (auto *BTE = dyn_cast(E))
-  E = BTE->getSubExpr();
-  }
   return E;
 }
 
-Expr* Expr::IgnoreParens() {
-  Expr* E = this;
-  while (true) {
-if (ParenExpr* P = dyn_cast(E)) {
-  E = P->getSubExpr();
-  continue;
-}
-if (UnaryOperator* P = dyn_cast(E)) {
-  if (P->getOpcode() == UO_Extension) {
-E = P->getSubExpr();
-continue;
-  }
-}
-if (GenericSelectionExpr* P = dyn_cast(E)) {
-  if (!P->isResultDependent()) {
-E = P->getResultExpr();
-continue;
-  }
-}
-if (ChooseExpr* P = dyn_cast(E)) {
-  if (!P->isConditionDependent()) {
-E = P->getChosenSubExpr();
-continue;
-  }
-}
-if (ConstantExpr *CE = dyn_cast(E)) {
-  E = CE->getSubExpr();
-  continue;
-}
-return E;
+static Expr *IgnoreLValueCastsSingleStep(Expr *E) {
+  // Skip what IgnoreCastsSingleStep skips, except that only
+  // lvalue-to-rvalue casts are skipped.
+  if (auto *CE = dyn_cast_or_null(E))
+if (CE->getCastKind() != CK_LValueToRValue)
+  return E;
+
+  return IgnoreCastsSingleStep(E);
+}
+
+static Expr *IgnoreBaseCastsSingleStep(Expr *E) {
+  if (auto *CE = dyn_cast_or_null(E))
+if (CE->getCastKind() == CK_DerivedToBase ||
+CE->getCastKind() == CK_UncheckedDerivedToBase ||
+CE->getCastKind() == CK_NoOp)
+  return CE->getSubExpr();
+
+  return E;
+}
+
+static Expr *IgnoreImplicitSingleStep(Expr *E) {
+  E = IgnoreImpCastsSingleStep(E);
+
+  if (auto *MTE = dyn_cast_or_null(E))
+return MTE->GetTemporaryExpr();
+
+  else if (auto *BTE = dyn_cast_or_null(E))
+return BTE->getSubExpr();
+
+  return E;
+}
+
+static Expr *IgnoreParensSingleStep(Expr *E) {
+  if (auto *PE = dyn_cast_or_null(E))
+return PE->getSubExpr();
+
+  else if (auto *UO = dyn_cast_or_null(E)) {
+if (UO->getOpcode() == UO_Extension)
+  return UO->getSubExpr();
+  }
+
+  else if (auto *GSE = dyn_cast_or_null(E)) {
+if (!GSE->isResultDependent())
+  return GSE->getResultExpr();
+  }
+
+  else if (auto *CE = dyn_cast_or_null(E)) {
+if (!CE->isConditionDependent())
+  return CE->getChosenSubExpr();
   }
+
+  else if (auto *CE = dyn_cast_or_null(E))
+return CE->getSubExpr();
+
+  return E;
 }
 
-/// IgnoreParenCasts - Ignore parentheses and casts.  Strip off any ParenExpr
-/// or CastExprs or 

Re: r352079 - [FileManager] Revert r347205 to avoid PCH file-descriptor leak.

2019-01-25 Thread Hans Wennborg via cfe-commits
Sorry to bring more bad news, but merging this seems to have regressed
a clangd test on the branch (I didn't notice at the time, because I
ran the wrong set of tests, d'oh).

I've searched my inbox but couldn't find any recent commits touching
the test. Do you have any idea what might be happening?

 TEST 'Extra Tools Unit Tests ::
clangd/./ClangdTests/GoToInclude.All' FAILED 
Note: Google Test filter = GoToInclude.All
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from GoToInclude
[ RUN  ] GoToInclude.All
/work/llvm-8/llvm/tools/clang/tools/extra/unittests/clangd/XRefsTests.cpp:1086:
Failure
Value of: *Locations
Expected: has 1 element that file range ("/clangd-test/foo.h", 0:0-0:0)
  Actual: {}
/work/llvm-8/llvm/tools/clang/tools/extra/unittests/clangd/XRefsTests.cpp:1096:
Failure
Value of: *Locations
Expected: has 1 element that file range ("/clangd-test/foo.h", 0:0-0:0)
  Actual: {}
/work/llvm-8/llvm/tools/clang/tools/extra/unittests/clangd/XRefsTests.cpp:1101:
Failure
Value of: *Locations
Expected: has 1 element that file range ("/clangd-test/foo.h", 0:0-0:0)
  Actual: {}
[  FAILED  ] GoToInclude.All (14 ms)
[--] 1 test from GoToInclude (14 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (14 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] GoToInclude.All

 1 FAILED TEST
Updating file /clangd-test/foo.h with command [/clangd-test] clang
-ffreestanding /clangd-test/foo.h
Updating file /clangd-test/foo.cpp with command [/clangd-test] clang
-ffreestanding /clangd-test/foo.cpp
Preamble for file /clangd-test/foo.h cannot be reused. Attempting to rebuild it.
Preamble for file /clangd-test/foo.cpp cannot be reused. Attempting to
rebuild it.
Built preamble of size 169108 for file /clangd-test/foo.h
Built preamble of size 173056 for file /clangd-test/foo.cpp


Testing Time: 5.30s

Failing Tests (1):
Extra Tools Unit Tests :: clangd/./ClangdTests/GoToInclude.All

  Expected Passes: 1123
  Expected Failures  : 1
  Unsupported Tests  : 3
  Unexpected Failures: 1

On Fri, Jan 25, 2019 at 10:18 AM Hans Wennborg  wrote:
>
> Merged to 8.0 in r352225.
>
> On Thu, Jan 24, 2019 at 10:55 AM Sam McCall via cfe-commits
>  wrote:
> >
> > Author: sammccall
> > Date: Thu Jan 24 10:55:24 2019
> > New Revision: 352079
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=352079=rev
> > Log:
> > [FileManager] Revert r347205 to avoid PCH file-descriptor leak.
> >
> > Summary:
> > r347205 fixed a bug in FileManager: first calling
> > getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
> > the file not being open.
> >
> > Unfortunately, some code was (inadvertently?) relying on this bug: when
> > building with a PCH, the file entries are obtained first by passing
> > shouldOpen=false, and then later shouldOpen=true, without any intention
> > of reading them. After r347205, they do get unneccesarily opened.
> > Aside from extra operations, this means they need to be closed. Normally
> > files are closed when their contents are read. As these files are never
> > read, they stay open until clang exits. On platforms with a low
> > open-files limit (e.g. Mac), this can lead to spurious file-not-found
> > errors when building large projects with PCH enabled, e.g.
> >   https://bugs.chromium.org/p/chromium/issues/detail?id=924225
> >
> > Fixing the callsites to pass shouldOpen=false when the file won't be
> > read is not quite trivial (that info isn't available at the direct
> > callsite), and passing shouldOpen=false is a performance regression (it
> > results in open+fstat pairs being replaced by stat+open).
> >
> > So an ideal fix is going to be a little risky and we need some fix soon
> > (especially for the llvm 8 branch).
> > The problem addressed by r347205 is rare and has only been observed in
> > clangd. It was present in llvm-7, so we can live with it for now.
> >
> > Reviewers: bkramer, thakis
> >
> > Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
> >
> > Differential Revision: https://reviews.llvm.org/D57165
> >
> > Added:
> > cfe/trunk/test/PCH/leakfiles
> > Modified:
> > cfe/trunk/include/clang/Basic/FileManager.h
> > cfe/trunk/lib/Basic/FileManager.cpp
> > cfe/trunk/unittests/Basic/FileManagerTest.cpp
> >
> > Modified: cfe/trunk/include/clang/Basic/FileManager.h
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=352079=352078=352079=diff
> > ==
> > --- cfe/trunk/include/clang/Basic/FileManager.h (original)
> > +++ cfe/trunk/include/clang/Basic/FileManager.h Thu Jan 24 10:55:24 2019
> > @@ -69,15 +69,14 @@ class FileEntry {
> >bool IsNamedPipe;
> >bool InPCH;
> >bool IsValid;   // Is this \c 

[PATCH] D57266: [AST] Update the comments of the various Expr::Ignore* + Related cleanups

2019-01-25 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno created this revision.
riccibruno added a reviewer: aaron.ballman.
riccibruno added a project: clang.
Herald added a subscriber: cfe-commits.

The description of what the various `Expr::Ignore*` do has drifted from the 
actual implementation.

Inspection reveals that `IgnoreParenImpCasts()` is not equivalent to doing 
`IgnoreParens()` + `IgnoreImpCasts()` until reaching a fixed point, but 
`IgnoreParenCasts()` is equivalent to doing `IgnoreParens() + IgnoreCasts()` 
until reaching a fixed point.

There is also a fair amount of duplication in the various `Expr::Ignore*` 
functions which increase the chance of further future inconsistencies.

In preparation for the next patch which will factor out the implementation of 
the various `Expr::Ignore*`, do the following cleanups:

Remove `Stmt::IgnoreImplicit`, in favor of `Expr::IgnoreImplicit`. 
`IgnoreImplicit` is the only function among all of the `Expr::Ignore*` which is 
available in `Stmt`. There are only a few users of `Stmt::IgnoreImplicit`. They 
can just use instead `Expr::IgnoreImplicit` like they have to do for the other 
`Ignore*`.

Move `Expr::IgnoreImpCasts()` from `Expr.h` to `Expr.cpp`. This made no 
difference in the run-time with my usual benchmark (-fsyntax-only on all of 
Boost).

While we are at it, make `IgnoreParenNoopCasts` take a const reference to the 
`ASTContext` for const correctness.

Update the comments to match what the `Expr::Ignore*` are actually doing. I am 
not sure that listing exactly what each `Expr::Ignore*` do is optimal, but it 
certainly looks better than the current state which is in my opinion between 
misleading and just plain wrong.


Repository:
  rC Clang

https://reviews.llvm.org/D57266

Files:
  include/clang/AST/Expr.h
  include/clang/AST/Stmt.h
  lib/ARCMigrate/TransRetainReleaseDealloc.cpp
  lib/ARCMigrate/TransformActions.cpp
  lib/ARCMigrate/Transforms.cpp
  lib/AST/Expr.cpp
  lib/AST/Stmt.cpp
  lib/Analysis/ReachableCode.cpp
  lib/Tooling/ASTDiff/ASTDiff.cpp

Index: lib/Tooling/ASTDiff/ASTDiff.cpp
===
--- lib/Tooling/ASTDiff/ASTDiff.cpp
+++ lib/Tooling/ASTDiff/ASTDiff.cpp
@@ -237,8 +237,8 @@
 return true;
   }
   bool TraverseStmt(Stmt *S) {
-if (S)
-  S = S->IgnoreImplicit();
+if (auto *E = dyn_cast_or_null(S))
+  S = E->IgnoreImplicit();
 if (isNodeExcluded(Tree.AST.getSourceManager(), S))
   return true;
 auto SavedState = PreTraverse(S);
Index: lib/Analysis/ReachableCode.cpp
===
--- lib/Analysis/ReachableCode.cpp
+++ lib/Analysis/ReachableCode.cpp
@@ -192,10 +192,12 @@
   if (!S)
 return false;
 
-  S = S->IgnoreImplicit();
+  if (const auto *Ex = dyn_cast(S))
+S = Ex->IgnoreImplicit();
 
-  if (const Expr *Ex = dyn_cast(S))
+  if (const auto *Ex = dyn_cast(S)) {
 S = Ex->IgnoreCasts();
+  }
 
   // Special case looking for the sigil '()' around an integer literal.
   if (const ParenExpr *PE = dyn_cast(S))
Index: lib/AST/Stmt.cpp
===
--- lib/AST/Stmt.cpp
+++ lib/AST/Stmt.cpp
@@ -117,30 +117,6 @@
   StatisticsEnabled = true;
 }
 
-Stmt *Stmt::IgnoreImplicit() {
-  Stmt *s = this;
-
-  Stmt *lasts = nullptr;
-
-  while (s != lasts) {
-lasts = s;
-
-if (auto *fe = dyn_cast(s))
-  s = fe->getSubExpr();
-
-if (auto *mte = dyn_cast(s))
-  s = mte->GetTemporaryExpr();
-
-if (auto *bte = dyn_cast(s))
-  s = bte->getSubExpr();
-
-if (auto *ice = dyn_cast(s))
-  s = ice->getSubExpr();
-  }
-
-  return s;
-}
-
 /// Skip no-op (attributed, compound) container stmts and skip captured
 /// stmt at the top, if \a IgnoreCaptured is true.
 Stmt *Stmt::IgnoreContainers(bool IgnoreCaptured) {
Index: lib/AST/Expr.cpp
===
--- lib/AST/Expr.cpp
+++ lib/AST/Expr.cpp
@@ -2556,6 +2556,39 @@
   return QualType();
 }
 
+Expr *Expr::IgnoreImpCasts() {
+  Expr *E = this;
+  while (true)
+if (ImplicitCastExpr *ICE = dyn_cast(E))
+  E = ICE->getSubExpr();
+else if (FullExpr *FE = dyn_cast(E))
+  E = FE->getSubExpr();
+else
+  break;
+  return E;
+}
+
+Expr *Expr::IgnoreImplicit() {
+  Expr *E = this;
+  Expr *LastE = nullptr;
+  while (E != LastE) {
+LastE = E;
+
+if (auto *ICE = dyn_cast(E))
+  E = ICE->getSubExpr();
+
+if (auto *FE = dyn_cast(E))
+  E = FE->getSubExpr();
+
+if (auto *MTE = dyn_cast(E))
+  E = MTE->GetTemporaryExpr();
+
+if (auto *BTE = dyn_cast(E))
+  E = BTE->getSubExpr();
+  }
+  return E;
+}
+
 Expr* Expr::IgnoreParens() {
   Expr* E = this;
   while (true) {
@@ -2722,7 +2755,7 @@
 /// IgnoreParenNoopCasts - Ignore parentheses and casts that do not change the
 /// value (including ptr->int casts of the same size).  Strip off any
 /// ParenExpr or CastExprs, returning their operand.
-Expr 

[PATCH] D57265: [PM/CC1] Add -f[no-]split-cold-code CC1 options to toggle splitting

2019-01-25 Thread Vedant Kumar via Phabricator via cfe-commits
vsk created this revision.
vsk added reviewers: chandlerc, t.p.northover, tejohnson, hiraditya.
Herald added a subscriber: mehdi_amini.

In order for the hot/cold splitting pass to graduate out of experimental
status, users need some way to safely enable it.

The current method of passing `-mllvm -hot-cold-split=true` to clang is
not safe, because directly setting a cl::opt cannot interact well with
other CC1 options (e.g. `-O0`, or `-disable-llvm-passes`).

This patch adds -f[no-]split-cold-code CC1 options to clang so that the
splitting pass can be toggled/combined with other options without issue.
This makes it possible to deploy the new pass on a large scale.

I've held off on adding a driver option because the ultimate goal is to
remove these options, and to simply have the pass enabled by default.


https://reviews.llvm.org/D57265

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/CC1Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/split-cold-code.c
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Transforms/IPO/PassManagerBuilder.cpp

Index: llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
===
--- llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
+++ llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
@@ -168,6 +168,7 @@
 VerifyInput = false;
 VerifyOutput = false;
 MergeFunctions = false;
+SplitColdCode = false;
 PrepareForLTO = false;
 EnablePGOInstrGen = false;
 PGOInstrGen = "";
@@ -519,7 +520,7 @@
 
   // Split out cold code before inlining. See comment in the new PM
   // (\ref buildModuleSimplificationPipeline).
-  if (EnableHotColdSplit && DefaultOrPreLinkPipeline)
+  if ((EnableHotColdSplit || SplitColdCode) && DefaultOrPreLinkPipeline)
 MPM.add(createHotColdSplittingPass());
 
   addInstructionCombiningPass(MPM); // Clean up after IPCP & DAE
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -663,7 +663,7 @@
   // not grow after inlining, and 2) inhibiting inlining of cold code improves
   // code size & compile time. Split after Mem2Reg to make code model estimates
   // more accurate, but before InstCombine to allow it to clean things up.
-  if (EnableHotColdSplit && Phase != ThinLTOPhase::PostLink)
+  if ((EnableHotColdSplit || SplitColdCode) && Phase != ThinLTOPhase::PostLink)
 MPM.addPass(HotColdSplittingPass());
 
   // Create a small function pass pipeline to cleanup after all the global
@@ -2079,3 +2079,7 @@
 
   return Error::success();
 }
+
+void PassBuilder::setEnableHotColdSplitting(bool Enabled) {
+  SplitColdCode = Enabled;
+}
Index: llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
===
--- llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
+++ llvm/include/llvm/Transforms/IPO/PassManagerBuilder.h
@@ -152,6 +152,7 @@
   bool VerifyInput;
   bool VerifyOutput;
   bool MergeFunctions;
+  bool SplitColdCode;
   bool PrepareForLTO;
   bool PrepareForThinLTO;
   bool PerformThinLTO;
Index: llvm/include/llvm/Passes/PassBuilder.h
===
--- llvm/include/llvm/Passes/PassBuilder.h
+++ llvm/include/llvm/Passes/PassBuilder.h
@@ -577,6 +577,10 @@
 TopLevelPipelineParsingCallbacks.push_back(C);
   }
 
+  /// Enable or disable the hot/cold splitting optimization. By default, it is
+  /// disabled.
+  void setEnableHotColdSplitting(bool Enabled);
+
 private:
   static Optional>
   parsePipelineText(StringRef Text);
@@ -664,6 +668,8 @@
   // AA callbacks
   SmallVector, 2>
   AAParsingCallbacks;
+  // Tunable passes
+  bool SplitColdCode = false;
 };
 
 /// This utility template takes care of adding require<> and invalidate<>
Index: clang/test/CodeGen/split-cold-code.c
===
--- /dev/null
+++ clang/test/CodeGen/split-cold-code.c
@@ -0,0 +1,81 @@
+// === Old PM ===
+// No splitting at -O0.
+// RUN: %clang_cc1 -O0 -fsplit-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// No splitting at -Oz.
+// RUN: %clang_cc1 -Oz -fsplit-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// No splitting by default, even at -O3.
+// RUN: %clang_cc1 -O3 -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | FileCheck --check-prefix=OLDPM-NO-SPLIT %s
+//
+// No splitting when it's explicitly disabled.
+// RUN: %clang_cc1 -O3 -fno-split-cold-code -mllvm -debug-pass=Structure \
+// RUN:   -emit-llvm -o /dev/null %s 2>&1 | 

[PATCH] D57075: [ObjC] For type substitution in generics use a regular recursive type visitor.

2019-01-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai planned changes to this revision.
vsapsai added inline comments.



Comment at: clang/lib/AST/Type.cpp:1295
+
+  QualType VisitObjCObjectType(const ObjCObjectType *objType) {
+if (!objType->isKindOfType())

vsapsai wrote:
> erik.pilkington wrote:
> > Does this works with type sugar? i.e. previously calling 
> > `Ty->getAs()` would have stripped through `TypedefType`, 
> > but its not obvious to me that this traversal is doing the right thing for 
> > that case.
> You are right, great catch. And I have a test case to confirm that.
> 
> I've started this refactoring to avoid copy-pasting
> 
> ```lang=c++
> QualType modifiedType = recurse(T->getModifiedType());
> if (modifiedType.isNull())
>   return {};
> 
> QualType equivalentType = recurse(T->getEquivalentType());
> if (equivalentType.isNull())
>   return {};
> 
> if (modifiedType.getAsOpaquePtr()
>   == T->getModifiedType().getAsOpaquePtr() &&
> equivalentType.getAsOpaquePtr()
>   == T->getEquivalentType().getAsOpaquePtr())
>   return QualType(T, 0);
> ```
> 
> and use `BaseType::VisitAttributedType(attrType)` instead. I think it is 
> possible to achieve the previous behaviour with the traditional recursive 
> visitor. But ideas that I have are pretty complicated and I don't think 
> that's the right trade-off.
The test case I've added isn't really testing regressions in this refactoring, 
it uncovers already broken functionality. After some investigation turns out 
there is no simple test case that would be passing before this change and 
failing afterwards. It is so because we were going past type sugar only in 
`stripObjCKindOfType` which is called from `sameObjCTypeArgs` to compare type 
args and type args are [canonicalized during 
construction](https://github.com/llvm/llvm-project/blob/e9cac31dac90aaf0829b7215778fce41edc946f5/clang/lib/AST/ASTContext.cpp#L4457-L4459),
 so there is no type sugar. We also have `stripObjCKindOfTypeAndQuals` which 
has different implementation.

My next step is to have a separate fix for `TypedefTypeParam`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57075/new/

https://reviews.llvm.org/D57075



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


[PATCH] D56945: [clang-tidy] Delete obsolete objc-property-declaration options ✂️

2019-01-25 Thread Stephane Moore via Phabricator via cfe-commits
stephanemoore marked an inline comment as done.
stephanemoore added inline comments.



Comment at: docs/ReleaseNotes.rst:248
 
+- The `Acronyms` and `IncludeDefaultAcronyms` options for the
+  :doc:`objc-property-declaration`

stephanemoore wrote:
> Eugene.Zelenko wrote:
> > Please rebase from trunk and use :option: prefix for options..
> Could using the :option: prefix cause issues if I am removing the option?
> 
> The documentation generation seems to emit a warning for an unknown option:
> "llvm/src/tools/clang/tools/extra/docs/ReleaseNotes.rst:76: WARNING: unknown 
> option: Acronyms"
> http://lab.llvm.org:8011/builders/clang-tools-sphinx-docs/builds/36425/steps/docs-clang-tools-html/logs/stdio
FYI:
I rolled this change back due to the documentation generation failure and sent 
out https://reviews.llvm.org/D57080 with amended changes.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56945/new/

https://reviews.llvm.org/D56945



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


[PATCH] D57207: [clang-tidy] Make google-objc-function-naming ignore implicit functions 

2019-01-25 Thread Stephane Moore via Phabricator via cfe-commits
stephanemoore marked 2 inline comments as done.
stephanemoore added inline comments.



Comment at: clang-tidy/google/FunctionNamingCheck.cpp:96-97
 
   // Match function declarations that are not in system headers and are not
   // main.
   Finder->addMatcher(

aaron.ballman wrote:
> This comment is drifting more and more out of sync with the code.
Good catch; updated the comment.



Comment at: test/clang-tidy/google-objc-function-naming.m:5-8
+static void TestImplicitlyDefinedFunction(int a) {
+  printf("%d", a);
+}
+

aaron.ballman wrote:
> Excuse my ignorance, but I don't see what about this function definition is 
> testing an implicitly-defined function. Doesn't the `#import` above bring in 
> the declaration for `printf()`, while `TestImplicitlyDefinedFunction()` 
> itself is explicitly defined?
**tl;dr**: Yes, we have an explicit function declaration but clang generates an 
implicit function declaration as well.

I found this surprising as well but the AST generated from this includes an 
implicit function declaration. Even though we have an explicit function 
declaration for `printf` from , clang still generates an implicit 
declaration of `printf` 廊 Similar behavior occurs with other functions, e.g., 
`memset` and various C11 atomic functions.

I have been spelunking in search of the reason but I do not have a full 
understanding yet. I believe I have insight into the underlying mechanism 
though: the behavior seems linked to builtin functions (e.g., `printf` is 
declared as a builtin function 
[here](https://github.com/llvm/llvm-project/blob/2946cd7/clang/include/clang/Basic/Builtins.def#L889)).
 I have attached a small sample program and an associated AST dump below to 
demonstrate the behavior.

❧

```
$ cat /tmp/test.c
extern int printf(const char *format, ...);

int main(int argc, const char **argv) {
  printf("%d", argc);
  return 0;
}
```

```
$ clang -cc1 -ast-dump /tmp/test.c 
TranslationUnitDecl 0x561b9f7fe570 <> 
|-TypedefDecl 0x561b9f7feac0 <>  implicit 
__int128_t '__int128'
| `-BuiltinType 0x561b9f7fe7e0 '__int128'
|-TypedefDecl 0x561b9f7feb28 <>  implicit 
__uint128_t 'unsigned __int128'
| `-BuiltinType 0x561b9f7fe800 'unsigned __int128'
|-TypedefDecl 0x561b9f7fedf8 <>  implicit 
__NSConstantString 'struct __NSConstantString_tag'
| `-RecordType 0x561b9f7fec00 'struct __NSConstantString_tag'
|   `-Record 0x561b9f7feb78 '__NSConstantString_tag'
|-TypedefDecl 0x561b9f7fee90 <>  implicit 
__builtin_ms_va_list 'char *'
| `-PointerType 0x561b9f7fee50 'char *'
|   `-BuiltinType 0x561b9f7fe600 'char'
|-TypedefDecl 0x561b9f7ff158 <>  implicit 
__builtin_va_list 'struct __va_list_tag [1]'
| `-ConstantArrayType 0x561b9f7ff100 'struct __va_list_tag [1]' 1 
|   `-RecordType 0x561b9f7fef70 'struct __va_list_tag'
| `-Record 0x561b9f7feee0 '__va_list_tag'
|-FunctionDecl 0x561b9f851860  col:12 implicit used printf 
'int (const char *, ...)' extern
| |-ParmVarDecl 0x561b9f8518f8 <>  'const char *'
| `-FormatAttr 0x561b9f851960  Implicit printf 1 2
|-FunctionDecl 0x561b9f8519b8 prev 0x561b9f851860  col:12 used 
printf 'int (const char *, ...)' extern
| |-ParmVarDecl 0x561b9f7ff1c0  col:31 format 'const char *'
| `-FormatAttr 0x561b9f851a90  Inherited printf 1 2
`-FunctionDecl 0x561b9f851c48  line:3:5 main 'int (int, 
const char **)'
  |-ParmVarDecl 0x561b9f851ac8  col:14 used argc 'int'
  |-ParmVarDecl 0x561b9f851b70  col:33 argv 'const char **'
  `-CompoundStmt 0x561b9f851f08 
|-CallExpr 0x561b9f851e50  'int'
| |-ImplicitCastExpr 0x561b9f851e38  'int (*)(const char *, ...)' 

| | `-DeclRefExpr 0x561b9f851d58  'int (const char *, ...)' Function 
0x561b9f8519b8 'printf' 'int (const char *, ...)'
| |-ImplicitCastExpr 0x561b9f851ea0  'const char *' 
| | `-ImplicitCastExpr 0x561b9f851e88  'char *' 

| |   `-StringLiteral 0x561b9f851db8  'char [3]' lvalue "%d"
| `-ImplicitCastExpr 0x561b9f851eb8  'int' 
|   `-DeclRefExpr 0x561b9f851de8  'int' lvalue ParmVar 
0x561b9f851ac8 'argc' 'int'
`-ReturnStmt 0x561b9f851ef0 
  `-IntegerLiteral 0x561b9f851ed0  'int' 0
```

Note the presence of implicit and explicit declarations of `printf` in the AST 
dump 樂


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57207/new/

https://reviews.llvm.org/D57207



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


[PATCH] D56928: Support attribute used in member funcs of class templates

2019-01-25 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

Thanks for looking into my almost 6 year old bug!




Comment at: 
test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp:1
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -O0 -o - %s \
+// RUN:  | FileCheck %s

Could you mention PR17480 in this test file as well?



Comment at: 
test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp:8
+  template  struct S {
+int USED f() {
+  return 0;

Any reason to use the preprocessor here instead of  `__attribute__` directly?



Comment at: 
test/CodeGenCXX/attr-used-member-function-implicit-instantiation.cpp:16
+// as a result of the S class template implicit instantiation
+// CHECK-DAG: define linkonce_odr i32 
@_ZN31InstantiateUsedMemberDefinition1SIiE1fEv
+S inst;

`CHECK:` instead of `CHECK-DAG` should be sufficient. 


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56928/new/

https://reviews.llvm.org/D56928



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


[PATCH] D57207: [clang-tidy] Make google-objc-function-naming ignore implicit functions 

2019-01-25 Thread Stephane Moore via Phabricator via cfe-commits
stephanemoore updated this revision to Diff 183646.
stephanemoore added a comment.

Updated the comment describing the matching behavior.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57207/new/

https://reviews.llvm.org/D57207

Files:
  clang-tidy/google/FunctionNamingCheck.cpp
  test/clang-tidy/google-objc-function-naming.m


Index: test/clang-tidy/google-objc-function-naming.m
===
--- test/clang-tidy/google-objc-function-naming.m
+++ test/clang-tidy/google-objc-function-naming.m
@@ -1,5 +1,11 @@
 // RUN: %check_clang_tidy %s google-objc-function-naming %t
 
+#import 
+
+static void TestImplicitlyDefinedFunction(int a) {
+  printf("%d", a);
+}
+
 typedef _Bool bool;
 
 static bool ispositive(int a) { return a > 0; }
Index: clang-tidy/google/FunctionNamingCheck.cpp
===
--- clang-tidy/google/FunctionNamingCheck.cpp
+++ clang-tidy/google/FunctionNamingCheck.cpp
@@ -93,12 +93,16 @@
   if (!getLangOpts().ObjC)
 return;
 
-  // Match function declarations that are not in system headers and are not
-  // main.
+  // Enforce Objective-C function naming conventions on all functions except:
+  // • Functions defined in system headers.
+  // • C++ member functions.
+  // • Namespaced functions.
+  // • Implicitly defined functions.
+  // • The main function.
   Finder->addMatcher(
   functionDecl(
   unless(anyOf(isExpansionInSystemHeader(), cxxMethodDecl(),
-   hasAncestor(namespaceDecl()), isMain(),
+   hasAncestor(namespaceDecl()), isMain(), isImplicit(),
matchesName(validFunctionNameRegex(true)),
allOf(isStaticStorageClass(),
  matchesName(validFunctionNameRegex(false))


Index: test/clang-tidy/google-objc-function-naming.m
===
--- test/clang-tidy/google-objc-function-naming.m
+++ test/clang-tidy/google-objc-function-naming.m
@@ -1,5 +1,11 @@
 // RUN: %check_clang_tidy %s google-objc-function-naming %t
 
+#import 
+
+static void TestImplicitlyDefinedFunction(int a) {
+  printf("%d", a);
+}
+
 typedef _Bool bool;
 
 static bool ispositive(int a) { return a > 0; }
Index: clang-tidy/google/FunctionNamingCheck.cpp
===
--- clang-tidy/google/FunctionNamingCheck.cpp
+++ clang-tidy/google/FunctionNamingCheck.cpp
@@ -93,12 +93,16 @@
   if (!getLangOpts().ObjC)
 return;
 
-  // Match function declarations that are not in system headers and are not
-  // main.
+  // Enforce Objective-C function naming conventions on all functions except:
+  // • Functions defined in system headers.
+  // • C++ member functions.
+  // • Namespaced functions.
+  // • Implicitly defined functions.
+  // • The main function.
   Finder->addMatcher(
   functionDecl(
   unless(anyOf(isExpansionInSystemHeader(), cxxMethodDecl(),
-   hasAncestor(namespaceDecl()), isMain(),
+   hasAncestor(namespaceDecl()), isMain(), isImplicit(),
matchesName(validFunctionNameRegex(true)),
allOf(isStaticStorageClass(),
  matchesName(validFunctionNameRegex(false))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57258: Attempt to fix build on Windows with LLVM_ENABLE_PIC=OFF

2019-01-25 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352253: Attempt to fix build on Windows with 
LLVM_ENABLE_PIC=OFF (authored by nico, committed by ).

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57258/new/

https://reviews.llvm.org/D57258

Files:
  tools/libclang/CMakeLists.txt


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -74,7 +74,7 @@
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if( LLVM_ENABLE_PIC )
+if(LLVM_ENABLE_PIC OR WIN32)
   set(ENABLE_SHARED SHARED)
 endif()
 


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -74,7 +74,7 @@
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if( LLVM_ENABLE_PIC )
+if(LLVM_ENABLE_PIC OR WIN32)
   set(ENABLE_SHARED SHARED)
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r352253 - Attempt to fix build on Windows with LLVM_ENABLE_PIC=OFF

2019-01-25 Thread Nico Weber via cfe-commits
Author: nico
Date: Fri Jan 25 15:37:57 2019
New Revision: 352253

URL: http://llvm.org/viewvc/llvm-project?rev=352253=rev
Log:
Attempt to fix build on Windows with LLVM_ENABLE_PIC=OFF

libclang can be built in shared or static mode. On Windows, with
LLVM_ENABLE_PIC=OFF, it was built in neither mode, leading to clients of
libclang (c-index-test, c-arcmt-test) failing to link with it set.

Since PIC isn't really a thing on Windows, build libclang in shared mode when
LLVM_ENABLE_PIC=OFF there. This is also somewhat symmetric with the existing
ENABLE_STATIC a few lines down.

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

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

Modified: cfe/trunk/tools/libclang/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CMakeLists.txt?rev=352253=352252=352253=diff
==
--- cfe/trunk/tools/libclang/CMakeLists.txt (original)
+++ cfe/trunk/tools/libclang/CMakeLists.txt Fri Jan 25 15:37:57 2019
@@ -74,7 +74,7 @@ if(MSVC)
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if( LLVM_ENABLE_PIC )
+if(LLVM_ENABLE_PIC OR WIN32)
   set(ENABLE_SHARED SHARED)
 endif()
 


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


[PATCH] D57232: [ASTImporter] Check visibility/linkage of functions and variables

2019-01-25 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: lib/AST/ASTImporter.cpp:2954
+return Found->hasExternalFormalLinkage();
+  else if (Importer.GetFromTU(Found) == From->getTranslationUnitDecl()) {
+if (From->isInAnonymousNamespace())

We don't really need an `else ` here and it would be more like an early exit 
which is what llvm style guide suggests.

In the same vein I would do:

if (Importer.GetFromTU(Found) != From->getTranslationUnitDecl())
   return false; 

so a second early exit and remove a level of nesting at the same time.



Comment at: unittests/AST/ASTImporterTest.cpp:65
 // -fms-compatibility or -fdelayed-template-parsing.
-struct ParameterizedTestsFixture : ::testing::TestWithParam {
+class CompilerOptionSpecificTest : public ::testing::Test {
+protected:

Are these changes directly related to the visibility change? There is a lot of 
noise that is not obviously related to the description in the PR.


If not maybe it should be a separate PR?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57232/new/

https://reviews.llvm.org/D57232



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


r352252 - Fixed frontend clang tests in windows read-only container

2019-01-25 Thread Stella Stamenova via cfe-commits
Author: stella.stamenova
Date: Fri Jan 25 15:03:12 2019
New Revision: 352252

URL: http://llvm.org/viewvc/llvm-project?rev=352252=rev
Log:
Fixed frontend clang tests in windows read-only container

Summary:
When mounting LLVM source into a windows container in read-only mode, certain 
tests fail. Ideally, we want all these tests to pass so that developers can 
mount the same source folder into multiple (windows) containers simultaneously, 
allowing them to build/test the same source code using various different 
configurations simultaneously.

**Fix**: I've found that when attempting to open a file for writing on windows, 
if you don't have the correct permissions (trying to open a file for writing in 
a read-only folder), you get [Access is 
denied](https://support.microsoft.com/en-us/help/2623670/access-denied-or-other-errors-when-you-access-or-work-with-files-and-f).
 In llvm, we map this error message to a linux based error, see: 
https://github.com/llvm-mirror/llvm/blob/master/lib/Support/ErrorHandling.cpp

This is why we see "Permission denied" in our output as opposed to the expected 
"No such file or directory", thus causing the tests to fail.

I've changed the test locally to instead point to the root drive so that they 
can successfully bypass the Access is denied error when LLVM is mounted in as a 
read-only directory. This way, the test operate exactly the same, but we can 
get around the windows-complications of what error to expect in a read-only 
directory.

Patch By: justice_adams

Reviewers: rsmith, zturner, MatzeB, stella.stamenova

Reviewed By: stella.stamenova

Subscribers: ormris, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/test/Frontend/output-failures.c
cfe/trunk/test/Frontend/stats-file.c

Modified: cfe/trunk/test/Frontend/output-failures.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/output-failures.c?rev=352252=352251=352252=diff
==
--- cfe/trunk/test/Frontend/output-failures.c (original)
+++ cfe/trunk/test/Frontend/output-failures.c Fri Jan 25 15:03:12 2019
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -emit-llvm -o %S/doesnotexist/somename %s 2> %t
+// RUN: not %clang_cc1 -emit-llvm -o %T/doesnotexist/somename %s 2> %t
 // RUN: FileCheck -check-prefix=OUTPUTFAIL -input-file=%t %s
 
-// OUTPUTFAIL: error: unable to open output file 
'{{.*}}{{[/\\]}}test{{[/\\]}}Frontend{{[/\\]}}doesnotexist{{[/\\]}}somename': 
'{{[nN]}}o such file or directory'
+// OUTPUTFAIL: error: unable to open output file 
'{{.*}}doesnotexist{{.}}somename': '{{[nN]}}o such file or directory'

Modified: cfe/trunk/test/Frontend/stats-file.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/stats-file.c?rev=352252=352251=352252=diff
==
--- cfe/trunk/test/Frontend/stats-file.c (original)
+++ cfe/trunk/test/Frontend/stats-file.c Fri Jan 25 15:03:12 2019
@@ -4,5 +4,5 @@
 //  ... here come some json values ...
 // CHECK: }
 
-// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%S/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%T/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
 // OUTPUTFAIL: warning: unable to open statistics output file 
'{{.*}}doesnotexist{{.}}bla': '{{[Nn]}}o such file or directory'


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


[PATCH] D57219: [Fixed Point Arithmetic] Fixed Point Comparisons

2019-01-25 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 183629.
leonardchan marked 4 inline comments as done.

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57219/new/

https://reviews.llvm.org/D57219

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/Frontend/fixed_point_comparisons.c

Index: clang/test/Frontend/fixed_point_comparisons.c
===
--- /dev/null
+++ clang/test/Frontend/fixed_point_comparisons.c
@@ -0,0 +1,368 @@
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,SIGNED
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -fpadding-on-unsigned-fixed-point -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,UNSIGNED
+
+// Fixed point against other fixed point
+_Bool b_eq_true = 2.5hk == 2.5uhk;  // CHECK-DAG: @b_eq_true  = {{.*}}global i8 1, align 1
+_Bool b_eq_false = 2.5hk == 2.4uhk; // CHECK-DAG: @b_eq_false = {{.*}}global i8 0, align 1
+
+_Bool b_ne_true = 2.5hk != 2.4uhk;  // CHECK-DAG: @b_ne_true  = {{.*}}global i8 1, align 1
+_Bool b_ne_false = 2.5hk != 2.5uhk; // CHECK-DAG: @b_ne_false = {{.*}}global i8 0, align 1
+
+_Bool b_lt_true = 2.5hk < 2.75uhk; // CHECK-DAG: @b_lt_true  = {{.*}}global i8 1, align 1
+_Bool b_lt_false = 2.5hk < 2.5uhk; // CHECK-DAG: @b_lt_false = {{.*}}global i8 0, align 1
+
+_Bool b_le_true = 2.5hk <= 2.75uhk; // CHECK-DAG: @b_le_true  = {{.*}}global i8 1, align 1
+_Bool b_le_true2 = 2.5hk <= 2.5uhk; // CHECK-DAG: @b_le_true2 = {{.*}}global i8 1, align 1
+_Bool b_le_false = 2.5hk <= 2.4uhk; // CHECK-DAG: @b_le_false = {{.*}}global i8 0, align 1
+
+_Bool b_gt_true = 2.75hk > 2.5uhk;   // CHECK-DAG: @b_gt_true  = {{.*}}global i8 1, align 1
+_Bool b_gt_false = 2.75hk > 2.75uhk; // CHECK-DAG: @b_gt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ge_true = 2.75hk >= 2.5uhk;   // CHECK-DAG: @b_ge_true  = {{.*}}global i8 1, align 1
+_Bool b_ge_true2 = 2.75hk >= 2.75uhk; // CHECK-DAG: @b_ge_true2 = {{.*}}global i8 1, align 1
+_Bool b_ge_false = 2.5hk >= 2.75uhk;  // CHECK-DAG: @b_ge_false = {{.*}}global i8 0, align 1
+
+// Fixed point against int
+_Bool b_ieq_true = 2.0hk == 2;  // CHECK-DAG: @b_ieq_true  = {{.*}}global i8 1, align 1
+_Bool b_ieq_false = 2.0hk == 3; // CHECK-DAG: @b_ieq_false = {{.*}}global i8 0, align 1
+
+_Bool b_ine_true = 2.0hk != 3;  // CHECK-DAG: @b_ine_true  = {{.*}}global i8 1, align 1
+_Bool b_ine_false = 2.0hk != 2; // CHECK-DAG: @b_ine_false = {{.*}}global i8 0, align 1
+
+_Bool b_ilt_true = 2.0hk < 3;  // CHECK-DAG: @b_ilt_true  = {{.*}}global i8 1, align 1
+_Bool b_ilt_false = 2.0hk < 2; // CHECK-DAG: @b_ilt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ile_true = 2.0hk <= 3;  // CHECK-DAG: @b_ile_true  = {{.*}}global i8 1, align 1
+_Bool b_ile_true2 = 2.0hk <= 2; // CHECK-DAG: @b_ile_true2 = {{.*}}global i8 1, align 1
+_Bool b_ile_false = 2.0hk <= 1; // CHECK-DAG: @b_ile_false = {{.*}}global i8 0, align 1
+
+_Bool b_igt_true = 2.0hk > 1;  // CHECK-DAG: @b_igt_true  = {{.*}}global i8 1, align 1
+_Bool b_igt_false = 2.0hk > 2; // CHECK-DAG: @b_igt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ige_true = 2.0hk >= 1;  // CHECK-DAG: @b_ige_true  = {{.*}}global i8 1, align 1
+_Bool b_ige_true2 = 2.0hk >= 2; // CHECK-DAG: @b_ige_true2 = {{.*}}global i8 1, align 1
+_Bool b_ige_false = 2.0hk >= 3; // CHECK-DAG: @b_ige_false = {{.*}}global i8 0, align 1
+
+// Different signage
+// Since we can have different precisions, non powers of 2 fractions may have
+// different actual values when being compared.
+_Bool b_sne_true = 2.6hk != 2.6uhk;
+// SIGNED-DAG:   @b_sne_true = {{.*}}global i8 1, align 1
+// UNSIGNED-DAG: @b_sne_true = {{.*}}global i8 0, align 1
+
+_Bool b_seq_true = 2.0hk == 2u;  // CHECK-DAG: @b_seq_true  = {{.*}}global i8 1, align 1
+_Bool b_seq_true2 = 2.0uhk == 2; // CHECK-DAG: @b_seq_true2 = {{.*}}global i8 1, align 1
+
+void TestComparisons() {
+  short _Accum sa;
+  _Accum a;
+  unsigned short _Accum usa;
+  unsigned _Accum ua;
+
+  // Each of these should be a fixed point conversion followed by the actual
+  // comparison operation.
+  sa == a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+  // CHECK-NEXT: [[RESIZE_A:%[a-z0-9]+]] = sext i16 [[A]] to i32
+  // CHECK-NEXT: [[UPSCALE_A:%[a-z0-9]+]] = shl i32 [[RESIZE_A]], 8
+  // CHECK-NEXT: {{.*}} = icmp eq i32 [[UPSCALE_A]], [[A2]]
+
+  sa != a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+  // CHECK-NEXT: [[RESIZE_A:%[a-z0-9]+]] = sext i16 [[A]] to i32
+  // CHECK-NEXT: [[UPSCALE_A:%[a-z0-9]+]] = shl i32 [[RESIZE_A]], 8
+  // CHECK-NEXT: {{.*}} = icmp ne i32 [[UPSCALE_A]], [[A2]]
+
+  sa > a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+ 

[PATCH] D57219: [Fixed Point Arithmetic] Fixed Point Comparisons

2019-01-25 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:141
+ (RHSType->isFixedPointType() &&
+  LHSType->isFixedPointOrIntegerType());
+}

ebevhan wrote:
> Can't it just be `LHSType->isFixedPointType() || RHSType->isFixedPointType()`?
> 
> I don't think there are cases where one is a fixed-point type and the other 
> is not an integer or another fixed-point type, so if one is fixed-point then 
> you already know it's a fixed-point operation.
Ah you're right.



Comment at: clang/test/Frontend/fixed_point_comparisons.c:56
+
+void TestComparisons() {
+  short _Accum sa;

ebevhan wrote:
> Missing saturating and saturating/non-saturating comparisons. I'd like to see 
> the differences between unsigned padding and not there, if there are any.
I don't think there should be since we compare by converting to a common type 
that should fit both operands, but it does help to have tests that also confirm 
this. Added some saturation cases under `TestSaturationComparisons`.

As for padding, `TestSaturationComparisons` have cases comparing signed with 
unsigned types, and there are other cases in `TestComparisons` and 
`TestIntComparisons` that deal with unsigned comparisons. The way the lit tests 
are organized, lines marked with `CHECK` mean that those lines are produced for 
both the padding and no padding cases whereas `SIGNED` or `UNSIGNED` are 
produced exclusively for no padding and padding cases, respectively.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57219/new/

https://reviews.llvm.org/D57219



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


[PATCH] D50563: Fixed frontend clang tests in windows read-only container

2019-01-25 Thread Stella Stamenova via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352252: Fixed frontend clang tests in windows read-only 
container (authored by stella.stamenova, committed by ).

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D50563/new/

https://reviews.llvm.org/D50563

Files:
  test/Frontend/output-failures.c
  test/Frontend/stats-file.c


Index: test/Frontend/stats-file.c
===
--- test/Frontend/stats-file.c
+++ test/Frontend/stats-file.c
@@ -4,5 +4,5 @@
 //  ... here come some json values ...
 // CHECK: }
 
-// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%S/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%T/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
 // OUTPUTFAIL: warning: unable to open statistics output file 
'{{.*}}doesnotexist{{.}}bla': '{{[Nn]}}o such file or directory'
Index: test/Frontend/output-failures.c
===
--- test/Frontend/output-failures.c
+++ test/Frontend/output-failures.c
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -emit-llvm -o %S/doesnotexist/somename %s 2> %t
+// RUN: not %clang_cc1 -emit-llvm -o %T/doesnotexist/somename %s 2> %t
 // RUN: FileCheck -check-prefix=OUTPUTFAIL -input-file=%t %s
 
-// OUTPUTFAIL: error: unable to open output file 
'{{.*}}{{[/\\]}}test{{[/\\]}}Frontend{{[/\\]}}doesnotexist{{[/\\]}}somename': 
'{{[nN]}}o such file or directory'
+// OUTPUTFAIL: error: unable to open output file 
'{{.*}}doesnotexist{{.}}somename': '{{[nN]}}o such file or directory'


Index: test/Frontend/stats-file.c
===
--- test/Frontend/stats-file.c
+++ test/Frontend/stats-file.c
@@ -4,5 +4,5 @@
 //  ... here come some json values ...
 // CHECK: }
 
-// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%S/doesnotexist/bla %s 2>&1 | FileCheck -check-prefix=OUTPUTFAIL %s
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%T/doesnotexist/bla %s 2>&1 | FileCheck -check-prefix=OUTPUTFAIL %s
 // OUTPUTFAIL: warning: unable to open statistics output file '{{.*}}doesnotexist{{.}}bla': '{{[Nn]}}o such file or directory'
Index: test/Frontend/output-failures.c
===
--- test/Frontend/output-failures.c
+++ test/Frontend/output-failures.c
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -emit-llvm -o %S/doesnotexist/somename %s 2> %t
+// RUN: not %clang_cc1 -emit-llvm -o %T/doesnotexist/somename %s 2> %t
 // RUN: FileCheck -check-prefix=OUTPUTFAIL -input-file=%t %s
 
-// OUTPUTFAIL: error: unable to open output file '{{.*}}{{[/\\]}}test{{[/\\]}}Frontend{{[/\\]}}doesnotexist{{[/\\]}}somename': '{{[nN]}}o such file or directory'
+// OUTPUTFAIL: error: unable to open output file '{{.*}}doesnotexist{{.}}somename': '{{[nN]}}o such file or directory'
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32635: [libcxx] regex: fix backreferences in forward assertions

2019-01-25 Thread Josh Junon via Phabricator via cfe-commits
Qix- added a comment.

Ping @EricWF - few years but this is still an issue, rendering ECMAscript regex 
backreferences almost entirely broken in libcxx :/ Would be great to get a 
champion for it. OP has indicated on Github that they'd be happy to rebase.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D32635/new/

https://reviews.llvm.org/D32635



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


[PATCH] D56900: [Fixed Point Arithmetic] Fixed Point and Integer Conversions

2019-01-25 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan marked an inline comment as done.
leonardchan added inline comments.



Comment at: clang/test/Frontend/fixed_point_conversions.c:437
+  // DEFAULT-NEXT: [[RES:%[a-z0-9]+]] = trunc i39 [[SATMIN]] to i16
+  // DEFAULT-NEXT: store i16 [[RES]], i16* %sat_sa, align 2
+

ebevhan wrote:
> leonardchan wrote:
> > ebevhan wrote:
> > > Conversions like this are a bit odd. There shouldn't be a need to 
> > > upsize/upscale the container before the saturation, should there?
> > I see. You're saying that we can just check directly if the value exceeds 
> > 255 (or goes under -256) since the range of target values can always fit in 
> > the range of source values. Therefore we do not need to cast up since the 
> > only reason we would need to is if converting to a type with a greater 
> > source range.
> > 
> > In this case, we could technically have a special case for integers where I 
> > think we can perform the saturation checks without the initial sign 
> > extension. I think it might be simpler though if in 
> > `EmitFixedPointConversion`, we treat an integer as a 'zero-scale fixed 
> > point number'. I think the reason the upsizing occurs in the first place is 
> > so that we satisfy the first FX conversion rule of calculating the result 
> > with full precision of both operands.
> > I see. You're saying that we can just check directly if the value exceeds 
> > 255 (or goes under -256) since the range of target values can always fit in 
> > the range of source values. Therefore we do not need to cast up since the 
> > only reason we would need to is if converting to a type with a greater 
> > source range.
> 
> That's right. Though, for integer to fixed-point conversion, I don't think 
> you ever need to upcast first; either the integer is larger than or equal to 
> the integral part of the fixed-point type, in which case we can check the 
> magnitude in the type as is, or it's smaller, and we don't have to do any 
> saturation.
> 
> > I think it might be simpler though if in `EmitFixedPointConversion`, we 
> > treat an integer as a 'zero-scale fixed point number'.
> 
> Isn't this already the case? The semantics for an integer type are fetched as 
> a zero scale fixed-point type and used that way (except when the target is an 
> integer due to the rounding requirement).
> That's right. Though, for integer to fixed-point conversion, I don't think 
> you ever need to upcast first; either the integer is larger than or equal to 
> the integral part of the fixed-point type, in which case we can check the 
> magnitude in the type as is, or it's smaller, and we don't have to do any 
> saturation.

I see. I think this would be more of a matter then of when checking for 
saturation, we either should check against the source value after resizing and 
scaling (container), or the source by itself before resizing and scaling. 
Actually, I think that when comparing saturation against the source value, we 
could save an instruction since we can just generate a constant  to compare the 
source against instead of comparing against a potentially shifted value. I 
think this could work when converting from fixed point types as well.

With saturation conversion, (if the target scale >= src scale) currently we 
could generate up to 7 instructions:
- 1 resize + 1 shift on the result if target scale > src scale
- 1 cmp gt + 1 select for clamping to max
- 1 cmp lt + 1 select for clamping to min
- 1 resize if container width != target width

I think we don't need either the first or last resize if the constants that we 
check against are the respective max's/min's of the target type against the 
source. I think this deserves a patch on it's own though since it could change 
a bunch of tests that depend on `EmitFixedPointConversion`.

>Isn't this already the case? The semantics for an integer type are fetched as 
>a zero scale fixed-point type and used that way (except when the target is an 
>integer due to the rounding requirement).

What I meant by this was that we are already doing the right thing in that we 
calculate the result with the full precision of both operands.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56900/new/

https://reviews.llvm.org/D56900



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


[PATCH] D57106: [AST] Introduce GenericSelectionExpr::Association

2019-01-25 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno marked 3 inline comments as done.
riccibruno added inline comments.



Comment at: include/clang/AST/Expr.h:5084
+  /// storage of Stmt * and TypeSourceInfo * in GenericSelectionExpr.
+  template  class AssociationIteratorTy {
+friend class GenericSelectionExpr;

aaron.ballman wrote:
> riccibruno wrote:
> > dblaikie wrote:
> > > Worth using any of the iterator helpers LLVM has? (iterator_facade or the 
> > > like)
> > I did try to use `iteratore_facade` but for some reason I was getting 
> > strange overload resolution failures with it.
> > 
> > In the end it did not save much and so I just rewrote the boiler-plate 
> > (especially given that if we end up going with an input iterator there is 
> > not going to be much boiler-plate).
> Does using the `iterator_facade_base` help now that we're back to an input 
> iterator? It seems like that should be able to get rid of some of the 
> boilerplate.
I must be holding it wrong; for some reason the post-fix operator ++ is not 
getting found when I use `iterator_facade_base`. It also forces me to define 
`operator==` as a member instead of a non-member function. Do you mind terribly 
if I don't use it ? It only at best avoid me to write `operator!=` and 
`operator++(int)`.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57106/new/

https://reviews.llvm.org/D57106



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


[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-01-25 Thread Lingda Li via Phabricator via cfe-commits
lildmh updated this revision to Diff 183615.
lildmh added a comment.

Address review comments and rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6228,6 +6228,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
+
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp 

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-01-25 Thread Lingda Li via Phabricator via cfe-commits
lildmh marked 18 inline comments as done.
lildmh added a comment.

Hi Alexey,

Thanks a lot for the review! Tried to address all of your comments in the new 
diff.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



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


[libunwind] r352245 - [libunwind] Use placement new to avoid dependency C++ library

2019-01-25 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Fri Jan 25 13:39:46 2019
New Revision: 352245

URL: http://llvm.org/viewvc/llvm-project?rev=352245=rev
Log:
[libunwind] Use placement new to avoid dependency C++ library

The rest of libunwind already uses placement new, these are the only
places where non-placement new is being used introducing undesirable
C++ library dependency.

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

Modified:
libunwind/trunk/src/libunwind.cpp

Modified: libunwind/trunk/src/libunwind.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/libunwind.cpp?rev=352245=352244=352245=diff
==
--- libunwind/trunk/src/libunwind.cpp (original)
+++ libunwind/trunk/src/libunwind.cpp Fri Jan 25 13:39:46 2019
@@ -14,8 +14,6 @@
 #ifndef NDEBUG
 #include  // getenv
 #endif
-#include 
-#include 
 
 #include "libunwind_ext.h"
 #include "config.h"
@@ -122,12 +120,14 @@ static bool is64bit(task_t task) {
 _LIBUNWIND_EXPORT unw_addr_space_t unw_create_addr_space_for_task(task_t task) 
{
 #if __i386__
   if (is64bit(task)) {
-unw_addr_space_x86_64 *as = new unw_addr_space_x86_64(task);
+unw_addr_space_x86_64 *as = malloc(sizeof(unw_addr_space_x86_64));
+new (as) unw_addr_space_x86_64(task);
 as->taskPort = task;
 as->cpuType = CPU_TYPE_X86_64;
 //as->oas
   } else {
-unw_addr_space_i386 *as = new unw_addr_space_i386(task);
+unw_addr_space_i386 *as = malloc(sizeof(unw_addr_space_i386));
+new (as) unw_addr_space_i386(task);
 as->taskPort = task;
 as->cpuType = CPU_TYPE_I386;
 //as->oas
@@ -144,18 +144,21 @@ _LIBUNWIND_EXPORT void unw_destroy_addr_
 #if __i386__ || __x86_64__
   case CPU_TYPE_I386: {
 unw_addr_space_i386 *as = (unw_addr_space_i386 *)asp;
-delete as;
+as->~unw_addr_space_i386();
+free(as);
   }
   break;
   case CPU_TYPE_X86_64: {
 unw_addr_space_x86_64 *as = (unw_addr_space_x86_64 *)asp;
-delete as;
+as->~unw_addr_space_x86_64();
+free(as);
   }
   break;
 #endif
   case CPU_TYPE_POWERPC: {
 unw_addr_space_ppc *as = (unw_addr_space_ppc *)asp;
-delete as;
+as->~unw_addr_space_ppc();
+free(as);
   }
   break;
   }


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


[PATCH] D57258: Attempt to fix build on Windows with LLVM_ENABLE_PIC=OFF

2019-01-25 Thread Nico Weber via Phabricator via cfe-commits
thakis created this revision.
thakis added a reviewer: rnk.
Herald added a subscriber: mgorny.

libclang can be built in shared or static mode. On Windows, with 
LLVM_ENABLE_PIC=OFF, it was built in neither mode, leading to clients of 
libclang (c-index-test, c-arcmt-test) failing to link with it set.

Since PIC isn't really a thing on Windows, build libclang in shared mode when 
LLVM_ENABLE_PIC=OFF on Windows. This is also somewhat symmetric with the 
existing ENABLE_STATIC a few lines down.


https://reviews.llvm.org/D57258

Files:
  tools/libclang/CMakeLists.txt


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -74,7 +74,7 @@
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if( LLVM_ENABLE_PIC )
+if(LLVM_ENABLE_PIC OR WIN32)
   set(ENABLE_SHARED SHARED)
 endif()
 


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -74,7 +74,7 @@
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if( LLVM_ENABLE_PIC )
+if(LLVM_ENABLE_PIC OR WIN32)
   set(ENABLE_SHARED SHARED)
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57064: [Sema] Improve a -Warray-bounds diagnostic

2019-01-25 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL352239: [Sema] Improve a -Warray-bounds diagnostic (authored 
by epilk, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57064?vs=182960=183604#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57064/new/

https://reviews.llvm.org/D57064

Files:
  cfe/trunk/include/clang/AST/ASTContext.h
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/Sema/SemaExpr.cpp
  cfe/trunk/test/Sema/static-array.c

Index: cfe/trunk/include/clang/AST/ASTContext.h
===
--- cfe/trunk/include/clang/AST/ASTContext.h
+++ cfe/trunk/include/clang/AST/ASTContext.h
@@ -2088,6 +2088,16 @@
   CharUnits getTypeSizeInChars(QualType T) const;
   CharUnits getTypeSizeInChars(const Type *T) const;
 
+  Optional getTypeSizeInCharsIfKnown(QualType Ty) const {
+if (Ty->isIncompleteType() || Ty->isDependentType())
+  return None;
+return getTypeSizeInChars(Ty);
+  }
+
+  Optional getTypeSizeInCharsIfKnown(const Type *Ty) const {
+return getTypeSizeInCharsIfKnown(QualType(Ty, 0));
+  }
+
   /// Return the ABI-specified alignment of a (complete) type \p T, in
   /// bits.
   unsigned getTypeAlign(QualType T) const { return getTypeInfo(T).Align; }
Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7841,7 +7841,8 @@
   "cannot mix positional and non-positional arguments in format string">,
   InGroup;
 def warn_static_array_too_small : Warning<
-  "array argument is too small; contains %0 elements, callee requires at least %1">,
+  "array argument is too small; %select{contains %0 elements|is of size %0}2,"
+  " callee requires at least %1">,
   InGroup;
 def note_callee_static_array : Note<
   "callee declares array parameter as static here">;
Index: cfe/trunk/test/Sema/static-array.c
===
--- cfe/trunk/test/Sema/static-array.c
+++ cfe/trunk/test/Sema/static-array.c
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 -fsyntax-only -fblocks -verify %s
 
 void cat0(int a[static 0]) {} // expected-warning {{'static' has no effect on zero-length arrays}}
 
-void cat(int a[static 3]) {} // expected-note 2 {{callee declares array parameter as static here}}
+void cat(int a[static 3]) {} // expected-note 4 {{callee declares array parameter as static here}} expected-note 2 {{passing argument to parameter 'a' here}}
 
 void vat(int i, int a[static i]) {} // expected-note {{callee declares array parameter as static here}}
 
@@ -19,6 +19,14 @@
 
   vat(1, 0); // expected-warning {{null passed to a callee that requires a non-null argument}}
   vat(3, b);
+
+  char d[4];
+  cat((int *)d); // expected-warning {{array argument is too small; is of size 4, callee requires at least 12}}
+  cat(d); // expected-warning {{array argument is too small; is of size 4, callee requires at least 12}} expected-warning {{incompatible pointer types}}
+
+  char e[12];
+  cat((int *)e);
+  cat(e); // expected-warning {{incompatible pointer types}}
 }
 
 
Index: cfe/trunk/lib/Sema/SemaExpr.cpp
===
--- cfe/trunk/lib/Sema/SemaExpr.cpp
+++ cfe/trunk/lib/Sema/SemaExpr.cpp
@@ -5228,15 +5228,29 @@
 return;
 
   const ConstantArrayType *ArgCAT =
-Context.getAsConstantArrayType(ArgExpr->IgnoreParenImpCasts()->getType());
+Context.getAsConstantArrayType(ArgExpr->IgnoreParenCasts()->getType());
   if (!ArgCAT)
 return;
 
-  if (ArgCAT->getSize().ult(CAT->getSize())) {
+  if (getASTContext().hasSameUnqualifiedType(CAT->getElementType(),
+ ArgCAT->getElementType())) {
+if (ArgCAT->getSize().ult(CAT->getSize())) {
+  Diag(CallLoc, diag::warn_static_array_too_small)
+  << ArgExpr->getSourceRange()
+  << (unsigned)ArgCAT->getSize().getZExtValue()
+  << (unsigned)CAT->getSize().getZExtValue() << 0;
+  DiagnoseCalleeStaticArrayParam(*this, Param);
+}
+return;
+  }
+
+  Optional ArgSize =
+  getASTContext().getTypeSizeInCharsIfKnown(ArgCAT);
+  Optional ParmSize = getASTContext().getTypeSizeInCharsIfKnown(CAT);
+  if (ArgSize && ParmSize && *ArgSize < *ParmSize) {
 Diag(CallLoc, diag::warn_static_array_too_small)
-  << ArgExpr->getSourceRange()
-  << (unsigned) ArgCAT->getSize().getZExtValue()
-  << (unsigned) CAT->getSize().getZExtValue();
+<< ArgExpr->getSourceRange() << (unsigned)ArgSize->getQuantity()
+<< (unsigned)ParmSize->getQuantity() << 1;
 DiagnoseCalleeStaticArrayParam(*this, Param);

r352239 - [Sema] Improve a -Warray-bounds diagnostic

2019-01-25 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Fri Jan 25 12:52:45 2019
New Revision: 352239

URL: http://llvm.org/viewvc/llvm-project?rev=352239=rev
Log:
[Sema] Improve a -Warray-bounds diagnostic

Fix a bug where we would compare array sizes with incompatible
element types, and look through explicit casts.

rdar://44800168

Differential revision: https://reviews.llvm.org/D57064

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/Sema/static-array.c

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=352239=352238=352239=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jan 25 12:52:45 2019
@@ -2088,6 +2088,16 @@ public:
   CharUnits getTypeSizeInChars(QualType T) const;
   CharUnits getTypeSizeInChars(const Type *T) const;
 
+  Optional getTypeSizeInCharsIfKnown(QualType Ty) const {
+if (Ty->isIncompleteType() || Ty->isDependentType())
+  return None;
+return getTypeSizeInChars(Ty);
+  }
+
+  Optional getTypeSizeInCharsIfKnown(const Type *Ty) const {
+return getTypeSizeInCharsIfKnown(QualType(Ty, 0));
+  }
+
   /// Return the ABI-specified alignment of a (complete) type \p T, in
   /// bits.
   unsigned getTypeAlign(QualType T) const { return getTypeInfo(T).Align; }

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=352239=352238=352239=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jan 25 12:52:45 
2019
@@ -7841,7 +7841,8 @@ def warn_format_mix_positional_nonpositi
   "cannot mix positional and non-positional arguments in format string">,
   InGroup;
 def warn_static_array_too_small : Warning<
-  "array argument is too small; contains %0 elements, callee requires at least 
%1">,
+  "array argument is too small; %select{contains %0 elements|is of size %0}2,"
+  " callee requires at least %1">,
   InGroup;
 def note_callee_static_array : Note<
   "callee declares array parameter as static here">;

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=352239=352238=352239=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri Jan 25 12:52:45 2019
@@ -5228,15 +5228,29 @@ Sema::CheckStaticArrayArgument(SourceLoc
 return;
 
   const ConstantArrayType *ArgCAT =
-Context.getAsConstantArrayType(ArgExpr->IgnoreParenImpCasts()->getType());
+Context.getAsConstantArrayType(ArgExpr->IgnoreParenCasts()->getType());
   if (!ArgCAT)
 return;
 
-  if (ArgCAT->getSize().ult(CAT->getSize())) {
+  if (getASTContext().hasSameUnqualifiedType(CAT->getElementType(),
+ ArgCAT->getElementType())) {
+if (ArgCAT->getSize().ult(CAT->getSize())) {
+  Diag(CallLoc, diag::warn_static_array_too_small)
+  << ArgExpr->getSourceRange()
+  << (unsigned)ArgCAT->getSize().getZExtValue()
+  << (unsigned)CAT->getSize().getZExtValue() << 0;
+  DiagnoseCalleeStaticArrayParam(*this, Param);
+}
+return;
+  }
+
+  Optional ArgSize =
+  getASTContext().getTypeSizeInCharsIfKnown(ArgCAT);
+  Optional ParmSize = 
getASTContext().getTypeSizeInCharsIfKnown(CAT);
+  if (ArgSize && ParmSize && *ArgSize < *ParmSize) {
 Diag(CallLoc, diag::warn_static_array_too_small)
-  << ArgExpr->getSourceRange()
-  << (unsigned) ArgCAT->getSize().getZExtValue()
-  << (unsigned) CAT->getSize().getZExtValue();
+<< ArgExpr->getSourceRange() << (unsigned)ArgSize->getQuantity()
+<< (unsigned)ParmSize->getQuantity() << 1;
 DiagnoseCalleeStaticArrayParam(*this, Param);
   }
 }

Modified: cfe/trunk/test/Sema/static-array.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/static-array.c?rev=352239=352238=352239=diff
==
--- cfe/trunk/test/Sema/static-array.c (original)
+++ cfe/trunk/test/Sema/static-array.c Fri Jan 25 12:52:45 2019
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -fsyntax-only -fblocks -verify %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 -fsyntax-only -fblocks 
-verify %s
 
 void cat0(int a[static 0]) {} // expected-warning {{'static' has no effect on 
zero-length arrays}}
 
-void cat(int a[static 3]) {} // expected-note 2 {{callee declares array 
parameter as static here}}
+void cat(int a[static 3]) {} // expected-note 4 {{callee declares array 
parameter as 

[PATCH] D57207: [clang-tidy] Make google-objc-function-naming ignore implicit functions 

2019-01-25 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang-tidy/google/FunctionNamingCheck.cpp:96-97
 
   // Match function declarations that are not in system headers and are not
   // main.
   Finder->addMatcher(

This comment is drifting more and more out of sync with the code.



Comment at: test/clang-tidy/google-objc-function-naming.m:5-8
+static void TestImplicitlyDefinedFunction(int a) {
+  printf("%d", a);
+}
+

Excuse my ignorance, but I don't see what about this function definition is 
testing an implicitly-defined function. Doesn't the `#import` above bring in 
the declaration for `printf()`, while `TestImplicitlyDefinedFunction()` itself 
is explicitly defined?


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57207/new/

https://reviews.llvm.org/D57207



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


[PATCH] D56851: [ASTMatchers] Adds `CXXMemberCallExpr` matcher `invokedAtType`.

2019-01-25 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3300
+///   matches `x.m()` and `p->m()`.
+AST_MATCHER_P_OVERLOAD(clang::CXXMemberCallExpr, invokedAtType,
+   clang::ast_matchers::internal::Matcher,

ymandel wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > ymandel wrote:
> > > > ymandel wrote:
> > > > > aaron.ballman wrote:
> > > > > > alexfh wrote:
> > > > > > > The name of the matcher doesn't tell me much. I had to carefully 
> > > > > > > read the documentation to understand what is it about. I don't 
> > > > > > > have a name that would raise no questions and wouldn't be too 
> > > > > > > verbose at the same time, but a bit of verbosity wouldn't hurt I 
> > > > > > > guess. How about `objectTypeAsWritten`?
> > > > > > Yeah, I think this would be a better name. Also, having some 
> > > > > > examples that demonstrate where this behavior differs from 
> > > > > > `thisPointerType` would be helpful.
> > > > > Agreed that it needs a new name, but I'm having trouble finding one 
> > > > > I'm satisfied with.  Here's the full description: "the type of the 
> > > > > written implicit object argument".  I base this phrasing on the class 
> > > > > CXXMemberCallExpr's terminology.  In `x.f(5)`, `x` is the implicit 
> > > > > object argument, whether or not it is also implicitly surrounded by a 
> > > > > cast.  That is, "implicit" has two different meanings in this context.
> > > > > 
> > > > > So, with that, how about `writtenObjectType`? It's close to 
> > > > > `objectTypeAsWritten` but I'm hoping it makes more clear that the 
> > > > > "written" part is the object not the type.
> > > > I've contrasted the behavior with thisPointerType in both of the 
> > > > examples. Do you think this helps or do you want something more 
> > > > explicit?
> > > Here's a totally different direction: `onOrPointsToType()`
> > > ```
> > > cxxMemberCallExpr(onOrPointsToType(hasDeclaration(cxxRecordDecl(hasName("Y")
> > > ```
> > > 
> > I think more explicit would be better. e.g.,
> > ```
> > cxxMemberCallExpr(invokedAtType(hasDeclaration(cxxRecordDecl(hasName("X")
> > matches 'x.m()' and 'p->m()'.
> > cxxMemberCallExpr(on(thisPointerType(hasDeclaration(cxxRecordDecl(hasName("X"))
> > matches nothing because the type of 'this' is 'Y' in both cases.
> > ```
> But, what about even simpler: onType? I think this parallels the intuition of 
> the name thisPointerType.  onType(T) should match x.f and x->f, where x is 
> type T.  
You've pointed out why I don't think `onType` works -- it doesn't match on type 
T -- it matches on type T, or a pointer/reference to type T, which is pretty 
different. Someone reading the matcher may expect an exact type match and 
insert a `pointerType()` or something there thinking they need to do that to 
match a call through a pointer.

@alexfh, opinions?



Comment at: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:473
 
+TEST(MatcherCXXMemberCallExpr, InvokedAtType) {
+  auto M = cxxMemberCallExpr(invokedAtType(cxxRecordDecl(hasName("Y";

The test name is using the old name for the matcher.



Comment at: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:474
+TEST(MatcherCXXMemberCallExpr, InvokedAtType) {
+  auto M = cxxMemberCallExpr(invokedAtType(cxxRecordDecl(hasName("Y";
+  EXPECT_TRUE(matches(

Same here as well.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56851/new/

https://reviews.llvm.org/D56851



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


[PATCH] D56424: [clang-tidy] Add check for underscores in googletest names.

2019-01-25 Thread Kar Epker via Phabricator via cfe-commits
karepker added a comment.

In D56424#1370908 , @hokein wrote:

> In D56424#1370461 , @karepker wrote:
>
> > Rebasing against master.
> >
> > Not sure if re-arc diffing this is necessary, but I hope it doesn't hurt.
>
>
> Didn't notice that you don't have commit access,  committed in rL352183 
>  (with a small change of the new license).


I just received commit access yesterday but hadn't quite figured out how to use 
it by the time your modified patch went in. Thanks for taking care of it.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56424/new/

https://reviews.llvm.org/D56424



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


[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-01-25 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: include/clang/AST/DeclBase.h:181
+/// This declaration is an OpenMP user defined mapper.
+IDNS_OMPMapper   = 0x2000
   };

Add comma after `0x2000` to exclude this line from the next pactches



Comment at: include/clang/AST/DeclOpenMP.h:220
+
+  // Clauses assoicated with this mapper declaration
+  MutableArrayRef Clauses;

Use `///` style of comments in class interface



Comment at: include/clang/AST/DeclOpenMP.h:224
+  // Mapper variable, which is 'v' in the example above
+  Expr *MapperVar = nullptr;
+

Better to call it `MapperVarRef`



Comment at: include/clang/AST/DeclOpenMP.h:279
+  clauselist_const_iterator clauselist_begin() const {
+return static_cast>(Clauses).begin();
+  }

Just `Clauses.begin()` does not work here?



Comment at: include/clang/AST/DeclOpenMP.h:282
+  clauselist_const_iterator clauselist_end() const {
+return static_cast>(Clauses).end();
+  }

Same here, the conversion looks ugly.



Comment at: lib/AST/ASTDumper.cpp:769
+  NodeDumper.dumpName(D);
+  for (auto *C : D->clauselists()) {
+dumpChild([=] {

`const auto *`



Comment at: lib/AST/ASTDumper.cpp:786
+OS << " ";
+  for (auto *S : C->children())
+dumpStmt(S);

`const auto *`



Comment at: lib/AST/DeclOpenMP.cpp:136
+ OMPDeclareMapperDecl *PrevDeclInScope) {
+  OMPDeclareMapperDecl *D = new (C, DC) OMPDeclareMapperDecl(
+  OMPDeclareMapper, DC, L, Name, T, VarName, PrevDeclInScope);

`auto *` or just `return new `



Comment at: lib/AST/DeclOpenMP.cpp:144
+   unsigned N) {
+  OMPDeclareMapperDecl *D = new (C, ID)
+  OMPDeclareMapperDecl(OMPDeclareMapper, /*DC=*/nullptr, SourceLocation(),

`auto *`



Comment at: lib/AST/DeclOpenMP.cpp:150
+OMPClause **ClauseStorage =
+(OMPClause **)C.Allocate(sizeof(OMPClause *) * N);
+D->Clauses = MutableArrayRef(ClauseStorage, N);

1. `auto **`
2. Use `C.Allocate(N)`



Comment at: lib/AST/DeclOpenMP.cpp:151
+(OMPClause **)C.Allocate(sizeof(OMPClause *) * N);
+D->Clauses = MutableArrayRef(ClauseStorage, N);
+  }

Use `makeMutableArrayRef(ClauseStorage, N)`



Comment at: lib/AST/DeclOpenMP.cpp:163
+  assert(Clauses.empty() && "Number of clauses should be 0 on initialization");
+  auto NumClauses = CL.size();
+  if (NumClauses) {

Do not use `auto` here



Comment at: lib/AST/DeclOpenMP.cpp:165
+  if (NumClauses) {
+OMPClause **ClauseStorage =
+(OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);

See previous comments for `ClauseStorage`



Comment at: lib/AST/DeclPrinter.cpp:1612
+  OMPClausePrinter Printer(Out, Policy);
+  for (auto I = D->clauselist_begin(), E = D->clauselist_end(); I != E;
+   ++I) {

Use range-based loop



Comment at: lib/Parse/ParseOpenMP.cpp:44
+  OMPD_target_teams_distribute_parallel,
+  OMPD_mapper
 };

Add comma after the new enum



Comment at: lib/Parse/ParseOpenMP.cpp:571
+  }
+  if (Clauses.size() == 0) {
+Diag(Tok, diag::err_omp_expected_clause)

`Clauses.empty()`



Comment at: lib/Sema/SemaOpenMP.cpp:13427
+TypeResult ParsedType) {
+  assert(ParsedType.isUsable());
+

Text message



Comment at: lib/Sema/SemaOpenMP.cpp:13430
+  QualType MapperType = GetTypeFromParser(ParsedType.get());
+  assert(!MapperType.isNull());
+

Add the text message for the assert


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



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


[PATCH] D57228: [clangd] Make USRs for macros to be position independent

2019-01-25 Thread Jan Korous via Phabricator via cfe-commits
jkorous accepted this revision.
jkorous added a comment.
This revision is now accepted and ready to land.

Thanks for fixing this Kadir!

LGTM


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57228/new/

https://reviews.llvm.org/D57228



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


[PATCH] D57112: [ASTTypeTraits] OMPClause handling

2019-01-25 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri marked an inline comment as done and an inline comment as not done.
lebedev.ri added inline comments.



Comment at: lib/AST/ASTTypeTraits.cpp:114
+#define OPENMP_CLAUSE(Name, Class) 
\
+case OMPC_##Name: return ASTNodeKind(NKI_##Class);
+#include "clang/Basic/OpenMPKinds.def"

ABataev wrote:
> ABataev wrote:
> > lebedev.ri wrote:
> > > ABataev wrote:
> > > > Well, I think it would be good to filter out `OMPC_flush` somehow 
> > > > because there is no such clause actually, it is a pseudo clause for 
> > > > better handling of the `flush` directive.
> > > > 
> > > Are `OMPC_threadprivate` and `OMPC_uniform` also in the same boat?
> > > I don't see those clauses in spec.
> > > 
> > > Perhaps `OMPC_flush` should be made more like those other two?
> > > (i.e. handled outside of `OPENMP_CLAUSE` macro)
> > `OMPC_threadprivate` is also a special kind of pseudo-clause.
> > `OMPC_flush` is in the enum, because it has the corresponding class. You 
> > can try to exclude it from the enum, but it may require some additional 
> > work.
> > `OMPC_uniform` is a normal clause, but it has the corresponding class. This 
> > clause can be used on `declare simd` directive, which is represented as an 
> > attribute.
> I mean, `OOMPC_uniform` has no(!) corresponding class. Mistyped
As one would expect, simply adding 
```
  case OMPC_flush: // Pseudo clause, does not exist (keep before including .def)
llvm_unreachable("unexpected OpenMP clause kind");
```
results in a
```
[58/1118 5.6/sec] Building CXX object 
tools/clang/lib/AST/CMakeFiles/clangAST.dir/ASTTypeTraits.cpp.o
FAILED: tools/clang/lib/AST/CMakeFiles/clangAST.dir/ASTTypeTraits.cpp.o 
/usr/bin/g++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/lib/AST -I/build/clang/lib/AST -I/build/clang/include 
-Itools/clang/include -I/usr/include/libxml2 -Iinclude -I/build/llvm/include 
-pipe -O2 -g0 -UNDEBUG -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type 
-Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -pipe -O2 
-g0 -UNDEBUG -fPIC   -UNDEBUG  -fno-exceptions -fno-rtti -MD -MT 
tools/clang/lib/AST/CMakeFiles/clangAST.dir/ASTTypeTraits.cpp.o -MF 
tools/clang/lib/AST/CMakeFiles/clangAST.dir/ASTTypeTraits.cpp.o.d -o 
tools/clang/lib/AST/CMakeFiles/clangAST.dir/ASTTypeTraits.cpp.o -c 
/build/clang/lib/AST/ASTTypeTraits.cpp
/build/clang/include/clang/Basic/OpenMPKinds.def: In static member function 
‘static clang::ast_type_traits::ASTNodeKind 
clang::ast_type_traits::ASTNodeKind::getFromNode(const clang::OMPClause&)’:
/build/clang/lib/AST/ASTTypeTraits.cpp:116:5: error: duplicate case value
 case OMPC_##Name: return ASTNodeKind(NKI_##Class);
 ^~~~
/build/clang/include/clang/Basic/OpenMPKinds.def:261:1: note: in expansion of 
macro ‘OPENMP_CLAUSE’
 OPENMP_CLAUSE(flush, OMPFlushClause)
 ^
/build/clang/lib/AST/ASTTypeTraits.cpp:113:3: note: previously used here
   case OMPC_flush: // Pseudo clause, does not exist (keep before including 
.def)
   ^~~~
```
So one will need to pull `OMPC_flush` out of `clang/Basic/OpenMPKinds.def`.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57112/new/

https://reviews.llvm.org/D57112



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


[PATCH] D56851: [ASTMatchers] Adds `CXXMemberCallExpr` matcher `invokedAtType`.

2019-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel marked 3 inline comments as done.
ymandel added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3300
+///   matches `x.m()` and `p->m()`.
+AST_MATCHER_P_OVERLOAD(clang::CXXMemberCallExpr, invokedAtType,
+   clang::ast_matchers::internal::Matcher,

aaron.ballman wrote:
> aaron.ballman wrote:
> > ymandel wrote:
> > > ymandel wrote:
> > > > aaron.ballman wrote:
> > > > > alexfh wrote:
> > > > > > The name of the matcher doesn't tell me much. I had to carefully 
> > > > > > read the documentation to understand what is it about. I don't have 
> > > > > > a name that would raise no questions and wouldn't be too verbose at 
> > > > > > the same time, but a bit of verbosity wouldn't hurt I guess. How 
> > > > > > about `objectTypeAsWritten`?
> > > > > Yeah, I think this would be a better name. Also, having some examples 
> > > > > that demonstrate where this behavior differs from `thisPointerType` 
> > > > > would be helpful.
> > > > Agreed that it needs a new name, but I'm having trouble finding one I'm 
> > > > satisfied with.  Here's the full description: "the type of the written 
> > > > implicit object argument".  I base this phrasing on the class 
> > > > CXXMemberCallExpr's terminology.  In `x.f(5)`, `x` is the implicit 
> > > > object argument, whether or not it is also implicitly surrounded by a 
> > > > cast.  That is, "implicit" has two different meanings in this context.
> > > > 
> > > > So, with that, how about `writtenObjectType`? It's close to 
> > > > `objectTypeAsWritten` but I'm hoping it makes more clear that the 
> > > > "written" part is the object not the type.
> > > I've contrasted the behavior with thisPointerType in both of the 
> > > examples. Do you think this helps or do you want something more explicit?
> > Here's a totally different direction: `onOrPointsToType()`
> > ```
> > cxxMemberCallExpr(onOrPointsToType(hasDeclaration(cxxRecordDecl(hasName("Y")
> > ```
> > 
> I think more explicit would be better. e.g.,
> ```
> cxxMemberCallExpr(invokedAtType(hasDeclaration(cxxRecordDecl(hasName("X")
> matches 'x.m()' and 'p->m()'.
> cxxMemberCallExpr(on(thisPointerType(hasDeclaration(cxxRecordDecl(hasName("X"))
> matches nothing because the type of 'this' is 'Y' in both cases.
> ```
But, what about even simpler: onType? I think this parallels the intuition of 
the name thisPointerType.  onType(T) should match x.f and x->f, where x is type 
T.  


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56851/new/

https://reviews.llvm.org/D56851



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


[PATCH] D56851: [ASTMatchers] Adds `CXXMemberCallExpr` matcher `invokedAtType`.

2019-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 183591.
ymandel added a comment.

Contrast to thisPointerType with explicit examples.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56851/new/

https://reviews.llvm.org/D56851

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -470,6 +470,35 @@
 
 }
 
+TEST(MatcherCXXMemberCallExpr, InvokedAtType) {
+  auto M = cxxMemberCallExpr(invokedAtType(cxxRecordDecl(hasName("Y";
+  EXPECT_TRUE(matches(
+  R"cc(
+struct Y {
+  void m();
+};
+void z(Y y) { y.m(); }
+  )cc",
+  M));
+  EXPECT_TRUE(matches(
+  R"cc(
+struct Y {
+  void m();
+};
+void z(Y *y) { y->m(); }
+  )cc",
+  M));
+  EXPECT_TRUE(notMatches(
+  R"cc(
+struct Y {
+  void m();
+};
+struct X : public Y {};
+void z(X x) { x.m(); }
+  )cc",
+  M));
+}
+
 TEST(ForEachArgumentWithParam, ReportsNoFalsePositives) {
   StatementMatcher ArgumentY =
 declRefExpr(to(varDecl(hasName("y".bind("arg");
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -3278,6 +3278,49 @@
   .matches(Node, Finder, Builder);
 }
 
+/// Matches if the type of the object expression (as written, without any
+/// implicit casts) either matches the InnerMatcher, or is a pointer to a
+/// type that matches the InnerMatcher. Differs from `thisPointerType` in that
+/// it matches against the type of the written object expression, which could be
+/// a subclass of the this-pointer type (like when the invoked member is
+/// inherited).
+///
+/// Given
+/// \code
+///   class Y { public: void m(); };
+///   class X : public Y {};
+///   void z() { Y y; y.m(); X x; x.m(); X *p; p->m(); }
+/// \endcode
+/// cxxMemberCallExpr(onOrPointsToType(hasDeclaration(
+/// cxxRecordDecl(hasName("Y")
+///   matches `y.m()`.
+/// cxxMemberCallExpr(thisPointerType(hasDeclaration(
+/// cxxRecordDecl(hasName("Y")
+///   matches `y.m()`, `x.m()` and `p->m()`.
+///
+/// cxxMemberCallExpr(onOrPointsToType(hasDeclaration(
+/// cxxRecordDecl(hasName("X")
+///   matches `x.m()` and `p->m()`.
+/// cxxMemberCallExpr(thisPointerType(hasDeclaration(
+/// cxxRecordDecl(hasName("X")
+///   matches nothing because the `this` type is `Y` in all three calls.
+AST_MATCHER_P_OVERLOAD(CXXMemberCallExpr, onOrPointsToType,
+   internal::Matcher, InnerMatcher, 0) {
+  return on(anyOf(hasType(InnerMatcher), hasType(pointsTo(InnerMatcher
+  .matches(Node, Finder, Builder);
+}
+
+/// Overloaded to match the type's declaration. With this overload, the above
+/// examples could be simplified to:
+///
+/// cxxMemberCallExpr(onOrPointsToType(cxxRecordDecl(hasName("Y"
+/// cxxMemberCallExpr(onOrPointsToType(cxxRecordDecl(hasName("X"
+AST_MATCHER_P_OVERLOAD(CXXMemberCallExpr, onOrPointsToType, DeclarationMatcher,
+   InnerMatcher, 1) {
+  return on(anyOf(hasType(InnerMatcher), hasType(pointsTo(InnerMatcher
+  .matches(Node, Finder, Builder);
+}
+
 /// Matches a DeclRefExpr that refers to a declaration that matches the
 /// specified matcher.
 ///
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -4224,6 +4224,11 @@
 
 
 
+Matcherclang::CXXMemberCallExprinvokedAtTypeclang::ast_matchers::DeclarationMatcher InnerMatcher
+Overloaded to match the type's declaration.
+
+
+
 Matcherinternal::Matcherhttps://clang.llvm.org/doxygen/classclang_1_1Decl.html;>DeclisInstantiated
 Matches declarations that are template instantiations or are inside
 template instantiations.
@@ -6956,6 +6961,27 @@
 
 
 
+Matcherclang::CXXMemberCallExprinvokedAtTypeclang::ast_matchers::Matcherclang::QualType InnerMatcher
+Matches if the type of the object expression (as written, without any
+implicit casts) either matches the InnerMatcher, or is a pointer to a
+type that matches the InnerMatcher. Differs from `thisPointerType` in that
+it matches against the type of the written object expression, which could be
+a subclass of the thisPointerType (like when the invoked member is
+inherited).
+
+Given
+  class Y { public: void m(); };
+  class X : public Y {};
+  void z() { Y y; y.m(); X x; x.m(); X *p; p-m(); }
+cxxMemberCallExpr(invokedAtType(hasDeclaration(
+cxxRecordDecl(hasName("Y")
+  

[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

@JonasToth @erichkeane thank you for taking care of this.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57249/new/

https://reviews.llvm.org/D57249



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


[PATCH] D56851: [ASTMatchers] Adds `CXXMemberCallExpr` matcher `invokedAtType`.

2019-01-25 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3300
+///   matches `x.m()` and `p->m()`.
+AST_MATCHER_P_OVERLOAD(clang::CXXMemberCallExpr, invokedAtType,
+   clang::ast_matchers::internal::Matcher,

ymandel wrote:
> ymandel wrote:
> > aaron.ballman wrote:
> > > alexfh wrote:
> > > > The name of the matcher doesn't tell me much. I had to carefully read 
> > > > the documentation to understand what is it about. I don't have a name 
> > > > that would raise no questions and wouldn't be too verbose at the same 
> > > > time, but a bit of verbosity wouldn't hurt I guess. How about 
> > > > `objectTypeAsWritten`?
> > > Yeah, I think this would be a better name. Also, having some examples 
> > > that demonstrate where this behavior differs from `thisPointerType` would 
> > > be helpful.
> > Agreed that it needs a new name, but I'm having trouble finding one I'm 
> > satisfied with.  Here's the full description: "the type of the written 
> > implicit object argument".  I base this phrasing on the class 
> > CXXMemberCallExpr's terminology.  In `x.f(5)`, `x` is the implicit object 
> > argument, whether or not it is also implicitly surrounded by a cast.  That 
> > is, "implicit" has two different meanings in this context.
> > 
> > So, with that, how about `writtenObjectType`? It's close to 
> > `objectTypeAsWritten` but I'm hoping it makes more clear that the "written" 
> > part is the object not the type.
> I've contrasted the behavior with thisPointerType in both of the examples. Do 
> you think this helps or do you want something more explicit?
Here's a totally different direction: `onOrPointsToType()`
```
cxxMemberCallExpr(onOrPointsToType(hasDeclaration(cxxRecordDecl(hasName("Y")
```




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3300
+///   matches `x.m()` and `p->m()`.
+AST_MATCHER_P_OVERLOAD(clang::CXXMemberCallExpr, invokedAtType,
+   clang::ast_matchers::internal::Matcher,

aaron.ballman wrote:
> ymandel wrote:
> > ymandel wrote:
> > > aaron.ballman wrote:
> > > > alexfh wrote:
> > > > > The name of the matcher doesn't tell me much. I had to carefully read 
> > > > > the documentation to understand what is it about. I don't have a name 
> > > > > that would raise no questions and wouldn't be too verbose at the same 
> > > > > time, but a bit of verbosity wouldn't hurt I guess. How about 
> > > > > `objectTypeAsWritten`?
> > > > Yeah, I think this would be a better name. Also, having some examples 
> > > > that demonstrate where this behavior differs from `thisPointerType` 
> > > > would be helpful.
> > > Agreed that it needs a new name, but I'm having trouble finding one I'm 
> > > satisfied with.  Here's the full description: "the type of the written 
> > > implicit object argument".  I base this phrasing on the class 
> > > CXXMemberCallExpr's terminology.  In `x.f(5)`, `x` is the implicit object 
> > > argument, whether or not it is also implicitly surrounded by a cast.  
> > > That is, "implicit" has two different meanings in this context.
> > > 
> > > So, with that, how about `writtenObjectType`? It's close to 
> > > `objectTypeAsWritten` but I'm hoping it makes more clear that the 
> > > "written" part is the object not the type.
> > I've contrasted the behavior with thisPointerType in both of the examples. 
> > Do you think this helps or do you want something more explicit?
> Here's a totally different direction: `onOrPointsToType()`
> ```
> cxxMemberCallExpr(onOrPointsToType(hasDeclaration(cxxRecordDecl(hasName("Y")
> ```
> 
I think more explicit would be better. e.g.,
```
cxxMemberCallExpr(invokedAtType(hasDeclaration(cxxRecordDecl(hasName("X")
matches 'x.m()' and 'p->m()'.
cxxMemberCallExpr(on(thisPointerType(hasDeclaration(cxxRecordDecl(hasName("X"))
matches nothing because the type of 'this' is 'Y' in both cases.
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56851/new/

https://reviews.llvm.org/D56851



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


r352232 - [CodeGen] Implement isTriviallyRecursive with StmtVisitor instead of RecursiveASTVisitor

2019-01-25 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Fri Jan 25 11:18:40 2019
New Revision: 352232

URL: http://llvm.org/viewvc/llvm-project?rev=352232=rev
Log:
[CodeGen] Implement isTriviallyRecursive with StmtVisitor instead of 
RecursiveASTVisitor

This code doesn't need to traverse types, lambdas, template arguments,
etc to detect trivial recursion. We can do a basic statement traversal
instead. This reduces the time spent compiling CodeGenModule.cpp, the
object file size (mostly reduced debug info), and the final executable
size by a small amount. I measured the exe mostly to check how much of
the overhead is from debug info, object file section headers, etc, vs
actual code.

metric   | before | after | diff
time (s) | 47.4   | 38.5  | -8.9
obj (kb) | 12888  | 12012 | -876
exe (kb) | 86072  | 85996 | -76

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=352232=352231=352232=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri Jan 25 11:18:40 2019
@@ -33,6 +33,7 @@
 #include "clang/AST/Mangle.h"
 #include "clang/AST/RecordLayout.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/StmtVisitor.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/CodeGenOptions.h"
@@ -2281,35 +2282,36 @@ static bool HasNonDllImportDtor(QualType
 }
 
 namespace {
-  struct FunctionIsDirectlyRecursive :
-public RecursiveASTVisitor {
+  struct FunctionIsDirectlyRecursive
+  : public ConstStmtVisitor {
 const StringRef Name;
 const Builtin::Context 
-bool Result;
-FunctionIsDirectlyRecursive(StringRef N, const Builtin::Context ) :
-  Name(N), BI(C), Result(false) {
-}
-typedef RecursiveASTVisitor Base;
+FunctionIsDirectlyRecursive(StringRef N, const Builtin::Context )
+: Name(N), BI(C) {}
 
-bool TraverseCallExpr(CallExpr *E) {
+bool VisitCallExpr(const CallExpr *E) {
   const FunctionDecl *FD = E->getDirectCallee();
   if (!FD)
-return true;
-  AsmLabelAttr *Attr = FD->getAttr();
-  if (Attr && Name == Attr->getLabel()) {
-Result = true;
 return false;
-  }
+  AsmLabelAttr *Attr = FD->getAttr();
+  if (Attr && Name == Attr->getLabel())
+return true;
   unsigned BuiltinID = FD->getBuiltinID();
   if (!BuiltinID || !BI.isLibFunction(BuiltinID))
-return true;
+return false;
   StringRef BuiltinName = BI.getName(BuiltinID);
   if (BuiltinName.startswith("__builtin_") &&
   Name == BuiltinName.slice(strlen("__builtin_"), StringRef::npos)) {
-Result = true;
-return false;
+return true;
   }
-  return true;
+  return false;
+}
+
+bool VisitStmt(const Stmt *S) {
+  for (const Stmt *Child : S->children())
+if (Child && this->Visit(Child))
+  return true;
+  return false;
 }
   };
 
@@ -2394,8 +2396,8 @@ CodeGenModule::isTriviallyRecursive(cons
   }
 
   FunctionIsDirectlyRecursive Walker(Name, Context.BuiltinInfo);
-  Walker.TraverseFunctionDecl(const_cast(FD));
-  return Walker.Result;
+  const Stmt *Body = FD->getBody();
+  return Body ? Walker.Visit(Body) : false;
 }
 
 bool CodeGenModule::shouldEmitFunction(GlobalDecl GD) {


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


[PATCH] D57185: [clang-tidy] Add the abseil-duration-addition check

2019-01-25 Thread Hyrum Wright via Phabricator via cfe-commits
hwright updated this revision to Diff 183583.
hwright marked an inline comment as done.
hwright added a comment.

Add another test


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57185/new/

https://reviews.llvm.org/D57185

Files:
  clang-tidy/abseil/AbseilTidyModule.cpp
  clang-tidy/abseil/CMakeLists.txt
  clang-tidy/abseil/DurationAdditionCheck.cpp
  clang-tidy/abseil/DurationAdditionCheck.h
  clang-tidy/abseil/DurationRewriter.cpp
  clang-tidy/abseil/DurationRewriter.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/abseil-duration-addition.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/Inputs/absl/time/time.h
  test/clang-tidy/abseil-duration-addition.cpp

Index: test/clang-tidy/abseil-duration-addition.cpp
===
--- /dev/null
+++ test/clang-tidy/abseil-duration-addition.cpp
@@ -0,0 +1,98 @@
+// RUN: %check_clang_tidy %s abseil-duration-addition %t -- -- -I%S/Inputs
+
+#include "absl/time/time.h"
+
+void f() {
+  absl::Time t;
+  int i;
+
+  i = absl::ToUnixHours(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixHours(t + absl::Hours(5))
+  i = absl::ToUnixMinutes(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMinutes(t + absl::Minutes(5))
+  i = absl::ToUnixSeconds(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(t + absl::Seconds(5))
+  i = absl::ToUnixMillis(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMillis(t + absl::Milliseconds(5))
+  i = absl::ToUnixMicros(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMicros(t + absl::Microseconds(5))
+  i = absl::ToUnixNanos(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixNanos(t + absl::Nanoseconds(5))
+
+  i = 3 + absl::ToUnixHours(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixHours(absl::Hours(3) + t)
+  i = 3 + absl::ToUnixMinutes(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMinutes(absl::Minutes(3) + t)
+  i = 3 + absl::ToUnixSeconds(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(absl::Seconds(3) + t)
+  i = 3 + absl::ToUnixMillis(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMillis(absl::Milliseconds(3) + t)
+  i = 3 + absl::ToUnixMicros(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMicros(absl::Microseconds(3) + t)
+  i = 3 + absl::ToUnixNanos(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixNanos(absl::Nanoseconds(3) + t)
+
+  // Undoing inverse conversions
+  i = absl::ToUnixMicros(t) + absl::ToInt64Microseconds(absl::Seconds(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMicros(t + absl::Seconds(1))
+
+  // Parens
+  i = 3 + (absl::ToUnixHours(t));
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixHours(absl::Hours(3) + t)
+
+  // Float folding
+  i = absl::ToUnixSeconds(t) + 5.0;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(t + absl::Seconds(5))
+
+  // We can rewrite the argument of the duration conversion
+#define THIRTY absl::FromUnixSeconds(30)
+  i = absl::ToUnixSeconds(THIRTY) + 1;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(THIRTY + absl::Seconds(1))
+#undef THIRTY
+
+  // Some other contexts
+  if (absl::ToUnixSeconds(t) + 1.0 > 10) {}
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(t + absl::Seconds(1))
+
+  // These should not match
+  i = 5 + 6;
+  i = absl::ToUnixSeconds(t) - 1.0;
+  i = absl::ToUnixSeconds(t) * 1.0;
+  i = 

[PATCH] D56851: [ASTMatchers] Adds `CXXMemberCallExpr` matcher `invokedAtType`.

2019-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel marked 3 inline comments as done.
ymandel added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3300
+///   matches `x.m()` and `p->m()`.
+AST_MATCHER_P_OVERLOAD(clang::CXXMemberCallExpr, invokedAtType,
+   clang::ast_matchers::internal::Matcher,

ymandel wrote:
> aaron.ballman wrote:
> > alexfh wrote:
> > > The name of the matcher doesn't tell me much. I had to carefully read the 
> > > documentation to understand what is it about. I don't have a name that 
> > > would raise no questions and wouldn't be too verbose at the same time, 
> > > but a bit of verbosity wouldn't hurt I guess. How about 
> > > `objectTypeAsWritten`?
> > Yeah, I think this would be a better name. Also, having some examples that 
> > demonstrate where this behavior differs from `thisPointerType` would be 
> > helpful.
> Agreed that it needs a new name, but I'm having trouble finding one I'm 
> satisfied with.  Here's the full description: "the type of the written 
> implicit object argument".  I base this phrasing on the class 
> CXXMemberCallExpr's terminology.  In `x.f(5)`, `x` is the implicit object 
> argument, whether or not it is also implicitly surrounded by a cast.  That 
> is, "implicit" has two different meanings in this context.
> 
> So, with that, how about `writtenObjectType`? It's close to 
> `objectTypeAsWritten` but I'm hoping it makes more clear that the "written" 
> part is the object not the type.
I've contrasted the behavior with thisPointerType in both of the examples. Do 
you think this helps or do you want something more explicit?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56851/new/

https://reviews.llvm.org/D56851



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


[PATCH] D56851: [ASTMatchers] Adds `CXXMemberCallExpr` matcher `invokedAtType`.

2019-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 183582.
ymandel added a comment.

Remove unneeded qualifiers and clarify constrast with `thisPointerType`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56851/new/

https://reviews.llvm.org/D56851

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -470,6 +470,35 @@
 
 }
 
+TEST(MatcherCXXMemberCallExpr, InvokedAtType) {
+  auto M = cxxMemberCallExpr(invokedAtType(cxxRecordDecl(hasName("Y";
+  EXPECT_TRUE(matches(
+  R"cc(
+struct Y {
+  void m();
+};
+void z(Y y) { y.m(); }
+  )cc",
+  M));
+  EXPECT_TRUE(matches(
+  R"cc(
+struct Y {
+  void m();
+};
+void z(Y *y) { y->m(); }
+  )cc",
+  M));
+  EXPECT_TRUE(notMatches(
+  R"cc(
+struct Y {
+  void m();
+};
+struct X : public Y {};
+void z(X x) { x.m(); }
+  )cc",
+  M));
+}
+
 TEST(ForEachArgumentWithParam, ReportsNoFalsePositives) {
   StatementMatcher ArgumentY =
 declRefExpr(to(varDecl(hasName("y".bind("arg");
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -3278,6 +3278,40 @@
   .matches(Node, Finder, Builder);
 }
 
+/// Matches if the type of the object expression (as written, without any
+/// implicit casts) either matches the InnerMatcher, or is a pointer to a
+/// type that matches the InnerMatcher. Differs from `thisPointerType` in that
+/// it matches against the type of the written object expression, which could be
+/// a subclass of the thisPointerType (like when the invoked member is
+/// inherited).
+///
+/// Given
+/// \code
+///   class Y { public: void m(); };
+///   class X : public Y {};
+///   void z() { Y y; y.m(); X x; x.m(); X *p; p->m(); }
+/// \endcode
+/// cxxMemberCallExpr(invokedAtType(hasDeclaration(
+/// cxxRecordDecl(hasName("Y")
+///   matches `y.m()` (while `thisPointerType` would match all three calls.)
+///
+/// cxxMemberCallExpr(invokedAtType(hasDeclaration(
+/// cxxRecordDecl(hasName("X")
+///   matches `x.m()` and `p->m()` (while `thisPointerType` would not match any
+///   of the calls, because `this`'s type is `Y` in those calls).
+AST_MATCHER_P_OVERLOAD(CXXMemberCallExpr, invokedAtType,
+   internal::Matcher, InnerMatcher, 0) {
+  return on(anyOf(hasType(InnerMatcher), hasType(pointsTo(InnerMatcher
+  .matches(Node, Finder, Builder);
+}
+
+/// Overloaded to match the type's declaration.
+AST_MATCHER_P_OVERLOAD(CXXMemberCallExpr, invokedAtType, DeclarationMatcher,
+   InnerMatcher, 1) {
+  return on(anyOf(hasType(InnerMatcher), hasType(pointsTo(InnerMatcher
+  .matches(Node, Finder, Builder);
+}
+
 /// Matches a DeclRefExpr that refers to a declaration that matches the
 /// specified matcher.
 ///
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -4224,6 +4224,11 @@
 
 
 
+Matcherclang::CXXMemberCallExprinvokedAtTypeclang::ast_matchers::DeclarationMatcher InnerMatcher
+Overloaded to match the type's declaration.
+
+
+
 Matcherinternal::Matcherhttps://clang.llvm.org/doxygen/classclang_1_1Decl.html;>DeclisInstantiated
 Matches declarations that are template instantiations or are inside
 template instantiations.
@@ -6956,6 +6961,27 @@
 
 
 
+Matcherclang::CXXMemberCallExprinvokedAtTypeclang::ast_matchers::Matcherclang::QualType InnerMatcher
+Matches if the type of the object expression (as written, without any
+implicit casts) either matches the InnerMatcher, or is a pointer to a
+type that matches the InnerMatcher. Differs from `thisPointerType` in that
+it matches against the type of the written object expression, which could be
+a subclass of the thisPointerType (like when the invoked member is
+inherited).
+
+Given
+  class Y { public: void m(); };
+  class X : public Y {};
+  void z() { Y y; y.m(); X x; x.m(); X *p; p-m(); }
+cxxMemberCallExpr(invokedAtType(hasDeclaration(
+cxxRecordDecl(hasName("Y")
+  matches `y.m()`.
+cxxMemberCallExpr(invokedAtType(hasDeclaration(
+cxxRecordDecl(hasName("X")
+  matches `x.m()` and `p-m()`.
+
+
+
 

[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Jonas Toth via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL352231: [clang-tidy] fix unit tests for dropped _Float16 
support in X86 (authored by JonasToth, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57249/new/

https://reviews.llvm.org/D57249

Files:
  
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
  
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
  
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp

Index: clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
@@ -3,8 +3,6 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
-
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {
@@ -95,21 +93,6 @@
   static constexpr auto v12 = 0xfp0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v12 == 0xfp0, "");
-
-  // _Float16
-
-  static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES-NEXT: ^~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v13 = 0xfp0F16;
-  static_assert(is_same::value, "");
-  static_assert(v13 == 0xfp0F16, "");
-
-  static constexpr auto v14 = 0xfp0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v14 == 0xfp0F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
@@ -0,0 +1,51 @@
+// RUN: %check_clang_tidy %s readability-uppercase-literal-suffix %t -- -- -target aarch64-linux-gnu -I %S
+
+#include "readability-uppercase-literal-suffix.h"
+
+void float16_normal_literals() {
+  // _Float16
+
+  static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
+  static_assert(is_same::value, "");
+  static_assert(v14 == 1.F16, "");
+
+  static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
+  static_assert(is_same::value, "");
+  static_assert(v15 == 1.F16, "");
+
+  static constexpr auto v16 = 1.F16; // OK.
+  static_assert(is_same::value, "");
+  static_assert(v16 == 1.F16, "");
+
+  static constexpr auto v17 = 1.e0F16; // OK.
+  static_assert(is_same::value, "");
+  static_assert(v17 == 1.F16, "");
+}
+
+void float16_hexadecimal_literals() {
+// _Float16
+
+  static constexpr auto v13 = 0xfp0f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v13 = 0xfp0f16;
+  // CHECK-MESSAGES-NEXT: ^~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v13 = 0xfp0F16;
+  static_assert(is_same::value, "");
+  static_assert(v13 == 0xfp0F16, "");
+
+  static constexpr auto v14 = 0xfp0F16; // OK.
+  static_assert(is_same::value, "");
+  static_assert(v14 == 0xfp0F16, "");
+
+}
Index: clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
@@ -3,8 +3,6 @@
 // RUN: clang-tidy %t.cpp 

[clang-tools-extra] r352231 - [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Jonas Toth via cfe-commits
Author: jonastoth
Date: Fri Jan 25 11:05:12 2019
New Revision: 352231

URL: http://llvm.org/viewvc/llvm-project?rev=352231=rev
Log:
[clang-tidy] fix unit tests for dropped _Float16 support in X86

Summary:
Because _Float16 was disabled for X86 targets the unit-tests started failing.
Extract the pieces for _Float16 and run theses tests under AArch64.

Reviewers: aaron.ballman, erichkeane, lebedev.ri

Reviewed By: erichkeane

Subscribers: javed.absar, xazax.hun, kristof.beyls, cfe-commits

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

Added:

clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
Modified:

clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp

clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp

Added: 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp?rev=352231=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
 (added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
 Fri Jan 25 11:05:12 2019
@@ -0,0 +1,51 @@
+// RUN: %check_clang_tidy %s readability-uppercase-literal-suffix %t -- -- 
-target aarch64-linux-gnu -I %S
+
+#include "readability-uppercase-literal-suffix.h"
+
+void float16_normal_literals() {
+  // _Float16
+
+  static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has 
suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
+  static_assert(is_same::value, "");
+  static_assert(v14 == 1.F16, "");
+
+  static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has 
suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
+  static_assert(is_same::value, "");
+  static_assert(v15 == 1.F16, "");
+
+  static constexpr auto v16 = 1.F16; // OK.
+  static_assert(is_same::value, "");
+  static_assert(v16 == 1.F16, "");
+
+  static constexpr auto v17 = 1.e0F16; // OK.
+  static_assert(is_same::value, "");
+  static_assert(v17 == 1.F16, "");
+}
+
+void float16_hexadecimal_literals() {
+// _Float16
+
+  static constexpr auto v13 = 0xfp0f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has 
suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v13 = 0xfp0f16;
+  // CHECK-MESSAGES-NEXT: ^~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v13 = 0xfp0F16;
+  static_assert(is_same::value, "");
+  static_assert(v13 == 0xfp0F16, "");
+
+  static constexpr auto v14 = 0xfp0F16; // OK.
+  static_assert(is_same::value, "");
+  static_assert(v14 == 0xfp0F16, "");
+
+}

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp?rev=352231=352230=352231=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
 Fri Jan 25 11:05:12 2019
@@ -3,8 +3,6 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' 
-fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' 
-warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target 
x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
-
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {
@@ -99,34 +97,6 @@ void floating_point_suffix() {
   static constexpr auto v13 = 1.e0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v13 == 1., "");
-
-  // _Float16
-
-  static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has 
suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
-  static_assert(is_same::value, "");
-  static_assert(v14 == 1.F16, "");
-
-  static constexpr 

[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth updated this revision to Diff 183580.
JonasToth marked an inline comment as done.
JonasToth added a comment.

- last nit, remove the disabled in hexadecimal


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57249/new/

https://reviews.llvm.org/D57249

Files:
  test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
  test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
  
test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp

Index: test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
@@ -3,8 +3,6 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
-
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {
@@ -95,21 +93,6 @@
   static constexpr auto v12 = 0xfp0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v12 == 0xfp0, "");
-
-  // _Float16
-
-  static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES-NEXT: ^~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v13 = 0xfp0F16;
-  static_assert(is_same::value, "");
-  static_assert(v13 == 0xfp0F16, "");
-
-  static constexpr auto v14 = 0xfp0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v14 == 0xfp0F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
@@ -3,8 +3,6 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
-
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {
@@ -99,34 +97,6 @@
   static constexpr auto v13 = 1.e0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v13 == 1., "");
-
-  // _Float16
-
-  static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
-  static_assert(is_same::value, "");
-  static_assert(v14 == 1.F16, "");
-
-  static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
-  static_assert(is_same::value, "");
-  static_assert(v15 == 1.F16, "");
-
-  static constexpr auto v16 = 1.F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v16 == 1.F16, "");
-
-  static constexpr auto v17 = 1.e0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v17 == 1.F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
@@ -0,0 +1,51 @@
+// RUN: %check_clang_tidy %s readability-uppercase-literal-suffix %t -- -- -target aarch64-linux-gnu -I %S
+
+#include "readability-uppercase-literal-suffix.h"
+
+void float16_normal_literals() {
+  // _Float16
+
+  static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
+  static_assert(is_same::value, "");
+  static_assert(v14 == 1.F16, "");
+
+  static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES: 

[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth updated this revision to Diff 183579.
JonasToth added a comment.

- Revert "add REQUIRES:  for the readability unit-tests where necessary" 
as its not necessary because only the frontend is run


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57249/new/

https://reviews.llvm.org/D57249

Files:
  test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
  test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
  
test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp

Index: test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
@@ -95,21 +95,6 @@
   static constexpr auto v12 = 0xfp0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v12 == 0xfp0, "");
-
-  // _Float16
-
-  static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES-NEXT: ^~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v13 = 0xfp0F16;
-  static_assert(is_same::value, "");
-  static_assert(v13 == 0xfp0F16, "");
-
-  static constexpr auto v14 = 0xfp0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v14 == 0xfp0F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
@@ -3,8 +3,6 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
-
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {
@@ -99,34 +97,6 @@
   static constexpr auto v13 = 1.e0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v13 == 1., "");
-
-  // _Float16
-
-  static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
-  static_assert(is_same::value, "");
-  static_assert(v14 == 1.F16, "");
-
-  static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
-  static_assert(is_same::value, "");
-  static_assert(v15 == 1.F16, "");
-
-  static constexpr auto v16 = 1.F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v16 == 1.F16, "");
-
-  static constexpr auto v17 = 1.e0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v17 == 1.F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
@@ -0,0 +1,51 @@
+// RUN: %check_clang_tidy %s readability-uppercase-literal-suffix %t -- -- -target aarch64-linux-gnu -I %S
+
+#include "readability-uppercase-literal-suffix.h"
+
+void float16_normal_literals() {
+  // _Float16
+
+  static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
+  static_assert(is_same::value, "");
+  static_assert(v14 == 1.F16, "");
+
+  static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
+  static_assert(is_same::value, "");
+  static_assert(v15 == 1.F16, "");
+
+  static constexpr auto v16 = 

[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth updated this revision to Diff 183578.
JonasToth added a comment.

- add REQUIRES:  for the readability unit-tests where necessary


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57249/new/

https://reviews.llvm.org/D57249

Files:
  test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
  
test/clang-tidy/readability-uppercase-literal-suffix-floating-point-opencl-half.cpp
  test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
  
test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
  test/clang-tidy/readability-uppercase-literal-suffix-integer-ms.cpp

Index: test/clang-tidy/readability-uppercase-literal-suffix-integer-ms.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-integer-ms.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-integer-ms.cpp
@@ -3,6 +3,8 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S -fms-extensions
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S -fms-extensions
 
+// REQUIRES: x86_64
+
 #include "readability-uppercase-literal-suffix.h"
 
 void integer_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
@@ -3,7 +3,7 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
+// REQUIRES: x86_64
 
 #include "readability-uppercase-literal-suffix.h"
 
@@ -95,21 +95,6 @@
   static constexpr auto v12 = 0xfp0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v12 == 0xfp0, "");
-
-  // _Float16
-
-  static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES-NEXT: ^~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v13 = 0xfp0F16;
-  static_assert(is_same::value, "");
-  static_assert(v13 == 0xfp0F16, "");
-
-  static constexpr auto v14 = 0xfp0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v14 == 0xfp0F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
@@ -3,7 +3,7 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
+// REQUIRES: x86_64
 
 #include "readability-uppercase-literal-suffix.h"
 
@@ -99,34 +99,6 @@
   static constexpr auto v13 = 1.e0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v13 == 1., "");
-
-  // _Float16
-
-  static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
-  static_assert(is_same::value, "");
-  static_assert(v14 == 1.F16, "");
-
-  static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
-  static_assert(is_same::value, "");
-  static_assert(v15 == 1.F16, "");
-
-  static constexpr auto v16 = 1.F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v16 == 1.F16, "");
-
-  static constexpr auto v17 = 1.e0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v17 == 1.F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-floating-point-opencl-half.cpp

[PATCH] D56851: [ASTMatchers] Adds `CXXMemberCallExpr` matcher `invokedAtType`.

2019-01-25 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel marked 2 inline comments as done.
ymandel added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3300
+///   matches `x.m()` and `p->m()`.
+AST_MATCHER_P_OVERLOAD(clang::CXXMemberCallExpr, invokedAtType,
+   clang::ast_matchers::internal::Matcher,

aaron.ballman wrote:
> alexfh wrote:
> > The name of the matcher doesn't tell me much. I had to carefully read the 
> > documentation to understand what is it about. I don't have a name that 
> > would raise no questions and wouldn't be too verbose at the same time, but 
> > a bit of verbosity wouldn't hurt I guess. How about `objectTypeAsWritten`?
> Yeah, I think this would be a better name. Also, having some examples that 
> demonstrate where this behavior differs from `thisPointerType` would be 
> helpful.
Agreed that it needs a new name, but I'm having trouble finding one I'm 
satisfied with.  Here's the full description: "the type of the written implicit 
object argument".  I base this phrasing on the class CXXMemberCallExpr's 
terminology.  In `x.f(5)`, `x` is the implicit object argument, whether or not 
it is also implicitly surrounded by a cast.  That is, "implicit" has two 
different meanings in this context.

So, with that, how about `writtenObjectType`? It's close to 
`objectTypeAsWritten` but I'm hoping it makes more clear that the "written" 
part is the object not the type.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56851/new/

https://reviews.llvm.org/D56851



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


[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added inline comments.



Comment at: test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp:2
+// RUN: %check_clang_tidy %s readability-uppercase-literal-suffix %t -- -- 
-target aarch64-linux-gnu -I %S
+
+#include "readability-uppercase-literal-suffix.h"

Targets can be disabled in cmake
This needs something like `// REQUIRES: aarch64`.
And yes, the tests that hardcoded x86 should require x86 too.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57249/new/

https://reviews.llvm.org/D57249



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


[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

LGTM, thanks for doing this!


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57249/new/

https://reviews.llvm.org/D57249



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


[PATCH] D57249: [clang-tidy] fix unit tests for dropped _Float16 support in X86

2019-01-25 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth created this revision.
JonasToth added reviewers: aaron.ballman, erichkeane, lebedev.ri.
Herald added subscribers: cfe-commits, kristof.beyls, xazax.hun, javed.absar.

Because _Float16 was disabled for X86 targets the unit-tests started failing.
Extract the pieces for _Float16 and run theses tests under AArch64.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D57249

Files:
  test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
  test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
  
test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp

Index: test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
@@ -95,21 +95,6 @@
   static constexpr auto v12 = 0xfp0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v12 == 0xfp0, "");
-
-  // _Float16
-
-  static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v13 = 0xfp0f16;
-  // CHECK-MESSAGES-NEXT: ^~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v13 = 0xfp0F16;
-  static_assert(is_same::value, "");
-  static_assert(v13 == 0xfp0F16, "");
-
-  static constexpr auto v14 = 0xfp0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v14 == 0xfp0F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
===
--- test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
+++ test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
@@ -3,8 +3,6 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' -warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target x86_64-pc-linux-gnu -I %S
 
-// REQUIRES: disabled
-
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {
@@ -99,34 +97,6 @@
   static constexpr auto v13 = 1.e0Q; // OK.
   static_assert(is_same::value, "");
   static_assert(v13 == 1., "");
-
-  // _Float16
-
-  static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
-  static_assert(is_same::value, "");
-  static_assert(v14 == 1.F16, "");
-
-  static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
-  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
-  // CHECK-MESSAGES-NEXT: ^ ~
-  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
-  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
-  static_assert(is_same::value, "");
-  static_assert(v15 == 1.F16, "");
-
-  static constexpr auto v16 = 1.F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v16 == 1.F16, "");
-
-  static constexpr auto v17 = 1.e0F16; // OK.
-  static_assert(is_same::value, "");
-  static_assert(v17 == 1.F16, "");
 }
 
 void floating_point_complex_suffix() {
Index: test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-uppercase-literal-suffix-float16.cpp
@@ -0,0 +1,51 @@
+// RUN: %check_clang_tidy %s readability-uppercase-literal-suffix %t -- -- -target aarch64-linux-gnu -I %S
+
+#include "readability-uppercase-literal-suffix.h"
+
+void float16_normal_literals() {
+  // _Float16
+
+  static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v14 = 1.f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v14 = 1.F16;
+  static_assert(is_same::value, "");
+  static_assert(v14 == 1.F16, "");
+
+  static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: floating point literal has suffix 'f16', which is not uppercase
+  // CHECK-MESSAGES-NEXT: static constexpr auto v15 = 1.e0f16;
+  // CHECK-MESSAGES-NEXT: ^ ~
+  // CHECK-MESSAGES-NEXT: {{^ *}}F16{{$}}
+  // CHECK-FIXES: static constexpr auto v15 = 1.e0F16;
+  static_assert(is_same::value, "");
+  

[PATCH] D57106: [AST] Introduce GenericSelectionExpr::Association

2019-01-25 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: include/clang/AST/Expr.h:5084
+  /// storage of Stmt * and TypeSourceInfo * in GenericSelectionExpr.
+  template  class AssociationIteratorTy {
+friend class GenericSelectionExpr;

riccibruno wrote:
> dblaikie wrote:
> > Worth using any of the iterator helpers LLVM has? (iterator_facade or the 
> > like)
> I did try to use `iteratore_facade` but for some reason I was getting strange 
> overload resolution failures with it.
> 
> In the end it did not save much and so I just rewrote the boiler-plate 
> (especially given that if we end up going with an input iterator there is not 
> going to be much boiler-plate).
Does using the `iterator_facade_base` help now that we're back to an input 
iterator? It seems like that should be able to get rid of some of the 
boilerplate.



Comment at: include/clang/AST/Expr.h:5100
+  public:
+// Note: This iterator could conceptually be a random access iterator.
+// However this iterator do not satisfy two requirements of forward

Note -> FIXME

iterator. -> iterator, and it would be nice if we could strengthen the iterator 
category someday.



Comment at: include/clang/AST/Expr.h:5101
+// Note: This iterator could conceptually be a random access iterator.
+// However this iterator do not satisfy two requirements of forward
+// iterators:

do not -> does not


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57106/new/

https://reviews.llvm.org/D57106



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


[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-01-25 Thread Lingda Li via Phabricator via cfe-commits
lildmh updated this revision to Diff 183570.
lildmh added a comment.

Change the type of mapper clause storage from OMPClause ** to 
MutableArrayRef, and rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6228,6 +6228,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
+
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal 

r352229 - Remove F16 literal support based on Float16 support.

2019-01-25 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Fri Jan 25 10:36:20 2019
New Revision: 352229

URL: http://llvm.org/viewvc/llvm-project?rev=352229=rev
Log:
Remove F16 literal support based on Float16 support.

Float16 support was disabled recently on many platforms, however that
commit still allowed literals of Float16 type to work.  This commit
removes those based on the same logic as Float16 disable.

Change-Id: I72243048ae2db3dc47bd3d699843e3edf9c395ea

Added:
cfe/trunk/test/SemaCXX/Float16.cpp   (with props)
Modified:
cfe/trunk/lib/Lex/LiteralSupport.cpp

Modified: cfe/trunk/lib/Lex/LiteralSupport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/LiteralSupport.cpp?rev=352229=352228=352229=diff
==
--- cfe/trunk/lib/Lex/LiteralSupport.cpp (original)
+++ cfe/trunk/lib/Lex/LiteralSupport.cpp Fri Jan 25 10:36:20 2019
@@ -616,10 +616,11 @@ NumericLiteralParser::NumericLiteralPars
   if (isHalf || isFloat || isLong || isFloat128)
 break; // HF, FF, LF, QF invalid.
 
-  if (s + 2 < ThisTokEnd && s[1] == '1' && s[2] == '6') {
-  s += 2; // success, eat up 2 characters.
-  isFloat16 = true;
-  continue;
+  if (PP.getTargetInfo().hasFloat16Type() && s + 2 < ThisTokEnd &&
+  s[1] == '1' && s[2] == '6') {
+s += 2; // success, eat up 2 characters.
+isFloat16 = true;
+continue;
   }
 
   isFloat = true;

Added: cfe/trunk/test/SemaCXX/Float16.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/Float16.cpp?rev=352229=auto
==
--- cfe/trunk/test/SemaCXX/Float16.cpp (added)
+++ cfe/trunk/test/SemaCXX/Float16.cpp Fri Jan 25 10:36:20 2019
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+
+#ifdef HAVE
+// expected-no-diagnostics
+#endif // HAVE
+
+#ifndef HAVE
+// expected-error@+2{{_Float16 is not supported on this target}}
+#endif // !HAVE
+_Float16 f;
+
+#ifndef HAVE
+// expected-error@+2{{invalid suffix 'F16' on floating constant}}
+#endif // !HAVE
+const auto g = 1.1F16;

Propchange: cfe/trunk/test/SemaCXX/Float16.cpp
--
svn:eol-style = native

Propchange: cfe/trunk/test/SemaCXX/Float16.cpp
--
svn:keywords = "Author Date Id Rev URL"

Propchange: cfe/trunk/test/SemaCXX/Float16.cpp
--
svn:mime-type = text/plain


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


[PATCH] D56998: [X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics.

2019-01-25 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon accepted this revision.
RKSimon added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56998/new/

https://reviews.llvm.org/D56998



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


[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

2019-01-25 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

In D57209#1370789 , @mstorsjo wrote:

> In D57209#1370608 , @rnk wrote:
>
> > and I don't think anyone has set up a continuous Windows ARM64 build with 
> > ToT clang anywhere in the world yet.
>
>
> Not sure if it qualifies as a proper continuous Windows ARM64 build, but I 
> build latest llvm+mingw-w64+compiler-rt+libcxx nightly and test build a bunch 
> of video-related projects including VLC on it (for all 4 current 
> architectures, i686/x86_64/armv7/aarch64), and run a bunch of tests of 
> projects built with that compiler in wine. But I'm pretty sure none of the 
> projects I test use these intrinsics.


Fair, my mistake, I should have qualified it with something along the lines of 
"... build that depends on these intrinsic changes ... yet".


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57209/new/

https://reviews.llvm.org/D57209



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


[PATCH] D57127: [analyzer] Port RetainSummaryManager to the new GenericCall interface, decouple ARCMT from the analyzer

2019-01-25 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.

> Also, isn't lib/Analysis a strange place for this? lib/Analysis is used by 
> the compiler proper (CodeGen, Sema, …), while RetainSummaryManager is only 
> used by tooling-like things (static analyzer, arcmigrate).

Not only, it has utilities used by the static analyzer which are too generic to 
be in the static analyzer itself - ProgramPoint.cpp, BodyFarm.cpp, 
CocoaConventions.cpp to name a few.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57127/new/

https://reviews.llvm.org/D57127



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


[PATCH] D57127: [analyzer] Port RetainSummaryManager to the new GenericCall interface, decouple ARCMT from the analyzer

2019-01-25 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.

> Can you elaborate a bit in what sense this decouples ARCMT from the analyzer?

ARCMT now does not need to link against the analyzer

> Can CLANG_ENABLE_STATIC_ANALYZER now be set independently of 
> CLANG_ENABLE_ARCMT?

Yes


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57127/new/

https://reviews.llvm.org/D57127



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


Re: r351740 - [AArch64] Use LL for 64-bit intrinsic arguments

2019-01-25 Thread Hans Wennborg via cfe-commits
I see this was reverted later, but please keep me posted on the
resolution as I think we might want to merge this to the 8.0 release
branch as well.

Thanks,
Hans

On Mon, Jan 21, 2019 at 3:01 AM Sam Parker via cfe-commits
 wrote:
>
> Author: sam_parker
> Date: Mon Jan 21 03:01:05 2019
> New Revision: 351740
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351740=rev
> Log:
> [AArch64] Use LL for 64-bit intrinsic arguments
>
> The ACLE states that 64-bit crc32, wsr, rsr and rbit operands are
> uint64_t so we should have the clang builtin match this description
> - which is what we already do for AArch32.
>
> Differential Revision: https://reviews.llvm.org/D56852
>
> Modified:
> cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> cfe/trunk/test/CodeGen/arm64-crc32.c
> cfe/trunk/test/CodeGen/builtins-arm64.c
>
> Modified: cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAArch64.def?rev=351740=351739=351740=diff
> ==
> --- cfe/trunk/include/clang/Basic/BuiltinsAArch64.def (original)
> +++ cfe/trunk/include/clang/Basic/BuiltinsAArch64.def Mon Jan 21 03:01:05 2019
> @@ -32,7 +32,7 @@ BUILTIN(__builtin_arm_clrex, "v", "")
>
>  // Bit manipulation
>  BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
> -BUILTIN(__builtin_arm_rbit64, "LUiLUi", "nc")
> +BUILTIN(__builtin_arm_rbit64, "LLUiLLUi", "nc")
>
>  // HINT
>  BUILTIN(__builtin_arm_nop, "v", "")
> @@ -49,8 +49,8 @@ BUILTIN(__builtin_arm_crc32h, "UiUiUs",
>  BUILTIN(__builtin_arm_crc32ch, "UiUiUs", "nc")
>  BUILTIN(__builtin_arm_crc32w, "UiUiUi", "nc")
>  BUILTIN(__builtin_arm_crc32cw, "UiUiUi", "nc")
> -BUILTIN(__builtin_arm_crc32d, "UiUiLUi", "nc")
> -BUILTIN(__builtin_arm_crc32cd, "UiUiLUi", "nc")
> +BUILTIN(__builtin_arm_crc32d, "UiUiLLUi", "nc")
> +BUILTIN(__builtin_arm_crc32cd, "UiUiLLUi", "nc")
>
>  // Memory barrier
>  BUILTIN(__builtin_arm_dmb, "vUi", "nc")
> @@ -62,10 +62,10 @@ BUILTIN(__builtin_arm_prefetch, "vvC*UiU
>
>  // System Registers
>  BUILTIN(__builtin_arm_rsr, "UicC*", "nc")
> -BUILTIN(__builtin_arm_rsr64, "LUicC*", "nc")
> +BUILTIN(__builtin_arm_rsr64, "LLUicC*", "nc")
>  BUILTIN(__builtin_arm_rsrp, "v*cC*", "nc")
>  BUILTIN(__builtin_arm_wsr, "vcC*Ui", "nc")
> -BUILTIN(__builtin_arm_wsr64, "vcC*LUi", "nc")
> +BUILTIN(__builtin_arm_wsr64, "vcC*LLUi", "nc")
>  BUILTIN(__builtin_arm_wsrp, "vcC*vC*", "nc")
>
>  // MSVC
>
> Modified: cfe/trunk/test/CodeGen/arm64-crc32.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm64-crc32.c?rev=351740=351739=351740=diff
> ==
> --- cfe/trunk/test/CodeGen/arm64-crc32.c (original)
> +++ cfe/trunk/test/CodeGen/arm64-crc32.c Mon Jan 21 03:01:05 2019
> @@ -1,54 +1,57 @@
>  // REQUIRES: aarch64-registered-target
>  // RUN: %clang_cc1 -triple arm64-none-linux-gnu \
>  // RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
> FileCheck %s
> +// RUN: %clang_cc1 -triple aarch64-windows \
> +// RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
> FileCheck %s
> +#include 
>
> -int crc32b(int a, char b)
> +uint32_t crc32b(uint32_t a, uint8_t b)
>  {
>  return __builtin_arm_crc32b(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32b(i32 %a, i32 [[T0]])
>  }
>
> -int crc32cb(int a, char b)
> +uint32_t crc32cb(uint32_t a, uint8_t b)
>  {
>  return __builtin_arm_crc32cb(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32cb(i32 %a, i32 [[T0]])
>  }
>
> -int crc32h(int a, short b)
> +uint32_t crc32h(uint32_t a, uint16_t b)
>  {
>  return __builtin_arm_crc32h(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32h(i32 %a, i32 [[T0]])
>  }
>
> -int crc32ch(int a, short b)
> +uint32_t crc32ch(uint32_t a, uint16_t b)
>  {
>  return __builtin_arm_crc32ch(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32ch(i32 %a, i32 [[T0]])
>  }
>
> -int crc32w(int a, int b)
> +uint32_t crc32w(uint32_t a, uint32_t b)
>  {
>  return __builtin_arm_crc32w(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32w(i32 %a, i32 %b)
>  }
>
> -int crc32cw(int a, int b)
> +uint32_t crc32cw(uint32_t a, uint32_t b)
>  {
>  return __builtin_arm_crc32cw(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32cw(i32 %a, i32 %b)
>  }
>
> -int crc32d(int a, long b)
> +uint32_t crc32d(uint32_t a, uint64_t b)
>  {
>  return __builtin_arm_crc32d(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32x(i32 %a, i64 %b)
>  }
>
> -int crc32cd(int a, long b)
> +uint32_t crc32cd(uint32_t a, uint64_t b)
>  {
>  return __builtin_arm_crc32cd(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32cx(i32 %a, i64 %b)
>
> Modified: cfe/trunk/test/CodeGen/builtins-arm64.c
> URL: 

Re: r352079 - [FileManager] Revert r347205 to avoid PCH file-descriptor leak.

2019-01-25 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r352225.

On Thu, Jan 24, 2019 at 10:55 AM Sam McCall via cfe-commits
 wrote:
>
> Author: sammccall
> Date: Thu Jan 24 10:55:24 2019
> New Revision: 352079
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352079=rev
> Log:
> [FileManager] Revert r347205 to avoid PCH file-descriptor leak.
>
> Summary:
> r347205 fixed a bug in FileManager: first calling
> getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
> the file not being open.
>
> Unfortunately, some code was (inadvertently?) relying on this bug: when
> building with a PCH, the file entries are obtained first by passing
> shouldOpen=false, and then later shouldOpen=true, without any intention
> of reading them. After r347205, they do get unneccesarily opened.
> Aside from extra operations, this means they need to be closed. Normally
> files are closed when their contents are read. As these files are never
> read, they stay open until clang exits. On platforms with a low
> open-files limit (e.g. Mac), this can lead to spurious file-not-found
> errors when building large projects with PCH enabled, e.g.
>   https://bugs.chromium.org/p/chromium/issues/detail?id=924225
>
> Fixing the callsites to pass shouldOpen=false when the file won't be
> read is not quite trivial (that info isn't available at the direct
> callsite), and passing shouldOpen=false is a performance regression (it
> results in open+fstat pairs being replaced by stat+open).
>
> So an ideal fix is going to be a little risky and we need some fix soon
> (especially for the llvm 8 branch).
> The problem addressed by r347205 is rare and has only been observed in
> clangd. It was present in llvm-7, so we can live with it for now.
>
> Reviewers: bkramer, thakis
>
> Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D57165
>
> Added:
> cfe/trunk/test/PCH/leakfiles
> Modified:
> cfe/trunk/include/clang/Basic/FileManager.h
> cfe/trunk/lib/Basic/FileManager.cpp
> cfe/trunk/unittests/Basic/FileManagerTest.cpp
>
> Modified: cfe/trunk/include/clang/Basic/FileManager.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=352079=352078=352079=diff
> ==
> --- cfe/trunk/include/clang/Basic/FileManager.h (original)
> +++ cfe/trunk/include/clang/Basic/FileManager.h Thu Jan 24 10:55:24 2019
> @@ -69,15 +69,14 @@ class FileEntry {
>bool IsNamedPipe;
>bool InPCH;
>bool IsValid;   // Is this \c FileEntry initialized and valid?
> -  bool DeferredOpen;  // Created by getFile(OpenFile=0); may open 
> later.
>
>/// The open file, if it is owned by the \p FileEntry.
>mutable std::unique_ptr File;
>
>  public:
>FileEntry()
> -  : UniqueID(0, 0), IsNamedPipe(false), InPCH(false), IsValid(false),
> -DeferredOpen(false) {}
> +  : UniqueID(0, 0), IsNamedPipe(false), InPCH(false), IsValid(false)
> +  {}
>
>FileEntry(const FileEntry &) = delete;
>FileEntry =(const FileEntry &) = delete;
>
> Modified: cfe/trunk/lib/Basic/FileManager.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileManager.cpp?rev=352079=352078=352079=diff
> ==
> --- cfe/trunk/lib/Basic/FileManager.cpp (original)
> +++ cfe/trunk/lib/Basic/FileManager.cpp Thu Jan 24 10:55:24 2019
> @@ -188,21 +188,15 @@ const FileEntry *FileManager::getFile(St
>*SeenFileEntries.insert(std::make_pair(Filename, nullptr)).first;
>
>// See if there is already an entry in the map.
> -  if (NamedFileEnt.second) {
> -if (NamedFileEnt.second == NON_EXISTENT_FILE)
> -  return nullptr;
> -// Entry exists: return it *unless* it wasn't opened and open is 
> requested.
> -if (!(NamedFileEnt.second->DeferredOpen && openFile))
> -  return NamedFileEnt.second;
> -// We previously stat()ed the file, but didn't open it: do that below.
> -// FIXME: the below does other redundant work too (stats the dir and 
> file).
> -  } else {
> -// By default, initialize it to invalid.
> -NamedFileEnt.second = NON_EXISTENT_FILE;
> -  }
> +  if (NamedFileEnt.second)
> +return NamedFileEnt.second == NON_EXISTENT_FILE ? nullptr
> +: NamedFileEnt.second;
>
>++NumFileCacheMisses;
>
> +  // By default, initialize it to invalid.
> +  NamedFileEnt.second = NON_EXISTENT_FILE;
> +
>// Get the null-terminated file name as stored as the key of the
>// SeenFileEntries map.
>StringRef InterndFileName = NamedFileEnt.first();
> @@ -240,7 +234,6 @@ const FileEntry *FileManager::getFile(St
>// It exists.  See if we have already opened a file with the same inode.
>// This occurs when one dir is symlinked to another, for example.
>FileEntry  = UniqueRealFiles[Data.UniqueID];
> -  UFE.DeferredOpen = !openFile;
>

Re: r352219 - Allow 'static' storage specifier on an out-of-line member function template

2019-01-25 Thread Roman Lebedev via cfe-commits
This review is invalid, since the lists weren't subscribed.

On Fri, Jan 25, 2019 at 8:01 PM Erich Keane via cfe-commits
 wrote:
>
> Author: erichkeane
> Date: Fri Jan 25 09:01:42 2019
> New Revision: 352219
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352219=rev
> Log:
> Allow 'static' storage specifier on an out-of-line member function template
> declaration in MSVCCompat mode
>
> Microsoft compiler permits the use of 'static' storage specifier outside
> of a class definition if it's on an out-of-line member function template
> declaration.
>
> This patch allows 'static' storage specifier on an out-of-line member
> function template declaration with a warning in Clang (To be compatible
> with Microsoft).
>
> Intel C/C++ compiler allows the 'static' keyword with a warning in
> Microsoft mode. GCC allows this with -fpermissive.
>
> Patch By: Manna
>
> Differential Revision: https://reviews.llvm.org/D56473
>
> Change-Id: I97b2d9e9d57cecbcd545d17e2523142a85ca2702
>
> Added:
> cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp   (with 
> props)
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/Sema/SemaDecl.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=352219=352218=352219=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jan 25 09:01:42 
> 2019
> @@ -1585,6 +1585,9 @@ def err_explicit_non_ctor_or_conv_functi
>  def err_static_not_bitfield : Error<"static member %0 cannot be a 
> bit-field">;
>  def err_static_out_of_line : Error<
>"'static' can only be specified inside the class definition">;
> +def ext_static_out_of_line : ExtWarn<
> +  err_static_out_of_line.Text>,
> +  InGroup;
>  def err_storage_class_for_static_member : Error<
>"static data member definition cannot specify a storage class">;
>  def err_typedef_not_bitfield : Error<"typedef member %0 cannot be a 
> bit-field">;
>
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=352219=352218=352219=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Jan 25 09:01:42 2019
> @@ -8625,8 +8625,12 @@ Sema::ActOnFunctionDeclarator(Scope *S,
>
>// Complain about the 'static' specifier if it's on an out-of-line
>// member function definition.
> +
> +  // MSVC permits the use of a 'static' storage specifier on an 
> out-of-line
> +  // member function template declaration, warn about this.
>Diag(D.getDeclSpec().getStorageClassSpecLoc(),
> -   diag::err_static_out_of_line)
> +   NewFD->getDescribedFunctionTemplate() && getLangOpts().MSVCCompat
> +   ? diag::ext_static_out_of_line : diag::err_static_out_of_line)
>  << 
> FixItHint::CreateRemoval(D.getDeclSpec().getStorageClassSpecLoc());
>  }
>
>
> Added: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp?rev=352219=auto
> ==
> --- cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp (added)
> +++ cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp Fri Jan 
> 25 09:01:42 2019
> @@ -0,0 +1,11 @@
> +// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
> +
> +struct C {
> +  template  static int foo(T);
> +};
> +
> +template  static int C::foo(T) {
> +  //expected-warning@-1 {{'static' can only be specified inside the class 
> definition}}
> +  return 0;
> +}
> +
>
> Propchange: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
> --
> svn:eol-style = native
>
> Propchange: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
> --
> svn:keywords = "Author Date Id Rev URL"
>
> Propchange: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
> --
> svn:mime-type = text/plain
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r352224 - Temporairly disable readability-uppercase-literal-suffix tests that depend on _Float16, to get bots back to green

2019-01-25 Thread Roman Lebedev via cfe-commits
Author: lebedevri
Date: Fri Jan 25 10:05:43 2019
New Revision: 352224

URL: http://llvm.org/viewvc/llvm-project?rev=352224=rev
Log:
Temporairly disable readability-uppercase-literal-suffix tests that depend on 
_Float16, to get bots back to green

Modified:

clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp

clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp?rev=352224=352223=352224=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-floating-point.cpp
 Fri Jan 25 10:05:43 2019
@@ -3,6 +3,8 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' 
-fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' 
-warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target 
x86_64-pc-linux-gnu -I %S
 
+// REQUIRES: disabled
+
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp?rev=352224=352223=352224=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-uppercase-literal-suffix-hexadecimal-floating-point.cpp
 Fri Jan 25 10:05:43 2019
@@ -3,6 +3,8 @@
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' 
-fix -- -target x86_64-pc-linux-gnu -I %S
 // RUN: clang-tidy %t.cpp -checks='-*,readability-uppercase-literal-suffix' 
-warnings-as-errors='-*,readability-uppercase-literal-suffix' -- -target 
x86_64-pc-linux-gnu -I %S
 
+// REQUIRES: disabled
+
 #include "readability-uppercase-literal-suffix.h"
 
 void floating_point_suffix() {


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


[PATCH] D57188: Disable _Float16 for non ARM/SPIR Targets

2019-01-25 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

"it" is the grammatically correct word.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57188/new/

https://reviews.llvm.org/D57188



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


[PATCH] D56998: [X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics.

2019-01-25 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

Ping


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56998/new/

https://reviews.llvm.org/D56998



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


[PATCH] D56581: [ASTImporter] Set the described template if not set

2019-01-25 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added a subscriber: aprantl.
shafik added a comment.

I don't believe it is directly related to modules but that it just triggers the 
issue because it may be bringing in more. You can find a description here 
https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-g and @aprantl 
pointed me to this talk if you want to even more 
http://llvm.org/devmtg/2015-10/#talk19


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56581/new/

https://reviews.llvm.org/D56581



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


r352222 - Fix incorrect indent from r352221

2019-01-25 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Fri Jan 25 09:39:57 2019
New Revision: 35

URL: http://llvm.org/viewvc/llvm-project?rev=35=rev
Log:
Fix incorrect indent from r352221

Change-Id: I0a7b1443eb6912ef7bea1a4cf2f696fc01726557

Modified:
cfe/trunk/docs/LanguageExtensions.rst

Modified: cfe/trunk/docs/LanguageExtensions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=35=352221=35=diff
==
--- cfe/trunk/docs/LanguageExtensions.rst (original)
+++ cfe/trunk/docs/LanguageExtensions.rst Fri Jan 25 09:39:57 2019
@@ -516,8 +516,8 @@ arithmetic conversions is ``float``.
 
 A literal can be given ``_Float16`` type using the suffix ``f16``; for example:
 ```
-  3.14f16
-  ```
+3.14f16
+```
 
 Because default argument promotion only applies to the standard floating-point
 types, ``_Float16`` values are not promoted to ``double`` when passed as 
variadic


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


[PATCH] D52839: Inform AST's UnaryOperator of FENV_ACCESS

2019-01-25 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn added a comment.

In D52839#1263794 , @rsmith wrote:

>




> 2. Track the FP environment somewhere more transient, probably on the `Scope` 
> object. When parsing an operator, store the environment on the expression, 
> and when performing a `TreeTransform`, inherit the state onto the new node.
> 
>   I think option 2 seems cleaner.

In D53157  it looks like an API where the 
IRBuilder has a constrained FP switch is preferred. This way calls to the 
IRBuilder can remain as one liners.

Going that route, would it make more sense to store the FP environment mode in 
some place like CompoundStmt so it gets set correctly when traversing the AST 
emitting IR? I'm not sure how TreeTransform would fit in here, though. The AST 
is supposed to be immutable once created, right? Can we set bits in a node 
after the node is created and before construction of the AST is completed?

Another wrinkle is that LLVM needs all FP in a function to be either 
constrained or non-constrained. This is to prevent code motion between the two 
modes. So clang would need to set the constrained mode someplace at function 
scope. I don't know the best place for that. And I'm not 100% sure that this 
requirement is set in stone yet. But where in the AST would be the proper place 
for that?

How does that change things?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52839/new/

https://reviews.llvm.org/D52839



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


[PATCH] D57188: Disable _Float16 for non ARM/SPIR Targets

2019-01-25 Thread Steve Canon via Phabricator via cfe-commits
scanon added a subscriber: ab.
scanon added a comment.

> do we want to support _Float16 anywhere else?

ARM is the only in-tree target with a defined ABI that I'm aware of.

> Do we need to lock down an ABI here for i386/x86_64 in advance of those gears 
> turning in the outer world?

We definitely want to push for one to be defined (and make sure that it makes 
sense), but I don't think we don't need to rush ahead of everyone, rather get 
to preliminary agreement. I think @ab was going to follow-up on that?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57188/new/

https://reviews.llvm.org/D57188



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


[PATCH] D57188: Disable _Float16 for non ARM/SPIR Targets

2019-01-25 Thread Erich Keane via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL352221: Disable _Float16 for non ARM/SPIR Targets (authored 
by erichkeane, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57188?vs=183536=183563#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57188/new/

https://reviews.llvm.org/D57188

Files:
  cfe/trunk/docs/LanguageExtensions.rst
  cfe/trunk/include/clang/Basic/TargetInfo.h
  cfe/trunk/lib/Basic/TargetInfo.cpp
  cfe/trunk/lib/Basic/Targets/AArch64.cpp
  cfe/trunk/lib/Basic/Targets/ARM.cpp
  cfe/trunk/lib/Basic/Targets/SPIR.h
  cfe/trunk/lib/Sema/SemaType.cpp
  cfe/trunk/test/AST/float16.cpp
  cfe/trunk/test/CodeGenCXX/float16-declarations.cpp
  cfe/trunk/test/CodeGenCXX/mangle-ms.cpp
  cfe/trunk/test/Lexer/half-literal.cpp
  cfe/trunk/test/Sema/Float16.c

Index: cfe/trunk/lib/Sema/SemaType.cpp
===
--- cfe/trunk/lib/Sema/SemaType.cpp
+++ cfe/trunk/lib/Sema/SemaType.cpp
@@ -1441,7 +1441,12 @@
 else
   Result = Context.Int128Ty;
 break;
-  case DeclSpec::TST_float16: Result = Context.Float16Ty; break;
+  case DeclSpec::TST_float16:
+if (!S.Context.getTargetInfo().hasFloat16Type())
+  S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported)
+<< "_Float16";
+Result = Context.Float16Ty;
+break;
   case DeclSpec::TST_half:Result = Context.HalfTy; break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
Index: cfe/trunk/lib/Basic/TargetInfo.cpp
===
--- cfe/trunk/lib/Basic/TargetInfo.cpp
+++ cfe/trunk/lib/Basic/TargetInfo.cpp
@@ -34,6 +34,7 @@
   NoAsmVariants = false;
   HasLegalHalfType = false;
   HasFloat128 = false;
+  HasFloat16 = false;
   PointerWidth = PointerAlign = 32;
   BoolWidth = BoolAlign = 8;
   IntWidth = IntAlign = 32;
Index: cfe/trunk/lib/Basic/Targets/AArch64.cpp
===
--- cfe/trunk/lib/Basic/Targets/AArch64.cpp
+++ cfe/trunk/lib/Basic/Targets/AArch64.cpp
@@ -49,6 +49,7 @@
 
   // All AArch64 implementations support ARMv8 FP, which makes half a legal type.
   HasLegalHalfType = true;
+  HasFloat16 = true;
 
   LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
   MaxVectorAlign = 128;
Index: cfe/trunk/lib/Basic/Targets/ARM.cpp
===
--- cfe/trunk/lib/Basic/Targets/ARM.cpp
+++ cfe/trunk/lib/Basic/Targets/ARM.cpp
@@ -396,6 +396,7 @@
   SoftFloat = SoftFloatABI = false;
   HWDiv = 0;
   DotProd = 0;
+  HasFloat16 = true;
 
   // This does not diagnose illegal cases like having both
   // "+vfpv2" and "+vfpv3" or having "+neon" and "+fp-only-sp".
Index: cfe/trunk/lib/Basic/Targets/SPIR.h
===
--- cfe/trunk/lib/Basic/Targets/SPIR.h
+++ cfe/trunk/lib/Basic/Targets/SPIR.h
@@ -47,6 +47,7 @@
 AddrSpaceMap = 
 UseAddrSpaceMapMangling = true;
 HasLegalHalfType = true;
+HasFloat16 = true;
 // Define available target features
 // These must be defined in sorted order!
 NoAsmVariants = true;
Index: cfe/trunk/docs/LanguageExtensions.rst
===
--- cfe/trunk/docs/LanguageExtensions.rst
+++ cfe/trunk/docs/LanguageExtensions.rst
@@ -474,44 +474,58 @@
 =
 
 Clang supports two half-precision (16-bit) floating point types: ``__fp16`` and
-``_Float16``. ``__fp16`` is defined in the ARM C Language Extensions (`ACLE
-`_)
-and ``_Float16`` in ISO/IEC TS 18661-3:2015.
-
-``__fp16`` is a storage and interchange format only. This means that values of
-``__fp16`` promote to (at least) float when used in arithmetic operations.
-There are two ``__fp16`` formats. Clang supports the IEEE 754-2008 format and
-not the ARM alternative format.
-
-ISO/IEC TS 18661-3:2015 defines C support for additional floating point types.
-``_FloatN`` is defined as a binary floating type, where the N suffix denotes
-the number of bits and is 16, 32, 64, or greater and equal to 128 and a
-multiple of 32. Clang supports ``_Float16``. The difference from ``__fp16`` is
-that arithmetic on ``_Float16`` is performed in half-precision, thus it is not
-a storage-only format. ``_Float16`` is available as a source language type in
-both C and C++ mode.
-
-It is recommended that portable code use the ``_Float16`` type because
-``__fp16`` is an ARM C-Language Extension (ACLE), whereas ``_Float16`` is
-defined by the C standards committee, so using ``_Float16`` will not prevent
-code from being ported to architectures other than Arm.  

[PATCH] D57188: Disable _Float16 for non ARM/SPIR Targets

2019-01-25 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: docs/LanguageExtensions.rst:484
+- SPIR
+``_Float16`` will be supported on more targets as they define ABIs for them.
+

rjmccall wrote:
> "them" should be "it" here.
Sorry, apparently Phabricator was sitting on a comment I made yesterday; ignore 
it, please, and just go with s/them/it/.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57188/new/

https://reviews.llvm.org/D57188



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


[PATCH] D57226: [Fixed Point] [AST] Add an AST serialization code for fixed-point literals.

2019-01-25 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: include/clang/Serialization/ASTBitCodes.h:1637
+  /// A FixedPointLiteral record.
+  EXPR_FIXEDPOINT_LITERAL,
+

ebevhan wrote:
> I'm unsure if this is the right location for a new code. This will bump down 
> all the other codes below this and cause any older file to not be read 
> correctly.
> 
> Should the file format version number be bumped up?
IIRC the real file format version for this is based on the exact revision of 
the compiler and there is no pretense of serialized ASTs being sharable between 
compilers.  I don't think we've ever bumped the version number for incompatible 
changes like this.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57226/new/

https://reviews.llvm.org/D57226



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


r352221 - Disable _Float16 for non ARM/SPIR Targets

2019-01-25 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Fri Jan 25 09:27:57 2019
New Revision: 352221

URL: http://llvm.org/viewvc/llvm-project?rev=352221=rev
Log:
Disable _Float16 for non ARM/SPIR Targets

As Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html

There are problems exposing the _Float16 type on architectures that
haven't defined the ABI/ISel for the type yet, so we're temporarily
disabling the type and making it opt-in.

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

Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736

Added:
cfe/trunk/test/Sema/Float16.c   (with props)
Modified:
cfe/trunk/docs/LanguageExtensions.rst
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/lib/Basic/TargetInfo.cpp
cfe/trunk/lib/Basic/Targets/AArch64.cpp
cfe/trunk/lib/Basic/Targets/ARM.cpp
cfe/trunk/lib/Basic/Targets/SPIR.h
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/AST/float16.cpp
cfe/trunk/test/CodeGenCXX/float16-declarations.cpp
cfe/trunk/test/CodeGenCXX/mangle-ms.cpp
cfe/trunk/test/Lexer/half-literal.cpp

Modified: cfe/trunk/docs/LanguageExtensions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=352221=352220=352221=diff
==
--- cfe/trunk/docs/LanguageExtensions.rst (original)
+++ cfe/trunk/docs/LanguageExtensions.rst Fri Jan 25 09:27:57 2019
@@ -474,44 +474,58 @@ Half-Precision Floating Point
 =
 
 Clang supports two half-precision (16-bit) floating point types: ``__fp16`` and
-``_Float16``. ``__fp16`` is defined in the ARM C Language Extensions (`ACLE
-`_)
-and ``_Float16`` in ISO/IEC TS 18661-3:2015.
-
-``__fp16`` is a storage and interchange format only. This means that values of
-``__fp16`` promote to (at least) float when used in arithmetic operations.
-There are two ``__fp16`` formats. Clang supports the IEEE 754-2008 format and
-not the ARM alternative format.
-
-ISO/IEC TS 18661-3:2015 defines C support for additional floating point types.
-``_FloatN`` is defined as a binary floating type, where the N suffix denotes
-the number of bits and is 16, 32, 64, or greater and equal to 128 and a
-multiple of 32. Clang supports ``_Float16``. The difference from ``__fp16`` is
-that arithmetic on ``_Float16`` is performed in half-precision, thus it is not
-a storage-only format. ``_Float16`` is available as a source language type in
-both C and C++ mode.
-
-It is recommended that portable code use the ``_Float16`` type because
-``__fp16`` is an ARM C-Language Extension (ACLE), whereas ``_Float16`` is
-defined by the C standards committee, so using ``_Float16`` will not prevent
-code from being ported to architectures other than Arm.  Also, ``_Float16``
-arithmetic and operations will directly map on half-precision instructions when
-they are available (e.g. Armv8.2-A), avoiding conversions to/from
-single-precision, and thus will result in more performant code. If
-half-precision instructions are unavailable, values will be promoted to
-single-precision, similar to the semantics of ``__fp16`` except that the
-results will be stored in single-precision.
-
-In an arithmetic operation where one operand is of ``__fp16`` type and the
-other is of ``_Float16`` type, the ``_Float16`` type is first converted to
-``__fp16`` type and then the operation is completed as if both operands were of
-``__fp16`` type.
-
-To define a ``_Float16`` literal, suffix ``f16`` can be appended to the 
compile-time
-constant declaration. There is no default argument promotion for ``_Float16``; 
this
-applies to the standard floating types only. As a consequence, for example, an
-explicit cast is required for printing a ``_Float16`` value (there is no string
-format specifier for ``_Float16``).
+``_Float16``.  These types are supported in all language modes.
+
+``__fp16`` is supported on every target, as it is purely a storage format; see 
below.
+``_Float16`` is currently only supported on the following targets, with further
+targets pending ABI standardization:
+- 32-bit ARM
+- 64-bit ARM (AArch64)
+- SPIR
+``_Float16`` will be supported on more targets as they define ABIs for it.
+
+``__fp16`` is a storage and interchange format only.  This means that values of
+``__fp16`` are immediately promoted to (at least) ``float`` when used in 
arithmetic
+operations, so that e.g. the result of adding two ``__fp16`` values has type 
``float``.
+The behavior of ``__fp16`` is specified by the ARM C Language Extensions 
(`ACLE 
`_).
+Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``, not the 
ARM
+alternative format.
+
+``_Float16`` is an extended floating-point type.  This means that, just like 
arithmetic on
+``float`` or ``double``, arithmetic on ``_Float16`` 

[PATCH] D57220: Test fix for isViableInline remark message

2019-01-25 Thread Adam Nemet via Phabricator via cfe-commits
anemet accepted this revision.
anemet added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57220/new/

https://reviews.llvm.org/D57220



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


[PATCH] D57188: Disable _Float16 for non ARM/SPIR Targets

2019-01-25 Thread John McCall via Phabricator via cfe-commits
rjmccall added a subscriber: scanon.
rjmccall added a comment.

This LGTM with one minor revision; feel free to commit with that.

For follow-up commit consideration: @scanon, do we want to support `_Float16` 
anywhere else?  Do we need to lock down an ABI here for i386/x86_64 in advance 
of those gears turning in the outer world?




Comment at: docs/LanguageExtensions.rst:497
 defined by the C standards committee, so using ``_Float16`` will not prevent
-code from being ported to architectures other than Arm.  Also, ``_Float16``
-arithmetic and operations will directly map on half-precision instructions when
-they are available (e.g. Armv8.2-A), avoiding conversions to/from
-single-precision, and thus will result in more performant code. If
-half-precision instructions are unavailable, values will be promoted to
+code from being ported to architectures other than Arm, though ``_Float16`` is
+currently disabled on most platforms until support is added to their published

rjmccall wrote:
> This entire documentation section really just needs to be reworked.  Here's a 
> starting point:
> 
>   Clang supports two half-precision (16-bit) floating point types: ``__fp16`` 
> and
>   ``_Float16``.  These types are supported in all language modes.
> 
>   ``__fp16`` is supported on every target, as it is purely a storage format; 
> see below.
>   ``_Float16`` is currently only supported on the following targets:
>   - 32-bit ARM
>   - 64-bit ARM (AArch64)
>   - SPIR
>   ``_Float16`` will be supported on more targets as they define ABIs for them.
> 
>   ``__fp16`` is a storage and interchange format only.  This means that 
> values of
>   ``__fp16`` are immediately promoted to (at least) ``float`` when used in 
> arithmetic
>   operations, so that e.g. the result of adding two ``__fp16`` values has 
> type ``float``.
>   The behavior of ``__fp16`` is specified by the ARM C Language Extensions 
> (`ACLE 
> `_).
>   Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``, not 
> the ARM
>   alternative format.
> 
>   ``_Float16`` is an extended floating-point type.  This means that, just 
> like arithmetic on
>   ``float`` or ``double``, arithmetic on ``_Float16`` operands is formally 
> performed in the
>   ``_Float16`` type, so that e.g. the result of adding two ``_Float16`` 
> values has type
>   ``_Float16``.  The behavior of ``_Float16`` is specified by ISO/IEC TS 
> 18661-3:2015
>   ("Floating-point extensions for C").  As with ``__fp16``, Clang uses the 
> ``binary16``
>   format from IEEE 754-2008 for ``_Float16``.
> 
>   ``_Float16`` arithmetic will be performed using native half-precision 
> support
>   when available on the target (e.g. on ARMv8.2a); otherwise it will be 
> performed
>   at a higher precision (currently always ``float``) and then truncated down 
> to
>   ``_Float16``.  Note that C and C++ allow intermediate floating-point 
> operands
>   of an expression to be computed with greater precision than is expressible 
> in
>   their type, so Clang may avoid intermediate truncations in certain cases; 
> this may
>   lead to results that are inconsistent with native arithmetic.
> 
>   It is recommended that portable code use ``_Float16`` instead of ``__fp16``,
>   as it has been defined by the C standards committee and has behavior that is
>   more familiar to most programmers.
> 
>   Because ``__fp16`` operands are always immediately promoted to ``float``, 
> the
>   common real type of ``__fp16`` and ``_Float16`` for the purposes of the 
> usual
>   arithmetic conversions is ``float``.
> 
>   A literal can be given ``_Float16`` type using the suffix ``f16``; for 
> example:
>   ```
> 3.14f16
>   ```
> 
>   Because default argument promotion only applies to the standard 
> floating-point
>   types, ``_Float16`` values are not promoted to ``double`` when passed as 
> variadic
>   or untyped arguments.  As a consequence, some caution must be taken when 
> using
>   certain library facilities with ``_Float16``; for example, there is no 
> ``printf`` format
>   specifier for ``_Float16``, and (unlike ``float``) it will not be 
> implicitly promoted to
>   ``double`` when passed to ``printf``, so the programmer must explicitly 
> cast it to
>   ``double`` before using it with an ``%f`` or similar specifier.
Hmm.  Here's a better way of expressing part of that:

  ``_Float16`` is currently only supported on the following targets, with 
further
  targets pending ABI standardization:
  - 32-bit ARM
  - 64-bit ARM (AArch64)
  - SPIR



Comment at: docs/LanguageExtensions.rst:484
+- SPIR
+``_Float16`` will be supported on more targets as they define ABIs for them.
+

"them" should be "it" here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57188/new/

https://reviews.llvm.org/D57188



___

[PATCH] D57232: [ASTImporter] Check visibility/linkage of functions and variables

2019-01-25 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: unittests/AST/ASTImporterTest.cpp:2523
+  Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
+  cast(ToTU)->dumpDeclContext();
+  ASSERT_EQ(DeclCounter().match(ToTU, 
functionDecl(hasName("f"))),

Is this dump needed? (The test should not write unnecessary text output. But 
debug statements can be leaved in the test, possibly in comment.)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57232/new/

https://reviews.llvm.org/D57232



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


r352219 - Allow 'static' storage specifier on an out-of-line member function template

2019-01-25 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Fri Jan 25 09:01:42 2019
New Revision: 352219

URL: http://llvm.org/viewvc/llvm-project?rev=352219=rev
Log:
Allow 'static' storage specifier on an out-of-line member function template
declaration in MSVCCompat mode

Microsoft compiler permits the use of 'static' storage specifier outside
of a class definition if it's on an out-of-line member function template
declaration.

This patch allows 'static' storage specifier on an out-of-line member
function template declaration with a warning in Clang (To be compatible
with Microsoft).

Intel C/C++ compiler allows the 'static' keyword with a warning in
Microsoft mode. GCC allows this with -fpermissive.

Patch By: Manna

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

Change-Id: I97b2d9e9d57cecbcd545d17e2523142a85ca2702

Added:
cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp   (with 
props)
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDecl.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=352219=352218=352219=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jan 25 09:01:42 
2019
@@ -1585,6 +1585,9 @@ def err_explicit_non_ctor_or_conv_functi
 def err_static_not_bitfield : Error<"static member %0 cannot be a bit-field">;
 def err_static_out_of_line : Error<
   "'static' can only be specified inside the class definition">;
+def ext_static_out_of_line : ExtWarn<
+  err_static_out_of_line.Text>,
+  InGroup;
 def err_storage_class_for_static_member : Error<
   "static data member definition cannot specify a storage class">;
 def err_typedef_not_bitfield : Error<"typedef member %0 cannot be a 
bit-field">;

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=352219=352218=352219=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Jan 25 09:01:42 2019
@@ -8625,8 +8625,12 @@ Sema::ActOnFunctionDeclarator(Scope *S,
 
   // Complain about the 'static' specifier if it's on an out-of-line
   // member function definition.
+
+  // MSVC permits the use of a 'static' storage specifier on an out-of-line
+  // member function template declaration, warn about this.
   Diag(D.getDeclSpec().getStorageClassSpecLoc(),
-   diag::err_static_out_of_line)
+   NewFD->getDescribedFunctionTemplate() && getLangOpts().MSVCCompat
+   ? diag::ext_static_out_of_line : diag::err_static_out_of_line)
 << FixItHint::CreateRemoval(D.getDeclSpec().getStorageClassSpecLoc());
 }
 

Added: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp?rev=352219=auto
==
--- cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp (added)
+++ cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp Fri Jan 25 
09:01:42 2019
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
+
+struct C {
+  template  static int foo(T);
+};
+
+template  static int C::foo(T) { 
+  //expected-warning@-1 {{'static' can only be specified inside the class 
definition}}
+  return 0;
+}
+

Propchange: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
--
svn:eol-style = native

Propchange: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
--
svn:keywords = "Author Date Id Rev URL"

Propchange: cfe/trunk/test/SemaCXX/warn-static-outside-class-definition.cpp
--
svn:mime-type = text/plain


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


[PATCH] D56267: [clangd] Interfaces for writing code actions

2019-01-25 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/Protocol.cpp:425
+const llvm::StringLiteral ExecuteCommandParams::CLANGD_APPLY_TWEAK =
+"clangd.applyCodeAction";
+

tweak or applyTweak



Comment at: clang-tools-extra/clangd/Protocol.h:634
 
+struct TweakArgs {
+  URIForFile file;

comment here?



Comment at: clang-tools-extra/clangd/SourceCode.h:59
+/// care to avoid comparing the result with expansion locations.
+llvm::Expected sourceLocationInMainFile(const SourceManager 
,
+Position P);

(can we add a unit test for this function?)



Comment at: clang-tools-extra/clangd/refactor/Tweak.cpp:27
+std::vector> prepareTweaks(const Tweak::Selection ) {
+#ifndef NDEBUG
+  {

ilya-biryukov wrote:
> Please note I added these assertions here.
> 
> It feels weird to traverse twice on every call to `prepareTweaks`, but that's 
> the simplest option I could come up with.
Looks fine - you could consider extracting to a separate function 
`validateRegistry` or so, but up to you


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56267/new/

https://reviews.llvm.org/D56267



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


[PATCH] D57242: [RISCV] Specify MaxAtomicInlineWidth for RISC-V

2019-01-25 Thread Lewis Revill via Phabricator via cfe-commits
lewis-revill created this revision.
lewis-revill added a reviewer: asb.
Herald added subscribers: cfe-commits, jocewei, PkmX, jfb, rkruppe, the_o, 
brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, shiva0217, 
kito-cheng, niosHD, sabuasal, apazos, simoncook, johnrusso, rbar.

This prevents Clang from generating libcalls which are not necessary when the 
target has atomic support.


Repository:
  rC Clang

https://reviews.llvm.org/D57242

Files:
  lib/Basic/Targets/RISCV.h


Index: lib/Basic/Targets/RISCV.h
===
--- lib/Basic/Targets/RISCV.h
+++ lib/Basic/Targets/RISCV.h
@@ -77,6 +77,7 @@
 IntPtrType = SignedInt;
 PtrDiffType = SignedInt;
 SizeType = UnsignedInt;
+MaxAtomicInlineWidth = 32;
 resetDataLayout("e-m:e-p:32:32-i64:64-n32-S128");
   }
 
@@ -95,6 +96,7 @@
   : RISCVTargetInfo(Triple, Opts) {
 LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
 IntMaxType = Int64Type = SignedLong;
+MaxAtomicInlineWidth = 64;
 resetDataLayout("e-m:e-p:64:64-i64:64-i128:128-n64-S128");
   }
 


Index: lib/Basic/Targets/RISCV.h
===
--- lib/Basic/Targets/RISCV.h
+++ lib/Basic/Targets/RISCV.h
@@ -77,6 +77,7 @@
 IntPtrType = SignedInt;
 PtrDiffType = SignedInt;
 SizeType = UnsignedInt;
+MaxAtomicInlineWidth = 32;
 resetDataLayout("e-m:e-p:32:32-i64:64-n32-S128");
   }
 
@@ -95,6 +96,7 @@
   : RISCVTargetInfo(Triple, Opts) {
 LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
 IntMaxType = Int64Type = SignedLong;
+MaxAtomicInlineWidth = 64;
 resetDataLayout("e-m:e-p:64:64-i64:64-i128:128-n64-S128");
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57106: [AST] Introduce GenericSelectionExpr::Association

2019-01-25 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno added inline comments.



Comment at: include/clang/AST/Expr.h:5103
+using reference = AssociationTy;
+using pointer = AssociationTy;
+AssociationIteratorTy() = default;

aaron.ballman wrote:
> riccibruno wrote:
> > dblaikie wrote:
> > > aaron.ballman wrote:
> > > > riccibruno wrote:
> > > > > aaron.ballman wrote:
> > > > > > Carrying over the conversation from D57098:
> > > > > > 
> > > > > > >> @aaron.ballman Cute, but I suspect this may come back to bite us 
> > > > > > >> at some point. For instance, if someone thinks they're working 
> > > > > > >> with a real pointer, they're likely to expect pointer arithmetic 
> > > > > > >> to work when it won't (at least they'll get compile errors 
> > > > > > >> though).
> > > > > > > @riccibruno Hmm, but pointer is just the return type of 
> > > > > > > operator-> no ? Is it actually required to behave like a pointer 
> > > > > > > ? The only requirement I can find is that It->x must be 
> > > > > > > equivalent to (*It).x, which is true here.
> > > > > > 
> > > > > > I double-checked and you're right, this is not a requirement of the 
> > > > > > STL.
> > > > > > 
> > > > > > > Also looking at the requirements for forward iterators I think 
> > > > > > > that this iterator should actually be downgraded to an input 
> > > > > > > iterator, because of the requirement that reference = T&.
> > > > > > 
> > > > > > My concern is that with the less functional iterators, common 
> > > > > > algorithms get more expensive. For instance, `std::distance()`, 
> > > > > > `std::advance()` become more expensive without random access, and 
> > > > > > things like `std::prev()` become impossible.
> > > > > > 
> > > > > > It seems like the view this needs to provide is a read-only access 
> > > > > > to the `AssociationTy` objects (because we need to construct them 
> > > > > > on the fly), but not the data contained within them. If the only 
> > > > > > thing you can get back from the iterator is a const 
> > > > > > pointer/reference/value type, then we could store a local "current 
> > > > > > association" object in the iterator and return a pointer/reference 
> > > > > > to that. WDYT?
> > > > > I am worried about lifetime issues with this approach. Returning a 
> > > > > reference/pointer to an `Association` object stored in the iterator 
> > > > > means that the reference/pointer will dangle as soon as the iterator 
> > > > > goes out of scope. This is potentially surprising since the 
> > > > > "container" (that is the `GenericSelectionExpr`) here will still be 
> > > > > in scope. Returning a value is safer in this aspect.
> > > > > 
> > > > > I believe it should be possible to make the iterator a random access 
> > > > > iterator, at least
> > > > > if we are willing to ignore some requirements:
> > > > > 
> > > > > 1.) For forward iterators and up, we must have `reference = T&` or 
> > > > > `const T&`.
> > > > > 2.) For forward iterators and up, `It1 == It2` if and only if `*It1` 
> > > > > and `*It2` are bound to the same object.
> > > > > I am worried about lifetime issues with this approach. Returning a 
> > > > > reference/pointer to an Association object stored in the iterator 
> > > > > means that the reference/pointer will dangle as soon as the iterator 
> > > > > goes out of scope. This is potentially surprising since the 
> > > > > "container" (that is the GenericSelectionExpr) here will still be in 
> > > > > scope. Returning a value is safer in this aspect.
> > > > 
> > > > That's valid.
> > > > 
> > > > > I believe it should be possible to make the iterator a random access 
> > > > > iterator, at least if we are willing to ignore some requirements:
> > > > >
> > > > > 1.) For forward iterators and up, we must have reference = T& or 
> > > > > const T&.
> > > > > 2.) For forward iterators and up, It1 == It2 if and only if *It1 and 
> > > > > *It2 are bound to the same object.
> > > > 
> > > > Yes, but then passing these iterators to STL algorithms will have UB 
> > > > because we claim to meet the requirements for random access iteration 
> > > > but don't actually meet the requirements. I am not certain what 
> > > > problems might arise from violating these requirements.
> > > > 
> > > > @dblaikie, @mclow.lists: do you have opinions on whether it's okay to 
> > > > not meet these requirements or suggestions on what we could do 
> > > > differently with the design?
> > > My vote is usually "yeah, have a member inside the iterator you return a 
> > > reference/pointer to" to meet the iterator requirements. Yes, it means if 
> > > you keep a pointer/reference to it, that is invalidated when you 
> > > increment the iterator. But that's well established in iterator semantics.
> > > 
> > > (might be shooting from the hip here/not fully understanding the 
> > > nuances/tradeoffs in this case)
> > I believe there are 3 possibilities here:
> > 
> > Option 1 : Make the iterator an input iterator, and make 

[PATCH] D57106: [AST] Introduce GenericSelectionExpr::Association

2019-01-25 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno updated this revision to Diff 183552.
riccibruno marked 10 inline comments as done.
riccibruno added a comment.

Moved back to an input iterator. Addressed Aaron's remaining comments.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57106/new/

https://reviews.llvm.org/D57106

Files:
  include/clang/AST/Expr.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/StmtDataCollectors.td
  lib/AST/ASTDumper.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Sema/SemaExprObjC.cpp
  lib/Sema/SemaPseudoObject.cpp
  lib/Sema/TreeTransform.h

Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -9071,10 +9071,10 @@
 
   SmallVector AssocExprs;
   SmallVector AssocTypes;
-  for (unsigned i = 0; i != E->getNumAssocs(); ++i) {
-TypeSourceInfo *TS = E->getAssocTypeSourceInfo(i);
-if (TS) {
-  TypeSourceInfo *AssocType = getDerived().TransformType(TS);
+  for (const GenericSelectionExpr::Association  : E->associations()) {
+TypeSourceInfo *TSI = Assoc.getTypeSourceInfo();
+if (TSI) {
+  TypeSourceInfo *AssocType = getDerived().TransformType(TSI);
   if (!AssocType)
 return ExprError();
   AssocTypes.push_back(AssocType);
@@ -9082,7 +9082,8 @@
   AssocTypes.push_back(nullptr);
 }
 
-ExprResult AssocExpr = getDerived().TransformExpr(E->getAssocExpr(i));
+ExprResult AssocExpr =
+getDerived().TransformExpr(Assoc.getAssociationExpr());
 if (AssocExpr.isInvalid())
   return ExprError();
 AssocExprs.push_back(AssocExpr.get());
Index: lib/Sema/SemaPseudoObject.cpp
===
--- lib/Sema/SemaPseudoObject.cpp
+++ lib/Sema/SemaPseudoObject.cpp
@@ -140,19 +140,23 @@
 unsigned resultIndex = gse->getResultIndex();
 unsigned numAssocs = gse->getNumAssocs();
 
-SmallVector assocs(numAssocs);
-SmallVector assocTypes(numAssocs);
-
-for (unsigned i = 0; i != numAssocs; ++i) {
-  Expr *assoc = gse->getAssocExpr(i);
-  if (i == resultIndex) assoc = rebuild(assoc);
-  assocs[i] = assoc;
-  assocTypes[i] = gse->getAssocTypeSourceInfo(i);
+SmallVector assocExprs;
+SmallVector assocTypes;
+assocExprs.reserve(numAssocs);
+assocTypes.reserve(numAssocs);
+
+for (const GenericSelectionExpr::Association  :
+ gse->associations()) {
+  Expr *assocExpr = assoc.getAssociationExpr();
+  if (assoc.isSelected())
+assocExpr = rebuild(assocExpr);
+  assocExprs.push_back(assocExpr);
+  assocTypes.push_back(assoc.getTypeSourceInfo());
 }
 
 return GenericSelectionExpr::Create(
 S.Context, gse->getGenericLoc(), gse->getControllingExpr(),
-assocTypes, assocs, gse->getDefaultLoc(), gse->getRParenLoc(),
+assocTypes, assocExprs, gse->getDefaultLoc(), gse->getRParenLoc(),
 gse->containsUnexpandedParameterPack(), resultIndex);
   }
 
Index: lib/Sema/SemaExprObjC.cpp
===
--- lib/Sema/SemaExprObjC.cpp
+++ lib/Sema/SemaExprObjC.cpp
@@ -4332,14 +4332,16 @@
 assert(!gse->isResultDependent());
 
 unsigned n = gse->getNumAssocs();
-SmallVector subExprs(n);
-SmallVector subTypes(n);
-for (unsigned i = 0; i != n; ++i) {
-  subTypes[i] = gse->getAssocTypeSourceInfo(i);
-  Expr *sub = gse->getAssocExpr(i);
-  if (i == gse->getResultIndex())
+SmallVector subExprs;
+SmallVector subTypes;
+subExprs.reserve(n);
+subTypes.reserve(n);
+for (const GenericSelectionExpr::Association  : gse->associations()) {
+  subTypes.push_back(assoc.getTypeSourceInfo());
+  Expr *sub = assoc.getAssociationExpr();
+  if (assoc.isSelected())
 sub = stripARCUnbridgedCast(sub);
-  subExprs[i] = sub;
+  subExprs.push_back(sub);
 }
 
 return GenericSelectionExpr::Create(
Index: lib/AST/StmtProfile.cpp
===
--- lib/AST/StmtProfile.cpp
+++ lib/AST/StmtProfile.cpp
@@ -1259,13 +1259,14 @@
 
 void StmtProfiler::VisitGenericSelectionExpr(const GenericSelectionExpr *S) {
   VisitExpr(S);
-  for (unsigned i = 0; i != S->getNumAssocs(); ++i) {
-QualType T = S->getAssocType(i);
+  for (const GenericSelectionExpr::ConstAssociation  :
+   S->associations()) {
+QualType T = Assoc.getType();
 if (T.isNull())
   ID.AddPointer(nullptr);
 else
   VisitType(T);
-VisitExpr(S->getAssocExpr(i));
+VisitExpr(Assoc.getAssociationExpr());
   }
 }
 
Index: lib/AST/StmtPrinter.cpp
===
--- lib/AST/StmtPrinter.cpp
+++ lib/AST/StmtPrinter.cpp
@@ -1261,15 +1261,15 @@
 void 

[PATCH] D57185: [clang-tidy] Add the abseil-duration-addition check

2019-01-25 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added inline comments.



Comment at: test/clang-tidy/abseil-duration-addition.cpp:84
+#undef PLUS_FIVE
+}

hwright wrote:
> JonasToth wrote:
> > a view template test-cases would be good to have.
> I'm not sure I know that terminology; do you have an example?
```
template
void foo(absl::Time t) {
  int i = absl::ToUnixNanos(t) + T{};
}
foo(t);
foo(t);
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57185/new/

https://reviews.llvm.org/D57185



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


[PATCH] D57185: [clang-tidy] Add the abseil-duration-addition check

2019-01-25 Thread Hyrum Wright via Phabricator via cfe-commits
hwright marked 2 inline comments as done.
hwright added inline comments.



Comment at: test/clang-tidy/abseil-duration-addition.cpp:84
+#undef PLUS_FIVE
+}

JonasToth wrote:
> a view template test-cases would be good to have.
I'm not sure I know that terminology; do you have an example?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57185/new/

https://reviews.llvm.org/D57185



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


[PATCH] D56903: [clangd] Suggest adding missing includes for incomplete type diagnostics.

2019-01-25 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Just a bunch of nits, up to you to work out how/whether to address.

One substantive issue around classes defined outside headers - will chat 
offline.




Comment at: clangd/ClangdServer.h:118
+
+bool EnableIncludeFixer = false;
   };

Can we call this option `SuggestMissingIncludes` or so? include-fixer is the 
name of a separate tool.



Comment at: clangd/ClangdUnit.cpp:295
 
+  llvm::Optional FixIncludes;
+  auto BuildDir = VFS->getCurrentWorkingDirectory();

sammccall wrote:
> Probably worth a two-line comment explaining at a high level what this is 
> doing.
> Somewhat redundant with `IncludeFixer.h` but probably worth it anyway since 
> this containing function is a complicated mess.
nit: can you hoist this above the line declaring FixIncludes?
That way (I think) it reads more naturally as "this is what the following block 
of code does" in a big method, doesn't fold away with the if, etc



Comment at: clangd/ClangdUnit.cpp:305
+}
+FixIncludes.emplace(MainInput.getFile(), std::move(Inserter), *Index);
+ASTDiags.contributeFixes([](DiagnosticsEngine::Level DiagLevl,

nit: I'm not sure I agree with the IncludeFixer class taking ownership of the 
include inserter.
It reads it but never writes to it, so full ownership isn't *needed*. And if we 
had other features that wanted to compute include insertions, we'd want them to 
share an inserter.



Comment at: clangd/Compiler.h:49
+  // Used to recover from diagnostics (e.g. find missing includes for symbol).
+  llvm::Optional Index;
+  ParseOptions Opts;

isn't an optional pointer just a pointer?



Comment at: clangd/IncludeFixer.cpp:39
+   const clang::Diagnostic ) const {
+  if (IndexRequestCount >= 5)
+return {}; // Avoid querying index too many times in a single parse.

consider moving this 5 to a constructor param, so this file can be entirely 
mechanism and the policy is spelled out at the construction site.
(No need to actually make it configurable, I think)



Comment at: clangd/IncludeFixer.cpp:41
+return {}; // Avoid querying index too many times in a single parse.
+  if (isIncompleteTypeDiag(Info.getID())) {
+// Incomplete type diagnostics should have a QualType argument for the

(You could also just write this as just a switch on Info.getID(), I'd find that 
a little direct/easier to read, up to you)



Comment at: clangd/IncludeFixer.cpp:61
+return {};
+  std::string IncompleteType = printQualifiedName(*TD);
+  if (IncompleteType.empty()) {

TypeName?



Comment at: clangd/IncludeFixer.cpp:63
+  if (IncompleteType.empty()) {
+vlog("No incomplete type name is found in diagnostic. Ignore.");
+return {};

this seems an odd thing to check and way to phrase - there *was* a type in the 
message, but its name happens to be empty. Am I missing something? (I'd suggest 
just removing this)



Comment at: clangd/IncludeFixer.cpp:80
+  Index.lookup(Req, [&](const Symbol ) {
+// FIXME: support multiple matched symbols.
+if (Matched || (Sym.Scope + Sym.Name).str() != IncompleteType)

fixme is obsolete



Comment at: clangd/IncludeFixer.cpp:81
+// FIXME: support multiple matched symbols.
+if (Matched || (Sym.Scope + Sym.Name).str() != IncompleteType)
+  return;

no need to check name



Comment at: clangd/IncludeFixer.cpp:86
+
+  if (!Matched || Matched->IncludeHeaders.empty())
+return {};

There's a case I'm worried about:

Foo.h declares `class X;`, Foo.cpp defines `class X{}`.
Now Bar.cpp tries to do `sizeof(X)`, so we get an incomplete type diagnostic.
 - suggesting `#include Foo.cpp` is bad - can't include impl file
 - suggesting `#include Foo.h` is also bad - doesn't help
 - providing no suggestion is correct.

I'm not sure the index really has enough structured information to detect this 
case, but we could check e.g. that definition header == canonical declaration 
header? Or that basename(IncludeHeaders) == basename(definition header)?

If possible, can you add a test for this case?



Comment at: clangd/IncludeFixer.h:39
+  /// Attempts to recover diagnostic caused by an incomplete type \p T.
+  std::vector fixInCompleteType(const Type ) const;
+

sammccall wrote:
> nit: incomplete is one word
not done - method is still "fixInCompleteType"



Comment at: clangd/tool/ClangdMain.cpp:210
 
+static llvm::cl::opt EnableIncludeFixer(
+"include-fixer",

similarly, I'd call this -suggest-missing-includes or just -suggest-includes



[PATCH] D57113: [clang-tidy] openmp-use-default-none - a new module and a check

2019-01-25 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri marked 2 inline comments as not done.
lebedev.ri added inline comments.



Comment at: docs/clang-tidy/checks/openmp-use-default-none.rst:12
+being implicitly determined, and thus forces developer to be explicit about the
+desired data scoping for each variable.
+

JonasToth wrote:
> lebedev.ri wrote:
> > JonasToth wrote:
> > > JonasToth wrote:
> > > > If I understand correctly the issue is more about implicitly shared 
> > > > variables that lead to data-races and bad access patterns, is that 
> > > > correct?
> > > > If so it might clarify the reason for this check, if added directly in 
> > > > the first motivational sentence.
> > > is it scoping or rather sharing? The scope is C++-terrain or at least 
> > > used in C++-Speak. Maybe there is a unambiguous word instead?
> > I'm not quite sure how to formulate the reasoning to be honest.
> > Let me try to show some reasonably-complete example:
> > https://godbolt.org/z/mMQhbr
> > 
> > We have 4 compilers: clang trunk + openmp 3.1, clang trunk + openmp 4, gcc 
> > 8, gcc trunk
> > 
> > We have 5 code samples, all operating with a `const` variable: (the same 
> > code, just different omp clauses)
> > * If no `default` clause is specified, every compiler is fine with the code.
> > * If `default(shared)` clause is specified, every compiler is still fine 
> > with the code.
> >   On this example, no clause and `default(shared)` clause are equivalent.
> >   I can't/won't claim whether or not that is always the case, as i'm mostly 
> > arguing re `default(none)`.
> > * If `default(none) shared(num)` is specified, all is also fine.
> >   That is equivalent to just the `default(none)` for OpenMP 3.1
> > * If `default(none) firstprivate(num)` is specified, all still fine fine.
> > * If only ``default(none)` is specified, things start to get wonky.
> >   The general idea is that before OpenMP 4.0 such `const` variables were 
> > auto-determined as `shared`,
> >   and now they won't. So one will need to add either `shared(num)` or 
> > `firstprivate(num)`.
> >   Except the older gcc will diagnose `shared(num)` :)
> > 
> > Roughly the same is true when the variable is not `const`: 
> > https://godbolt.org/z/wuouI_
> > 
> > Thus, `default(none)` forced one to be explicit about what shall be done 
> > with the variable,
> > should it be `shared`, or `firstprivate`.
> > 
> > 
> > ^ Not whether this rambling makes sense?
> Yes, so its about being explicit if state is shared or not. Given that its 
> hard to reason about parallel programs being explicit helps reading the code. 
> I think that could be condensed in a short motivation section.
> Yes, so its about being explicit if state is shared or not. Given that its 
> hard to reason about parallel programs being explicit helps reading the code. 
> I think that could be condensed in a short motivation section.

Yep. Will try to reword.

> is it scoping or rather sharing? The scope is C++-terrain or at least used in 
> C++-Speak. Maybe there is a unambiguous word instead?

E.g. clang messages say `variable 'num' must have explicitly specified data 
sharing attributes`
So "data sharing" i suppose.



Comment at: test/clang-tidy/openmp-use-default-none.cpp:53
+// 'parallel' directive can have 'default' clause, and said clause is 
specified,
+// with 'none' kind, all good.
+void t5(const int a) {

JonasToth wrote:
> Please add basic test-cases for the other constructs that are allowed to have 
> the `default` specified.
For the base directives (so 3x4 new tests) i assume,
not all the possible combinations of directives that are allowed to contain 
`default` (a *LOT* more tests)?


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57113/new/

https://reviews.llvm.org/D57113



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


[PATCH] D57185: [clang-tidy] Add the abseil-duration-addition check

2019-01-25 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added inline comments.



Comment at: clang-tidy/abseil/DurationAdditionCheck.cpp:22
+void DurationAdditionCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+  binaryOperator(hasOperatorName("+"),

hwright wrote:
> JonasToth wrote:
> > This whole file is structurally similar to the 
> > `DurationSubtractionCheck.cpp` equivalent (which is expected :)), maybe 
> > some parts could be refactored out?
> > Will there be a check for duration scaling or the like?
> I think that most of it already has been factored out (e.g., 
> `rewriteExprFromNumberToDuration` and `getScaleForTimeInverse`, etc) . The 
> actual meat here is pretty light: the matcher, and then the diagnostic 
> generation.
> 
> A scaling change may also follow.  Our experience has been that scaling isn't 
> quite straight forward, as the scaling factor may have semantic meaning which 
> changes the result, but which isn't captured by the type system.  Probably 
> not a design discussion to have here, but suffice it to say that I don't know 
> if this is yet settled.
Your right, there is not too much to gain. Only if there are more checks coming 
with the same structure it makes sense to think again.



Comment at: test/clang-tidy/abseil-duration-addition.cpp:84
+#undef PLUS_FIVE
+}

a view template test-cases would be good to have.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57185/new/

https://reviews.llvm.org/D57185



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


[PATCH] D56925: Do not use frame pointer by default for MSP430

2019-01-25 Thread Kristina Bessonova via Phabricator via cfe-commits
krisb added inline comments.



Comment at: test/CodeGen/msp430-fp-elim.c:16
+{
+   asm volatile ("calla r4");
+}

This test as it is will fail after integrated assembler will be turned on by 
default (see https://reviews.llvm.org/D56787).  Since `calla` instruction isn't 
supported yet, the assembler will report an error of 'invalid instruction 
mnemonic'.
So, please, choose another instruction from ones that are already supported. Or 
turn -integrated-as off.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56925/new/

https://reviews.llvm.org/D56925



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


  1   2   >