[PATCH] D60907: [OpenMP][WIP] Add math functions support in OpenMP offloading

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

So the scheme is: `pow` is defined in `__clang_openmp_math.h` to call 
`__kmpc_pow`. This lives in `libomptarget-nvptx` (both bc and static lib) and 
just calls `pow` which works because `nvcc` and Clang in CUDA mode make sure 
that the call gets routed into `libdevice`?

Did you test that something like `pow(d, 2)` is optimized by LLVM to `d * d`? 
There's a pass doing so (can't recall the name) and from my previous attempts 
it didn't work well if you hid the function name instead of the known `pow` one.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60907



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

[PATCH] D60899: [analyzer] Unbreak body farms in presence of multiple declarations.

[Aleksei Sidorin via Phabricator via cfe-commits]

a_sidorin accepted this revision.
a_sidorin added a comment.
This revision is now accepted and ready to land.

Hi Artem,
This looks good to me. However, it seems to me that the correct solution is to 
synthesize a shining new function and include it into the redeclaration chain. 
This requires much more work, however.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60899



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

[PATCH] D60934: [clang] adding explicit(bool) from c++2a

[Gauthier via Phabricator via cfe-commits]

Tyker created this revision.
Tyker added a reviewer: rsmith.
Herald added a reviewer: martong.
Herald added a reviewer: shafik.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

this patch adds support for the explicit bool specifier.

added parsing for explicit bool specifier in ParseDecl.cpp
adapted storage of explicit specifier in AST and DeclSpec.

  was boolean value not it is a PointerIntPair with a flag and a potential 
expression.
  was stored in every function declaration. now it is stored only in 
CXXConstructorDecl, CXXDeductionGuideDecl and CXXConversionDecl.

adpated AddOverloadCandidate, AddTemplateOverloadCandidate, 
AddConversionCandidate and AddTemplateConversionCandidate
adapted template instatiation to instantiate explicit bool expressions.
to receive a boolean idicating if function resolved to be explicit should be 
removed.
adapted Serialization, ASTMatchers, ASTComparator and ASTPrinter
added test for semantic and serialization.

this patch is not yet complete. i still need to check the interaction with CTAD 
and deduction guides.
and add more tests for AST operations. but i wanted first feedback.

perhaps this patch should be splitted in smaller patchs. but making each patch 
testable as a standalone may be tricky.


Repository:
  rC Clang

https://reviews.llvm.org/D60934

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Overload.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/PCH/cxx-explicit-spec.cpp
  clang/test/SemaCXX/cxx2a-explicit-bool.cpp
  clang/test/SemaCXX/explicit.cpp

Index: clang/test/SemaCXX/explicit.cpp
===
--- clang/test/SemaCXX/explicit.cpp
+++ clang/test/SemaCXX/explicit.cpp
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2a %s
+
 namespace Constructor {
 struct A {
   A(int);
@@ -183,7 +185,8 @@
 const int ©List7 = {b};
 const int ©List8 = {n}; // expected-error {{no viable conversion}}
   }
-  
+
+#if __cplusplus < 201707L
   void testNew()
   {
 // 5.3.4p6:
@@ -200,7 +203,8 @@
 new int[i];
 new int[ni]; // expected-error {{array size expression of type 'NotInt' requires explicit conversion to type 'int'}}
   }
-  
+#endif
+
   void testDelete()
   {
 // 5.3.5pp2:
Index: clang/test/SemaCXX/cxx2a-explicit-bool.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2a-explicit-bool.cpp
@@ -0,0 +1,336 @@
+// RUN: %clang_cc1 -std=c++2a -fsyntax-only %s -verify
+
+template
+struct enable_ifv {};
+
+template
+struct enable_ifv {
+  static constexpr auto value = val;
+};
+
+template
+struct is_same {
+static constexpr bool value = false;
+};
+
+template
+struct is_same {
+static constexpr bool value = true;
+};
+
+namespace test0
+{
+
+template
+struct A {
+  explicit(1 << a)
+  //expected-error@-1 {{argument to explicit specifier is not a valid constant expression}}
+  //expected-note@-2 {{negative shift count -1}}
+  A(int);
+};
+
+A<-1> a(0); //expected-note {{in instantiation of template class}}
+
+template
+struct B {
+  explicit(b)
+  // expected-error@-1 {{use of undeclared identifier}}
+  // expected-note@-2 {{this expression is parsed as explicit(bool) since c++2a}}
+  B(int);
+};
+
+}
+
+
+namespace test1 {
+
+template
+struct A {
+  // expected-note@-1 {{candidate constructor}}
+  // expected-note@-2 {{candidate constructor}}
+  // expected-note@-3 {{candidate function}} expected-note@-3 {{candidate function}}
+  // expected-note@-4 {{candidate function}} expected-note@-4 {{candidate function}}
+  explicit(b) A(int, int = 0);
+  // expected-note@-1 {{explicit constructor declared here}}
+  // expected-note@-2 {{explicit constructor declared here}}
+  // expected-note@-3 {{explicit constructor declared here}}
+};
+
+template
+A::A(int, int) {}
+
+void f()
+{
+  A a0 = 0; // expected-error {{no viable conversion}}
+  A a1( 0);
+  A && a2 = 0;

[PATCH] D60523: [clang] Bugfixe for 41400

[Gauthier via Phabricator via cfe-commits]

Tyker added a comment.

awaiting feedback on this


Repository:
  rC Clang

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

https://reviews.llvm.org/D60523



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

[PATCH] D60910: [WIP] Dumping the AST to JSON

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a subscriber: lebedev.ri.
riccibruno added a comment.

A few comments/questions:

1. How stable is the format going to be, and how much state is going to be 
exposed ?
2. I am wondering if it would be possible to separate the logic about how to 
visit a given AST node, from the logic about what to do with the node's state. 
For example it seems to me that `JSONNodeDumper::VisitVarDecl` and 
`TextNodeDumper::VisitVarDecl` are somewhat similar. You could instead imagine 
having a generic way to visit each node, which would then inform 
`JSONNodeDumper` or `TextNodeDumper` about the various bits of state in the 
node. With the proposed implementation essentially all of the logic for what is 
in each node has to be duplicated. This is not an objection about the current 
patch, just something I am wondering about.




Comment at: include/clang/AST/JSONNodeDumper.h:55
+  }
+
+  /// Add a child of the current node with an optional label.

Perhaps you should perfect-forward `DoAddChild` ?



Comment at: include/clang/AST/JSONNodeDumper.h:164
+  std::string createAccessSpecifier(AccessSpecifier AS);
+
+  void writePreviousDeclImpl(...) {}

@lebedev.ri might want to comment on the use of `llvm::json`. I think that 
there has been issues in the recent past where it was unexpectedly slow 
(although it might not matter for this use case).



Comment at: lib/AST/ASTDumper.cpp:231
+
+  if (ADOF_JSON == Format) {
+JSONDumper P(OS, SM, Ctx.getPrintingPolicy());

(Ah, Yoda conditionals ! (I am not saying to change it))

Do you plan to do the same modification to the others `dump` methods ?


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

https://reviews.llvm.org/D60910



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

[PATCH] D60934: [clang] adding explicit(bool) from c++2a

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang/include/clang/AST/DeclCXX.h:2620
+
+  bool hasExplicitSpecifer() const {
+return ExplicitSpecifier.getInt() != ESF_resolved_false ||

s/Specifer/Specifier/ (and please `git grep` for other instances of the same 
typo)



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:40
+def note_explicit_bool_breaking_change_cxx2a : Note<
+  "this expression is parsed as explicit(bool) since c++2a">;
+

"C++2a" should be uppercased.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2125
+def err_deduction_guide_explicit_bool : Error<
+  "explicit specfier of a deduction guide cannot depend on a constant 
expression">;
 def err_deduction_guide_specialized : Error<"deduction guide cannot be "

s/specfier/specifier/ (and please git grep for other instances)



Comment at: clang/lib/Sema/DeclSpec.cpp:959
+  // Each decl-specifier shall appear at most once in a complete
+  // decl-specifier-seq, except that long may appear twice.
+  if (hasExplicitSpecifier()) {

Spelling/grammar/capitalization-of-C++2a.
Also, it seems to me that you've got a CWG wording issue here: what does N4810 
mean by "Each //decl-specifier// shall appear at most once in a complete 
//decl-specifier-seq//, except that `long` may appear twice"? What is "each" 
decl-specifier? Is `explicit(true)` a different decl-specifier from 
`explicit(1+1==2)`? Is `explicit(true)` different from `explicit(false)`?



Comment at: clang/test/SemaCXX/explicit.cpp:189
+
+#if __cplusplus < 201707L
   void testNew()

Why?


Repository:
  rC Clang

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

https://reviews.llvm.org/D60934



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

[PATCH] D60186: Support CLANG_ENABLE_DEFAULT_PIE like gcc --enable-default-pie

[Jiang Yi via Phabricator via cfe-commits]

jiangyi added a comment.

@rsmith How do you think of this patch?


Repository:
  rC Clang

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

https://reviews.llvm.org/D60186



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

[PATCH] D60934: [clang] adding explicit(bool) from c++2a

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

This patch certainly took a few hours to write. Can you spend 5 minutes on 
making the summary readable (spelling, capitalization, formatting, well-formed 
sentences, ...) ?


Repository:
  rC Clang

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

https://reviews.llvm.org/D60934



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

[PATCH] D60872: Add new warning knob for unknown attribute namespaces

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman marked 2 inline comments as done.
aaron.ballman added a comment.

In D60872#1473205 , @rsmith wrote:

> Hmm. So there are a few different situations where we might meet an unknown 
> attribute (I'm sure I missed some):
>
> 1. The attribute had a typo in it (eg: [[clagn::fallthrough]]).
> 2. The attribute has semantic effects (ignoring it is incorrect and will -- 
> at best -- not compile or -- at worst -- generate a subtly broken program, 
> eg: [[gnu::aligned]] or [[gnu::target]]).
> 3. The attribute has important effects (ignoring it is probably correct but 
> suboptimal in some way, eg: [[no_unique_address]], [[gnu::packed]], ...).
> 4. The attribute has unimportant effects (is entirely safely ignorable) or is 
> only intended to affect the behavior of a different tool (eg: gsl, static 
> analyzer, clang-tidy, etc).
>
>   I think the ideal would be to warn on unknown attributes in cases 1 and 2, 
> optionally warn on unknown attributes in case 3, and to not warn in case 4. 
> Without user hints, we can't tell which is which in general.
>
>   "Do not warn on unknown namespaces" gives us some part of not warning on 
> case 4. However, it also turns off warnings in cases 1-3 (eg, we won't warn 
> on `[[gcc::noinline]]` as a typo for `[[gnu::noinline]]`),


Disabling warnings sometimes means you lose out on good information. It's a 
good point to keep in mind, but at the same time, it's also the point to the 
diagnostic to not warn on attributes in unknown namespaces, so the behavior 
doesn't seem all that surprising to me.

> and doesn't turn off warnings for case-4 attributes in, say, namespace `gnu`, 
> so it's somewhat imperfect. I think it's also going to be surprising that the 
> clang release that starts parsing a [[gsl::*]] attribute also starts warning 
> on other ("unknown") [[gsl::*]] attributes for people in this new mode.
> 
> It seems to me that we can achieve the ideal (don't warn on safely-ignorable 
> unknown attributes, but warn on all other unknown attributes) if we ask the 
> user to give us a list of safely-ignorable attributes and attribute 
> namespaces that they intend to use. (That even lets us do typo-correction for 
> attributes we don't support.) In the cfe-dev thread, there was mention that 
> there are hundreds of attributes supported by clang, and so hundreds of 
> attributes would need to be listed, but that doesn't follow: you only need to 
> list the attributes that you actually intend to use. That should be a much 
> smaller list (especially once modules adoption picks up, and you don't need 
> to list those attributes used by your dependencies).

I am pretty strongly opposed to having the user specify the list of attributes 
on the command line. We spend a lot of time worrying about users who cannot 
spell, so giving them another place to make typos (but one that pushes them 
towards needing more advanced build strategies like response files) seems 
counter-intuitive. We also would have to solve some interesting issues like the 
user specifying "foo_attr" on the command line, using 
`__attribute__((foo_attr))` in code and having it warned on as an unknown 
attribute because we happen to know about `__declspec(foo_attr)` but not the 
`__attribute__((foo_attr))` spelling, etc.

I think am coming at this from a different angle -- the user's code is compiled 
with 1 compiler (Clang) vs N compilers (including Clang). For a user who is 
using N compilers, they should be using the preprocessor to solve this issue. 
This is the longstanding status quo solution and is the reason we standardized 
`__has_cpp_attribute` and friends, and I'm not strongly motivated to maintain 
an additional solution that pushes the issue into the build system for only one 
of their N compilers because the user will still have to come up with ad hoc 
solutions for the other N - 1 compilers, so this doesn't seem like it gets them 
much (compared to the macro approach, which can work for all compilers). What I 
am strongly motivated to support are users who are using Clang as their only 
compiler. These users have no reason to need the macro boilerplate, except for 
3rd party tooling that is entirely unknown to Clang (static analyzers being a 
primary source). Given that well-behaved 3rd party tools should only be 
introducing attributes in their own vendor namespace (a namespace Clang is 
unlikely to know anything about), and we have no reason to believe 3rd parties 
won't come up with numerous attributes the user may want to use, it seems very 
useful to allow users to inhibit the unknown attribute warnings for those 
vendor namespaces without making the user maintain a separate, manual list of 
attributes in the build system. I also don't see Clang introducing attributes 
from those vendor namespaces with any frequency, so that's why I'm not too 
worried about upgrades introducing new warnings.




Comment at: test/SemaCXX/attr-cxx

[PATCH] D60910: [WIP] Dumping the AST to JSON

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman marked 2 inline comments as done.
aaron.ballman added a comment.

In D60910#1473441 , @riccibruno wrote:

> A few comments/questions:
>
> 1. How stable is the format going to be, and how much state is going to be 
> exposed ?


I don't expect it to be particularly stable (I'm not suggesting we conform to 
some particular schema) and for my own needs, I'm happy enough if new Clang 
releases break us due to new, deleted, or renamed information. I need to expose 
as much state as required for our research team to import the data and reason 
about the AST; I'd guess it's going to be roughly the same as the textual 
dumper, but different in spots.

> 2. I am wondering if it would be possible to separate the logic about how to 
> visit a given AST node, from the logic about what to do with the node's 
> state. For example it seems to me that `JSONNodeDumper::VisitVarDecl` and 
> `TextNodeDumper::VisitVarDecl` are somewhat similar. You could instead 
> imagine having a generic way to visit each node, which would then inform 
> `JSONNodeDumper` or `TextNodeDumper` about the various bits of state in the 
> node. With the proposed implementation essentially all of the logic for what 
> is in each node has to be duplicated. This is not an objection about the 
> current patch, just something I am wondering about.

This was something I had been pondering when we were doing the great AST dump 
refactoring earlier this year, but I didn't think we could get it to be 
sufficiently general to suit various purposes. On the one hand, there's 
definitely a ton of overlap between any two "dump the AST in this format" 
approaches, but on the other hand, different approaches have different 
requirements that may change what data is displayed. For instance, the textual 
dump will likely write out more information than the JSON dump because the 
textual dump is purely for human readability (so having extra information near 
the node may be critical) whereas the JSON dump is for machine readability (so 
having extra information may or may not be prohibitive, but hooking up 
disparate data within the file may be trivial).




Comment at: include/clang/AST/JSONNodeDumper.h:164
+  std::string createAccessSpecifier(AccessSpecifier AS);
+
+  void writePreviousDeclImpl(...) {}

riccibruno wrote:
> @lebedev.ri might want to comment on the use of `llvm::json`. I think that 
> there has been issues in the recent past where it was unexpectedly slow 
> (although it might not matter for this use case).
I'm currently only using the JSON functionality for wholly-contained "leaf" 
nodes, so I don't think there will be a strong performance concern here from 
using it. However, there's no strong requirement that I continue to use it (I 
just thought it was a bit cleaner), so I could also replace it with the 
streaming functionality I use elsewhere.



Comment at: lib/AST/ASTDumper.cpp:231
+
+  if (ADOF_JSON == Format) {
+JSONDumper P(OS, SM, Ctx.getPrintingPolicy());

riccibruno wrote:
> (Ah, Yoda conditionals ! (I am not saying to change it))
> 
> Do you plan to do the same modification to the others `dump` methods ?
Yes, I do (though probably not all of them, like `dumpColor()`)


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

https://reviews.llvm.org/D60910



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

[PATCH] D60934: [clang] adding explicit(bool) from c++2a

[Gauthier via Phabricator via cfe-commits]

Tyker marked 2 inline comments as done.
Tyker added inline comments.



Comment at: clang/lib/Sema/DeclSpec.cpp:959
+  // Each decl-specifier shall appear at most once in a complete
+  // decl-specifier-seq, except that long may appear twice.
+  if (hasExplicitSpecifier()) {

Quuxplusone wrote:
> Spelling/grammar/capitalization-of-C++2a.
> Also, it seems to me that you've got a CWG wording issue here: what does 
> N4810 mean by "Each //decl-specifier// shall appear at most once in a 
> complete //decl-specifier-seq//, except that `long` may appear twice"? What 
> is "each" decl-specifier? Is `explicit(true)` a different decl-specifier from 
> `explicit(1+1==2)`? Is `explicit(true)` different from `explicit(false)`?
I agree that it isn't clear. but i assumed that each counts every 
explicit-specifier as one.



Comment at: clang/test/SemaCXX/explicit.cpp:189
+
+#if __cplusplus < 201707L
   void testNew()

Quuxplusone wrote:
> Why?
i added a run line with the -std=c++2a flag to ensure no regression in c++2a 
mode as well as in c++11 mode. the warning that is being tested doesn't appear 
with this flag. the #if is to prevent the test from failling with the -stdc++2a 
flag. i don't know if the flag's behavior is intended or not.
[[ https://godbolt.org/z/df_rvX | godbolt example ]]



Repository:
  rC Clang

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

https://reviews.llvm.org/D60934



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

[PATCH] D60934: [clang] adding explicit(bool) from c++2a

[Gauthier via Phabricator via cfe-commits]

Tyker updated this revision to Diff 195973.

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

https://reviews.llvm.org/D60934

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Overload.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/PCH/cxx-explicit-spec.cpp
  clang/test/SemaCXX/cxx2a-explicit-bool.cpp
  clang/test/SemaCXX/explicit.cpp

Index: clang/test/SemaCXX/explicit.cpp
===
--- clang/test/SemaCXX/explicit.cpp
+++ clang/test/SemaCXX/explicit.cpp
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2a %s
+
 namespace Constructor {
 struct A {
   A(int);
@@ -183,7 +185,8 @@
 const int ©List7 = {b};
 const int ©List8 = {n}; // expected-error {{no viable conversion}}
   }
-  
+
+#if __cplusplus < 201707L
   void testNew()
   {
 // 5.3.4p6:
@@ -200,7 +203,8 @@
 new int[i];
 new int[ni]; // expected-error {{array size expression of type 'NotInt' requires explicit conversion to type 'int'}}
   }
-  
+#endif
+
   void testDelete()
   {
 // 5.3.5pp2:
Index: clang/test/SemaCXX/cxx2a-explicit-bool.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2a-explicit-bool.cpp
@@ -0,0 +1,335 @@
+// RUN: %clang_cc1 -std=c++2a -fsyntax-only %s -verify
+
+template
+struct enable_ifv {};
+
+template
+struct enable_ifv {
+  static constexpr auto value = val;
+};
+
+template
+struct is_same {
+static constexpr bool value = false;
+};
+
+template
+struct is_same {
+static constexpr bool value = true;
+};
+
+namespace test0
+{
+
+template
+struct A {
+  explicit(1 << a)
+  //expected-error@-1 {{argument to explicit specifier is not a valid constant expression}}
+  //expected-note@-2 {{negative shift count -1}}
+  A(int);
+};
+
+A<-1> a(0); //expected-note {{in instantiation of template class}}
+
+template
+struct B {
+  explicit(b)
+  // expected-error@-1 {{use of undeclared identifier}}
+  // expected-note@-2 {{this expression is parsed as explicit(bool) since c++2a}}
+  B(int);
+};
+
+}
+
+namespace test1 {
+
+template
+struct A {
+  // expected-note@-1 {{candidate constructor}}
+  // expected-note@-2 {{candidate constructor}}
+  // expected-note@-3 {{candidate function}} expected-note@-3 {{candidate function}}
+  // expected-note@-4 {{candidate function}} expected-note@-4 {{candidate function}}
+  explicit(b) A(int, int = 0);
+  // expected-note@-1 {{explicit constructor declared here}}
+  // expected-note@-2 {{explicit constructor declared here}}
+  // expected-note@-3 {{explicit constructor declared here}}
+};
+
+template
+A::A(int, int) {}
+
+void f()
+{
+  A a0 = 0; // expected-error {{no viable conversion}}
+  A a1( 0);
+  A && a2 = 0;// expected-error {{could not bind}}
+  A && a3( 0);// expected-error {{could not bind}}
+  A a4{ 0};
+  A && a5 = { 0};// expected-error {{chosen constructor is explicit}}
+  A && a6{ 0};
+  A a7 = { 0}; // expected-error {{chosen constructor is explicit in copy-initialization}}
+
+  a0 = 0;
+  a1 = { 0}; // expected-error {{no viable overloaded '='}}
+  a2 = A( 0);
+  a3 = A{ 0};
+
+  A c0 =  ((short)0);
+  A c1( ((short)0));
+  A && c2 =  ((short)0);
+  A && c3( ((short)0));
+  A c4{ ((short)0)};
+  A && c5 = { ((short)0)};
+  A && c6{ ((short)0)};
+
+  A d1( 0, 0);
+  A d2{ 0, 0};
+  A d3 = { 0, 0}; // expected-error {{chosen constructor is explicit in copy-initialization}}
+
+  d1 = { 0, 0}; // expected-error {{no viable overloaded '='}}
+  d2 = A( 0, 0);
+  d3 = A{ 0, 0};
+}
+}
+
+namespace test2 {
+
+template
+struct A {
+// expected-note@-1 {{candidate constructor}} expected-note@-1 {{candidate constructor}}
+// expected-note@-2 {{candidate constructor}} expected-note@-2 {{candidate constructor}}
+  template
+  explicit(a ^ is_same::value)
+// expected-note@-1 {{explicit(bool) specifier resolved to true}} expected-note@-1 {{explicit(bool) specifier resolved to true}}
+  

[PATCH] D60910: [WIP] Dumping the AST to JSON

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

In D60910#1473484 , @aaron.ballman 
wrote:

> In D60910#1473441 , @riccibruno 
> wrote:
>
> > A few comments/questions:
> >
> > 1. How stable is the format going to be, and how much state is going to be 
> > exposed ?
>
>
> I don't expect it to be particularly stable (I'm not suggesting we conform to 
> some particular schema) and for my own needs, I'm happy enough if new Clang 
> releases break us due to new, deleted, or renamed information. I need to 
> expose as much state as required for our research team to import the data and 
> reason about the AST; I'd guess it's going to be roughly the same as the 
> textual dumper, but different in spots.


I am fine with that.

> 
> 
>> 2. I am wondering if it would be possible to separate the logic about how to 
>> visit a given AST node, from the logic about what to do with the node's 
>> state. For example it seems to me that `JSONNodeDumper::VisitVarDecl` and 
>> `TextNodeDumper::VisitVarDecl` are somewhat similar. You could instead 
>> imagine having a generic way to visit each node, which would then inform 
>> `JSONNodeDumper` or `TextNodeDumper` about the various bits of state in the 
>> node. With the proposed implementation essentially all of the logic for what 
>> is in each node has to be duplicated. This is not an objection about the 
>> current patch, just something I am wondering about.
> 
> This was something I had been pondering when we were doing the great AST dump 
> refactoring earlier this year, but I didn't think we could get it to be 
> sufficiently general to suit various purposes. On the one hand, there's 
> definitely a ton of overlap between any two "dump the AST in this format" 
> approaches, but on the other hand, different approaches have different 
> requirements that may change what data is displayed. For instance, the 
> textual dump will likely write out more information than the JSON dump 
> because the textual dump is purely for human readability (so having extra 
> information near the node may be critical) whereas the JSON dump is for 
> machine readability (so having extra information may or may not be 
> prohibitive, but hooking up disparate data within the file may be trivial).

I see, thanks for the explanation.

Someone who is actually going to use the JSON output should probably comment on 
this patch, but as far as I am concerned I have no objection or additional 
comment. This is a self-contained feature which is not going to impact anyone 
else.


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

https://reviews.llvm.org/D60910



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

[PATCH] D60937: [clangd] Fix code completion of macros defined in the preamble region of the main file.

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: ilya-biryukov.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay, 
ioeric.
Herald added a project: clang.

This is a tricky case (we baked the assumption that symbols come from
the preamble xor mainfile pretty deeply) and the fix is a bit of a hack:
We look at the code to guess the macro names, and deserialize them from
the preamble "by hand".


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D60937

Files:
  clangd/CodeComplete.cpp
  clangd/index/SymbolCollector.cpp
  unittests/clangd/CodeCompleteTests.cpp

Index: unittests/clangd/CodeCompleteTests.cpp
===
--- unittests/clangd/CodeCompleteTests.cpp
+++ unittests/clangd/CodeCompleteTests.cpp
@@ -2069,19 +2069,28 @@
   UnorderedElementsAre(Named("Clangd_Macro_Test")));
 }
 
-TEST(CompletionTest, NoMacroFromPreambleIfIndexIsSet) {
+TEST(CompletionTest, MacroFromPreamble) {
+  MockFSProvider FS;
+  MockCompilationDatabase CDB;
+  std::string FooHeader = testPath("foo.h");
+  FS.Files[FooHeader] = "#define CLANGD_PREAMBLE_HEADER x\n";
+  IgnoreDiagnostics DiagConsumer;
+  ClangdServer Server(CDB, FS, DiagConsumer, ClangdServer::optsForTest());
   auto Results = completions(
-  R"cpp(#define CLANGD_PREAMBLE x
+  R"cpp(#include "foo.h"
+  define CLANGD_PREAMBLE_MAIN x
 
   int x = 0;
   #define CLANGD_MAIN x
   void f() { CLANGD_^ }
   )cpp",
   {func("CLANGD_INDEX")});
-  // Index is overriden in code completion options, so the preamble symbol is
-  // not seen.
-  EXPECT_THAT(Results.Completions, UnorderedElementsAre(Named("CLANGD_MAIN"),
-Named("CLANGD_INDEX")));
+  // We should get results from the main file, including the preamble section.
+  // However no results from included files (the index should cover them).
+  EXPECT_THAT(Results.Completions,
+  UnorderedElementsAre(Named("CLANGD_PREAMBLE_MAIN"),
+   Named("CLANGD_MAIN"),
+   Named("CLANGD_INDEX")));
 }
 
 TEST(CompletionTest, DeprecatedResults) {
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -24,6 +24,7 @@
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Specifiers.h"
 #include "clang/Index/IndexSymbol.h"
+#include "clang/Index/IndexingAction.h"
 #include "clang/Index/USRGeneration.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/Support/Casting.h"
Index: clangd/CodeComplete.cpp
===
--- clangd/CodeComplete.cpp
+++ clangd/CodeComplete.cpp
@@ -44,6 +44,8 @@
 #include "clang/Format/Format.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendActions.h"
+#include "clang/Lex/ExternalPreprocessorSource.h"
+#include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "clang/Sema/CodeCompleteConsumer.h"
 #include "clang/Sema/DeclSpec.h"
@@ -1019,6 +1021,44 @@
   llvm::IntrusiveRefCntPtr VFS;
 };
 
+void loadMainFilePreambleMacros(const Preprocessor &PP,
+llvm::StringRef PreambleText) {
+  // The ExternalPreprocessorSource has our macros, if we know where to look.
+  // We can read all the macros using PreambleMacros->ReadDefinedMacros(),
+  // but this includes transitively included files, so may deserialize a lot.
+  ExternalPreprocessorSource *PreambleMacros = PP.getExternalSource();
+  // If we have the names of the macros, we can look up their IdentifierInfo
+  // and then use this to load just the macros we want.
+  IdentifierInfoLookup *PreambleIdentifiers =
+  PP.getIdentifierTable().getExternalIdentifierLookup();
+  if (!PreambleIdentifiers || !PreambleMacros)
+return;
+  auto Probe = [&](llvm::StringRef MacroName) {
+if (auto *II = PreambleIdentifiers->get(MacroName))
+  PreambleMacros->updateOutOfDateIdentifier(*II);
+  };
+
+  // We get the identifiers by lexing the preamble text for #define lines.
+  // This may contain false positives (e.g. #if'ed out), it doesn't matter.
+  // This doesn't handle pathological input (e.g line continuation before name).
+  llvm::StringRef Line;
+  while (!PreambleText.empty()) {
+std::tie(Line, PreambleText) = PreambleText.split('\n');
+Line = Line.ltrim();
+if (!Line.consume_front("#"))
+  continue;
+Line = Line.ltrim();
+if (!Line.consume_front("define"))
+  continue;
+Line = Line.ltrim();
+if (Line.empty() || !isIdentifierHead(Line.front()))
+  continue;
+llvm::StringRef MacroName =
+Line.take_while([&](char C) { return isIdentifierBody(C); });
+Probe(MacroName);
+  }
+}
+
 // Invokes Sema code completion on a file.
 // If \p Inc

Re: r358665 - [clang][CIndex] Use llvm::set_thread_priority

[Nico Weber via cfe-commits]

This breaks building with LLVM_ENABLE_THREADS=OFF. The call probably needs
to be behind a `#if LLVM_ENABLE_THREADS`.

FAILED: bin/c-index-test
...
lib/libclang.a(CIndex.cpp.o): In function `void llvm::function_ref::callback_fn(long)':
CIndex.cpp:(.text._ZN4llvm12function_refIFvvEE11callback_fnIZ25clang_saveTranslationUnitEUlvE_EEvl+0x5a):
undefined reference to `llvm::set_thread_priority(llvm::ThreadPriority)'
lib/libclang.a(CIndex.cpp.o): In function
`clang::setThreadBackgroundPriority()':
CIndex.cpp:(.text._ZN5clang27setThreadBackgroundPriorityEv+0x27): undefined
reference to `llvm::set_thread_priority(llvm::ThreadPriority)'
lib/libclang.a(CIndex.cpp.o): In function `clang_saveTranslationUnit':
CIndex.cpp:(.text.clang_saveTranslationUnit+0x316): undefined reference to
`llvm::set_thread_priority(llvm::ThreadPriority)'


On Thu, Apr 18, 2019 at 9:47 AM Kadir Cetinkaya via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: kadircet
> Date: Thu Apr 18 06:49:20 2019
> New Revision: 358665
>
> URL: http://llvm.org/viewvc/llvm-project?rev=358665&view=rev
> Log:
> [clang][CIndex] Use llvm::set_thread_priority
>
> Reviewers: jkorous, gribozavr
>
> Subscribers: dexonsmith, arphaman, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D60867
>
> Modified:
> cfe/trunk/tools/libclang/CIndex.cpp
>
> Modified: cfe/trunk/tools/libclang/CIndex.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=358665&r1=358664&r2=358665&view=diff
>
> ==
> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
> +++ cfe/trunk/tools/libclang/CIndex.cpp Thu Apr 18 06:49:20 2019
> @@ -8723,9 +8723,7 @@ void clang::setThreadBackgroundPriority(
>if (getenv("LIBCLANG_BGPRIO_DISABLE"))
>  return;
>
> -#ifdef USE_DARWIN_THREADS
> -  setpriority(PRIO_DARWIN_THREAD, 0, PRIO_DARWIN_BG);
> -#endif
> +  llvm::set_thread_priority(llvm::ThreadPriority::Background);
>  }
>
>  void cxindex::printDiagsToStderr(ASTUnit *Unit) {
>
>
> ___
> 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

[PATCH] D29707: Fix improper microsoft-pure-definition warning on template class

[Jack Adrian Zappa via Phabricator via cfe-commits]

adrianh.bsc added a comment.

Just wondering if this will be fixed soon. It's kinda annoying.


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

https://reviews.llvm.org/D29707



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