[clang] 1aaba40 - [C++] [Modules] Add a test case for mocking implementation for std modules

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2022-09-23T15:20:46+08:00
New Revision: 1aaba40dcbe8fdc93d825d1f4e22edaa3e9aa5b1

URL: 
https://github.com/llvm/llvm-project/commit/1aaba40dcbe8fdc93d825d1f4e22edaa3e9aa5b1
DIFF: 
https://github.com/llvm/llvm-project/commit/1aaba40dcbe8fdc93d825d1f4e22edaa3e9aa5b1.diff

LOG: [C++] [Modules] Add a test case for mocking implementation for std modules

I found this with the patch: https://reviews.llvm.org/D131858. It breaks
my local implementation but not the in-tree test cases. So I reduce the
failure and submit the test case. The more testing should be always
good.

Added: 
clang/test/Modules/pair-unambiguous-ctor.cppm

Modified: 


Removed: 




diff  --git a/clang/test/Modules/pair-unambiguous-ctor.cppm 
b/clang/test/Modules/pair-unambiguous-ctor.cppm
new file mode 100644
index 0..8022f34f3aafa
--- /dev/null
+++ b/clang/test/Modules/pair-unambiguous-ctor.cppm
@@ -0,0 +1,265 @@
+// Test case reduced from an experimental std modules implementation.
+// Tests that the compiler don't emit confusing error about the ambiguous ctor
+// about std::pair.
+//
+// RUN: rm -fr %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/string.cppm -I%t -emit-module-interface -o 
%t/std-string.pcm
+// RUN: %clang_cc1 -std=c++20 %t/algorithm.cppm -I%t -emit-module-interface -o 
%t/std-algorithm.pcm
+// RUN: %clang_cc1 -std=c++20 %t/Use.cppm -I%t -fprebuilt-module-path=%t 
-emit-module-interface -verify -o %t/Use.pcm
+
+//--- Use.cppm
+// expected-no-diagnostics
+module;
+#include "config.h"
+export module std:M;
+import :string;
+import :algorithm;
+
+auto check() {
+return std::string();
+}
+
+//--- string.cppm
+module;
+#include "string.h"
+export module std:string;
+export namespace std {
+using std::string;
+}
+
+//--- algorithm.cppm
+module;
+#include "algorithm.h"
+export module std:algorithm;
+
+//--- pair.h
+namespace std __attribute__ ((__visibility__ ("default")))
+{ 
+  typedef long unsigned int size_t;
+  typedef long int ptr
diff _t;
+
+  typedef decltype(nullptr) nullptr_t;
+
+  template
+struct integral_constant
+{
+  static constexpr _Tp value = __v;
+  typedef _Tp value_type;
+  typedef integral_constant<_Tp, __v> type;
+  constexpr operator value_type() const noexcept { return value; }
+  constexpr value_type operator()() const noexcept { return value; }
+};
+
+  template
+constexpr _Tp integral_constant<_Tp, __v>::value;
+
+  typedef integral_constant true_type;
+  typedef integral_constant false_type;
+
+  template
+using __bool_constant = integral_constant;
+
+
+  template
+struct conditional;
+
+  template
+struct conditional
+{ typedef _Iftrue type; };
+
+  template
+struct conditional
+{ typedef _Iffalse type; };
+
+
+  template
+struct enable_if
+{ };
+
+
+  template
+struct enable_if
+{ typedef _Tp type; };
+
+  template
+struct __is_constructible_impl
+: public __bool_constant<__is_constructible(_Tp, _Args...)>
+{ };
+
+
+  template
+struct is_constructible
+  : public __is_constructible_impl<_Tp, _Args...>
+{};
+
+  template
+struct __is_void_helper
+: public false_type { };
+
+  template<>
+struct __is_void_helper
+: public true_type { };
+
+  template
+struct is_void
+: public __is_void_helper<_Tp>::type
+{ };
+
+  template
+class tuple;
+
+  template
+struct _Index_tuple;
+
+  template 
+struct _PCC
+{
+  template 
+  static constexpr bool _ConstructiblePair()
+  {
+ return is_constructible<_T1, const _U1&>::value;
+  }
+
+  };
+
+  template
+struct pair
+{
+  typedef _T1 first_type;
+  typedef _T2 second_type;
+
+  _T1 first;
+  _T2 second;
+
+  using _PCCP = _PCC;
+
+  template(),
+ bool>::type=true>
+  constexpr pair(const _T1& __a, const _T2& __b)
+  : first(__a), second(__b) { }
+
+  constexpr pair&
+  operator=(typename conditional<
+ is_constructible<_T2>::value,
+  const pair&, nullptr_t>::type __p)
+  {
+ first = __p.first;
+ second = __p.second;
+ return *this;
+  }
+
+private:
+  template
+  constexpr
+  pair(tuple<_Args1...>&, tuple<_Args2...>&,
+   _Index_tuple<_Indexes1...>, _Index_tuple<_Indexes2...>);
+
+};
+
+  template pair(_T1, _T2) -> pair<_T1, _T2>;
+}
+
+//--- string.h
+#include "pair.h"
+
+namespace std __attribute__ ((__visibility__ ("default")))
+{
+  class __undefined;
+
+  template
+using __make_not_void
+  = typename conditional::value, __undefined, _Tp>::type;
+
+  template 
+  struct pointer_traits {};
+  
+  template
+struct pointer_traits<_Tp*>
+{
+
+  typedef _Tp* pointer;
+
+  typedef _Tp element_type;
+
+  static constexpr pointer
+  pointer_to(__make_not_void& __r) noexcept
+  { return _

[PATCH] D131858: [clang] Track the templated entity in type substitution.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/lib/Serialization/ASTWriterDecl.cpp:623-626
+  VisitDeclaratorDecl(D);
+  Record.AddDeclarationNameLoc(D->DNLoc, D->getDeclName());
+  Record.push_back(D->getIdentifierNamespace());
+

ChuanqiXu wrote:
> mizvekov wrote:
> > ChuanqiXu wrote:
> > > mizvekov wrote:
> > > > ChuanqiXu wrote:
> > > > > mizvekov wrote:
> > > > > > ChuanqiXu wrote:
> > > > > > > ChuanqiXu wrote:
> > > > > > > > ChuanqiXu wrote:
> > > > > > > > > mizvekov wrote:
> > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > I still don't get the reason for the move. What's the 
> > > > > > > > > > > benefit? Or why is it necessary?
> > > > > > > > > > Yeah, now the type can reference the template decl, so 
> > > > > > > > > > without moving this, it can happen during import of the 
> > > > > > > > > > type that we try to read this function template bits 
> > > > > > > > > > without having imported them yet.
> > > > > > > > > Oh, I guess I met the problem before (D129748 ) and I made a 
> > > > > > > > > workaround for it (https://reviews.llvm.org/D130331). If I 
> > > > > > > > > understood right, the patch will solve that problem. I'll 
> > > > > > > > > check it out later.
> > > > > > > > > 
> > > > > > > > > (This kind of code move looks dangerous you know and I'll 
> > > > > > > > > take a double check)
> > > > > > > > After looking into the detailed change for the serialization 
> > > > > > > > part, I feel it is a not-so-good workaround indeed.. It looks 
> > > > > > > > like we need a better method to delay reading the type in the 
> > > > > > > > serializer. And I'm looking at it. @mizvekov would you like to 
> > > > > > > > rebase the series of patches to the main branch so that I can 
> > > > > > > > test it actually.
> > > > > > > Or would it be simpler to rebase and squash them into a draft 
> > > > > > > revision?
> > > > > > I had given this some thought, and it made sense to me that we 
> > > > > > should deal with the template bits first, since these are closer to 
> > > > > > the introducer for these declarations, and so that it would be 
> > > > > > harder to have a dependence the other way around.
> > > > > > 
> > > > > > But I would like to hear your thoughts on this after you have taken 
> > > > > > a better look.
> > > > > > I am working on a bunch of things right now, I should be able to 
> > > > > > rebase this on the next few days, but otherwise
> > > > > > I last rebased about 4 days ago, so you can also check that out at 
> > > > > > https://github.com/mizvekov/llvm-project/tree/resugar
> > > > > > That link has the whole stack, you probably should check out just 
> > > > > > the commit for this patch, as you are probably going to encounter 
> > > > > > issues with the resugarer if you try it on substantial code bases.
> > > > > > It will carry other changes with it, but I think those should be 
> > > > > > safe.
> > > > > I won't say it is bad to deal with template bits first. I just feel 
> > > > > it is a workaround to avoid the circular dependent problem in 
> > > > > deserialization. Or in another word, here the method works due to you 
> > > > > put some decls* in the template parameter types. And we avoid the 
> > > > > circular dependent problem by adjusting the order we deserializes. 
> > > > > The reasons why I don't feel it is good include:
> > > > > (1) Although we touched template function decl and template var decl, 
> > > > > we don't touched template var decl. I guess it'll be a problem now or 
> > > > > later.
> > > > > (2) The solution here can't solve the similar circular dependent 
> > > > > problem I sawed in attributes. So the method only workarounds some 
> > > > > resulting of the same problem.
> > > > > 
> > > > > Or in one shorter explanation, it should be greater to solve the root 
> > > > > problems. I have an idea and I am going to to do a proof-of-concept 
> > > > > implementation first since I feel like nobody are happy about an 
> > > > > unimplementable idea. Generally I don't like to block patches due to 
> > > > > such reasons since it is completely not your fault but I guess it may 
> > > > > be better to wait some time. Since if we want to allow workarounds 
> > > > > first and clear the workarounds, things will be harder. If you want a 
> > > > > timeline, I guess 2 months may be reasonable choices. I mean if I 
> > > > > can't make it in 2 months and other reviewers feel this is good (what 
> > > > > I am seeing), I feel bad to block this. (But if we're more patient, 
> > > > > it'll be better). How do you think about this?
> > > > Well we touch FunctionTemplates and VariableTemplates in this patch, 
> > > > because they were not doing template first.
> > > > For whatever reason, class templates were already doing template first, 
> > > > so no need to fix that.
> > > > 
> > > > So this patch at least puts that into consistency.
> > > > 
> > > > Also, this patch is a pre-requisite for t

[PATCH] D134379: [clangd] IncludeCleaner: handle using namespace

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX added a comment.

In D134379#3808043 , @kadircet wrote:

> In D134379#3807770 , @ArcsinX wrote:
>
>> Anyway if this is the only concern, we can handle namespace declaration as a 
>> special case inside `ReferencedLocationCrawler::add()`. something like this:
>>
>>   diff
>>   -for (const Decl *Redecl : D->redecls())
>>   -  Result.User.insert(Redecl->getLocation());
>>   +if (llvm::isa(D)) {
>>   +  Result.User.insert(D->getCanonicalDecl()->getLocation());
>>   +} else {
>>   +  for (const Decl *Redecl : D->redecls())
>>   +Result.User.insert(Redecl->getLocation());
>>   +}
>>
>> And in the above example `#include bar.h` will be suggested to remove
>>
>> Could this be a suitable solution?
>
> I don't think picking the canonical declaration would be helpful in general 
> case; it'll likely preserve the first header all the time, which might be 
> unused otherwise.
>
> I feel like the best option here is, diagnosing the unused using directive as 
> well. but I am not sure if changing the lookup semantics would always be 
> "right".

Diagnosing the unused using directive is a good option, but it's not related 
with `IncludeCleaner`. For now `IncludeCleaner` suggests to remove a header, 
but removing it leads to compile errors, which looks wrong.

> The other option would be to consider headers in batches after full analysis 
> is complete, while keeping track of symbols provided by a particular header.
> That way when we have a symbol that's only re-declared in a bunch of headers, 
> we can rank them based on other symbols being provided and only keep the 
> headers that are providing some extra "used" symbols in addition to redecls.
> In the absence of such we get to pick an option between "all/none/forward 
> declare ourselves". I guess picking "all" in this case is less troublesome, 
> the user will get all the "unused include" warnings as soon as they use a 
> symbol from that namespace.

This looks like a general problem, declaration of a used function in every 
header leads to "every header is used", maybe it's ok as far as it's not a 
common case.

So, yes, with the proposed solution we will get rid of some "false positive" 
cases, but we will get some "false negative" cases.
But IWYU handles this 
https://github.com/include-what-you-use/include-what-you-use/commit/97e236c55e5ebbd95b8bb221fd9497851f67c3cc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134379

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

[clang] 3dab7fe - [CMake] Add clang-bolt target

[Amir Ayupov via cfe-commits]

Author: Amir Ayupov
Date: 2022-09-23T10:10:31+02:00
New Revision: 3dab7fede2019c399d793c43ca9ea5a4f2d5031f

URL: 
https://github.com/llvm/llvm-project/commit/3dab7fede2019c399d793c43ca9ea5a4f2d5031f
DIFF: 
https://github.com/llvm/llvm-project/commit/3dab7fede2019c399d793c43ca9ea5a4f2d5031f.diff

LOG: [CMake] Add clang-bolt target

This patch adds `CLANG_BOLT_INSTRUMENT` option that applies BOLT instrumentation
to Clang, performs a bootstrap build with the resulting Clang, merges resulting
fdata files into a single profile file, and uses it to perform BOLT optimization
on the original Clang binary.

The projects and targets used for bootstrap/profile collection are configurable 
via
`CLANG_BOLT_INSTRUMENT_PROJECTS` and `CLANG_BOLT_INSTRUMENT_TARGETS`.
The defaults are "llvm" and "count" respectively, which results in a profile 
with
~5.3B dynamically executed instructions.

The intended use of the functionality is through BOLT CMake cache file, similar
to PGO 2-stage build:
```
cmake /llvm -C /clang/cmake/caches/BOLT.cmake
ninja clang++-bolt # pulls clang-bolt
```

Stats with a recent checkout (clang-16), pre-built BOLT and Clang, 72vCPU/224G
| CMake configure with host Clang + BOLT.cmake | 1m6.592s
| Instrumenting Clang with BOLT | 2m50.508s
| CMake configure `llvm` with instrumented Clang | 5m46.364s (~5x slowdown)
| CMake build `not` with instrumented Clang |0m6.456s
| Merging fdata files | 0m9.439s
| Optimizing Clang with BOLT | 0m39.201s

Building Clang:
```cmake ../llvm-project/llvm -DCMAKE_C_COMPILER=... -DCMAKE_CXX_COMPILER=...
  -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
  -DLLVM_TARGETS_TO_BUILD=Native -GNinja```

| | Release | BOLT-optimized
| cmake | 0m24.016s | 0m22.333s
| ninja clang | 5m55.692s | 4m35.122s

I know it's not rigorous, but shows a ballpark figure.

Reviewed By: phosek

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

Added: 
clang/cmake/caches/BOLT.cmake

Modified: 
clang/CMakeLists.txt
clang/utils/perf-training/perf-helper.py

Removed: 




diff  --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 02ce5de4652de..22b5118c83eda 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -443,7 +443,7 @@ CMAKE_DEPENDENT_OPTION(CLANG_PLUGIN_SUPPORT
   "HAVE_CLANG_PLUGIN_SUPPORT" OFF)
 
 # If libstdc++ is statically linked, clang-repl needs to statically link 
libstdc++
-# itself, which is not possible in many platforms because of current 
limitations in 
+# itself, which is not possible in many platforms because of current 
limitations in
 # JIT stack. (more platforms need to be supported by JITLink)
 if(NOT LLVM_STATIC_LINK_CXX_STDLIB)
   set(HAVE_CLANG_REPL_SUPPORT ON)
@@ -881,6 +881,118 @@ if (CLANG_ENABLE_BOOTSTRAP)
   endforeach()
 endif()
 
+if (CLANG_BOLT_INSTRUMENT)
+  set(CLANG_PATH ${LLVM_RUNTIME_OUTPUT_INTDIR}/clang)
+  set(CLANGXX_PATH ${CLANG_PATH}++)
+  set(CLANG_INSTRUMENTED ${CLANG_PATH}-bolt.inst)
+  set(CLANGXX_INSTRUMENTED ${CLANGXX_PATH}-bolt.inst)
+  set(CLANG_OPTIMIZED ${CLANG_PATH}-bolt)
+  set(CLANGXX_OPTIMIZED ${CLANGXX_PATH}-bolt)
+
+  # Instrument clang with BOLT
+  add_custom_target(clang-instrumented
+DEPENDS ${CLANG_INSTRUMENTED}
+  )
+  add_custom_command(OUTPUT ${CLANG_INSTRUMENTED}
+DEPENDS clang llvm-bolt
+COMMAND llvm-bolt ${CLANG_PATH} -o ${CLANG_INSTRUMENTED}
+  -instrument --instrumentation-file-append-pid
+  --instrumentation-file=${CMAKE_CURRENT_BINARY_DIR}/prof.fdata
+COMMENT "Instrumenting clang binary with BOLT"
+VERBATIM
+  )
+
+  # Make a symlink from clang-bolt.inst to clang++-bolt.inst
+  add_custom_target(clang++-instrumented
+DEPENDS ${CLANGXX_INSTRUMENTED}
+  )
+  add_custom_command(OUTPUT ${CLANGXX_INSTRUMENTED}
+DEPENDS clang-instrumented
+COMMAND ${CMAKE_COMMAND} -E create_symlink
+  ${CLANG_INSTRUMENTED}
+  ${CLANGXX_INSTRUMENTED}
+COMMENT "Creating symlink from BOLT instrumented clang to clang++"
+VERBATIM
+  )
+
+  # Build specified targets with instrumented Clang to collect the profile
+  set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/bolt-instrumented-clang-stamps/)
+  set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/bolt-instrumented-clang-bins/)
+  set(build_configuration "$")
+  include(ExternalProject)
+  ExternalProject_Add(bolt-instrumentation-profile
+DEPENDS clang++-instrumented
+PREFIX bolt-instrumentation-profile
+SOURCE_DIR ${CMAKE_SOURCE_DIR}
+STAMP_DIR ${STAMP_DIR}
+BINARY_DIR ${BINARY_DIR}
+EXCLUDE_FROM_ALL 1
+CMAKE_ARGS
+${CLANG_BOLT_INSTRUMENT_EXTRA_CMAKE_FLAGS}
+# We shouldn't need to set this here, but INSTALL_DIR doesn't
+# seem to work, so instead I'm passing this through
+-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
+-DCMAKE_C_COMPILER=${CLANG_INSTRUMENTED}
+-DCMAKE_CXX_COMPILER=${CLANGXX_INSTRUMENTED}
+   

[PATCH] D132975: [CMake] Add clang-bolt target

[Amir Ayupov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3dab7fede201: [CMake] Add clang-bolt target (authored by 
Amir).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132975

Files:
  clang/CMakeLists.txt
  clang/cmake/caches/BOLT.cmake
  clang/utils/perf-training/perf-helper.py

Index: clang/utils/perf-training/perf-helper.py
===
--- clang/utils/perf-training/perf-helper.py
+++ clang/utils/perf-training/perf-helper.py
@@ -38,7 +38,7 @@
 
 def merge(args):
   if len(args) != 3:
-print('Usage: %s clean   \n' % __file__ +
+print('Usage: %s merge   \n' % __file__ +
   '\tMerges all profraw files from path into output.')
 return 1
   cmd = [args[0], 'merge', '-o', args[1]]
@@ -46,6 +46,16 @@
   subprocess.check_call(cmd)
   return 0
 
+def merge_fdata(args):
+  if len(args) != 3:
+print('Usage: %s merge-fdata   \n' % __file__ +
+  '\tMerges all fdata files from path into output.')
+return 1
+  cmd = [args[0], '-o', args[1]]
+  cmd.extend(findFilesWithExtension(args[2], "fdata"))
+  subprocess.check_call(cmd)
+  return 0
+
 def dtrace(args):
   parser = argparse.ArgumentParser(prog='perf-helper dtrace',
 description='dtrace wrapper for order file generation')
@@ -395,10 +405,12 @@
   return 0
 
 commands = {'clean' : clean,
-  'merge' : merge, 
+  'merge' : merge,
   'dtrace' : dtrace,
   'cc1' : cc1,
-  'gen-order-file' : genOrderFile}
+  'gen-order-file' : genOrderFile,
+  'merge-fdata' : merge_fdata,
+  }
 
 def main():
   f = commands[sys.argv[1]]
Index: clang/cmake/caches/BOLT.cmake
===
--- /dev/null
+++ clang/cmake/caches/BOLT.cmake
@@ -0,0 +1,15 @@
+set(CMAKE_BUILD_TYPE Release CACHE STRING "")
+set(CLANG_BOLT_INSTRUMENT ON CACHE BOOL "")
+set(CLANG_BOLT_INSTRUMENT_PROJECTS "llvm" CACHE STRING "")
+set(CLANG_BOLT_INSTRUMENT_TARGETS "count" CACHE STRING "")
+set(CMAKE_EXE_LINKER_FLAGS "-Wl,--emit-relocs,-znow" CACHE STRING "")
+set(CLANG_BOLT_INSTRUMENT_EXTRA_CMAKE_FLAGS "" CACHE STRING "")
+
+set(LLVM_ENABLE_PROJECTS "bolt;clang" CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+
+# Disable function splitting enabled by default in GCC8+
+if("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
+  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-reorder-blocks-and-partition")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-reorder-blocks-and-partition")
+endif()
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -443,7 +443,7 @@
   "HAVE_CLANG_PLUGIN_SUPPORT" OFF)
 
 # If libstdc++ is statically linked, clang-repl needs to statically link libstdc++
-# itself, which is not possible in many platforms because of current limitations in 
+# itself, which is not possible in many platforms because of current limitations in
 # JIT stack. (more platforms need to be supported by JITLink)
 if(NOT LLVM_STATIC_LINK_CXX_STDLIB)
   set(HAVE_CLANG_REPL_SUPPORT ON)
@@ -881,6 +881,118 @@
   endforeach()
 endif()
 
+if (CLANG_BOLT_INSTRUMENT)
+  set(CLANG_PATH ${LLVM_RUNTIME_OUTPUT_INTDIR}/clang)
+  set(CLANGXX_PATH ${CLANG_PATH}++)
+  set(CLANG_INSTRUMENTED ${CLANG_PATH}-bolt.inst)
+  set(CLANGXX_INSTRUMENTED ${CLANGXX_PATH}-bolt.inst)
+  set(CLANG_OPTIMIZED ${CLANG_PATH}-bolt)
+  set(CLANGXX_OPTIMIZED ${CLANGXX_PATH}-bolt)
+
+  # Instrument clang with BOLT
+  add_custom_target(clang-instrumented
+DEPENDS ${CLANG_INSTRUMENTED}
+  )
+  add_custom_command(OUTPUT ${CLANG_INSTRUMENTED}
+DEPENDS clang llvm-bolt
+COMMAND llvm-bolt ${CLANG_PATH} -o ${CLANG_INSTRUMENTED}
+  -instrument --instrumentation-file-append-pid
+  --instrumentation-file=${CMAKE_CURRENT_BINARY_DIR}/prof.fdata
+COMMENT "Instrumenting clang binary with BOLT"
+VERBATIM
+  )
+
+  # Make a symlink from clang-bolt.inst to clang++-bolt.inst
+  add_custom_target(clang++-instrumented
+DEPENDS ${CLANGXX_INSTRUMENTED}
+  )
+  add_custom_command(OUTPUT ${CLANGXX_INSTRUMENTED}
+DEPENDS clang-instrumented
+COMMAND ${CMAKE_COMMAND} -E create_symlink
+  ${CLANG_INSTRUMENTED}
+  ${CLANGXX_INSTRUMENTED}
+COMMENT "Creating symlink from BOLT instrumented clang to clang++"
+VERBATIM
+  )
+
+  # Build specified targets with instrumented Clang to collect the profile
+  set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/bolt-instrumented-clang-stamps/)
+  set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/bolt-instrumented-clang-bins/)
+  set(build_configuration "$")
+  include(ExternalProject)
+  ExternalProject_Add(bolt-instrumentation-profile
+DEPENDS clang++-instrumented
+PREFIX bolt-instrumentation-profile
+SOURCE_DIR ${CMAKE_SOURCE_DIR}
+STAMP_DIR ${STAMP_DIR}
+BINARY_DIR ${BINARY_DIR}
+EXCLUDE_FROM_ALL 1
+CMAKE_ARGS
+$

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

[David Sherwood via Phabricator via cfe-commits]

david-arm added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64.td:1112
+   FeatureNEON, FeatureSVE2BitPerm, 
FeatureFP16FML,
+   FeatureMTE, FeatureRandGen];
   list Saphira= [HasV8_4aOps, FeatureCrypto, 
FeatureFPARMv8,

Matt wrote:
> Shouldn't `FeatureMTE` (Enable Memory Tagging Extension) be present, too (as 
> in NeoverseN2)?
It is already included in the patch, i.e. see above:

  FeatureMTE, FeatureRandGen];


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

https://reviews.llvm.org/D134352

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

[PATCH] D132918: [clang] Fix a crash in constant evaluation

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet closed this revision.
kadircet added a comment.

Landed as abd2b1a9d0421f99d3d132dc99af55ae52f3ac3e 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132918

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

[PATCH] D134349: [Arm][AArch64] Make getArchFeatures to use TargetParser.def

[Daniel Kiss via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7e1a87387209: [Arm][AArch64] Make getArchFeatures to use 
TargetParser.def (authored by danielkiss).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134349

Files:
  clang/test/Driver/arch.c
  clang/test/Driver/arm-cortex-cpus-1.c
  clang/test/Driver/arm-cortex-cpus-2.c
  clang/test/Driver/arm-features.c
  clang/test/Driver/arm-target-as-march-mcpu.s
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.h
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -483,7 +483,7 @@
   testARMArch("armv7e-m", "cortex-m4", "v7em",
   ARMBuildAttrs::CPUArch::v7E_M));
   EXPECT_TRUE(
-  testARMArch("armv8-a", "generic", "v8",
+  testARMArch("armv8-a", "generic", "v8a",
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(
   testARMArch("armv8.1-a", "generic", "v8.1a",
@@ -1308,7 +1308,7 @@
 }
 
 TEST(TargetParserTest, testAArch64Arch) {
-  EXPECT_TRUE(testAArch64Arch("armv8-a", "cortex-a53", "v8",
+  EXPECT_TRUE(testAArch64Arch("armv8-a", "cortex-a53", "v8a",
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv8.1-a", "generic", "v8.1a",
   ARMBuildAttrs::CPUArch::v8_A));
Index: llvm/lib/Support/AArch64TargetParser.cpp
===
--- llvm/lib/Support/AArch64TargetParser.cpp
+++ llvm/lib/Support/AArch64TargetParser.cpp
@@ -78,36 +78,11 @@
 
 bool AArch64::getArchFeatures(AArch64::ArchKind AK,
   std::vector &Features) {
-  if (AK == ArchKind::ARMV8A)
-Features.push_back("+v8a");
-  if (AK == ArchKind::ARMV8_1A)
-Features.push_back("+v8.1a");
-  if (AK == ArchKind::ARMV8_2A)
-Features.push_back("+v8.2a");
-  if (AK == ArchKind::ARMV8_3A)
-Features.push_back("+v8.3a");
-  if (AK == ArchKind::ARMV8_4A)
-Features.push_back("+v8.4a");
-  if (AK == ArchKind::ARMV8_5A)
-Features.push_back("+v8.5a");
-  if (AK == AArch64::ArchKind::ARMV8_6A)
-Features.push_back("+v8.6a");
-  if (AK == AArch64::ArchKind::ARMV8_7A)
-Features.push_back("+v8.7a");
-  if (AK == AArch64::ArchKind::ARMV8_8A)
-Features.push_back("+v8.8a");
-  if (AK == AArch64::ArchKind::ARMV9A)
-Features.push_back("+v9a");
-  if (AK == AArch64::ArchKind::ARMV9_1A)
-Features.push_back("+v9.1a");
-  if (AK == AArch64::ArchKind::ARMV9_2A)
-Features.push_back("+v9.2a");
-  if (AK == AArch64::ArchKind::ARMV9_3A)
-Features.push_back("+v9.3a");
-  if(AK == AArch64::ArchKind::ARMV8R)
-Features.push_back("+v8r");
-
-  return AK != ArchKind::INVALID;
+  if (AK == ArchKind::INVALID)
+return false;
+  Features.push_back(
+  AArch64ARCHNames[static_cast(AK)].getArchFeature());
+  return true;
 }
 
 StringRef AArch64::getArchName(AArch64::ArchKind AK) {
Index: llvm/include/llvm/Support/ARMTargetParser.h
===
--- llvm/include/llvm/Support/ARMTargetParser.h
+++ llvm/include/llvm/Support/ARMTargetParser.h
@@ -216,7 +216,14 @@
   StringRef getCPUAttr() const { return StringRef(CPUAttrCStr, CPUAttrLength); }
 
   // Sub-Arch name.
-  StringRef getSubArch() const { return StringRef(SubArchCStr, SubArchLength); }
+  StringRef getSubArch() const {
+return getArchFeature().substr(1, SubArchLength);
+  }
+
+  // Arch Feature name.
+  StringRef getArchFeature() const {
+return StringRef(SubArchCStr, SubArchLength);
+  }
 };
 
 static const ArchNames ARCHNames[] = {
@@ -224,7 +231,7 @@
  ARCH_BASE_EXT)\
   {NAME, sizeof(NAME) - 1, \
CPU_ATTR, sizeof(CPU_ATTR) - 1, \
-   SUB_ARCH, sizeof(SUB_ARCH) - 1, \
+   "+" SUB_ARCH, sizeof(SUB_ARCH), \
ARCH_FPU, ARCH_BASE_EXT,\
ArchKind::ID, ARCH_ATTR},
 #include "llvm/Support/ARMTargetParser.def"
Index: llvm/include/llvm/Support/ARMTargetParser.def
===
--- llvm/include/llvm/Support/ARMTargetParser.def
+++ llvm/include/llvm/Support/ARMTargetParser.d

[clang] 7e1a873 - [Arm][AArch64] Make getArchFeatures to use TargetParser.def

[Daniel Kiss via cfe-commits]

Author: Daniel Kiss
Date: 2022-09-23T10:25:37+02:00
New Revision: 7e1a87387209252dec5902925a232467db951db6

URL: 
https://github.com/llvm/llvm-project/commit/7e1a87387209252dec5902925a232467db951db6
DIFF: 
https://github.com/llvm/llvm-project/commit/7e1a87387209252dec5902925a232467db951db6.diff

LOG: [Arm][AArch64] Make getArchFeatures to use TargetParser.def

Prefixing the the SubArch with plus sign makes the ArchFeature name.

Reviewed By: DavidSpickett

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

Added: 


Modified: 
clang/test/Driver/arch.c
clang/test/Driver/arm-cortex-cpus-1.c
clang/test/Driver/arm-cortex-cpus-2.c
clang/test/Driver/arm-features.c
clang/test/Driver/arm-target-as-march-mcpu.s
llvm/include/llvm/Support/AArch64TargetParser.def
llvm/include/llvm/Support/AArch64TargetParser.h
llvm/include/llvm/Support/ARMTargetParser.def
llvm/include/llvm/Support/ARMTargetParser.h
llvm/lib/Support/AArch64TargetParser.cpp
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/test/Driver/arch.c b/clang/test/Driver/arch.c
index f113c1dfa5c27..09afc6a6455b7 100644
--- a/clang/test/Driver/arch.c
+++ b/clang/test/Driver/arch.c
@@ -2,4 +2,4 @@
 // RUN: %clang -target armv8a-unknown-linux-gnueabi -S -emit-llvm %s -o - | 
FileCheck %s --check-prefix=V8
 
 // V7: target triple = "armv7-unknown-linux-gnueabi"
-// V8: target triple = "armv8-unknown-linux-gnueabi"
+// V8: target triple = "armv8a-unknown-linux-gnueabi"

diff  --git a/clang/test/Driver/arm-cortex-cpus-1.c 
b/clang/test/Driver/arm-cortex-cpus-1.c
index 7b6c203b53b80..bfdf4d1515793 100644
--- a/clang/test/Driver/arm-cortex-cpus-1.c
+++ b/clang/test/Driver/arm-cortex-cpus-1.c
@@ -148,7 +148,7 @@
 // RUN: %clang -target armv8a -mlittle-endian -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V8A %s
 // RUN: %clang -target arm -march=armv8a -mlittle-endian -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-V8A %s
 // RUN: %clang -target arm -march=armv8-a -mlittle-endian -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-V8A %s
-// CHECK-V8A: "-cc1"{{.*}} "-triple" "armv8-{{.*}}" "-target-cpu" "generic"
+// CHECK-V8A: "-cc1"{{.*}} "-triple" "armv8a-{{.*}}" "-target-cpu" "generic"
 
 // RUN: %clang -target armv8r-linux-gnueabi -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V8R %s
 // RUN: %clang -target arm -march=armv8r -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V8R %s
@@ -181,7 +181,7 @@
 // RUN: %clang -mcpu=generic -target armv8a -mlittle-endian -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-V8A-GENERIC %s
 // RUN: %clang -mcpu=generic -target arm -march=armv8a -mlittle-endian -### -c 
%s 2>&1 | FileCheck -check-prefix=CHECK-V8A-GENERIC %s
 // RUN: %clang -mcpu=generic -target arm -march=armv8-a -mlittle-endian -### 
-c %s 2>&1 | FileCheck -check-prefix=CHECK-V8A-GENERIC %s
-// CHECK-V8A-GENERIC: "-cc1"{{.*}} "-triple" "armv8-{{.*}}" "-target-cpu" 
"generic"
+// CHECK-V8A-GENERIC: "-cc1"{{.*}} "-triple" "armv8a-{{.*}}" "-target-cpu" 
"generic"
 
 // RUN: %clang -target armebv8 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V8A %s
 // RUN: %clang -target armeb -march=armebv8 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V8A %s
@@ -193,7 +193,7 @@
 // RUN: %clang -target armv8a -mbig-endian -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V8A %s
 // RUN: %clang -target arm -march=armebv8a -mbig-endian -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-BE-V8A %s
 // RUN: %clang -target arm -march=armebv8-a -mbig-endian -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-BE-V8A %s
-// CHECK-BE-V8A: "-cc1"{{.*}} "-triple" "armebv8-{{.*}}" "-target-cpu" 
"generic"
+// CHECK-BE-V8A: "-cc1"{{.*}} "-triple" "armebv8a-{{.*}}" "-target-cpu" 
"generic"
 
 // RUN: %clang -target armv8 -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V8A-THUMB %s
 // RUN: %clang -target arm -march=armv8 -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V8A-THUMB %s
@@ -203,7 +203,7 @@
 // RUN: %clang -target arm -march=armv8 -mlittle-endian -mthumb -### -c %s 
2>&1 | FileCheck -check-prefix=CHECK-V8A-THUMB %s
 // RUN: %clang -target armv8a -mlittle-endian -mthumb -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-V8A-THUMB %s
 // RUN: %clang -target arm -march=armv8a -mlittle-endian -mthumb -### -c %s 
2>&1 | FileCheck -check-prefix=CHECK-V8A-THUMB %s
-// CHECK-V8A-THUMB: "-cc1"{{.*}} "-triple" "thumbv8-{{.*}}" "-target-cpu" 
"generic"
+// CHECK-V8A-THUMB: "-cc1"{{.*}} "-triple" "thumbv8a-{{.*}}" "-target-cpu" 
"generic"
 
 // RUN: %clang -target armebv8 -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-V8A-THUMB %s
 // RUN: %clang -target armeb -march=armebv8 -mthumb -### -c %s 2>&1 | 
FileCheck -check-prefix=CHECK-BE-V8A-THUMB %s
@@ -213,7 +213,7 @@
 // RUN: %clang -target arm -march=armebv8 -mbig-endian -mthumb -### -c %s 2>&1 
| FileCheck -check-prefix=CHECK-BE-V8A-THUMB %s
 // R

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

[Dave Green via Phabricator via cfe-commits]

dmgreen added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64.td:1112
+   FeatureNEON, FeatureSVE2BitPerm, 
FeatureFP16FML,
+   FeatureMTE, FeatureRandGen];
   list Saphira= [HasV8_4aOps, FeatureCrypto, 
FeatureFPARMv8,

david-arm wrote:
> Matt wrote:
> > Shouldn't `FeatureMTE` (Enable Memory Tagging Extension) be present, too 
> > (as in NeoverseN2)?
> It is already included in the patch, i.e. see above:
> 
>   FeatureMTE, FeatureRandGen];
Oh yeah so it is. Should we add AEK_MTE too then?



Comment at: llvm/unittests/Support/TargetParserTest.cpp:1033
+AArch64::AEK_RCPC | AArch64::AEK_CRC | AArch64::AEK_FP |
+AArch64::AEK_SIMD | AArch64::AEK_RAS | AArch64::AEK_LSE |
+AArch64::AEK_RDM | AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |

RAS is here twice.


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

https://reviews.llvm.org/D134352

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

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

[Thorsten via Phabricator via cfe-commits]

tschuett added inline comments.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:238
   AArch64::AEK_RAND | AArch64::AEK_FP16FML | 
AArch64::AEK_I8MM))
+AARCH64_CPU_NAME("neoverse-v2", ARMV9A, FK_NEON_FP_ARMV8, false,
+ (AArch64::AEK_SVE | AArch64::AEK_SVE2 | AArch64::AEK_SSBS |

MTE is implied by ARMV9A or missing?


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

https://reviews.llvm.org/D134352

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

[PATCH] D123808: [clang] Fix the bogus diagnostic introduced by the newly-added UsingTemplate Kind.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 462418.
hokein marked 3 inline comments as done.
hokein added a comment.

rebase and address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123808

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/temp/temp.deduct.guide/p3.cpp


Index: clang/test/CXX/temp/temp.deduct.guide/p3.cpp
===
--- clang/test/CXX/temp/temp.deduct.guide/p3.cpp
+++ clang/test/CXX/temp/temp.deduct.guide/p3.cpp
@@ -55,8 +55,6 @@
   }
   using N::NamedNS1;
   NamedNS1(int) -> NamedNS1; // expected-error {{deduction guide must be 
declared in the same scope as template}}
-  // FIXME: remove the following bogus diagnostic
-  // expected-error@-2{{deduction guide is not written as a specialization of 
template 'NamedNS1'}}
 
   using namespace N;
   NamedNS2(int) -> NamedNS2; // expected-error {{deduction guide must be 
declared in the same scope as template}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -11056,6 +11056,7 @@
 
 // Check that the return type is written as a specialization of
 // the template specified as the deduction-guide's name.
+// The template name may not be qualified. [temp.deduct.guide]
 ParsedType TrailingReturnType = Chunk.Fun.getTrailingReturnType();
 TypeSourceInfo *TSI = nullptr;
 QualType RetTy = GetTypeFromParser(TrailingReturnType, &TSI);
@@ -11067,9 +11068,13 @@
   TemplateName SpecifiedName = RetTST.getTypePtr()->getTemplateName();
   bool TemplateMatches =
   Context.hasSameTemplateName(SpecifiedName, GuidedTemplate);
-  // FIXME: We should consider other template kinds (using, qualified),
-  // otherwise we will emit bogus diagnostics.
-  if (SpecifiedName.getKind() == TemplateName::Template && TemplateMatches)
+  auto TKind = SpecifiedName.getKind();
+  // A Using TemplateName can't actually be valid (either it's qualified, 
or
+  // we're in the wrong scope). But we have diagnosed these problems
+  // already.
+  bool SimplyWritten = TKind == TemplateName::Template ||
+   TKind == TemplateName::UsingTemplate;
+  if (SimplyWritten && TemplateMatches)
 AcceptableReturnType = true;
   else {
 // This could still instantiate to the right type, unless we know it


Index: clang/test/CXX/temp/temp.deduct.guide/p3.cpp
===
--- clang/test/CXX/temp/temp.deduct.guide/p3.cpp
+++ clang/test/CXX/temp/temp.deduct.guide/p3.cpp
@@ -55,8 +55,6 @@
   }
   using N::NamedNS1;
   NamedNS1(int) -> NamedNS1; // expected-error {{deduction guide must be declared in the same scope as template}}
-  // FIXME: remove the following bogus diagnostic
-  // expected-error@-2{{deduction guide is not written as a specialization of template 'NamedNS1'}}
 
   using namespace N;
   NamedNS2(int) -> NamedNS2; // expected-error {{deduction guide must be declared in the same scope as template}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -11056,6 +11056,7 @@
 
 // Check that the return type is written as a specialization of
 // the template specified as the deduction-guide's name.
+// The template name may not be qualified. [temp.deduct.guide]
 ParsedType TrailingReturnType = Chunk.Fun.getTrailingReturnType();
 TypeSourceInfo *TSI = nullptr;
 QualType RetTy = GetTypeFromParser(TrailingReturnType, &TSI);
@@ -11067,9 +11068,13 @@
   TemplateName SpecifiedName = RetTST.getTypePtr()->getTemplateName();
   bool TemplateMatches =
   Context.hasSameTemplateName(SpecifiedName, GuidedTemplate);
-  // FIXME: We should consider other template kinds (using, qualified),
-  // otherwise we will emit bogus diagnostics.
-  if (SpecifiedName.getKind() == TemplateName::Template && TemplateMatches)
+  auto TKind = SpecifiedName.getKind();
+  // A Using TemplateName can't actually be valid (either it's qualified, or
+  // we're in the wrong scope). But we have diagnosed these problems
+  // already.
+  bool SimplyWritten = TKind == TemplateName::Template ||
+   TKind == TemplateName::UsingTemplate;
+  if (SimplyWritten && TemplateMatches)
 AcceptableReturnType = true;
   else {
 // This could still instantiate to the right type, unless we know it
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

[David Sherwood via Phabricator via cfe-commits]

david-arm updated this revision to Diff 462420.
david-arm added a comment.

- Added AEK_MTE to target parser flags.


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

https://reviews.llvm.org/D134352

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/Driver/aarch64-mcpu.c
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Support/Host.cpp
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/test/CodeGen/AArch64/cpus.ll
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1026,6 +1026,16 @@
 AArch64::AEK_PROFILE | AArch64::AEK_RAND |
 AArch64::AEK_FP16FML | AArch64::AEK_I8MM,
 "8.4-A"),
+ARMCPUTestParams(
+"neoverse-v2", "armv9-a", "neon-fp-armv8",
+AArch64::AEK_RAS | AArch64::AEK_SVE | AArch64::AEK_SSBS |
+AArch64::AEK_RCPC | AArch64::AEK_CRC | AArch64::AEK_FP |
+AArch64::AEK_SIMD | AArch64::AEK_MTE | AArch64::AEK_LSE |
+AArch64::AEK_RDM | AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+AArch64::AEK_FP16 | AArch64::AEK_BF16 | AArch64::AEK_SVE2 |
+AArch64::AEK_PROFILE | AArch64::AEK_FP16FML |
+AArch64::AEK_I8MM | AArch64::AEK_RAND,
+"9-A"),
 ARMCPUTestParams("cortex-r82", "armv8-r", "crypto-neon-fp-armv8",
  AArch64::AEK_CRC | AArch64::AEK_RDM |
  AArch64::AEK_SSBS | AArch64::AEK_DOTPROD |
@@ -1257,7 +1267,7 @@
  AArch64::AEK_LSE | AArch64::AEK_RDM,
  "8.2-A")));
 
-static constexpr unsigned NumAArch64CPUArchs = 54;
+static constexpr unsigned NumAArch64CPUArchs = 55;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/test/CodeGen/AArch64/cpus.ll
===
--- llvm/test/CodeGen/AArch64/cpus.ll
+++ llvm/test/CodeGen/AArch64/cpus.ll
@@ -23,6 +23,7 @@
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=neoverse-n2 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=neoverse-512tvb 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=neoverse-v1 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=neoverse-v2 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=exynos-m3 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=exynos-m4 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=exynos-m5 2>&1 | FileCheck %s
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.h
+++ llvm/lib/Target/AArch64/AArch64Subtarget.h
@@ -74,6 +74,7 @@
 NeoverseN2,
 Neoverse512TVB,
 NeoverseV1,
+NeoverseV2,
 Saphira,
 ThunderX2T99,
 ThunderX,
Index: llvm/lib/Target/AArch64/AArch64Subtarget.cpp
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -199,6 +199,7 @@
 MaxBytesForLoopAlignment = 16;
 break;
   case NeoverseN2:
+  case NeoverseV2:
 PrefFunctionLogAlignment = 4;
 PrefLoopLogAlignment = 5;
 MaxBytesForLoopAlignment = 16;
Index: llvm/lib/Target/AArch64/AArch64.td
===
--- llvm/lib/Target/AArch64/AArch64.td
+++ llvm/lib/Target/AArch64/AArch64.td
@@ -936,6 +936,12 @@
   FeatureLSLFast,
   FeaturePostRAScheduler]>;
 
+def TuneNeoverseV2 : SubtargetFeature<"neoversev2", "ARMProcFamily", "NeoverseV2",
+  "Neoverse V2 ARM processors", [
+  FeatureFuseAES,
+  FeatureLSLFast,
+  FeaturePostRAScheduler]>;
+
 def TuneSaphira  : SubtargetFeature<"saphira", "ARMProcFamily", "Saphira",
"Qualcomm Saphira processors", [
FeatureCustomCheapAsMoveHandling,
@@ -1100,6 +1106,10 @@
FeatureFullFP16, FeatureMatMulInt8, FeatureNEON,
FeaturePerfMon, FeatureRandGen, FeatureSPE,
FeatureSSBS, FeatureSVE];
+  list NeoverseV2 = [HasV9_0aOps, FeatureBF16, FeatureSPE,
+   FeaturePerfMon, FeatureETE, FeatureMatMulInt8,
+  

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

[Dave Green via Phabricator via cfe-commits]

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

Thanks. LGTM


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

https://reviews.llvm.org/D134352

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

[clang] 4f8d92f - [clang] Fix the bogus diagnostic introduced by the newly-added UsingTemplate Kind.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2022-09-23T10:36:55+02:00
New Revision: 4f8d92f1d6bea3bed2dc450ba33efa4a0f5baffb

URL: 
https://github.com/llvm/llvm-project/commit/4f8d92f1d6bea3bed2dc450ba33efa4a0f5baffb
DIFF: 
https://github.com/llvm/llvm-project/commit/4f8d92f1d6bea3bed2dc450ba33efa4a0f5baffb.diff

LOG: [clang] Fix the bogus diagnostic introduced by the newly-added 
UsingTemplate Kind.

Reviewed By: sammccall

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

Added: 


Modified: 
clang/lib/Sema/SemaDeclCXX.cpp
clang/test/CXX/temp/temp.deduct.guide/p3.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index bad298c8c8bc8..2516d18b31c25 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -11056,6 +11056,7 @@ void Sema::CheckDeductionGuideDeclarator(Declarator &D, 
QualType &R,
 
 // Check that the return type is written as a specialization of
 // the template specified as the deduction-guide's name.
+// The template name may not be qualified. [temp.deduct.guide]
 ParsedType TrailingReturnType = Chunk.Fun.getTrailingReturnType();
 TypeSourceInfo *TSI = nullptr;
 QualType RetTy = GetTypeFromParser(TrailingReturnType, &TSI);
@@ -11067,9 +11068,13 @@ void Sema::CheckDeductionGuideDeclarator(Declarator 
&D, QualType &R,
   TemplateName SpecifiedName = RetTST.getTypePtr()->getTemplateName();
   bool TemplateMatches =
   Context.hasSameTemplateName(SpecifiedName, GuidedTemplate);
-  // FIXME: We should consider other template kinds (using, qualified),
-  // otherwise we will emit bogus diagnostics.
-  if (SpecifiedName.getKind() == TemplateName::Template && TemplateMatches)
+  auto TKind = SpecifiedName.getKind();
+  // A Using TemplateName can't actually be valid (either it's qualified, 
or
+  // we're in the wrong scope). But we have diagnosed these problems
+  // already.
+  bool SimplyWritten = TKind == TemplateName::Template ||
+   TKind == TemplateName::UsingTemplate;
+  if (SimplyWritten && TemplateMatches)
 AcceptableReturnType = true;
   else {
 // This could still instantiate to the right type, unless we know it

diff  --git a/clang/test/CXX/temp/temp.deduct.guide/p3.cpp 
b/clang/test/CXX/temp/temp.deduct.guide/p3.cpp
index 33f70e5c019bb..cdc073066f3e3 100644
--- a/clang/test/CXX/temp/temp.deduct.guide/p3.cpp
+++ b/clang/test/CXX/temp/temp.deduct.guide/p3.cpp
@@ -55,8 +55,6 @@ namespace WrongScope {
   }
   using N::NamedNS1;
   NamedNS1(int) -> NamedNS1; // expected-error {{deduction guide must be 
declared in the same scope as template}}
-  // FIXME: remove the following bogus diagnostic
-  // expected-error@-2{{deduction guide is not written as a specialization of 
template 'NamedNS1'}}
 
   using namespace N;
   NamedNS2(int) -> NamedNS2; // expected-error {{deduction guide must be 
declared in the same scope as template}}



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

[PATCH] D123808: [clang] Fix the bogus diagnostic introduced by the newly-added UsingTemplate Kind.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4f8d92f1d6be: [clang] Fix the bogus diagnostic introduced by 
the newly-added UsingTemplate… (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123808

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/temp/temp.deduct.guide/p3.cpp


Index: clang/test/CXX/temp/temp.deduct.guide/p3.cpp
===
--- clang/test/CXX/temp/temp.deduct.guide/p3.cpp
+++ clang/test/CXX/temp/temp.deduct.guide/p3.cpp
@@ -55,8 +55,6 @@
   }
   using N::NamedNS1;
   NamedNS1(int) -> NamedNS1; // expected-error {{deduction guide must be 
declared in the same scope as template}}
-  // FIXME: remove the following bogus diagnostic
-  // expected-error@-2{{deduction guide is not written as a specialization of 
template 'NamedNS1'}}
 
   using namespace N;
   NamedNS2(int) -> NamedNS2; // expected-error {{deduction guide must be 
declared in the same scope as template}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -11056,6 +11056,7 @@
 
 // Check that the return type is written as a specialization of
 // the template specified as the deduction-guide's name.
+// The template name may not be qualified. [temp.deduct.guide]
 ParsedType TrailingReturnType = Chunk.Fun.getTrailingReturnType();
 TypeSourceInfo *TSI = nullptr;
 QualType RetTy = GetTypeFromParser(TrailingReturnType, &TSI);
@@ -11067,9 +11068,13 @@
   TemplateName SpecifiedName = RetTST.getTypePtr()->getTemplateName();
   bool TemplateMatches =
   Context.hasSameTemplateName(SpecifiedName, GuidedTemplate);
-  // FIXME: We should consider other template kinds (using, qualified),
-  // otherwise we will emit bogus diagnostics.
-  if (SpecifiedName.getKind() == TemplateName::Template && TemplateMatches)
+  auto TKind = SpecifiedName.getKind();
+  // A Using TemplateName can't actually be valid (either it's qualified, 
or
+  // we're in the wrong scope). But we have diagnosed these problems
+  // already.
+  bool SimplyWritten = TKind == TemplateName::Template ||
+   TKind == TemplateName::UsingTemplate;
+  if (SimplyWritten && TemplateMatches)
 AcceptableReturnType = true;
   else {
 // This could still instantiate to the right type, unless we know it


Index: clang/test/CXX/temp/temp.deduct.guide/p3.cpp
===
--- clang/test/CXX/temp/temp.deduct.guide/p3.cpp
+++ clang/test/CXX/temp/temp.deduct.guide/p3.cpp
@@ -55,8 +55,6 @@
   }
   using N::NamedNS1;
   NamedNS1(int) -> NamedNS1; // expected-error {{deduction guide must be declared in the same scope as template}}
-  // FIXME: remove the following bogus diagnostic
-  // expected-error@-2{{deduction guide is not written as a specialization of template 'NamedNS1'}}
 
   using namespace N;
   NamedNS2(int) -> NamedNS2; // expected-error {{deduction guide must be declared in the same scope as template}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -11056,6 +11056,7 @@
 
 // Check that the return type is written as a specialization of
 // the template specified as the deduction-guide's name.
+// The template name may not be qualified. [temp.deduct.guide]
 ParsedType TrailingReturnType = Chunk.Fun.getTrailingReturnType();
 TypeSourceInfo *TSI = nullptr;
 QualType RetTy = GetTypeFromParser(TrailingReturnType, &TSI);
@@ -11067,9 +11068,13 @@
   TemplateName SpecifiedName = RetTST.getTypePtr()->getTemplateName();
   bool TemplateMatches =
   Context.hasSameTemplateName(SpecifiedName, GuidedTemplate);
-  // FIXME: We should consider other template kinds (using, qualified),
-  // otherwise we will emit bogus diagnostics.
-  if (SpecifiedName.getKind() == TemplateName::Template && TemplateMatches)
+  auto TKind = SpecifiedName.getKind();
+  // A Using TemplateName can't actually be valid (either it's qualified, or
+  // we're in the wrong scope). But we have diagnosed these problems
+  // already.
+  bool SimplyWritten = TKind == TemplateName::Template ||
+   TKind == TemplateName::UsingTemplate;
+  if (SimplyWritten && TemplateMatches)
 AcceptableReturnType = true;
   else {
 // This could still instantiate to the right type, unless we know it
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134453: Introduce the `AlwaysIncludeTypeForNonTypeTemplateArgument` into printing policy

[Nenad Mikša via Phabricator via cfe-commits]

DoDoENT added inline comments.



Comment at: clang/include/clang/AST/PrettyPrinter.h:307
+  /// decltype(s) will be printed as "S" if enabled and as 
"S<{1,2}>" if disabled,
+  /// regardless if PrintCanonicalTypes is enabled.
+  unsigned AlwaysIncludeTypeForNonTypeTemplateArgument : 1;

aaron.ballman wrote:
> dblaikie wrote:
> > DoDoENT wrote:
> > > dblaikie wrote:
> > > > What does `PrintCanonicalTypes` have to do with this? Does it overlap 
> > > > with this functionality in some way, but doesn't provide the 
> > > > functionality you want in particular?
> > > Thank you for the question. If you set the `PrintCanonicalTypes` to 
> > > `false`, the `S` would be printed as `S` even 
> > > without this patch. However, if you set it to `true`, it will be printed 
> > > as `S<{1, 2}>`.
> > > 
> > > I don't fully understand why it does that, but it's quite annoying.
> > > 
> > > For a better example, please take a look at the 
> > > `TemplateIdWithComplexFullTypeNTTP` unit tests that I've added: if 
> > > `PrintCanonicalTypes` is set to `true`, the original print output of type 
> > > is `NDArray`, and if set to `false` 
> > > (which is default), the output is `NDArray > > Width{{{0}}}, Channels{{{0}}}>` - so the NTTP type is neither fully 
> > > written nor fully omitted, which is weird.
> > > 
> > > As I said, I don't really understand the idea behind 
> > > `PrintCanonicalTypes`, but when my new 
> > > `AlwaysIncludeTypeForNonTypeTemplateArgument` is enabled, you will get 
> > > the full type printed, regardless of value of `PrintCanonicalTypes` 
> > > setting.
> > > 
> > Perhaps this might be more of a bug in PrintCanonicalTypes than something 
> > to add a separate flag for.
> > 
> > @aaron.ballman D2 for context here... 
> > 
> > Hmm, actually, just adding the top level `Height{{0}}, Width{{0}}, 
> > Channels{{0}}` is sufficient to make this code compile (whereas with the 
> > `{{{0}}}` it doesn't form a valid identifier.
> > 
> > So what's your use case for needing more explicitness than that top level? 
> > Perhaps this might be more of a bug in PrintCanonicalTypes than something 
> > to add a separate flag for.
> >
> > @aaron.ballman D2 for context here...
> 
> I looked over D2 again and haven't spotted anything with it that seems 
> amiss; the change there is to grab the canonical type before trying to print 
> it which is all the more I'd expect `PrintCanonicalTypes` to impact.
> 
> This looks like the behavior you'd get when you desugar the type. Check out 
> the AST dump for `s`: https://godbolt.org/z/vxh5j6qWr
> ```
> `-VarDecl  col:20 s 'S':'S<{1, 2}>' callinit
> ```
> We generate that type information at 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/TextNodeDumper.cpp#L663
>  for doing the AST dump, note how the second type printed is the desugared 
> type and that matches what we're seeing from the pretty printer.
> So what's your use case for needing more explicitness than that top level?

As I described in the [github 
issue](https://github.com/llvm/llvm-project/issues/57562), I'm trying to write 
a clang-based tool that will have different behavior if the printed `{{{0}}}` 
is actually `Width` than if its `Height` or anything else.

You can see the the issue in the AST dump for `bla`: 
https://godbolt.org/z/fMr4f13o3

The type is
```
`-VarDecl  col:21 bla 'NDArray':'NDArray' callinit
  `-CXXConstructExpr  'NDArray':'NDArray' 
'void () noexcept'
```

so it's unknown whether `{{{0}}}` represent the `Width` or `Height`. My patch 
makes it work exactly like GCC (see the comparison of error message between 
[clang 15 and GCC 12.1](https://godbolt.org/z/WenWe8caf).

> Perhaps this might be more of a bug in PrintCanonicalTypes than something to 
> add a separate flag for.

This was also my first thought and the first version of my patch (before even 
submitting it here) was to actually change the behavior of 
`PrintCanonicalTypes`. However, that change made some tests fail, as I 
described in the patch description:

- CodeGenCXX/debug-info-template.cpp
- SemaCXX/constexpr-printing.cpp
- SemaCXX/cxx2a-nttp-printing.cpp
- SemaTemplate/temp_arg_string_printing.cpp

Of course, it's possible to simply update the tests, but I actually don't fully 
understand what is the goal of `PrintCanonicalTypes` and whether its current 
behavior is actually desired or not, so I played it safe and introduced a new 
policy that is disabled by default until I get more feedback from more 
experienced LLVM developers.

The patch does solve my problem and since I'm building LLVM from source anyway, 
I can have it enabled in my fork.

I just want to see if it would also be beneficial to be introduced into the 
upstream LLVM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134453

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

[PATCH] D134454: [Driver][Distro] Fix ArchLinux triplet and sysroot detection

[Adrian Ratiu via Phabricator via cfe-commits]

10ne1 updated this revision to Diff 462423.
10ne1 added a comment.

Regenerated diff with git diff HEAD~1 -U99


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

https://reviews.llvm.org/D134454

Files:
  clang/include/clang/Driver/Distro.h
  clang/lib/Driver/Distro.cpp
  clang/lib/Driver/ToolChains/Linux.cpp


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -370,6 +370,16 @@
 return std::string();
   }
 
+  const Distro Distro(getDriver().getVFS(), getTriple());
+  const StringRef InstallDir = GCCInstallation.getInstallPath();
+  const StringRef TripleStr = GCCInstallation.getTriple().str();
+
+  if (Distro.IsArchLinux()) {
+std::string Path = (InstallDir + "/../../../../"  + TripleStr).str();
+if (getVFS().exists(Path))
+  return Path;
+  }
+
   if (!GCCInstallation.isValid() || !getTriple().isMIPS())
 return std::string();
 
@@ -377,8 +387,6 @@
   // and put it into different places. Here we try to check some known
   // variants.
 
-  const StringRef InstallDir = GCCInstallation.getInstallPath();
-  const StringRef TripleStr = GCCInstallation.getTriple().str();
   const Multilib &Multilib = GCCInstallation.getMultilib();
 
   std::string Path =
Index: clang/lib/Driver/Distro.cpp
===
--- clang/lib/Driver/Distro.cpp
+++ clang/lib/Driver/Distro.cpp
@@ -205,9 +205,16 @@
 
 static Distro::DistroType GetDistro(llvm::vfs::FileSystem &VFS,
 const llvm::Triple &TargetOrHost) {
+
+  // Sometimes the OS can't be detected from the triplet due to ambiguity, for
+  // eg. ArchLinux uses aarch64-linux-gnu which results in Uknonwn OS & distro,
+  // so normalize the triplet which results in aarch64-unknown-linux-gnu, such
+  // that the Linux OS and distro are properly detected in this cases.
+  llvm::Triple NormTargetOrHost = 
llvm::Triple(Twine(TargetOrHost.normalize()));
+
   // If we don't target Linux, no need to check the distro. This saves a few
   // OS calls.
-  if (!TargetOrHost.isOSLinux())
+  if (!NormTargetOrHost.isOSLinux())
 return Distro::UnknownDistro;
 
   // True if we're backed by a real file system.
Index: clang/include/clang/Driver/Distro.h
===
--- clang/include/clang/Driver/Distro.h
+++ clang/include/clang/Driver/Distro.h
@@ -134,6 +134,8 @@
 
   bool IsGentoo() const { return DistroVal == Gentoo; }
 
+  bool IsArchLinux() const { return DistroVal == ArchLinux; }
+
   /// @}
 };
 


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -370,6 +370,16 @@
 return std::string();
   }
 
+  const Distro Distro(getDriver().getVFS(), getTriple());
+  const StringRef InstallDir = GCCInstallation.getInstallPath();
+  const StringRef TripleStr = GCCInstallation.getTriple().str();
+
+  if (Distro.IsArchLinux()) {
+std::string Path = (InstallDir + "/../../../../"  + TripleStr).str();
+if (getVFS().exists(Path))
+  return Path;
+  }
+
   if (!GCCInstallation.isValid() || !getTriple().isMIPS())
 return std::string();
 
@@ -377,8 +387,6 @@
   // and put it into different places. Here we try to check some known
   // variants.
 
-  const StringRef InstallDir = GCCInstallation.getInstallPath();
-  const StringRef TripleStr = GCCInstallation.getTriple().str();
   const Multilib &Multilib = GCCInstallation.getMultilib();
 
   std::string Path =
Index: clang/lib/Driver/Distro.cpp
===
--- clang/lib/Driver/Distro.cpp
+++ clang/lib/Driver/Distro.cpp
@@ -205,9 +205,16 @@
 
 static Distro::DistroType GetDistro(llvm::vfs::FileSystem &VFS,
 const llvm::Triple &TargetOrHost) {
+
+  // Sometimes the OS can't be detected from the triplet due to ambiguity, for
+  // eg. ArchLinux uses aarch64-linux-gnu which results in Uknonwn OS & distro,
+  // so normalize the triplet which results in aarch64-unknown-linux-gnu, such
+  // that the Linux OS and distro are properly detected in this cases.
+  llvm::Triple NormTargetOrHost = llvm::Triple(Twine(TargetOrHost.normalize()));
+
   // If we don't target Linux, no need to check the distro. This saves a few
   // OS calls.
-  if (!TargetOrHost.isOSLinux())
+  if (!NormTargetOrHost.isOSLinux())
 return Distro::UnknownDistro;
 
   // True if we're backed by a real file system.
Index: clang/include/clang/Driver/Distro.h
===
--- clang/include/clang/Driver/Distro.h
+++ clang/include/clang/Driver/Distro.h
@@ -134,6 +134,8 @@
 
   bool IsGentoo() const { return DistroVal == Gentoo; }
 
+  bool IsArchLinux() co

[PATCH] D133801: Extraction of a matcher for an unused value from an expression from the bugprone-unused-return-value check

[Konrad Wilhelm Kleine via Phabricator via cfe-commits]

kwk added inline comments.



Comment at: clang-tools-extra/unittests/clang-tidy/MatchersTest.cpp:2
+#include "utils/Matchers.h"
+#include "../../clang/unittests/ASTMatchers/ASTMatchersTest.h"
+

njames93 wrote:
> @kwk I seem to recall you saying in another patch that this include will 
> break standalone builds, would stripping the leading `../../` work?
> @kwk I seem to recall you saying in another patch that this include will 
> break standalone builds, 

@njames93 that's correct. But I don't recall the patch ID :/

> would stripping the leading `../../` work?

I don't know if the file is found then but it would make standalone builds 
certainly easier.

I'm not sure if I calculate correctly but given:

`clang-tools-extra/unittests/clang-tidy/MatchersTest.cpp`

then `../../` means `clang-tools-extra/`, no? If so, that directory doesn't 
contain a `clang` directory here. It seems as if the `../../` is relative to 
some other directory but not this file. Or am I too tired to get it?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133801

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

[PATCH] D134461: [Clang] Diagnose an error when trying to deferencing void pointers in C

[Jun Zhang via Phabricator via cfe-commits]

junaire updated this revision to Diff 462426.
junaire added a comment.

Address comments from reviewers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134461

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Analysis/misc-ps.m
  clang/test/C/drs/dr1xx.c
  clang/test/Sema/asm.c
  clang/test/Sema/builtins-arm.c
  clang/test/Sema/conditional-expr.c
  clang/test/Sema/expr-address-of.c
  clang/test/Sema/i-c-e.c

Index: clang/test/Sema/i-c-e.c
===
--- clang/test/Sema/i-c-e.c
+++ clang/test/Sema/i-c-e.c
@@ -3,7 +3,7 @@
 #include 
 #include 
 
-int a(void) {int p; *(1 ? &p : (void*)(0 && (a(),1))) = 10;} // expected-error {{incomplete type 'void' is not assignable}}
+int a(void) {int p; *(1 ? &p : (void*)(0 && (a(),1))) = 10;} // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
 
 // rdar://6091492 - ?: with __builtin_constant_p as the operand is an i-c-e.
 int expr;
Index: clang/test/Sema/expr-address-of.c
===
--- clang/test/Sema/expr-address-of.c
+++ clang/test/Sema/expr-address-of.c
@@ -105,7 +105,7 @@
   int* dummy2 = &(t2.a); // expected-error {{address of bit-field requested}}
   int* dummy3 = &(t2.b); // expected-error {{address of bit-field requested}}
 
-  void* t3 = &(*(void*)0);
+  void* t3 = &*(void*)0;
 }
 
 void f8(void) {
Index: clang/test/Sema/conditional-expr.c
===
--- clang/test/Sema/conditional-expr.c
+++ clang/test/Sema/conditional-expr.c
@@ -2,11 +2,11 @@
 void foo(void) {
   *(0 ? (double *)0 : (void *)0) = 0;
   // FIXME: GCC doesn't consider the following two statements to be errors.
-  *(0 ? (double *)0 : (void *)(int *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}}
-  *(0 ? (double *)0 : (void *)(double *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}}
-  *(0 ? (double *)0 : (int *)(void *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{pointer type mismatch ('double *' and 'int *')}}
+  *(0 ? (double *)0 : (void *)(int *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
+  *(0 ? (double *)0 : (void *)(double *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
+  *(0 ? (double *)0 : (int *)(void *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{pointer type mismatch ('double *' and 'int *')}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
   *(0 ? (double *)0 : (double *)(void *)0) = 0;
-  *((void *) 0) = 0; // expected-error {{incomplete type 'void' is not assignable}}
+  *((void *) 0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
   double *dp;
   int *ip;
   void *vp;
Index: clang/test/Sema/builtins-arm.c
===
--- clang/test/Sema/builtins-arm.c
+++ clang/test/Sema/builtins-arm.c
@@ -18,7 +18,7 @@
 void test1(void) {
   __builtin_va_list ptr;
   ptr.__ap = "x";
-  *(ptr.__ap) = '0'; // expected-error {{incomplete type 'void' is not assignable}}
+  *(ptr.__ap) = '0'; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
 }
 #else
 // va_list on ARM apcs-gnu is void*.
@@ -30,7 +30,8 @@
 
 void test2(void) {
   __builtin_va_list ptr = "x";
-  *ptr = '0'; // expected-error {{incomplete type 'void' is not assignable}}
+  *ptr = '0'; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type '__builtin_va_list'}}
+
 }
 #endif
 
Index: clang/test/Sema/asm.c
===
--- clang/test/Sema/asm.c
+++ clang/test/Sema/asm.c
@@ -50,8 +50,8 @@
 // 
 void test4(const volatile void *addr)
 {
-asm ("nop" : : "r"(*addr)); // expected-error {{invalid type 'const volatile void' in asm input for constraint 'r'}}
-asm ("nop" : : "m"(*addr));
+asm ("nop" : : "r"(*addr)); // expected-error {{invalid type 'const volatile void' in asm input for constraint 'r'}} expected-warning {{ISO C does not allow indirection on operand of type 'const volatile void *'}}
+asm ("nop" : : "m"(*addr)); // expected-warning {{ISO C does not allow indirection

[PATCH] D134461: [Clang] Diagnose an error when trying to deferencing void pointers in C

[Jun Zhang via Phabricator via cfe-commits]

junaire marked 3 inline comments as done.
junaire added a comment.

> So I thought 'isAddressOfOperand' might be good enough for this, is this not 
> the case?

Yeah, that works, I somehow missed it ;D Thank you, Erich!




Comment at: clang/lib/Sema/SemaExpr.cpp:14541
+  Kind = diag::ext_typecheck_indirection_through_void_pointer;
+else if (S.getLangOpts().C99 && !IsAfterAmp)
+  Kind = diag::warn_deference_void_pointer;

aaron.ballman wrote:
> junaire wrote:
> > I don't know why we don't have `getLangOpts().C89`. I'm a bit confused 
> > about how we deal with different C standards...
> This trips up folks somewhat often, unfortunately! All of the language mode 
> options are cumulative, so if the user specifies C11, then C99 and C11 will 
> both be true. However, we don't have an explicit C89 language mode, instead 
> we rely on `!CPlusPlus` to tell us we're in C mode and `!C99` to tell us 
> we're in C89 mode. Does that make sense?
Thanks for the explanation! That works for me!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134461

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

[PATCH] D134461: [Clang] Warn when trying to deferencing void pointers in C

[Jun Zhang via Phabricator via cfe-commits]

junaire updated this revision to Diff 462428.
junaire marked an inline comment as done.
junaire added a comment.

Add `&(*p)` test case in dr1xx.c. (Previous seperate test is removed as it 
mostly duplicate with the DR test)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134461

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Analysis/misc-ps.m
  clang/test/C/drs/dr1xx.c
  clang/test/Sema/asm.c
  clang/test/Sema/builtins-arm.c
  clang/test/Sema/conditional-expr.c
  clang/test/Sema/expr-address-of.c
  clang/test/Sema/i-c-e.c

Index: clang/test/Sema/i-c-e.c
===
--- clang/test/Sema/i-c-e.c
+++ clang/test/Sema/i-c-e.c
@@ -3,7 +3,7 @@
 #include 
 #include 
 
-int a(void) {int p; *(1 ? &p : (void*)(0 && (a(),1))) = 10;} // expected-error {{incomplete type 'void' is not assignable}}
+int a(void) {int p; *(1 ? &p : (void*)(0 && (a(),1))) = 10;} // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
 
 // rdar://6091492 - ?: with __builtin_constant_p as the operand is an i-c-e.
 int expr;
Index: clang/test/Sema/expr-address-of.c
===
--- clang/test/Sema/expr-address-of.c
+++ clang/test/Sema/expr-address-of.c
@@ -105,7 +105,7 @@
   int* dummy2 = &(t2.a); // expected-error {{address of bit-field requested}}
   int* dummy3 = &(t2.b); // expected-error {{address of bit-field requested}}
 
-  void* t3 = &(*(void*)0);
+  void* t3 = &*(void*)0;
 }
 
 void f8(void) {
Index: clang/test/Sema/conditional-expr.c
===
--- clang/test/Sema/conditional-expr.c
+++ clang/test/Sema/conditional-expr.c
@@ -2,11 +2,11 @@
 void foo(void) {
   *(0 ? (double *)0 : (void *)0) = 0;
   // FIXME: GCC doesn't consider the following two statements to be errors.
-  *(0 ? (double *)0 : (void *)(int *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}}
-  *(0 ? (double *)0 : (void *)(double *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}}
-  *(0 ? (double *)0 : (int *)(void *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{pointer type mismatch ('double *' and 'int *')}}
+  *(0 ? (double *)0 : (void *)(int *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
+  *(0 ? (double *)0 : (void *)(double *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
+  *(0 ? (double *)0 : (int *)(void *)0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{pointer type mismatch ('double *' and 'int *')}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
   *(0 ? (double *)0 : (double *)(void *)0) = 0;
-  *((void *) 0) = 0; // expected-error {{incomplete type 'void' is not assignable}}
+  *((void *) 0) = 0; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
   double *dp;
   int *ip;
   void *vp;
Index: clang/test/Sema/builtins-arm.c
===
--- clang/test/Sema/builtins-arm.c
+++ clang/test/Sema/builtins-arm.c
@@ -18,7 +18,7 @@
 void test1(void) {
   __builtin_va_list ptr;
   ptr.__ap = "x";
-  *(ptr.__ap) = '0'; // expected-error {{incomplete type 'void' is not assignable}}
+  *(ptr.__ap) = '0'; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type 'void *'}}
 }
 #else
 // va_list on ARM apcs-gnu is void*.
@@ -30,7 +30,8 @@
 
 void test2(void) {
   __builtin_va_list ptr = "x";
-  *ptr = '0'; // expected-error {{incomplete type 'void' is not assignable}}
+  *ptr = '0'; // expected-error {{incomplete type 'void' is not assignable}} expected-warning {{ISO C does not allow indirection on operand of type '__builtin_va_list'}}
+
 }
 #endif
 
Index: clang/test/Sema/asm.c
===
--- clang/test/Sema/asm.c
+++ clang/test/Sema/asm.c
@@ -50,8 +50,8 @@
 // 
 void test4(const volatile void *addr)
 {
-asm ("nop" : : "r"(*addr)); // expected-error {{invalid type 'const volatile void' in asm input for constraint 'r'}}
-asm ("nop" : : "m"(*addr));
+asm ("nop" : : "r"(*addr)); // expected-error {{invalid type 'const volatile void' in asm input for constraint 'r'}} expected-warning {{ISO C does not allow indirection on operand o

[PATCH] D134523: [clang][Interp] Fix copy constructors with record array members

[Timm Bäder via Phabricator via cfe-commits]

tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, erichkeane, shafik, tahonermann.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Previously, we were only handling arrays of arrays because we only called 
`visitArrayInitializer()` when initializing a non-primitive array member. 
Change that to recurse into `visitInitializer()` and fix the bytecodegen for 
`CXXConstructExpr` with non-primitive field types.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134523

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/Pointer.cpp
  clang/test/AST/Interp/records.cpp

Index: clang/test/AST/Interp/records.cpp
===
--- clang/test/AST/Interp/records.cpp
+++ clang/test/AST/Interp/records.cpp
@@ -140,3 +140,24 @@
   return c.a;
 }
 static_assert(locals() == 10, "");
+
+struct FourBoolPairs {
+  BoolPair v[4] = {
+{false, false},
+{false,  true},
+{true,  false},
+{true,  true },
+  };
+};
+// Init
+constexpr FourBoolPairs LT;
+// Copy ctor
+constexpr FourBoolPairs LT2 = LT;
+// FIXME: The copy constructor call above
+//   works, but APValue we generate for it is
+//   not sufficiently correct, so the lvalue-to-rvalue
+//   conversion in ExprConstant.c runs into an assertion.
+//static_assert(LT2.v[0].first == false, "");
+//static_assert(LT2.v[0].second == false, "");
+//static_assert(LT2.v[2].first == true, "");
+//static_assert(LT2.v[2].second == false, "");
Index: clang/lib/AST/Interp/Pointer.cpp
===
--- clang/lib/AST/Interp/Pointer.cpp
+++ clang/lib/AST/Interp/Pointer.cpp
@@ -37,8 +37,11 @@
 Pointer::Pointer(Block *Pointee, unsigned Base, unsigned Offset)
 : Pointee(Pointee), Base(Base), Offset(Offset) {
   assert((Base == RootPtrMark || Base % alignof(void *) == 0) && "wrong base");
-  if (Pointee)
+  if (Pointee) {
 Pointee->addPointer(this);
+assert(Base < Pointee->getSize());
+assert(Offset < Pointee->getSize());
+  }
 }
 
 Pointer::~Pointer() {
@@ -151,6 +154,7 @@
 bool Pointer::isInitialized() const {
   assert(Pointee && "Cannot check if null pointer was initialized");
   Descriptor *Desc = getFieldDesc();
+  assert(Desc);
   if (Desc->isPrimitiveArray()) {
 if (Pointee->IsStatic)
   return true;
@@ -171,6 +175,7 @@
   assert(Pointee && "Cannot initialize null pointer");
   Descriptor *Desc = getFieldDesc();
 
+  assert(Desc);
   if (Desc->isArray()) {
 if (Desc->isPrimitiveArray() && !Pointee->IsStatic) {
   // Primitive array initializer.
Index: clang/lib/AST/Interp/Interp.h
===
--- clang/lib/AST/Interp/Interp.h
+++ clang/lib/AST/Interp/Interp.h
@@ -494,7 +494,7 @@
 
 /// 1) Pops the value from the stack
 /// 2) Pops a pointer from the stack
-/// 3) Writes the value to field I of the pointer
+/// 3) Pushes the value to field I of the pointer on the stack
 template ::T>
 bool InitField(InterpState &S, CodePtr OpPC, uint32_t I) {
   const T &Value = S.Stk.pop();
@@ -548,6 +548,8 @@
   return true;
 }
 
+/// 1) Pops a Pointer from the stack
+/// 2) Pushes Pointer.atField(Off) on the stack
 inline bool GetPtrField(InterpState &S, CodePtr OpPC, uint32_t Off) {
   const Pointer &Ptr = S.Stk.pop();
   if (!CheckNull(S, OpPC, Ptr, CSK_Field))
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -328,7 +328,10 @@
 template 
 bool ByteCodeExprGen::VisitArrayInitIndexExpr(
 const ArrayInitIndexExpr *E) {
-  assert(ArrayIndex);
+  // ArrayIndex might not be set if a ArrayInitIndexExpr is being evaluated
+  // stand-alone, e.g. via EvaluateAsInt().
+  if (!ArrayIndex)
+return false;
   return this->emitConstUint64(*ArrayIndex, E);
 }
 
@@ -604,9 +607,15 @@
   if (const auto *InitList = dyn_cast(Initializer)) {
 unsigned ElementIndex = 0;
 for (const Expr *Init : InitList->inits()) {
-  QualType InitType = Init->getType();
-
-  if (InitType->isArrayType()) {
+  if (Optional T = classify(Init->getType())) {
+// Visit the primitive element like normal.
+if (!this->emitDupPtr(Init))
+  return false;
+if (!this->visit(Init))
+  return false;
+if (!this->emitInitElem(*T, ElementIndex, Init))
+  return false;
+  } else {
 // Advance the pointer currently on the stack to the given
 // dimension and narrow().
 if (!this->emitDupPtr(Init))
@@ -617,21 +626,12 @@
   return false;
 if (!this->emitNarrowPtr(Init))
   return false;
-if (!visitArrayInitializer(Init))
+
+if (!visitInitializer(Init))
   ret

[clang-tools-extra] 7438df9 - Remove an unused var decl, NFC.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2022-09-23T11:54:50+02:00
New Revision: 7438df99604233bf9e319875adcbd97aae608520

URL: 
https://github.com/llvm/llvm-project/commit/7438df99604233bf9e319875adcbd97aae608520
DIFF: 
https://github.com/llvm/llvm-project/commit/7438df99604233bf9e319875adcbd97aae608520.diff

LOG: Remove an unused var decl, NFC.

Added: 


Modified: 
clang-tools-extra/clangd/ClangdLSPServer.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdLSPServer.cpp 
b/clang-tools-extra/clangd/ClangdLSPServer.cpp
index c5238e426d692..8b94d0d84fd4c 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ b/clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -606,7 +606,6 @@ void ClangdLSPServer::onInitialize(const InitializeParams 
&Params,
   // Per LSP, codeActionProvider can be either boolean or CodeActionOptions.
   // CodeActionOptions is only valid if the client supports action literal
   // via textDocument.codeAction.codeActionLiteralSupport.
-  llvm::json::Value CodeActionProvider = true;
   ServerCaps["codeActionProvider"] =
   Params.capabilities.CodeActionStructure
   ? llvm::json::Object{{"codeActionKinds",



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

[PATCH] D133659: [Clang] P1169R4: static operator()

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson updated this revision to Diff 462437.
royjacobson added a comment.

Apply suggestions from Aaron and rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133659

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OperatorKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/over/over.match/over.match.best/over.best.ics/p6.cpp
  clang/test/CXX/over/over.oper/p7.cpp
  clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
  clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
  clang/test/Parser/cxx2b-lambdas.cpp
  clang/test/SemaCXX/lambda-unevaluated.cpp
  clang/test/SemaCXX/overloaded-operator-decl.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1481,7 +1481,7 @@
 
   static operator()
   https://wg21.link/P1169R4";>P1169R4
-  No
+  Clang 16
 
 
   Extended floating-point types and standard names
Index: clang/test/SemaCXX/overloaded-operator-decl.cpp
===
--- clang/test/SemaCXX/overloaded-operator-decl.cpp
+++ clang/test/SemaCXX/overloaded-operator-decl.cpp
@@ -51,7 +51,7 @@
 
 namespace PR14120 {
   struct A {
-static void operator()(int& i) { ++i; } // expected-error{{overloaded 'operator()' cannot be a static member function}}
+static void operator()(int& i) { ++i; } // expected-error{{overloaded 'operator()' cannot be declared static}}
   };
   void f() {
 int i = 0;
Index: clang/test/SemaCXX/lambda-unevaluated.cpp
===
--- clang/test/SemaCXX/lambda-unevaluated.cpp
+++ clang/test/SemaCXX/lambda-unevaluated.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++20 %s -verify
+// RUN: %clang_cc1 -std=c++2b %s -verify
 
 
 template  struct Nothing {};
@@ -120,3 +121,28 @@
 void foo(decltype(+[](T) {}) lambda, T param);
 static_assert(!__is_same(decltype(foo), void));
 } // namespace GH51641
+
+#if __cplusplus > 202002L
+namespace StaticLambdas {
+template  struct Nothing {};
+Nothing<[]() static { return 0; }()> nothing;
+
+template  struct NothingT {};
+Nothing<[]() static { return 0; }> nothingT;
+
+template 
+concept True = [] static { return true; }();
+static_assert(True);
+
+static_assert(sizeof([] static { return 0; }));
+static_assert(sizeof([] static { return 0; }()));
+
+void f()  noexcept(noexcept([] static { return 0; }()));
+
+using a = decltype([] static { return 0; });
+using b = decltype([] static { return 0; }());
+using c = decltype([]() static noexcept(noexcept([] { return 0; }())) { return 0; });
+using d = decltype(sizeof([] static { return 0; }));
+
+}
+#endif
Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -38,3 +38,31 @@
 auto XL4 = [] requires true {}; // expected-error{{expected body}}
 auto XL5 = [] requires true requires true {}; // expected-error{{expected body}}
 auto XL6 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+
+auto XL7 = []() static static {}; // expected-error {{cannot appear multiple times}}
+auto XL8 = []() static mutable {}; // expected-error {{cannot be both mutable and static}}
+auto XL9 = []() static consteval {};
+auto XL10 = []() static constexpr {};
+
+auto XL11 = [] static {};
+auto XL12 = []() static {};
+auto XL13 = []() static extern {};  // expected-error {{expected body of lambda expression}}
+auto XL14 = []() extern {};  // expected-error {{expected body of lambda expression}}
+
+
+void static_captures() {
+  int x;
+  auto SC1 = [&]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC4 = [x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC2 = [&x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC3 = [y=x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC5 = [&y = x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC6 = [=]() static {}; // expected-error {{a static lambda cannot hav

[PATCH] D133659: [Clang] P1169R4: static operator()

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson updated this revision to Diff 462438.
royjacobson marked 8 inline comments as done.
royjacobson added a comment.

Small doc change


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133659

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OperatorKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/over/over.match/over.match.best/over.best.ics/p6.cpp
  clang/test/CXX/over/over.oper/p7.cpp
  clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
  clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
  clang/test/Parser/cxx2b-lambdas.cpp
  clang/test/SemaCXX/lambda-unevaluated.cpp
  clang/test/SemaCXX/overloaded-operator-decl.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1481,7 +1481,7 @@
 
   static operator()
   https://wg21.link/P1169R4";>P1169R4
-  No
+  Clang 16
 
 
   Extended floating-point types and standard names
Index: clang/test/SemaCXX/overloaded-operator-decl.cpp
===
--- clang/test/SemaCXX/overloaded-operator-decl.cpp
+++ clang/test/SemaCXX/overloaded-operator-decl.cpp
@@ -51,7 +51,7 @@
 
 namespace PR14120 {
   struct A {
-static void operator()(int& i) { ++i; } // expected-error{{overloaded 'operator()' cannot be a static member function}}
+static void operator()(int& i) { ++i; } // expected-error{{overloaded 'operator()' cannot be declared static}}
   };
   void f() {
 int i = 0;
Index: clang/test/SemaCXX/lambda-unevaluated.cpp
===
--- clang/test/SemaCXX/lambda-unevaluated.cpp
+++ clang/test/SemaCXX/lambda-unevaluated.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++20 %s -verify
+// RUN: %clang_cc1 -std=c++2b %s -verify
 
 
 template  struct Nothing {};
@@ -120,3 +121,28 @@
 void foo(decltype(+[](T) {}) lambda, T param);
 static_assert(!__is_same(decltype(foo), void));
 } // namespace GH51641
+
+#if __cplusplus > 202002L
+namespace StaticLambdas {
+template  struct Nothing {};
+Nothing<[]() static { return 0; }()> nothing;
+
+template  struct NothingT {};
+Nothing<[]() static { return 0; }> nothingT;
+
+template 
+concept True = [] static { return true; }();
+static_assert(True);
+
+static_assert(sizeof([] static { return 0; }));
+static_assert(sizeof([] static { return 0; }()));
+
+void f()  noexcept(noexcept([] static { return 0; }()));
+
+using a = decltype([] static { return 0; });
+using b = decltype([] static { return 0; }());
+using c = decltype([]() static noexcept(noexcept([] { return 0; }())) { return 0; });
+using d = decltype(sizeof([] static { return 0; }));
+
+}
+#endif
Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -38,3 +38,31 @@
 auto XL4 = [] requires true {}; // expected-error{{expected body}}
 auto XL5 = [] requires true requires true {}; // expected-error{{expected body}}
 auto XL6 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+
+auto XL7 = []() static static {}; // expected-error {{cannot appear multiple times}}
+auto XL8 = []() static mutable {}; // expected-error {{cannot be both mutable and static}}
+auto XL9 = []() static consteval {};
+auto XL10 = []() static constexpr {};
+
+auto XL11 = [] static {};
+auto XL12 = []() static {};
+auto XL13 = []() static extern {};  // expected-error {{expected body of lambda expression}}
+auto XL14 = []() extern {};  // expected-error {{expected body of lambda expression}}
+
+
+void static_captures() {
+  int x;
+  auto SC1 = [&]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC4 = [x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC2 = [&x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC3 = [y=x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC5 = [&y = x]() static {}; // expected-error {{a static lambda cannot have any captures}} // expected-note {{captures declared here}}
+  auto SC6 = [=]() static {}; // expected-error {{a st

[PATCH] D133659: [Clang] P1169R4: static operator()

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson marked an inline comment as not done.
royjacobson added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1037-1041
+def err_static_mutable_lambda : Error<
+  "lambda cannot be both mutable and static">;
+def err_static_lambda_captures : Error<
+  "a static lambda cannot have any captures">;
+def note_lambda_captures : Note<"captures declared here">;

aaron.ballman wrote:
> royjacobson wrote:
> > aaron.ballman wrote:
> > > royjacobson wrote:
> > > > aaron.ballman wrote:
> > > > > These are semantic errors, not parsing ones. This means these will be 
> > > > > diagnosed when parsing the lambda rather than when instantiating it. 
> > > > > I don't think that matters for the cast of combining `mutable` and 
> > > > > `static`, but I'm less certain about "have any captures" because of 
> > > > > cases like:
> > > > > ```
> > > > > template 
> > > > > auto func(Types... Ts) {
> > > > >   return [Ts...] { return 1; };
> > > > > }
> > > > > 
> > > > > int main() {
> > > > >   auto lambda = func();
> > > > > }
> > > > > ```
> > > > > I'm pretty sure that lambda has no captures for that call, but it 
> > > > > could have captures depending on the instantiation.
> > > > > 
> > > > > Actually, from some off-list discussion with @erichkeane, even 
> > > > > mutable and static are a problem in code like:
> > > > > ```
> > > > > template 
> > > > > void func(T t) {
> > > > >   if constexpr (Something) {
> > > > > [](){};
> > > > >   } else {
> > > > > [t](){};
> > > > >   }
> > > > > ```
> > > > > where the lambda is in a discarded statement.
> > > > > 
> > > > > So I think these might need to change to be Sema diagnostics (and we 
> > > > > should add some additional test coverage).
> > > > From https://eel.is/c++draft/expr.prim.lambda.general#4 
> > > > 
> > > > > If the lambda-specifier-seq contains static, there shall be no 
> > > > > lambda-capture
> > > > 
> > > > So this should be a parsing error. Or maybe I don't understand what 
> > > > you're saying. There are no static lambdas in your examples so I'm not 
> > > > sure how they're related.
> > > > 
> > > > So this should be a parsing error. Or maybe I don't understand what 
> > > > you're saying. 
> > > 
> > > Parsing errors are where the grammar disallows something, generally. The 
> > > rest are semantic diagnostics (e.g., we can parse the construct just 
> > > fine, but we diagnose when turning it into an AST node because that's the 
> > > point at which we have complete information about what we've parsed).
> > > 
> > > That said, my concern was mostly around SFINAE situations. My 
> > > recollection is that SFINAE traps do not cover parsing errors only type 
> > > substitution errors. So for my first example, I would expect there to be 
> > > no parsing error despite specifying a capture list because that capture 
> > > list can be empty when the pack is empty, but we would get a SFINAE 
> > > diagnostic when rebuilding declaration during template instantiation if 
> > > the pack was not empty.
> > > 
> > > >  There are no static lambdas in your examples so I'm not sure how 
> > > > they're related.
> > > 
> > > Sorry, I was being lazy with my examples and showing more about the 
> > > capture list. Consider:
> > > ```
> > > template 
> > > auto func(Types... Ts) {
> > >   return [Ts...] static { return 1; };
> > > }
> > > 
> > > int main() {
> > >   auto lambda = func();
> > > }
> > > ```
> > > 
> > Like I said,
> > 
> > > If the lambda-specifier-seq contains static, there shall be no 
> > > lambda-capture
> > 
> > `Ts...` is still a syntactic `lambda-capture`, even if it's instantiated as 
> > an empty pack. I don't see how that's not a parsing error.
> Ah, I think I maybe see where the confusion is coming in, now: you think my 
> example should be diagnosed and I think my example should be accepted.
> 
> Based on the standards wording, I think you're right. The standard 
> specifically uses "lambda-capture" as a grammar term, so it *is* a parsing 
> error at that point.
> 
> Based on my understanding of the intent behind the feature, I think I'm right 
> and there's a core issue here. I don't think we intended to prohibit empty 
> packs from being captured as non-SFINAEable error (and in off-list talks with 
> @erichkeane, he agrees). as that allows different specializations of the 
> function containing the lambda, which could be of use. However, I'm not 100% 
> sure on the intent. CC @hubert.reinterpretcast as the C++ standards 
> conformance code owner to see if he has an opinion or other recollections 
> here.
I can see something like 

```
[Ts...] static(sizeof...(Types) == 0) {}
```

being eventually useful, but as long as the `static` is non-conditional 
allowing a capture list with an empty pack doesn't make sense to me. I think 
you can always do something like
```
[]::value> {}
```
and that should have the same functionality.

Do you or Erich plan to open a CW

[PATCH] D133659: [Clang] P1169R4: static operator()

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1037-1041
+def err_static_mutable_lambda : Error<
+  "lambda cannot be both mutable and static">;
+def err_static_lambda_captures : Error<
+  "a static lambda cannot have any captures">;
+def note_lambda_captures : Note<"captures declared here">;

royjacobson wrote:
> aaron.ballman wrote:
> > royjacobson wrote:
> > > aaron.ballman wrote:
> > > > royjacobson wrote:
> > > > > aaron.ballman wrote:
> > > > > > These are semantic errors, not parsing ones. This means these will 
> > > > > > be diagnosed when parsing the lambda rather than when instantiating 
> > > > > > it. I don't think that matters for the cast of combining `mutable` 
> > > > > > and `static`, but I'm less certain about "have any captures" 
> > > > > > because of cases like:
> > > > > > ```
> > > > > > template 
> > > > > > auto func(Types... Ts) {
> > > > > >   return [Ts...] { return 1; };
> > > > > > }
> > > > > > 
> > > > > > int main() {
> > > > > >   auto lambda = func();
> > > > > > }
> > > > > > ```
> > > > > > I'm pretty sure that lambda has no captures for that call, but it 
> > > > > > could have captures depending on the instantiation.
> > > > > > 
> > > > > > Actually, from some off-list discussion with @erichkeane, even 
> > > > > > mutable and static are a problem in code like:
> > > > > > ```
> > > > > > template 
> > > > > > void func(T t) {
> > > > > >   if constexpr (Something) {
> > > > > > [](){};
> > > > > >   } else {
> > > > > > [t](){};
> > > > > >   }
> > > > > > ```
> > > > > > where the lambda is in a discarded statement.
> > > > > > 
> > > > > > So I think these might need to change to be Sema diagnostics (and 
> > > > > > we should add some additional test coverage).
> > > > > From https://eel.is/c++draft/expr.prim.lambda.general#4 
> > > > > 
> > > > > > If the lambda-specifier-seq contains static, there shall be no 
> > > > > > lambda-capture
> > > > > 
> > > > > So this should be a parsing error. Or maybe I don't understand what 
> > > > > you're saying. There are no static lambdas in your examples so I'm 
> > > > > not sure how they're related.
> > > > > 
> > > > > So this should be a parsing error. Or maybe I don't understand what 
> > > > > you're saying. 
> > > > 
> > > > Parsing errors are where the grammar disallows something, generally. 
> > > > The rest are semantic diagnostics (e.g., we can parse the construct 
> > > > just fine, but we diagnose when turning it into an AST node because 
> > > > that's the point at which we have complete information about what we've 
> > > > parsed).
> > > > 
> > > > That said, my concern was mostly around SFINAE situations. My 
> > > > recollection is that SFINAE traps do not cover parsing errors only type 
> > > > substitution errors. So for my first example, I would expect there to 
> > > > be no parsing error despite specifying a capture list because that 
> > > > capture list can be empty when the pack is empty, but we would get a 
> > > > SFINAE diagnostic when rebuilding declaration during template 
> > > > instantiation if the pack was not empty.
> > > > 
> > > > >  There are no static lambdas in your examples so I'm not sure how 
> > > > > they're related.
> > > > 
> > > > Sorry, I was being lazy with my examples and showing more about the 
> > > > capture list. Consider:
> > > > ```
> > > > template 
> > > > auto func(Types... Ts) {
> > > >   return [Ts...] static { return 1; };
> > > > }
> > > > 
> > > > int main() {
> > > >   auto lambda = func();
> > > > }
> > > > ```
> > > > 
> > > Like I said,
> > > 
> > > > If the lambda-specifier-seq contains static, there shall be no 
> > > > lambda-capture
> > > 
> > > `Ts...` is still a syntactic `lambda-capture`, even if it's instantiated 
> > > as an empty pack. I don't see how that's not a parsing error.
> > Ah, I think I maybe see where the confusion is coming in, now: you think my 
> > example should be diagnosed and I think my example should be accepted.
> > 
> > Based on the standards wording, I think you're right. The standard 
> > specifically uses "lambda-capture" as a grammar term, so it *is* a parsing 
> > error at that point.
> > 
> > Based on my understanding of the intent behind the feature, I think I'm 
> > right and there's a core issue here. I don't think we intended to prohibit 
> > empty packs from being captured as non-SFINAEable error (and in off-list 
> > talks with @erichkeane, he agrees). as that allows different 
> > specializations of the function containing the lambda, which could be of 
> > use. However, I'm not 100% sure on the intent. CC @hubert.reinterpretcast 
> > as the C++ standards conformance code owner to see if he has an opinion or 
> > other recollections here.
> I can see something like 
> 
> ```
> [Ts...] static(sizeof...(Types) == 0) {}
> ```
> 
> being eventually useful, but as long as the `static` is non-conditional 
> allowing a capture 

[PATCH] D130460: [pseudo] Add recovery for declarations

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 462448.
hokein added a comment.

Fix a bug caused by my change, and add test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130460

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/Language.h
  clang-tools-extra/pseudo/include/clang-pseudo/cxx/Recovery.h
  clang-tools-extra/pseudo/lib/GLR.cpp
  clang-tools-extra/pseudo/lib/cxx/CMakeLists.txt
  clang-tools-extra/pseudo/lib/cxx/CXX.cpp
  clang-tools-extra/pseudo/lib/cxx/Recovery.cpp
  clang-tools-extra/pseudo/lib/cxx/cxx.bnf
  clang-tools-extra/pseudo/test/cxx/recovery-declarations.cpp
  clang-tools-extra/pseudo/unittests/CMakeLists.txt
  clang-tools-extra/pseudo/unittests/CXXRecoveryTest.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp

Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -48,13 +48,13 @@
testing::UnorderedElementsAreArray(Parents));
 }
 
-Token::Index recoverBraces(Token::Index Begin, const TokenStream &Code) {
-  EXPECT_GT(Begin, 0u);
-  const Token &Left = Code.tokens()[Begin - 1];
+Token::Index recoverBraces(const RecoveryParams &P) {
+  EXPECT_GT(P.Begin, 0u);
+  const Token &Left = P.Tokens.tokens()[P.Begin - 1];
   EXPECT_EQ(Left.Kind, tok::l_brace);
   if (const auto* Right = Left.pair()) {
 EXPECT_EQ(Right->Kind, tok::r_brace);
-return Code.index(*Right);
+return P.Tokens.index(*Right);
   }
   return Token::Invalid;
 }
@@ -613,7 +613,7 @@
   TestLang.Table = LRTable::buildSLR(TestLang.G);
   TestLang.RecoveryStrategies.try_emplace(
   extensionID("Skip"),
-  [](Token::Index Start, const TokenStream &) { return Start; });
+  [](const RecoveryParams& P) { return P.Begin; });
   clang::LangOptions LOptions;
   TokenStream Tokens = cook(lex("foo", LOptions), LOptions);
 
@@ -641,7 +641,7 @@
   TestLang.Table = LRTable::buildSLR(TestLang.G);
   TestLang.RecoveryStrategies.try_emplace(
   extensionID("AcceptAnyTokenInstead"),
-  [](Token::Index Start, const TokenStream &Stream) { return Start + 1; });
+  [](const RecoveryParams& P) { return P.Begin + 1; });
 
   const ForestNode &Parsed =
   glrParse({Tokens, Arena, GSStack}, id("sentence"), TestLang);
@@ -660,9 +660,9 @@
   )bnf");
   TestLang.Table = LRTable::buildSLR(TestLang.G);
   bool fallback_recovered = false;
-  auto fallback = [&](Token::Index Start, const TokenStream & Code) {
+  auto fallback = [&](const RecoveryParams& P) {
 fallback_recovered = true;
-return Code.tokens().size();
+return P.Tokens.tokens().size();
   };
   TestLang.RecoveryStrategies.try_emplace(
   extensionID("Fallback"),
@@ -694,7 +694,7 @@
   TestLang.Table = LRTable::buildSLR(TestLang.G);
   TestLang.RecoveryStrategies.try_emplace(
   extensionID("Skip"),
-  [](Token::Index Start, const TokenStream &) { return Start; });
+  [](const RecoveryParams& P) { return P.Begin; });
   clang::LangOptions LOptions;
   TokenStream Tokens = cook(lex("main", LOptions), LOptions);
 
Index: clang-tools-extra/pseudo/unittests/CXXRecoveryTest.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/unittests/CXXRecoveryTest.cpp
@@ -0,0 +1,110 @@
+//===--- CXXRecoveryTest.cpp - --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang-pseudo/Bracket.h"
+#include "clang-pseudo/Language.h"
+#include "clang-pseudo/Token.h"
+#include "clang-pseudo/cxx/Recovery.h"
+
+#include "clang/Basic/LangOptions.h"
+#include "llvm/Testing/Support/Annotations.h"
+#include "gtest/gtest.h"
+
+namespace clang::pseudo {
+
+namespace {
+
+std::pair
+extract(const llvm::Annotations &Test) {
+  assert(Test.points().size() == 2 && "Expect two ^s in the test annotations");
+  LangOptions Opts = clang::pseudo::genericLangOpts();
+  std::string Code = Test.code().str();
+  TokenStream Cook = cook(lex(Code, Opts), Opts);
+  pairBrackets(Cook);
+
+  RecoveryParams P{0, Token::Invalid, Cook};
+  auto StartOffset = [&](const Token &T) -> size_t {
+return T.Data - Code.data();
+  };
+  for (const auto &T : Cook.tokens()) {
+if (StartOffset(T) == Test.points().front()) {
+  P.Cursor = Cook.index(T);
+  break;
+}
+  }
+  assert(P.Cursor != Token::Invalid && "no cursor position provided");
+  Token::Index Expect = Token::Invalid;
+  if (Test.points().back() > StartOffset(Cook.tokens().back()))
+Expect = Cook.tokens().size(); // EOF
+  else {
+for (const auto &T : Cook.tokens()

[PATCH] D134441: [ObjC][ARC] Don't use operand bundle "clang.arc.attachedcall" in codegen for Windows

[Stefan Gränitz via Phabricator via cfe-commits]

sgraenitz added a comment.

Thanks for your feedback! For the moment, I continued the discussion in the 
GitHub ticket. My gut feeling is that I should fix the X86ExpandPseudo code to 
emit the right register-register move instead of preventing the use of the 
operand bundle here in CodeGen, because the inliner may generate it as well. I 
tested it like this and it works as expected:
https://github.com/weliveindetail/llvm-project/commit/c36eeefb3917c66ad75c7dd1dbcda29645d05aed

I'd like to wait for David's response on whether or not GNUstep is checking for 
optimized callers (or wants to do it in the future) before deciding for one way 
or the other.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134441

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

[clang] 31142c4 - [clang] Make --ld-path= work with -fuse-ld=lld

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2022-09-23T09:04:19-04:00
New Revision: 31142c4290533eeb771a0fc66af4918bd74bc162

URL: 
https://github.com/llvm/llvm-project/commit/31142c4290533eeb771a0fc66af4918bd74bc162
DIFF: 
https://github.com/llvm/llvm-project/commit/31142c4290533eeb771a0fc66af4918bd74bc162.diff

LOG: [clang] Make --ld-path= work with -fuse-ld=lld

This allows using --ld-path= to set a custom linker path, while
still informing clang that the binary at that path is an lld built
at the same revision as clang, so that clang can make assumptions
about the flags it supports, its output format, etc.

This currently only has an observable effect on Darwin.

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

Added: 


Modified: 
clang/lib/Driver/ToolChain.cpp
clang/test/Driver/darwin-ld-demangle-lld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 5547f28d6351..fdbe7270bddd 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -621,13 +621,18 @@ std::string ToolChain::GetLinkerPath(bool *LinkerIsLLD) 
const {
   // --ld-path= takes precedence over -fuse-ld= and specifies the executable
   // name. -B, COMPILER_PATH and PATH and consulted if the value does not
   // contain a path component separator.
+  // -fuse-ld=lld can be used with --ld-path= to inform clang that the binary
+  // that --ld-path= points to is lld.
   if (const Arg *A = Args.getLastArg(options::OPT_ld_path_EQ)) {
 std::string Path(A->getValue());
 if (!Path.empty()) {
   if (llvm::sys::path::parent_path(Path).empty())
 Path = GetProgramPath(A->getValue());
-  if (llvm::sys::fs::can_execute(Path))
+  if (llvm::sys::fs::can_execute(Path)) {
+if (LinkerIsLLD)
+  *LinkerIsLLD = UseLinker == "lld";
 return std::string(Path);
+  }
 }
 getDriver().Diag(diag::err_drv_invalid_linker_name) << 
A->getAsString(Args);
 return GetProgramPath(getDefaultLinker());

diff  --git a/clang/test/Driver/darwin-ld-demangle-lld.c 
b/clang/test/Driver/darwin-ld-demangle-lld.c
index 3d44c3d432f2..12fd8502ce7a 100644
--- a/clang/test/Driver/darwin-ld-demangle-lld.c
+++ b/clang/test/Driver/darwin-ld-demangle-lld.c
@@ -1,8 +1,12 @@
 // With -fuse-ld=lld, -demangle is always passed to the linker on Darwin.
 // REQUIRES: shell
 
-// RUN: %clang --target=x86_64-apple-darwin -### \
-// RUN:   -fuse-ld=lld -B%S/Inputs/lld -mlinker-version=0 %s 2>&1 \
+// RUN: %clang --target=x86_64-apple-darwin -### -fuse-ld=lld \
+// RUN:   -B%S/Inputs/lld -mlinker-version=0 %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// RUN: %clang --target=x86_64-apple-darwin -### -fuse-ld=lld \
+// RUN:   --ld-path=%S/Inputs/lld/ld64.lld -mlinker-version=0 %s 2>&1 \
 // RUN:   | FileCheck %s
 
 // CHECK: "-demangle"



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

[PATCH] D134063: [clang] Make --ld-path= work with -fuse-ld=lld

[Nico Weber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG31142c429053: [clang] Make --ld-path= work with -fuse-ld=lld 
(authored by thakis).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134063

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/darwin-ld-demangle-lld.c


Index: clang/test/Driver/darwin-ld-demangle-lld.c
===
--- clang/test/Driver/darwin-ld-demangle-lld.c
+++ clang/test/Driver/darwin-ld-demangle-lld.c
@@ -1,8 +1,12 @@
 // With -fuse-ld=lld, -demangle is always passed to the linker on Darwin.
 // REQUIRES: shell
 
-// RUN: %clang --target=x86_64-apple-darwin -### \
-// RUN:   -fuse-ld=lld -B%S/Inputs/lld -mlinker-version=0 %s 2>&1 \
+// RUN: %clang --target=x86_64-apple-darwin -### -fuse-ld=lld \
+// RUN:   -B%S/Inputs/lld -mlinker-version=0 %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// RUN: %clang --target=x86_64-apple-darwin -### -fuse-ld=lld \
+// RUN:   --ld-path=%S/Inputs/lld/ld64.lld -mlinker-version=0 %s 2>&1 \
 // RUN:   | FileCheck %s
 
 // CHECK: "-demangle"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -621,13 +621,18 @@
   // --ld-path= takes precedence over -fuse-ld= and specifies the executable
   // name. -B, COMPILER_PATH and PATH and consulted if the value does not
   // contain a path component separator.
+  // -fuse-ld=lld can be used with --ld-path= to inform clang that the binary
+  // that --ld-path= points to is lld.
   if (const Arg *A = Args.getLastArg(options::OPT_ld_path_EQ)) {
 std::string Path(A->getValue());
 if (!Path.empty()) {
   if (llvm::sys::path::parent_path(Path).empty())
 Path = GetProgramPath(A->getValue());
-  if (llvm::sys::fs::can_execute(Path))
+  if (llvm::sys::fs::can_execute(Path)) {
+if (LinkerIsLLD)
+  *LinkerIsLLD = UseLinker == "lld";
 return std::string(Path);
+  }
 }
 getDriver().Diag(diag::err_drv_invalid_linker_name) << 
A->getAsString(Args);
 return GetProgramPath(getDefaultLinker());


Index: clang/test/Driver/darwin-ld-demangle-lld.c
===
--- clang/test/Driver/darwin-ld-demangle-lld.c
+++ clang/test/Driver/darwin-ld-demangle-lld.c
@@ -1,8 +1,12 @@
 // With -fuse-ld=lld, -demangle is always passed to the linker on Darwin.
 // REQUIRES: shell
 
-// RUN: %clang --target=x86_64-apple-darwin -### \
-// RUN:   -fuse-ld=lld -B%S/Inputs/lld -mlinker-version=0 %s 2>&1 \
+// RUN: %clang --target=x86_64-apple-darwin -### -fuse-ld=lld \
+// RUN:   -B%S/Inputs/lld -mlinker-version=0 %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// RUN: %clang --target=x86_64-apple-darwin -### -fuse-ld=lld \
+// RUN:   --ld-path=%S/Inputs/lld/ld64.lld -mlinker-version=0 %s 2>&1 \
 // RUN:   | FileCheck %s
 
 // CHECK: "-demangle"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -621,13 +621,18 @@
   // --ld-path= takes precedence over -fuse-ld= and specifies the executable
   // name. -B, COMPILER_PATH and PATH and consulted if the value does not
   // contain a path component separator.
+  // -fuse-ld=lld can be used with --ld-path= to inform clang that the binary
+  // that --ld-path= points to is lld.
   if (const Arg *A = Args.getLastArg(options::OPT_ld_path_EQ)) {
 std::string Path(A->getValue());
 if (!Path.empty()) {
   if (llvm::sys::path::parent_path(Path).empty())
 Path = GetProgramPath(A->getValue());
-  if (llvm::sys::fs::can_execute(Path))
+  if (llvm::sys::fs::can_execute(Path)) {
+if (LinkerIsLLD)
+  *LinkerIsLLD = UseLinker == "lld";
 return std::string(Path);
+  }
 }
 getDriver().Diag(diag::err_drv_invalid_linker_name) << A->getAsString(Args);
 return GetProgramPath(getDefaultLinker());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134529: [C++20][Clang] P2468R2 The Equality Operator You Are Looking For

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 created this revision.
Herald added a project: All.
usaxena95 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Implement
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html.

Primarily we now accept

  template struct CRTPBase {
bool operator==(const T&) const;
bool operator!=(const T&) const;
  };
  struct CRTP : CRTPBase {};
  bool cmp_crtp = CRTP() == CRTP();
  bool cmp_crtp2 = CRTP() != CRTP();

Open questions:

1. Symmetric == member without a != defined.

`struct S{ bool operator==(const S&);};`.
In principle we should not add a reversed== in such cases as this would
never yield a better candidate and always an ambiguity with itself.
We already don't add reversed == for non-member operator with symmetric
parameters. The following is already accepted.

  struct S{};
  bool operator==(const S&, const S&);
  S() == S();

My proposal will be to do the same for member==.

2. The following example from the proposal produces error while paper suggests 
that this should be accepted. ``` struct D {};

template bool operator==(D, T); // 4
// expected-note@-1 {{candidate function template not viable: no known 
conversion from 'int' to 'D' for 1st argument}}
inline namespace N {

  template bool operator!=(D, T);   // 5

}
bool d1 = 0 == D();

  I don't follow why this disallows the reverse #4.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134529

Files:
  clang/include/clang/Sema/Overload.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp

Index: clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp
===
--- clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp
+++ clang/test/CXX/over/over.match/over.match.funcs/over.match.oper/p3-2a.cpp
@@ -135,36 +135,117 @@
   };
   bool cmp_non_const = A() == A(); // expected-warning {{ambiguous}}
 
-  struct B {
-virtual bool operator==(const B&) const;
-  };
-  struct D : B {
-bool operator==(const B&) const override; // expected-note {{operator}}
-  };
-  bool cmp_base_derived = D() == D(); // expected-warning {{ambiguous}}
+} // namespace problem_cases
 
-  template struct CRTPBase {
-bool operator==(const T&) const; // expected-note {{operator}} expected-note {{reversed}}
-bool operator!=(const T&) const; // expected-note {{non-reversed}}
-  };
-  struct CRTP : CRTPBase {};
-  bool cmp_crtp = CRTP() == CRTP(); // expected-warning-re {{ambiguous despite there being a unique best viable function{{$}}
-  bool cmp_crtp2 = CRTP() != CRTP(); // expected-warning {{ambiguous despite there being a unique best viable function with non-reversed arguments}}
-
-  // Given a choice between a rewritten and non-rewritten function with the
-  // same parameter types, where the rewritten function is reversed and each
-  // has a better conversion for one of the two arguments, prefer the
-  // non-rewritten one.
-  using UBool = signed char; // ICU uses this.
-  struct ICUBase {
-virtual UBool operator==(const ICUBase&) const;
-UBool operator!=(const ICUBase &arg) const { return !operator==(arg); }
-  };
-  struct ICUDerived : ICUBase {
-UBool operator==(const ICUBase&) const override; // expected-note {{declared here}} expected-note {{ambiguity is between}}
-  };
-  bool cmp_icu = ICUDerived() != ICUDerived(); // expected-warning {{ambiguous}} expected-warning {{'bool', not 'UBool'}}
+namespace P2468R2 {
+//=Problem cases prior to P2468R2 but now intentionally rejected=
+namespace no_more_problem_cases {
+struct B {
+  virtual bool operator==(const B&) const;
+};
+struct D : B {
+  bool operator==(const B&) const override; // expected-note {{operator}}
+};
+bool cmp_base_derived = D() == D(); // expected-warning {{ambiguous}}
+
+// Reversed "3" not used because we find "2".
+// Rewrite != from "3" but warn that "chosen rewritten candidate must return cv-bool".
+using UBool = signed char;
+struct ICUBase {
+  virtual UBool operator==(const ICUBase&) const; // 1.
+  UBool operator!=(const ICUBase &arg) const { return !operator==(arg); } // 2.
+};
+struct ICUDerived : ICUBase {
+  // 3.
+  UBool operator==(const ICUBase&) const override; // expected-note {{declared here}}
+};
+bool cmp_icu = ICUDerived() != ICUDerived(); // expected-warning {{ISO C++20 requires return type of selected 'operator==' function for rewritten '!=' comparison to be 'bool', not 'UBool' (aka 'signed char')}}
+} // namespace no_more_problem_cases
+//=Accepted by P2468R2=
+// 1
+struct S {
+  bool operator==(const S&) { return true; }
+  bool operator!=(const S&) { return false; }
+};
+bool ts = S{} != S{};
+// 2
+template struct CRTPBase {
+  bool operator==(const T&) const;
+  bool operator!=(const T&) const;
+};
+struct CRTP

[PATCH] D133659: [Clang] P1169R4: static operator()

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1037-1041
+def err_static_mutable_lambda : Error<
+  "lambda cannot be both mutable and static">;
+def err_static_lambda_captures : Error<
+  "a static lambda cannot have any captures">;
+def note_lambda_captures : Note<"captures declared here">;

cor3ntin wrote:
> royjacobson wrote:
> > aaron.ballman wrote:
> > > royjacobson wrote:
> > > > aaron.ballman wrote:
> > > > > royjacobson wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > These are semantic errors, not parsing ones. This means these 
> > > > > > > will be diagnosed when parsing the lambda rather than when 
> > > > > > > instantiating it. I don't think that matters for the cast of 
> > > > > > > combining `mutable` and `static`, but I'm less certain about 
> > > > > > > "have any captures" because of cases like:
> > > > > > > ```
> > > > > > > template 
> > > > > > > auto func(Types... Ts) {
> > > > > > >   return [Ts...] { return 1; };
> > > > > > > }
> > > > > > > 
> > > > > > > int main() {
> > > > > > >   auto lambda = func();
> > > > > > > }
> > > > > > > ```
> > > > > > > I'm pretty sure that lambda has no captures for that call, but it 
> > > > > > > could have captures depending on the instantiation.
> > > > > > > 
> > > > > > > Actually, from some off-list discussion with @erichkeane, even 
> > > > > > > mutable and static are a problem in code like:
> > > > > > > ```
> > > > > > > template 
> > > > > > > void func(T t) {
> > > > > > >   if constexpr (Something) {
> > > > > > > [](){};
> > > > > > >   } else {
> > > > > > > [t](){};
> > > > > > >   }
> > > > > > > ```
> > > > > > > where the lambda is in a discarded statement.
> > > > > > > 
> > > > > > > So I think these might need to change to be Sema diagnostics (and 
> > > > > > > we should add some additional test coverage).
> > > > > > From https://eel.is/c++draft/expr.prim.lambda.general#4 
> > > > > > 
> > > > > > > If the lambda-specifier-seq contains static, there shall be no 
> > > > > > > lambda-capture
> > > > > > 
> > > > > > So this should be a parsing error. Or maybe I don't understand what 
> > > > > > you're saying. There are no static lambdas in your examples so I'm 
> > > > > > not sure how they're related.
> > > > > > 
> > > > > > So this should be a parsing error. Or maybe I don't understand what 
> > > > > > you're saying. 
> > > > > 
> > > > > Parsing errors are where the grammar disallows something, generally. 
> > > > > The rest are semantic diagnostics (e.g., we can parse the construct 
> > > > > just fine, but we diagnose when turning it into an AST node because 
> > > > > that's the point at which we have complete information about what 
> > > > > we've parsed).
> > > > > 
> > > > > That said, my concern was mostly around SFINAE situations. My 
> > > > > recollection is that SFINAE traps do not cover parsing errors only 
> > > > > type substitution errors. So for my first example, I would expect 
> > > > > there to be no parsing error despite specifying a capture list 
> > > > > because that capture list can be empty when the pack is empty, but we 
> > > > > would get a SFINAE diagnostic when rebuilding declaration during 
> > > > > template instantiation if the pack was not empty.
> > > > > 
> > > > > >  There are no static lambdas in your examples so I'm not sure how 
> > > > > > they're related.
> > > > > 
> > > > > Sorry, I was being lazy with my examples and showing more about the 
> > > > > capture list. Consider:
> > > > > ```
> > > > > template 
> > > > > auto func(Types... Ts) {
> > > > >   return [Ts...] static { return 1; };
> > > > > }
> > > > > 
> > > > > int main() {
> > > > >   auto lambda = func();
> > > > > }
> > > > > ```
> > > > > 
> > > > Like I said,
> > > > 
> > > > > If the lambda-specifier-seq contains static, there shall be no 
> > > > > lambda-capture
> > > > 
> > > > `Ts...` is still a syntactic `lambda-capture`, even if it's 
> > > > instantiated as an empty pack. I don't see how that's not a parsing 
> > > > error.
> > > Ah, I think I maybe see where the confusion is coming in, now: you think 
> > > my example should be diagnosed and I think my example should be accepted.
> > > 
> > > Based on the standards wording, I think you're right. The standard 
> > > specifically uses "lambda-capture" as a grammar term, so it *is* a 
> > > parsing error at that point.
> > > 
> > > Based on my understanding of the intent behind the feature, I think I'm 
> > > right and there's a core issue here. I don't think we intended to 
> > > prohibit empty packs from being captured as non-SFINAEable error (and in 
> > > off-list talks with @erichkeane, he agrees). as that allows different 
> > > specializations of the function containing the lambda, which could be of 
> > > use. However, I'm not 100% sure on the intent. CC @hubert.reinterpretcast 
> > > as the C++ standards conformance code owner to see if he 

[PATCH] D134461: [Clang] Warn when trying to deferencing void pointers in C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:6922
 def ext_typecheck_indirection_through_void_pointer : ExtWarn<
-  "ISO C++ does not allow indirection on operand of type %0">,
+  "ISO %select{C++|C}0 does not allow indirection on operand of type %1">,
   InGroup>;

Swapping these so the logic is more straightforward elsewhere.



Comment at: clang/lib/Sema/SemaExpr.cpp:14538-14544
+if (S.getLangOpts().CPlusPlus)
+  S.Diag(OpLoc, diag::ext_typecheck_indirection_through_void_pointer)
+  << /* C++ mode */ 0 << OpTy << Op->getSourceRange();
+else if (!S.getLangOpts().CPlusPlus)
+  if (!(S.getLangOpts().C99 && IsAfterAmp))
+S.Diag(OpLoc, diag::ext_typecheck_indirection_through_void_pointer)
+<< /* C mode */ 1 << OpTy << Op->getSourceRange();

Simplifying the logic a bit.



Comment at: clang/test/C/drs/dr1xx.c:140
   /* The behavior changed between C89 and C99. */
-  (void)&*p; /* c89only-warning {{ISO C forbids taking the address of an 
expression of type 'void'}} */
+  (void)&*p; /* c89only-warning {{ISO C forbids taking the address of an 
expression of type 'void'}} c89only-warning {{ISO C does not allow indirection 
on operand of type 'void *'}} */
   /* The behavior of all three of these is undefined. */

Can you switch all of the warning changes in this file to use this style where 
each expected diagnostic is on its own line? That makes it easier to notice 
which diagnostics happen on the line (it's easy to lose sight of the trailing 
expected diagnostics otherwise).



Comment at: clang/test/C/drs/dr1xx.c:143
+  (void)*p; /* expected-warning {{ISO C does not allow indirection on operand 
of type 'void *'}}*/
+  (void)&(*p); /* c89only-warning {{ISO C forbids taking the address of an 
expression of type 'void'}} expected-warning {{ISO C does not allow indirection 
on operand of type 'void *'}}*/
+  (void)(i ? *p : *p); /* expected-warning {{ISO C does not allow indirection 
on operand of type 'void *'}} expected-warning {{ISO C does not allow 
indirection on operand of type 'void *'}}*/

This looks wrong to me -- this should be an `expected-warning` instead of a 
`c89only-warning`, same as two lines above, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134461

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

[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

[Pavel Samolysov via Phabricator via cfe-commits]

psamolysov added a comment.

@aeubanks Thank you very much for the re-landing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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

[PATCH] D133574: [C2x] reject type definitions in offsetof

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:279-280
   ``%hd``.
+- Reject type definitions in the ``type`` argument of ``__builtin_offsetof`` 
+  according to `WG14 N2350 
`_.
 

You should move this one down to the C2x Feature Support section instead, since 
it's a C2x paper.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:1650
+def err_type_defined_in_offsetof : Error<
+  "%0 cannot be defined in '__builtin_offsetof'">;
 

We might want this change, we might not -- can you test the diagnostic behavior 
when using `#include `? Does it print `__builtin_offsetof` in the 
following example?
```
#include 

int main() {
  return offsetof(struct S { int a; }, a);
}
```
when executed with `clang -fsyntax-only -ffreestanding -std=c2x test.c`

If it prints the builtin name, I think we'll want to look at the builtin token 
to see if it was expanded from a macro named `offsetof` to improve the 
diagnostic quality.



Comment at: clang/lib/Sema/SemaDecl.cpp:17034
+Diag(New->getLocation(), diag::err_type_defined_in_offsetof)
+<< Context.getTagDeclType(New);
+Invalid = true;

You should be able to pass in the `TagDecl` directly because the diagnostics 
engine knows how to print a `NamedDecl`.



Comment at: clang/test/Sema/offsetof.c:73-75
+// Reject definitions in __builtin_offsetof
+// https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
+int test_definition(void) {

Can you move this into a test named `clang/test/C/C2x/n2350.c` which looks like 
the other tests in that directory? That's the testing directory we're putting 
some basic validation tests for C papers we've implemented so that we can 
better track what features we claim to support.



Comment at: clang/test/SemaCXX/offsetof.cpp:93
+int a;
+struct B
+{

I'd like a FIXME comment here about wanting to diagnose this someday.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133574

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

[PATCH] D134416: Allow getting template args for ClassTemplateSpecializations

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM! I can fix up the minor nit with the release note formatting when I land 
on your behalf.




Comment at: clang/docs/ReleaseNotes.rst:407-408
+  ``clang_Cursor_getTemplateArgumentType``, 
``clang_Cursor_getTemplateArgumentValue`` and 
+  ``clang_Cursor_getTemplateArgumentUnsignedValue`` now work on struct, class 
and partial template specialization
+  cursors in addition to function cursors.
 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134416

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

[PATCH] D134507: [Clang] add missing ClangABICompat check

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

Hi @ychen I saw you updated the patch description, thanks.
IIUC, the change causes some difference in the interpretation of particular 
template stuff.  Would this be clearer if the BEFORE-15/AFTER-15 test cases 
used the same template construct?  Currently they are different so it's hard to 
work out the effect of the change.  In particular, naively I see different 
mangled names which makes me concerned that there _is_ in fact a net change to 
mangling.

I'll observe that D128745  updated the 
release notes, but not in the most useful way; it cites DRs without any 
explanation of what they do, and with no links.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134507

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

[PATCH] D125683: [runtimes] Replace LIBCXX_ENABLE_STATIC_ABI_LIBRARY & friends by a new LIBCXX_CXX_ABI choice

[Nikita Popov via Phabricator via cfe-commits]

nikic requested changes to this revision.
nikic added a comment.
This revision now requires changes to proceed.

I have some concerns about this change:

- It makes it fundamentally impossible to link against a static 
system-libcxxabi (or any other `LIBCXX_CXX_ABI` option). This is currently 
already broken (https://github.com/llvm/llvm-project/issues/57759), but used to 
work prior to LLVM 15.
- It makes it fundamentally impossible to use a linker script for the shared 
library while linking the abi library into the static library. I think this 
currently doesn't work either, but would be trivial to support. (I was going to 
work on this when I found this revision.)

I think both of these points highlight that `LIBCXX_CXX_ABI=libcxxabi-objects` 
is not the correct representation for this functionality.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125683

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

[PATCH] D133574: [C2x] reject type definitions in offsetof

[YingChi Long via Phabricator via cfe-commits]

inclyc added a comment.

Emm, is it necessary to add a `LangOpts` check so that this change only applies 
to c2x? If clang was invoked without `-std=c2x`, should we just accept 
`offsetof` with definitions?




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:1650
+def err_type_defined_in_offsetof : Error<
+  "%0 cannot be defined in '__builtin_offsetof'">;
 

aaron.ballman wrote:
> We might want this change, we might not -- can you test the diagnostic 
> behavior when using `#include `? Does it print `__builtin_offsetof` 
> in the following example?
> ```
> #include 
> 
> int main() {
>   return offsetof(struct S { int a; }, a);
> }
> ```
> when executed with `clang -fsyntax-only -ffreestanding -std=c2x test.c`
> 
> If it prints the builtin name, I think we'll want to look at the builtin 
> token to see if it was expanded from a macro named `offsetof` to improve the 
> diagnostic quality.
```
local/offsetofcc.c:4:26: error: 'struct S' cannot be defined in 
'__builtin_offsetof'
  return offsetof(struct S { int a; }, a);
 ^
1 error generated.
```
> If it prints the builtin name, I think we'll want to look at the builtin 
> token to see if it was expanded from a macro named offsetof to improve the 
> diagnostic quality.

OK


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133574

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

[PATCH] D134157: [Clang][LoongArch] Add inline asm support for constraints f/l/I/K

[Renato Golin via Phabricator via cfe-commits]

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

Thanks, looks good to me!

I wouldn't split this in two commits. One of the benefits of having a monorepo 
is that we don't have to do that anymore. :)




Comment at: llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp:2064
+uint64_t CVal = C->getSExtValue();
+if (isInt<16>(CVal))
+  Ops.push_back(

SixWeining wrote:
> rengolin wrote:
> > Shouldn't this break if the constant isn't in the right type? What happens 
> > if it isn't? 
> > 
> > It seems it just doesn't append the operand and return. Wouldn't that just 
> > break the op's format?
> > 
> > On Arm, the logic is simpler:
> >  - Iterate through all constraints, validating the input
> >  - If valie, set the Result and append to the Op at the end
> >  - Otherwise bail and let `TargetLowering::LowerAsmOperandForConstraint` 
> > handle it.
> If the constant isn't in the right type, SelectionDAGBuilder will emit an 
> error. There is a test 
> `llvm/test/CodeGen/LoongArch/inline-asm-constraint-error.ll` checking this.
> ```
> // CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
>8987   if (OpInfo.ConstraintType == TargetLowering::C_Immediate ||
>8988   OpInfo.ConstraintType == TargetLowering::C_Other) {
>8989 std::vector Ops;
>8990 TLI.LowerAsmOperandForConstraint(InOperandVal, 
> OpInfo.ConstraintCode,
>8991   Ops, DAG);
>8992 if (Ops.empty()) {
>8993   if (OpInfo.ConstraintType == TargetLowering::C_Immediate)
>8994 if (isa(InOperandVal)) {
>8995   emitInlineAsmError(Call, "value out of range for 
> constraint '" +
>8996
> Twine(OpInfo.ConstraintCode) + "'");
>8997   return;
>8998 }
> ```
> 
> 
> For arm/aarch64, if the input is invalid, the function also directly return.
> ```
> // AArch64ISelLowering.cpp
>9583 case 'K':
>9584   if (AArch64_AM::isLogicalImmediate(CVal, 32))
>9585 break;
>9586   return;
>9587 case 'L':
>9588   if (AArch64_AM::isLogicalImmediate(CVal, 64))
>9589 break;
>9590   return;
> ```
> 
> For LoongArch, `TargetLowering::LowerAsmOperandForConstraint` is only called 
> when the constraint is not one of `l/I/K`.
Ah, excellent. And the error is good too, so looks good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134157

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

[PATCH] D133586: [clang] initialize type qualifiers for FunctionNoProtoType

[Richard Howell via Phabricator via cfe-commits]

rmaz updated this revision to Diff 462483.
rmaz added a comment.

Return default Qualifiers for FunctionNoProtoType


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133586

Files:
  clang/include/clang/AST/Type.h
  clang/unittests/AST/DeclTest.cpp


Index: clang/unittests/AST/DeclTest.cpp
===
--- clang/unittests/AST/DeclTest.cpp
+++ clang/unittests/AST/DeclTest.cpp
@@ -354,3 +354,25 @@
 
   EXPECT_TRUE(getFooValue->isInlined());
 }
+
+TEST(Decl, NoProtoFunctionDeclAttributes) {
+  llvm::Annotations Code(R"(
+void f();
+)");
+
+  auto AST = tooling::buildASTFromCodeWithArgs(
+  Code.code(),
+  /*Args=*/{"-target", "i386-apple-darwin", "-x", "objective-c",
+"-std=c89"});
+  ASTContext &Ctx = AST->getASTContext();
+
+  auto *f = selectFirst(
+  "f", match(functionDecl(hasName("f")).bind("f"), Ctx));
+
+  const auto *FPT = f->getType()->getAs();
+
+  // Functions without prototypes always have 0 initialized qualifiers
+  EXPECT_FALSE(FPT->isConst());
+  EXPECT_FALSE(FPT->isVolatile());
+  EXPECT_FALSE(FPT->isRestrict());
+}
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -1647,6 +1647,7 @@
   /// Only common bits are stored here. Additional uncommon bits are stored
   /// in a trailing object after FunctionProtoType.
   class FunctionTypeBitfields {
+friend class FunctionNoProtoType;
 friend class FunctionProtoType;
 friend class FunctionType;
 
@@ -3892,7 +3893,10 @@
   }
 
   Qualifiers getFastTypeQuals() const {
-return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+if (isFunctionProtoType())
+  return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+else
+  return Qualifiers();
   }
 
 public:


Index: clang/unittests/AST/DeclTest.cpp
===
--- clang/unittests/AST/DeclTest.cpp
+++ clang/unittests/AST/DeclTest.cpp
@@ -354,3 +354,25 @@
 
   EXPECT_TRUE(getFooValue->isInlined());
 }
+
+TEST(Decl, NoProtoFunctionDeclAttributes) {
+  llvm::Annotations Code(R"(
+void f();
+)");
+
+  auto AST = tooling::buildASTFromCodeWithArgs(
+  Code.code(),
+  /*Args=*/{"-target", "i386-apple-darwin", "-x", "objective-c",
+"-std=c89"});
+  ASTContext &Ctx = AST->getASTContext();
+
+  auto *f = selectFirst(
+  "f", match(functionDecl(hasName("f")).bind("f"), Ctx));
+
+  const auto *FPT = f->getType()->getAs();
+
+  // Functions without prototypes always have 0 initialized qualifiers
+  EXPECT_FALSE(FPT->isConst());
+  EXPECT_FALSE(FPT->isVolatile());
+  EXPECT_FALSE(FPT->isRestrict());
+}
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -1647,6 +1647,7 @@
   /// Only common bits are stored here. Additional uncommon bits are stored
   /// in a trailing object after FunctionProtoType.
   class FunctionTypeBitfields {
+friend class FunctionNoProtoType;
 friend class FunctionProtoType;
 friend class FunctionType;
 
@@ -3892,7 +3893,10 @@
   }
 
   Qualifiers getFastTypeQuals() const {
-return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+if (isFunctionProtoType())
+  return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+else
+  return Qualifiers();
   }
 
 public:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e8c78d8 - Allow getting template args for ClassTemplateSpecializations

[Aaron Ballman via cfe-commits]

Author: Anders Langlands
Date: 2022-09-23T11:06:14-04:00
New Revision: e8c78d8528a6b7a96c93ea42749a3c0a03cd9b08

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

LOG: Allow getting template args for ClassTemplateSpecializations

Modifies clang_Cursor_getNumTemplateArguments() and friends to work on
Struct, Class and ClassTemplatePartialSpecialization decls as well as
functions.

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang-c/Index.h
clang/test/Index/get-cursor.cpp
clang/test/Index/index-templates.cpp
clang/test/Index/print-display-names.cpp
clang/test/Index/print-type.cpp
clang/tools/c-index-test/c-index-test.c
clang/tools/libclang/CXCursor.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index a208af832c7b..ed262823d004 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -424,6 +424,10 @@ libclang
   the behavior of ``QualType::getNonReferenceType`` for ``CXType``.
 - Introduced the new function ``clang_CXXMethod_isDeleted``, which queries
   whether the method is declared ``= delete``.
+- ``clang_Cursor_getNumTemplateArguments``, 
``clang_Cursor_getTemplateArgumentKind``, 
+  ``clang_Cursor_getTemplateArgumentType``, 
``clang_Cursor_getTemplateArgumentValue`` and 
+  ``clang_Cursor_getTemplateArgumentUnsignedValue`` now work on struct, class,
+  and partial template specialization cursors in addition to function cursors.
 
 Static Analyzer
 ---

diff  --git a/clang/include/clang-c/Index.h b/clang/include/clang-c/Index.h
index a9810aa4cf9d..3b0c5f6a68b6 100644
--- a/clang/include/clang-c/Index.h
+++ b/clang/include/clang-c/Index.h
@@ -3591,8 +3591,8 @@ enum CXTemplateArgumentKind {
 };
 
 /**
- *Returns the number of template args of a function decl representing a
- * template specialization.
+ * Returns the number of template args of a function, struct, or class decl
+ * representing a template specialization.
  *
  * If the argument cursor cannot be converted into a template function
  * declaration, -1 is returned.
@@ -3611,8 +3611,9 @@ CINDEX_LINKAGE int 
clang_Cursor_getNumTemplateArguments(CXCursor C);
 /**
  * Retrieve the kind of the I'th template argument of the CXCursor C.
  *
- * If the argument CXCursor does not represent a FunctionDecl, an invalid
- * template argument kind is returned.
+ * If the argument CXCursor does not represent a FunctionDecl, StructDecl, or
+ * ClassTemplatePartialSpecialization, an invalid template argument kind is
+ * returned.
  *
  * For example, for the following declaration and specialization:
  *   template 
@@ -3631,9 +3632,9 @@ clang_Cursor_getTemplateArgumentKind(CXCursor C, unsigned 
I);
  * Retrieve a CXType representing the type of a TemplateArgument of a
  *  function decl representing a template specialization.
  *
- * If the argument CXCursor does not represent a FunctionDecl whose I'th
- * template argument has a kind of CXTemplateArgKind_Integral, an invalid type
- * is returned.
+ * If the argument CXCursor does not represent a FunctionDecl, StructDecl,
+ * ClassDecl or ClassTemplatePartialSpecialization whose I'th template argument
+ * has a kind of CXTemplateArgKind_Integral, an invalid type is returned.
  *
  * For example, for the following declaration and specialization:
  *   template 
@@ -3653,7 +3654,8 @@ CINDEX_LINKAGE CXType 
clang_Cursor_getTemplateArgumentType(CXCursor C,
  *  decl representing a template specialization) as a signed long long.
  *
  * It is undefined to call this function on a CXCursor that does not represent 
a
- * FunctionDecl or whose I'th template argument is not an integral value.
+ * FunctionDecl, StructDecl, ClassDecl or ClassTemplatePartialSpecialization
+ * whose I'th template argument is not an integral value.
  *
  * For example, for the following declaration and specialization:
  *   template 
@@ -3673,7 +3675,8 @@ CINDEX_LINKAGE long long 
clang_Cursor_getTemplateArgumentValue(CXCursor C,
  *  decl representing a template specialization) as an unsigned long long.
  *
  * It is undefined to call this function on a CXCursor that does not represent 
a
- * FunctionDecl or whose I'th template argument is not an integral value.
+ * FunctionDecl, StructDecl, ClassDecl or ClassTemplatePartialSpecialization or
+ * whose I'th template argument is not an integral value.
  *
  * For example, for the following declaration and specialization:
  *   template 

diff  --git a/clang/test/Index/get-cursor.cpp b/clang/test/Index/get-cursor.cpp
index 6c3c880b2d85..85e22212ea50 100644
--- a/clang/test/Index/get-cursor.cpp
+++ b/clang/test/Index/get-cursor.cpp
@@ -221,7 +221,7 @@ struct Z {
 // CHECK-TEMPLPARAM: 55:23

[PATCH] D134416: Allow getting template args for ClassTemplateSpecializations

[Aaron Ballman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe8c78d8528a6: Allow getting template args for 
ClassTemplateSpecializations (authored by anderslanglands, committed by 
aaron.ballman).

Changed prior to commit:
  https://reviews.llvm.org/D134416?vs=462392&id=462491#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134416

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang-c/Index.h
  clang/test/Index/get-cursor.cpp
  clang/test/Index/index-templates.cpp
  clang/test/Index/print-display-names.cpp
  clang/test/Index/print-type.cpp
  clang/tools/c-index-test/c-index-test.c
  clang/tools/libclang/CXCursor.cpp

Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -1353,34 +1353,43 @@
 }
 
 int clang_Cursor_getNumTemplateArguments(CXCursor C) {
-  if (clang_getCursorKind(C) != CXCursor_FunctionDecl) {
+  CXCursorKind kind = clang_getCursorKind(C);
+  if (kind != CXCursor_FunctionDecl && kind != CXCursor_StructDecl &&
+  kind != CXCursor_ClassDecl &&
+  kind != CXCursor_ClassTemplatePartialSpecialization) {
 return -1;
   }
 
-  const FunctionDecl *FD =
-  llvm::dyn_cast_or_null(getCursorDecl(C));
-  if (!FD) {
-return -1;
+  if (const auto *FD =
+  llvm::dyn_cast_if_present(getCursorDecl(C))) {
+const FunctionTemplateSpecializationInfo *SpecInfo =
+FD->getTemplateSpecializationInfo();
+if (!SpecInfo) {
+  return -1;
+}
+return SpecInfo->TemplateArguments->size();
   }
 
-  const FunctionTemplateSpecializationInfo *SpecInfo =
-  FD->getTemplateSpecializationInfo();
-  if (!SpecInfo) {
-return -1;
+  if (const auto *SD =
+  llvm::dyn_cast_if_present(
+  getCursorDecl(C))) {
+return SD->getTemplateArgs().size();
   }
 
-  return SpecInfo->TemplateArguments->size();
+  return -1;
 }
 
 enum CXGetTemplateArgumentStatus {
   /** The operation completed successfully */
   CXGetTemplateArgumentStatus_Success = 0,
 
-  /** The specified cursor did not represent a FunctionDecl. */
-  CXGetTemplateArgumentStatus_CursorNotFunctionDecl = -1,
+  /** The specified cursor did not represent a FunctionDecl or
+  ClassTemplateSpecializationDecl. */
+  CXGetTemplateArgumentStatus_CursorNotCompatibleDecl = -1,
 
-  /** The specified cursor was not castable to a FunctionDecl. */
-  CXGetTemplateArgumentStatus_BadFunctionDeclCast = -2,
+  /** The specified cursor was not castable to a FunctionDecl or
+  ClassTemplateSpecializationDecl. */
+  CXGetTemplateArgumentStatus_BadDeclCast = -2,
 
   /** A NULL FunctionTemplateSpecializationInfo was retrieved. */
   CXGetTemplateArgumentStatus_NullTemplSpecInfo = -3,
@@ -1391,28 +1400,42 @@
 
 static int clang_Cursor_getTemplateArgument(CXCursor C, unsigned I,
 TemplateArgument *TA) {
-  if (clang_getCursorKind(C) != CXCursor_FunctionDecl) {
-return CXGetTemplateArgumentStatus_CursorNotFunctionDecl;
+  CXCursorKind kind = clang_getCursorKind(C);
+  if (kind != CXCursor_FunctionDecl && kind != CXCursor_StructDecl &&
+  kind != CXCursor_ClassDecl &&
+  kind != CXCursor_ClassTemplatePartialSpecialization) {
+return -1;
   }
 
-  const FunctionDecl *FD =
-  llvm::dyn_cast_or_null(getCursorDecl(C));
-  if (!FD) {
-return CXGetTemplateArgumentStatus_BadFunctionDeclCast;
-  }
+  if (const auto *FD =
+  llvm::dyn_cast_if_present(getCursorDecl(C))) {
+
+const FunctionTemplateSpecializationInfo *SpecInfo =
+FD->getTemplateSpecializationInfo();
+if (!SpecInfo) {
+  return CXGetTemplateArgumentStatus_NullTemplSpecInfo;
+}
 
-  const FunctionTemplateSpecializationInfo *SpecInfo =
-  FD->getTemplateSpecializationInfo();
-  if (!SpecInfo) {
-return CXGetTemplateArgumentStatus_NullTemplSpecInfo;
+if (I >= SpecInfo->TemplateArguments->size()) {
+  return CXGetTemplateArgumentStatus_InvalidIndex;
+}
+
+*TA = SpecInfo->TemplateArguments->get(I);
+return 0;
   }
 
-  if (I >= SpecInfo->TemplateArguments->size()) {
-return CXGetTemplateArgumentStatus_InvalidIndex;
+  if (const auto *SD =
+  llvm::dyn_cast_if_present(
+  getCursorDecl(C))) {
+if (I >= SD->getTemplateArgs().size()) {
+  return CXGetTemplateArgumentStatus_InvalidIndex;
+}
+
+*TA = SD->getTemplateArgs()[I];
+return 0;
   }
 
-  *TA = SpecInfo->TemplateArguments->get(I);
-  return 0;
+  return CXGetTemplateArgumentStatus_BadDeclCast;
 }
 
 enum CXTemplateArgumentKind clang_Cursor_getTemplateArgumentKind(CXCursor C,
Index: clang/tools/c-index-test/c-index-test.c
===
--- clang/tools/c-index-test/c-index-test.c
++

[PATCH] D134542: [Concepts] Recover properly from a RecoveryExpr in a concept

[Erich Keane via Phabricator via cfe-commits]

erichkeane created this revision.
erichkeane added a reviewer: clang-language-wg.
Herald added a project: All.
erichkeane requested review of this revision.

Discovered by reducing a different problem, we currently assert because
we failed to make the constraint expressions not dependent, since a
RecoveryExpr cannot be transformed.

This patch fixes that, and gets reasonably nice diagnostics by
introducing a concept (hah!) of "ContainsErrors" to the Satisfaction
types, which causes us to treat the candidate as non-viable.

However, just making THAT candidate non-viable would result in choosing
the 'next best' canddiate, which can result in awkward errors, where we
start evaluating a candidate that is not intended to be selected.
Because of this, and to make diagnostics more relevant, we now just
cause the entire lookup to result in a 'no-viable-candidates'.

This means we will only emit the list of candidates, rather than any
cascading failures.


https://reviews.llvm.org/D134542

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ASTConcept.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Overload.h
  clang/lib/AST/ASTConcept.cpp
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/SemaTemplate/concepts-recovery-expr.cpp

Index: clang/test/SemaTemplate/concepts-recovery-expr.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-recovery-expr.cpp
@@ -0,0 +1,182 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+// expected-error@+1{{use of undeclared identifier 'b'}}
+constexpr bool CausesRecoveryExpr = b;
+
+template
+concept ReferencesCRE = CausesRecoveryExpr;
+
+template requires CausesRecoveryExpr // #NVC1REQ
+void NoViableCands1(){} // #NVC1
+
+template requires ReferencesCRE // #NVC2REQ
+void NoViableCands2(){} // #NVC2
+
+template // #NVC3REQ
+void NoViableCands3(){} // #NVC3
+
+void NVCUse() {
+  NoViableCands1();
+  // expected-error@-1 {{no matching function for call to 'NoViableCands1'}}
+  // expected-note@#NVC1{{candidate template ignored: constraints not satisfied}}
+  // expected-note@#NVC1REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+
+  NoViableCands2();
+  // expected-error@-1 {{no matching function for call to 'NoViableCands2'}}
+  // expected-note@#NVC2{{candidate template ignored: constraints not satisfied}}
+  // expected-note@#NVC2REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+  NoViableCands3();
+  // expected-error@-1 {{no matching function for call to 'NoViableCands3'}}
+  // expected-note@#NVC3{{candidate template ignored: constraints not satisfied}}
+  // expected-note@#NVC3REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+}
+
+template requires CausesRecoveryExpr // #OVC1REQ
+void OtherViableCands1(){} // #OVC1
+
+template
+void OtherViableCands1(){} // #OVC1_ALT
+
+template requires ReferencesCRE // #OVC2REQ
+void OtherViableCands2(){} // #OVC2
+
+template
+void OtherViableCands2(){} // #OVC2_ALT
+
+template // #OVC3REQ
+void OtherViableCands3(){} // #OVC3
+template
+void OtherViableCands3(){} // #OVC3_ALT
+
+void OVCUse() {
+  OtherViableCands1();
+  // expected-error@-1 {{no matching function for call to 'OtherViableCands1'}}
+  // expected-note@#OVC1_ALT {{candidate function}}
+  // expected-note@#OVC1 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OVC1REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+  OtherViableCands2();
+  // expected-error@-1 {{no matching function for call to 'OtherViableCands2'}}
+  // expected-note@#OVC2_ALT {{candidate function}}
+  // expected-note@#OVC2 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OVC2REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+  OtherViableCands3();
+  // expected-error@-1 {{no matching function for call to 'OtherViableCands3'}}
+  // expected-note@#OVC3_ALT {{candidate function}}
+  // expected-note@#OVC3 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OVC3REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+}
+
+template requires CausesRecoveryExpr // #OBNVC1REQ
+void OtherBadNoViableCands1(){} // #OBNVC1
+
+template requires false // #OBNVC1REQ_ALT
+void OtherBadNoViableCands1(){} // #OBNVC1_ALT
+
+template requires ReferencesCRE // #OBNVC2REQ
+void OtherBadNoViableCands2(){} // #OBNVC2
+
+template requires false// #OBNVC2REQ_ALT
+void OtherBadNo

[PATCH] D134544: [clang-cl] Implement /ZH: flag

[Nico Weber via Phabricator via cfe-commits]

thakis created this revision.
thakis added a reviewer: hans.
Herald added a project: All.
thakis requested review of this revision.
Herald added a subscriber: MaskRay.

Based on a patch by Arlo Siemsen (D98438 )!


https://reviews.llvm.org/D134544

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/debug-info-file-checksum.c
  clang/test/Driver/cl-options.c

Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -395,9 +395,6 @@
 // RUN:/wd1234 \
 // RUN:/Wv \
 // RUN:/Wv:17 \
-// RUN:/ZH:MD5 \
-// RUN:/ZH:SHA1 \
-// RUN:/ZH:SHA_256 \
 // RUN:/Zm \
 // RUN:/Zo \
 // RUN:/Zo- \
@@ -578,6 +575,17 @@
 // Z7_gdwarf: "-debug-info-kind=constructor"
 // Z7_gdwarf: "-dwarf-version=
 
+// RUN: %clang_cl /ZH:MD5 /c -### -- %s 2>&1 | FileCheck -check-prefix=ZH_MD5 %s
+// ZH_MD5: "-gsrc-hash-algorithm=md5"
+
+// RUN: %clang_cl /ZH:SHA1 /c -### -- %s 2>&1 \
+// RUN: | FileCheck -check-prefix=ZH_SHA1 %s
+// ZH_SHA1: "-gsrc-hash-algorithm=sha1"
+
+// RUN: %clang_cl /ZH:SHA_256 /c -### -- %s 2>&1 \
+// RUN: | FileCheck -check-prefix=ZH_SHA256 %s
+// ZH_SHA256: "-gsrc-hash-algorithm=sha256"
+
 // RUN: %clang_cl -fmsc-version=1800 -TP -### -- %s 2>&1 | FileCheck -check-prefix=CXX11 %s
 // CXX11: -std=c++11
 
Index: clang/test/CodeGen/debug-info-file-checksum.c
===
--- clang/test/CodeGen/debug-info-file-checksum.c
+++ clang/test/CodeGen/debug-info-file-checksum.c
@@ -1,9 +1,21 @@
+// RUN: %clang -emit-llvm -S -g -gcodeview -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
+// RUN: %clang -emit-llvm -S -g -gcodeview -gsrc-hash-algorithm=md5 -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
+// RUN: %clang -emit-llvm -S -g -gcodeview -gsrc-hash-algorithm=sha1 -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - \
+// RUN: | FileCheck --check-prefix=SHA1 %s
+// RUN: %clang -emit-llvm -S -g -gcodeview -gsrc-hash-algorithm=sha256 -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - \
+// RUN: | FileCheck --check-prefix=SHA256 %s
 // RUN: %clang -emit-llvm -S -g -gcodeview -x c %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
 // RUN: %clang -emit-llvm -S -gdwarf-5 -x c %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
 
 // Check that "checksum" is created correctly for the compiled file.
 
 // CHECK: !DIFile(filename:{{.*}}, directory:{{.*}}, checksumkind: CSK_MD5, checksum: "a3b7d27af071accdeccaa933fc603608")
+// SHA1: !DIFile(filename:{{.*}}, directory:{{.*}}, checksumkind: CSK_SHA1, checksum: "6f6eeaba705ad6db6fbb05c2cbcf3cbb3e374bcd")
+// SHA256: !DIFile(filename:{{.*}}, directory:{{.*}}, checksumkind: CSK_SHA256, checksum: "2d49b53859e57898a0f8c16ff1fa4d99306b8ec28d65cf7577109761f0d56197")
 
 // Ensure #line directives (in already pre-processed files) do not emit checksums
 // RUN: %clang -emit-llvm -S -g -gcodeview -x c %S/Inputs/debug-info-file-checksum-pre.cpp -o - | FileCheck %s --check-prefix NOCHECKSUM
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4389,6 +4389,11 @@
 }
   }
 
+  if (const Arg *A = Args.getLastArg(options::OPT_gsrc_hash_algorithm_EQ)) {
+StringRef v = A->getValue();
+CmdArgs.push_back(Args.MakeArgString("-gsrc-hash-algorithm=" + v));
+  }
+
   if (Args.hasFlag(options::OPT_fdebug_ranges_base_address,
options::OPT_fno_debug_ranges_base_address, false)) {
 CmdArgs.push_back("-fdebug-ranges-base-address");
Index: clang/lib/CodeGen/CGDebugInfo.h
===
--- clang/lib/CodeGen/CGDebugInfo.h
+++ clang/lib/CodeGen/CGDebugInfo.h
@@ -631,7 +631,7 @@
 
   /// Compute the file checksum debug info for input file ID.
   Optional
-  computeChecksum(FileID FID, SmallString<32> &Checksum) const;
+  computeChecksum(FileID FID, SmallString<64> &Checksum) const;
 
   /// Get the source of the given file ID.
   Optional getSource(const SourceManager &SM, FileID FID);
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -48,6 +48,8 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/SHA1.h"
+#include "llvm/Support/SHA256.h"
 #include "llvm/Support/TimeProfiler.h"
 using namespace clang;
 using namespace

[PATCH] D98438: Clang: Allow selecting the hash algorithm for file checksums in debug info.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.
Herald added a subscriber: MaskRay.
Herald added a project: All.

I addressed pending comments, did some other minor tweaks, and uploaded the 
modified diff to D134544 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98438

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

[PATCH] D134304: [Docs] [HLSL] Add IR reference for HLSL

[Chris Bieneman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd20f9f8d2177: [Docs] [HLSL] Add IR reference for HLSL 
(authored by beanz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134304

Files:
  clang/docs/HLSL/HLSLDocs.rst
  clang/docs/HLSL/HLSLIRReference.rst


Index: clang/docs/HLSL/HLSLIRReference.rst
===
--- /dev/null
+++ clang/docs/HLSL/HLSLIRReference.rst
@@ -0,0 +1,31 @@
+=
+HLSL IR Reference
+=
+
+.. contents::
+   :local:
+
+Introduction
+
+
+The goal of this document is to provide a reference for all the special purpose
+IR metadata and attributes used by the HLSL code generation path.
+
+IR Metadata
+===
+
+``hlsl.uavs``
+-
+
+The ``hlsl.uavs`` metadata is a list of all the external global variables that
+represent UAV resources.
+
+Function Attributes
+===
+
+``hlsl.shader``
+---
+
+The ``hlsl.shader`` function attribute is a string attribute applied to entry
+functions. The value is the string representation of the shader stage (i.e.
+``compute``, ``pixel``, etc).
Index: clang/docs/HLSL/HLSLDocs.rst
===
--- clang/docs/HLSL/HLSLDocs.rst
+++ clang/docs/HLSL/HLSLDocs.rst
@@ -11,5 +11,6 @@
 .. toctree::
:maxdepth: 1
 
+   HLSLIRReference
ResourceTypes
EntryFunctions


Index: clang/docs/HLSL/HLSLIRReference.rst
===
--- /dev/null
+++ clang/docs/HLSL/HLSLIRReference.rst
@@ -0,0 +1,31 @@
+=
+HLSL IR Reference
+=
+
+.. contents::
+   :local:
+
+Introduction
+
+
+The goal of this document is to provide a reference for all the special purpose
+IR metadata and attributes used by the HLSL code generation path.
+
+IR Metadata
+===
+
+``hlsl.uavs``
+-
+
+The ``hlsl.uavs`` metadata is a list of all the external global variables that
+represent UAV resources.
+
+Function Attributes
+===
+
+``hlsl.shader``
+---
+
+The ``hlsl.shader`` function attribute is a string attribute applied to entry
+functions. The value is the string representation of the shader stage (i.e.
+``compute``, ``pixel``, etc).
Index: clang/docs/HLSL/HLSLDocs.rst
===
--- clang/docs/HLSL/HLSLDocs.rst
+++ clang/docs/HLSL/HLSLDocs.rst
@@ -11,5 +11,6 @@
 .. toctree::
:maxdepth: 1
 
+   HLSLIRReference
ResourceTypes
EntryFunctions
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] d20f9f8 - [Docs] [HLSL] Add IR reference for HLSL

[Chris Bieneman via cfe-commits]

Author: Chris Bieneman
Date: 2022-09-23T10:29:54-05:00
New Revision: d20f9f8d2177cd02184bb2c2794af398ba355f61

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

LOG: [Docs] [HLSL] Add IR reference for HLSL

HLSL uses a variety of named IR metadata and attributes to convey
additional information from the frontend to the backend. This document
tries to capture and document the named annotations to provide a
reference for future contributors.

Reviewed By: python3kgae

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

Added: 
clang/docs/HLSL/HLSLIRReference.rst

Modified: 
clang/docs/HLSL/HLSLDocs.rst

Removed: 




diff  --git a/clang/docs/HLSL/HLSLDocs.rst b/clang/docs/HLSL/HLSLDocs.rst
index 2cfe631da939..a02dd2e8a962 100644
--- a/clang/docs/HLSL/HLSLDocs.rst
+++ b/clang/docs/HLSL/HLSLDocs.rst
@@ -11,5 +11,6 @@ HLSL Design and Implementation
 .. toctree::
:maxdepth: 1
 
+   HLSLIRReference
ResourceTypes
EntryFunctions

diff  --git a/clang/docs/HLSL/HLSLIRReference.rst 
b/clang/docs/HLSL/HLSLIRReference.rst
new file mode 100644
index ..c0d8d33f33bf
--- /dev/null
+++ b/clang/docs/HLSL/HLSLIRReference.rst
@@ -0,0 +1,31 @@
+=
+HLSL IR Reference
+=
+
+.. contents::
+   :local:
+
+Introduction
+
+
+The goal of this document is to provide a reference for all the special purpose
+IR metadata and attributes used by the HLSL code generation path.
+
+IR Metadata
+===
+
+``hlsl.uavs``
+-
+
+The ``hlsl.uavs`` metadata is a list of all the external global variables that
+represent UAV resources.
+
+Function Attributes
+===
+
+``hlsl.shader``
+---
+
+The ``hlsl.shader`` function attribute is a string attribute applied to entry
+functions. The value is the string representation of the shader stage (i.e.
+``compute``, ``pixel``, etc).



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

[PATCH] D133574: [C2x] reject type definitions in offsetof

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D133574#3811496 , @inclyc wrote:

> Emm, is it necessary to add a `LangOpts` check so that this change only 
> applies to c2x? If clang was invoked without `-std=c2x`, should we just 
> accept `offsetof` with definitions?

No, I think we should treat this as a defect report and have the behavior be 
the same in all versions of C.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:1650
+def err_type_defined_in_offsetof : Error<
+  "%0 cannot be defined in '__builtin_offsetof'">;
 

inclyc wrote:
> aaron.ballman wrote:
> > We might want this change, we might not -- can you test the diagnostic 
> > behavior when using `#include `? Does it print 
> > `__builtin_offsetof` in the following example?
> > ```
> > #include 
> > 
> > int main() {
> >   return offsetof(struct S { int a; }, a);
> > }
> > ```
> > when executed with `clang -fsyntax-only -ffreestanding -std=c2x test.c`
> > 
> > If it prints the builtin name, I think we'll want to look at the builtin 
> > token to see if it was expanded from a macro named `offsetof` to improve 
> > the diagnostic quality.
> ```
> local/offsetofcc.c:4:26: error: 'struct S' cannot be defined in 
> '__builtin_offsetof'
>   return offsetof(struct S { int a; }, a);
>  ^
> 1 error generated.
> ```
> > If it prints the builtin name, I think we'll want to look at the builtin 
> > token to see if it was expanded from a macro named offsetof to improve the 
> > diagnostic quality.
> 
> OK
We have similar code for this here: 

https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaChecking.cpp#L13438


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133574

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

[PATCH] D131963: [libc++] Add custom clang-tidy checks

[Louis Dionne via Phabricator via cfe-commits]

ldionne accepted this revision.
ldionne added subscribers: smeenai, beanz.
ldionne added a comment.
This revision is now accepted and ready to land.

I'd be fine with this as-is if it works in the CI.

IIUC, the current blocker for this is that the `ClangConfig.cmake` installed by 
LLVM is not robust to the dev packages missing. If you do `find_package(Clang 
16.0)`, it will error out if the dev packages are not present, since it will 
try to reference static libraries (and other artifacts) that don't exist and 
try to create IMPORTED targets for those. @smeenai @beanz do you know more 
about that, or do you know someone that does? Do you know who set up the CMake 
config files so that `find_package(Clang)` would work in the first place? I'd 
also welcome your input on the `ClangConfigVersion.cmake.in` changes.

Just for the context, what we're trying to do here is simply use `clang-tidy`'s 
development packages from the libc++ build to add our own custom clang-tidy 
checks.

Accepting because this LGTM, although we do have some stuff to resolve before 
this can be shipped.




Comment at: libcxx/test/tools/clang_tidy_checks/CMakeLists.txt:39
+set_target_properties(cxx-tidy PROPERTIES LIBRARY_OUTPUT_DIRECTORY 
${CMAKE_CURRENT_BINARY_DIR})
+set(CMAKE_SHARED_MODULE_SUFFIX_CXX .plugin) # Use a single suffix to simplify 
how we can find it from Lit





Comment at: libcxx/test/tools/clang_tidy_checks/robust_against_adl.cpp:22
+AST_MATCHER(clang::UnresolvedLookupExpr, isCustomizationPoint) {
+  // TODO: Are make_error_code and make_error_condition actually customization 
points?
+  return std::ranges::any_of(

This is funny, I actually saw a LWG issue about that go by a few weeks ago. 
I'll try to get more details.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131963

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

[PATCH] D134544: [clang-cl] Implement /ZH: flag

[Nico Weber via Phabricator via cfe-commits]

thakis updated this revision to Diff 462503.
thakis added a comment.

tweak


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

https://reviews.llvm.org/D134544

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/debug-info-file-checksum.c
  clang/test/Driver/cl-options.c

Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -395,9 +395,6 @@
 // RUN:/wd1234 \
 // RUN:/Wv \
 // RUN:/Wv:17 \
-// RUN:/ZH:MD5 \
-// RUN:/ZH:SHA1 \
-// RUN:/ZH:SHA_256 \
 // RUN:/Zm \
 // RUN:/Zo \
 // RUN:/Zo- \
@@ -578,6 +575,17 @@
 // Z7_gdwarf: "-debug-info-kind=constructor"
 // Z7_gdwarf: "-dwarf-version=
 
+// RUN: %clang_cl /ZH:MD5 /c -### -- %s 2>&1 | FileCheck -check-prefix=ZH_MD5 %s
+// ZH_MD5: "-gsrc-hash-algorithm=md5"
+
+// RUN: %clang_cl /ZH:SHA1 /c -### -- %s 2>&1 \
+// RUN: | FileCheck -check-prefix=ZH_SHA1 %s
+// ZH_SHA1: "-gsrc-hash-algorithm=sha1"
+
+// RUN: %clang_cl /ZH:SHA_256 /c -### -- %s 2>&1 \
+// RUN: | FileCheck -check-prefix=ZH_SHA256 %s
+// ZH_SHA256: "-gsrc-hash-algorithm=sha256"
+
 // RUN: %clang_cl -fmsc-version=1800 -TP -### -- %s 2>&1 | FileCheck -check-prefix=CXX11 %s
 // CXX11: -std=c++11
 
Index: clang/test/CodeGen/debug-info-file-checksum.c
===
--- clang/test/CodeGen/debug-info-file-checksum.c
+++ clang/test/CodeGen/debug-info-file-checksum.c
@@ -1,9 +1,21 @@
+// RUN: %clang -emit-llvm -S -g -gcodeview -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
+// RUN: %clang -emit-llvm -S -g -gcodeview -gsrc-hash-algorithm=md5 -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
+// RUN: %clang -emit-llvm -S -g -gcodeview -gsrc-hash-algorithm=sha1 -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - \
+// RUN: | FileCheck --check-prefix=SHA1 %s
+// RUN: %clang -emit-llvm -S -g -gcodeview -gsrc-hash-algorithm=sha256 -x c \
+// RUN: %S/Inputs/debug-info-file-checksum.c -o - \
+// RUN: | FileCheck --check-prefix=SHA256 %s
 // RUN: %clang -emit-llvm -S -g -gcodeview -x c %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
 // RUN: %clang -emit-llvm -S -gdwarf-5 -x c %S/Inputs/debug-info-file-checksum.c -o - | FileCheck %s
 
 // Check that "checksum" is created correctly for the compiled file.
 
 // CHECK: !DIFile(filename:{{.*}}, directory:{{.*}}, checksumkind: CSK_MD5, checksum: "a3b7d27af071accdeccaa933fc603608")
+// SHA1: !DIFile(filename:{{.*}}, directory:{{.*}}, checksumkind: CSK_SHA1, checksum: "6f6eeaba705ad6db6fbb05c2cbcf3cbb3e374bcd")
+// SHA256: !DIFile(filename:{{.*}}, directory:{{.*}}, checksumkind: CSK_SHA256, checksum: "2d49b53859e57898a0f8c16ff1fa4d99306b8ec28d65cf7577109761f0d56197")
 
 // Ensure #line directives (in already pre-processed files) do not emit checksums
 // RUN: %clang -emit-llvm -S -g -gcodeview -x c %S/Inputs/debug-info-file-checksum-pre.cpp -o - | FileCheck %s --check-prefix NOCHECKSUM
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4389,6 +4389,11 @@
 }
   }
 
+  if (const Arg *A = Args.getLastArg(options::OPT_gsrc_hash_algorithm_EQ)) {
+StringRef v = A->getValue();
+CmdArgs.push_back(Args.MakeArgString("-gsrc-hash-algorithm=" + v));
+  }
+
   if (Args.hasFlag(options::OPT_fdebug_ranges_base_address,
options::OPT_fno_debug_ranges_base_address, false)) {
 CmdArgs.push_back("-fdebug-ranges-base-address");
Index: clang/lib/CodeGen/CGDebugInfo.h
===
--- clang/lib/CodeGen/CGDebugInfo.h
+++ clang/lib/CodeGen/CGDebugInfo.h
@@ -631,7 +631,7 @@
 
   /// Compute the file checksum debug info for input file ID.
   Optional
-  computeChecksum(FileID FID, SmallString<32> &Checksum) const;
+  computeChecksum(FileID FID, SmallString<64> &Checksum) const;
 
   /// Get the source of the given file ID.
   Optional getSource(const SourceManager &SM, FileID FID);
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -48,6 +48,8 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/SHA1.h"
+#include "llvm/Support/SHA256.h"
 #include "llvm/Support/TimeProfiler.h"
 using namespace clang;
 using namespace clang::CodeGen;
@@ -344,7 +346,7 @@
 }
 
 Optional
-CGDebugInfo::computeChecksum(FileID FID, SmallStri

[PATCH] D133574: [C2x] reject type definitions in offsetof

[YingChi Long via Phabricator via cfe-commits]

inclyc added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:1650
+def err_type_defined_in_offsetof : Error<
+  "%0 cannot be defined in '__builtin_offsetof'">;
 

aaron.ballman wrote:
> inclyc wrote:
> > aaron.ballman wrote:
> > > We might want this change, we might not -- can you test the diagnostic 
> > > behavior when using `#include `? Does it print 
> > > `__builtin_offsetof` in the following example?
> > > ```
> > > #include 
> > > 
> > > int main() {
> > >   return offsetof(struct S { int a; }, a);
> > > }
> > > ```
> > > when executed with `clang -fsyntax-only -ffreestanding -std=c2x test.c`
> > > 
> > > If it prints the builtin name, I think we'll want to look at the builtin 
> > > token to see if it was expanded from a macro named `offsetof` to improve 
> > > the diagnostic quality.
> > ```
> > local/offsetofcc.c:4:26: error: 'struct S' cannot be defined in 
> > '__builtin_offsetof'
> >   return offsetof(struct S { int a; }, a);
> >  ^
> > 1 error generated.
> > ```
> > > If it prints the builtin name, I think we'll want to look at the builtin 
> > > token to see if it was expanded from a macro named offsetof to improve 
> > > the diagnostic quality.
> > 
> > OK
> We have similar code for this here: 
> 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaChecking.cpp#L13438
> We have similar code for this here:

Wow! Thank you so much for this. I'm searching for how to do this in a LOT of 
doxygen generated pages (


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133574

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

[PATCH] D133574: [C2x] reject type definitions in offsetof

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:1650
+def err_type_defined_in_offsetof : Error<
+  "%0 cannot be defined in '__builtin_offsetof'">;
 

inclyc wrote:
> aaron.ballman wrote:
> > inclyc wrote:
> > > aaron.ballman wrote:
> > > > We might want this change, we might not -- can you test the diagnostic 
> > > > behavior when using `#include `? Does it print 
> > > > `__builtin_offsetof` in the following example?
> > > > ```
> > > > #include 
> > > > 
> > > > int main() {
> > > >   return offsetof(struct S { int a; }, a);
> > > > }
> > > > ```
> > > > when executed with `clang -fsyntax-only -ffreestanding -std=c2x test.c`
> > > > 
> > > > If it prints the builtin name, I think we'll want to look at the 
> > > > builtin token to see if it was expanded from a macro named `offsetof` 
> > > > to improve the diagnostic quality.
> > > ```
> > > local/offsetofcc.c:4:26: error: 'struct S' cannot be defined in 
> > > '__builtin_offsetof'
> > >   return offsetof(struct S { int a; }, a);
> > >  ^
> > > 1 error generated.
> > > ```
> > > > If it prints the builtin name, I think we'll want to look at the 
> > > > builtin token to see if it was expanded from a macro named offsetof to 
> > > > improve the diagnostic quality.
> > > 
> > > OK
> > We have similar code for this here: 
> > 
> > https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaChecking.cpp#L13438
> > We have similar code for this here:
> 
> Wow! Thank you so much for this. I'm searching for how to do this in a LOT of 
> doxygen generated pages (
No problem! I realized "this could be tricky, surely we've done this before" 
and went looking. :-D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133574

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

[PATCH] D134544: [clang-cl] Implement /ZH: flag

[Paul Robinson via Phabricator via cfe-commits]

probinson added a project: debug-info.
probinson added a comment.

Probably we should reject the -gsrc... option if we're emitting DWARF, which 
requires MD5 (at least so far).


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

https://reviews.llvm.org/D134544

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

[PATCH] D98438: Clang: Allow selecting the hash algorithm for file checksums in debug info.

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

So this one can be marked abandoned?  You might need to commandeer it first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98438

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

[PATCH] D134468: [Driver] Ignore -fmsc-version= -fms-compatibility-version= values smaller than 19

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

These kinds of compatibility changes generally should get a Discourse post for 
better visibility.




Comment at: clang/docs/ReleaseNotes.rst:85
+  a version smaller than ``19.0`` is now unsupported.
+
 

Or words to that effect.  "19.0" isn't particularly descriptive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134468

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

[PATCH] D134456: [PGO] Consider parent context when weighing branches with likelyhood.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D134456#3810769 , 
@serge-sans-paille wrote:

> Shouldn't this be a situation where `-Wmisexpect` shold / could trigger?

If we're going to let PGO override what the user explicitly wrote in their 
code, we definitely should be diagnosing it. But I'm still not convinced that 
PGO winning actually matches the intent of the feature.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0479r2.html was the 
last version of the paper which still had its motivation section (it's 
very frustrating when WG21 authors strip relevant information from the paper 
being adopted!). It talks about PGO explicitly:

  Objection #2: Why should branch hints be standardized when many compilers 
implement PGO?
  
  Branch hints are definitely not meant to replace PGO; if PGO can be used it 
should be. PGO may be able to give the optimizer even more information then a 
branch hint. However, PGO and branch hints do not need to be mutually 
exclusive; branch hints could act as another indicator of expected frequent 
usage of particular branches.
  
  Also, PGO is not always easy to use. PGO necessitates creating a realistic 
test scenario to profile which, depending on the application, may be difficult 
and opens up the possibility that some important real world usage may be 
missed. The additional build tooling to keep the profile up to date, 
particularly across multiple OS's and compilers may also be challenging.
  
  Additionally, certain kinds of applications, such as those which may be 
distributed to clients who then build and run their own plugins in the 
distributed application may be very difficult or impossible to generate a 
realistic benchmark for, as there is no way of knowing how the client will use 
the application. Similar problems could also occur if an application is highly 
configurable; creating test scenarios and builds for all different possible 
configurations may not be realistic.
  
  Finally, PGO sometimes does the exact opposite of what is wanted for certain 
low-latency use cases. PGO tries to make the common case faster, but it may 
actually be more important to make the uncommon cases faster so that when they 
do occur they run as quickly as possible.

The first few paragraphs read to me like "sure, PGO should win" but the last 
paragraph reads like "no, PGO should lose". I remember when we were discussing 
this proposal in WG21 and the last paragraph was what motivated a number of 
committee members, especially in safety-critical spaces. Looking back through 
Core discussion, this point was brought up there as well as being important 
(https://lists.isocpp.org/core/2019/09/7193.php for those with access to the 
committee reflectors).

> If we've already made promises about how this is supposed to work, I'd prefer 
> to trust our past decisions rather than revisiting them.

I'm sympathetic to this but only if we actually made a decision here instead of 
documenting whatever behavior we got by default. 
https://reviews.llvm.org/D59467 is the original review which added this feature 
and from my reading of that we recognized the conflict between PGO and an 
explicit annotation, but it doesn't look like this concern was really 
considered.

Do users have some other escape hatch to tell PGO "ignore what you think you 
know about this branch" so that a user who *wants* PGO to lose has some ability 
to do that other than "don't use PGO"?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134456

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

[PATCH] D134546: [clang-offload-bundler] extracting compatible bundle entry

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, saiislam, lamb-j.
Herald added a project: All.
yaxunl requested review of this revision.
Herald added subscribers: sstefan1, MaskRay.
Herald added a reviewer: jdoerfert.

In HIP a library is usually compiled with default target ID e.g. gfx906 so that
it can be used in all GPU configurations. The bitcode is saved in bundled
bitcode with gfx906 in entry ID.

In runtime compilation, a HIP program is compiled with a target ID matching
the GPU configuration, e.g. gfx906:xnack-. This program needs to link with
a library bundled bitcode with target ID gfx906.

For example:

  clang --offload-arch=gfx906 -o lib.o lib.hip
  clang --offload-arch=gfx906:xnack- program.hip lib.o

This common use case requires that clang-offlod-bundler to be able to extract
entry with compatible target ID, e.g. extracting an gfx906 entry when requesting
gfx906:xnack-.

Currently clang-offload-bundler only allow extracting entry with exact match
of target ID. This patch relaxes that so that it can extract entries with 
compatible
target ID.


https://reviews.llvm.org/D134546

Files:
  clang/include/clang/Basic/TargetID.h
  clang/include/clang/Driver/OffloadBundler.h
  clang/lib/Basic/TargetID.cpp
  clang/lib/Driver/OffloadBundler.cpp
  clang/test/Driver/clang-offload-bundler.c

Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -224,7 +224,7 @@
 // RUN: diff %t.empty %t.res.tgt2
 
 // Check that bindler prints an error if given host bundle does not exist in the fat binary.
-// RUN: not clang-offload-bundler -type=s -targets=host-x86_64-xxx-linux-gnu,openmp-powerpc64le-ibm-linux-gnu -output=%t.res.s -output=%t.res.tgt1 -input=%t.bundle3.s -unbundle -allow-missing-bundles 2>&1 | FileCheck %s --check-prefix CK-NO-HOST-BUNDLE
+// RUN: not clang-offload-bundler -type=s -targets=host-amdgcn-xxx-linux-gnu,openmp-powerpc64le-ibm-linux-gnu -output=%t.res.s -output=%t.res.tgt1 -input=%t.bundle3.s -unbundle -allow-missing-bundles 2>&1 | FileCheck %s --check-prefix CK-NO-HOST-BUNDLE
 // CK-NO-HOST-BUNDLE: error: Can't find bundle for the host target
 
 //
@@ -421,6 +421,29 @@
 // NOHOST-NOT: host-
 // NOHOST-DAG: hip-amdgcn-amd-amdhsa--gfx900
 // NOHOST-DAG: hip-amdgcn-amd-amdhsa--gfx906
+
+//
+// Check extracting bundle entry with compatible target ID for HIP.
+//
+// RUN: clang-offload-bundler -type=bc -targets=hip-amdgcn-amd-amdhsa--gfx906 \
+// RUN:   -input=%t.tgt1 -output=%t.hip.bundle.bc
+// RUN: clang-offload-bundler -type=bc -targets=hip-amdgcn-amd-amdhsa--gfx906:xnack- \
+// RUN:   -output=%t.res.tgt1 -input=%t.hip.bundle.bc -unbundle
+// RUN: diff %t.tgt1 %t.res.tgt1
+// RUN: clang-offload-bundler -type=bc -targets=hip-amdgcn-amd-amdhsa--gfx906:xnack+ \
+// RUN:   -output=%t.res.tgt1 -input=%t.hip.bundle.bc -unbundle
+// RUN: diff %t.tgt1 %t.res.tgt1
+
+// RUN: clang-offload-bundler -type=bc -targets=hip-amdgcn-amd-amdhsa--gfx906:xnack+ \
+// RUN:   -input=%t.tgt1 -output=%t.hip.bundle.bc
+// RUN: not clang-offload-bundler -type=bc -targets=hip-amdgcn-amd-amdhsa--gfx906:xnack- \
+// RUN:   -output=%t.res.tgt1 -input=%t.hip.bundle.bc -unbundle 2>&1 | FileCheck %s -check-prefix=NOXNACK
+// NOXNACK: error: Can't find bundles for hip-amdgcn-amd-amdhsa--gfx906:xnack-
+// RUN: not clang-offload-bundler -type=bc -targets=hip-amdgcn-amd-amdhsa--gfx906 \
+// RUN:   -output=%t.res.tgt1 -input=%t.hip.bundle.bc -unbundle 2>&1 | FileCheck %s -check-prefix=NOGFX906
+// NOGFX906: error: Can't find bundles for hip-amdgcn-amd-amdhsa--gfx906
+
+//
 // Check archive unbundling
 //
 // Create few code object bundles and archive them to create an input archive
@@ -431,6 +454,8 @@
 
 // RUN: clang-offload-bundler -unbundle -type=a -targets=openmp-amdgcn-amd-amdhsa-gfx906,openmp-amdgcn-amd-amdhsa-gfx908 -input=%t.input-archive.a -output=%t-archive-gfx906-simple.a -output=%t-archive-gfx908-simple.a
 // RUN: llvm-ar t %t-archive-gfx906-simple.a | FileCheck %s -check-prefix=GFX906
+// RUN: clang-offload-bundler -unbundle -type=a -targets=openmp-amdgcn-amd-amdhsa-gfx906:xnack+ -input=%t.input-archive.a -output=%t-archive-gfx906-simple.a
+// RUN: llvm-ar t %t-archive-gfx906-simple.a | FileCheck %s -check-prefix=GFX906
 // GFX906: simple-openmp-amdgcn-amd-amdhsa-gfx906
 // RUN: llvm-ar t %t-archive-gfx908-simple.a | FileCheck %s -check-prefix=GFX908
 // GFX908-NOT: {{gfx906}}
Index: clang/lib/Driver/OffloadBundler.cpp
===
--- clang/lib/Driver/OffloadBundler.cpp
+++ clang/lib/Driver/OffloadBundler.cpp
@@ -14,9 +14,10 @@
 ///
 //===--===//
 
+#include "clang/Driver/OffloadBundler.h"
 #include "clang/Basic/Cuda.h"
+#include "clang/Basic/TargetID.h"
 #include "clang/Basic/Version.h"
-#include "clang/Driver/OffloadBundler.h"

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

> The number of people likely to notice that PS4 is different from the other 
> targets seems far smaller than the number of people noticing the same for 
> Windows. But I've got no data to back that up, either.

heh.  There's a PS4 bot that notices.  But the PS4 situation is also different 
in that there is only one toolchain.  When you have multiple toolchains with 
different defaults, as is the case with Windows, then you have users getting 
annoyed or possibly into trouble.

FTR, we (Sony) did a huge pile of work some years ago to make a lot of the C++ 
tests dialect-agnostic (run with different values of `-std`, do a lot of `#if 
__cplusplus <= ...` for different dialects, like that).  There are really very 
few tests that actively care what the default is.  I think we just very 
recently added one specific to PS4.  I am not surprised that there isn't an 
equivalent for Windows.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D134468: [Driver] Ignore -fmsc-version= -fms-compatibility-version= values smaller than 19

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: clang-vendors.
aaron.ballman added a subscriber: andrew.w.kaylor.
aaron.ballman added a comment.

Adding clang-vendors for awareness as this has the potential to impact folks 
vending clang.

In D134468#3811882 , @probinson wrote:

> These kinds of compatibility changes generally should get a Discourse post 
> for better visibility.

Strong +1, this needs a community RFC to see if we have folks relying on this 
support. For example, Intel supports ICX as a drop-in replacement for cl, and 
I'm not certain what our MSVC compatibility requirements are (I'm trying to 
find out though; CC @andrew.w.kaylor 
for awareness).

In D134468#3810030 , @hans wrote:

> I'm conflicted about this. I see where you're coming from, but I could 
> imagine people using clang-cl with old VS versions e.g. to target old 
> Windows. I agree we shouldn't go out of our way to support that, but do we 
> think it's too much effort to keep the functionality we have (as defined by 
> the lit tests) working?

I'm also conflicted -- what's the pain point we're trying to solve with these 
changes? It doesn't seem like maintenance is an actual burden in practice.

In D134468#3809713 , @rnk wrote:

> If we do this, I'd like it to be a policy change. We should add a release 
> note about dropping support for `-fmsc-version=N` for N<1900, and audit for 
> other logic like this:
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDeclCXX.cpp#L6390

Do we have a policy written down anywhere for this? We have one for what 
versions of MSVC we'll support building LLVM with, but I don't think we have a 
policy for what versions of MSVC we'll support being compatible with. Given 
that we still have GCC compatibility hacks for GCC 4.2 (which we still report 
we emulate with the GNU version macros!) which came out in 2008, I'd like more 
motivation as for why we want to drop support for MSVC 2013 and a better 
understanding of how we decide when we no longer will support compatibility 
with an older compiler -- we should be able to communicate this to users so 
their expectations are set appropriately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134468

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

[PATCH] D133586: [clang] initialize type qualifiers for FunctionNoProtoType

[Richard Howell via Phabricator via cfe-commits]

rmaz updated this revision to Diff 462518.
rmaz added a comment.

Remove unnecessary friend class


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133586

Files:
  clang/include/clang/AST/Type.h
  clang/unittests/AST/DeclTest.cpp


Index: clang/unittests/AST/DeclTest.cpp
===
--- clang/unittests/AST/DeclTest.cpp
+++ clang/unittests/AST/DeclTest.cpp
@@ -354,3 +354,25 @@
 
   EXPECT_TRUE(getFooValue->isInlined());
 }
+
+TEST(Decl, NoProtoFunctionDeclAttributes) {
+  llvm::Annotations Code(R"(
+void f();
+)");
+
+  auto AST = tooling::buildASTFromCodeWithArgs(
+  Code.code(),
+  /*Args=*/{"-target", "i386-apple-darwin", "-x", "objective-c",
+"-std=c89"});
+  ASTContext &Ctx = AST->getASTContext();
+
+  auto *f = selectFirst(
+  "f", match(functionDecl(hasName("f")).bind("f"), Ctx));
+
+  const auto *FPT = f->getType()->getAs();
+
+  // Functions without prototypes always have 0 initialized qualifiers
+  EXPECT_FALSE(FPT->isConst());
+  EXPECT_FALSE(FPT->isVolatile());
+  EXPECT_FALSE(FPT->isRestrict());
+}
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -3892,7 +3892,10 @@
   }
 
   Qualifiers getFastTypeQuals() const {
-return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+if (isFunctionProtoType())
+  return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+else
+  return Qualifiers();
   }
 
 public:


Index: clang/unittests/AST/DeclTest.cpp
===
--- clang/unittests/AST/DeclTest.cpp
+++ clang/unittests/AST/DeclTest.cpp
@@ -354,3 +354,25 @@
 
   EXPECT_TRUE(getFooValue->isInlined());
 }
+
+TEST(Decl, NoProtoFunctionDeclAttributes) {
+  llvm::Annotations Code(R"(
+void f();
+)");
+
+  auto AST = tooling::buildASTFromCodeWithArgs(
+  Code.code(),
+  /*Args=*/{"-target", "i386-apple-darwin", "-x", "objective-c",
+"-std=c89"});
+  ASTContext &Ctx = AST->getASTContext();
+
+  auto *f = selectFirst(
+  "f", match(functionDecl(hasName("f")).bind("f"), Ctx));
+
+  const auto *FPT = f->getType()->getAs();
+
+  // Functions without prototypes always have 0 initialized qualifiers
+  EXPECT_FALSE(FPT->isConst());
+  EXPECT_FALSE(FPT->isVolatile());
+  EXPECT_FALSE(FPT->isRestrict());
+}
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -3892,7 +3892,10 @@
   }
 
   Qualifiers getFastTypeQuals() const {
-return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+if (isFunctionProtoType())
+  return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+else
+  return Qualifiers();
   }
 
 public:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134549: [clang] Add fix-it note to defaulted-function-deleted warning

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
njames93 added a reviewer: aaron.ballman.
Herald added a subscriber: martong.
Herald added a reviewer: shafik.
Herald added a project: All.
njames93 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Adds a fix to the diagnostic of replacing the `= default` to `= delete`


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134549

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/CXX/class.derived/class.abstract/p16.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p1.cpp
  clang/test/CXX/class/class.compare/class.compare.default/p2.cpp
  clang/test/CXX/class/class.compare/class.compare.secondary/p2.cpp
  clang/test/CXX/class/class.compare/class.eq/p2.cpp
  clang/test/CXX/class/class.compare/class.rel/p2.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
  clang/test/CXX/drs/dr6xx.cpp
  clang/test/SemaCXX/cxx0x-deleted-default-ctor.cpp
  clang/test/SemaCXX/dr1301.cpp
  clang/test/SemaCXX/explicitly-defaulted.cpp
  clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
  clang/test/SemaObjCXX/arc-0x.mm

Index: clang/test/SemaObjCXX/arc-0x.mm
===
--- clang/test/SemaObjCXX/arc-0x.mm
+++ clang/test/SemaObjCXX/arc-0x.mm
@@ -121,12 +121,12 @@
 
   union U1 {
 __weak id f0; // expected-note 12 {{'U1' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
-U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
-~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
-U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
-U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}}
-U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
-U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}}
+U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}} expected-note{{replace 'default'}}
+U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}} expected-note{{replace 'default'}}
+U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}} expected-note{{replace 'default'}}
   };
 
   id getStrong();
Index: clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
===
--- clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
+++ clang/test/SemaCXX/microsoft-dtor-lookup-cxx11.cpp
@@ -7,7 +7,7 @@
 } s; // expected-error {{attempt to use a deleted function}}
 
 struct T { // expected-note 2{{virtual destructor requires an unambiguous, accessible 'operator delete'}}
-  virtual ~T() = default; // expected-note {{explicitly defaulted function was implicitly deleted here}} expected-warning {{implicitly deleted}}
+  virtual ~T() = default; // expected-note {{explicitly defaulted function was implicitly deleted here}} expected-warning {{implicitly deleted}} expected-note{{replace 'default'}}
   void operator delete(void*, int);
   void operator delete(void*, double);
 } t; // expected-error {{attempt to use a deleted function}}
Index: clang/test/SemaCXX/explicitly-defaulted.cpp
==

[PATCH] D132379: [Support] Class for response file expansion

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff updated this revision to Diff 462528.
sepavloff added a comment.

Address reviewer's notes

- Pass BumpPtrAllocator instead of StringSaver,
- Use setter to specify file system object.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132379

Files:
  clang/lib/Driver/Driver.cpp
  clang/lib/Tooling/ExpandResponseFilesCompilationDatabase.cpp
  clang/tools/driver/driver.cpp
  llvm/include/llvm/Support/CommandLine.h
  llvm/include/llvm/Support/StringSaver.h
  llvm/lib/Support/CommandLine.cpp
  llvm/unittests/Support/CommandLineTest.cpp

Index: llvm/unittests/Support/CommandLineTest.cpp
===
--- llvm/unittests/Support/CommandLineTest.cpp
+++ llvm/unittests/Support/CommandLineTest.cpp
@@ -869,10 +869,9 @@
 
   // Expand response files.
   llvm::BumpPtrAllocator A;
-  llvm::StringSaver Saver(A);
-  ASSERT_TRUE(llvm::cl::ExpandResponseFiles(
-  Saver, llvm::cl::TokenizeGNUCommandLine, Argv, false, true, false,
-  /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(A, llvm::cl::TokenizeGNUCommandLine);
+  ECtx.setVFS(&FS).setCurrentDir(TestRoot).setRelativeNames(true);
+  ASSERT_TRUE(ECtx.expandResponseFiles(Argv));
   EXPECT_THAT(Argv, testing::Pointwise(
 StringEquality(),
 {"test/test", "-flag_1", "-option_1", "-option_2",
@@ -927,15 +926,14 @@
   SmallVector Argv = {"test/test", SelfFileRef.c_str(),
"-option_3"};
   BumpPtrAllocator A;
-  StringSaver Saver(A);
 #ifdef _WIN32
   cl::TokenizerCallback Tokenizer = cl::TokenizeWindowsCommandLine;
 #else
   cl::TokenizerCallback Tokenizer = cl::TokenizeGNUCommandLine;
 #endif
-  ASSERT_FALSE(
-  cl::ExpandResponseFiles(Saver, Tokenizer, Argv, false, false, false,
-  /*CurrentDir=*/llvm::StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(A, Tokenizer);
+  ECtx.setVFS(&FS).setCurrentDir(TestRoot);
+  ASSERT_FALSE(ECtx.expandResponseFiles(Argv));
 
   EXPECT_THAT(Argv,
   testing::Pointwise(StringEquality(),
@@ -971,10 +969,9 @@
   Argv.push_back(ResponseFileRef.c_str());
 
   BumpPtrAllocator A;
-  StringSaver Saver(A);
-  ASSERT_FALSE(cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv,
-   false, false, false,
-   /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(A, cl::TokenizeGNUCommandLine);
+  ECtx.setVFS(&FS).setCurrentDir(TestRoot);
+  ASSERT_FALSE(ECtx.expandResponseFiles(Argv));
 
   // ASSERT instead of EXPECT to prevent potential out-of-bounds access.
   ASSERT_EQ(Argv.size(), 1 + NON_RSP_AT_ARGS + 2);
@@ -1006,10 +1003,9 @@
   SmallVector Argv = {"test/test", "@dir/outer.rsp"};
 
   BumpPtrAllocator A;
-  StringSaver Saver(A);
-  ASSERT_TRUE(cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv,
-  false, true, false,
-  /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(A, cl::TokenizeGNUCommandLine);
+  ECtx.setVFS(&FS).setCurrentDir(TestRoot).setRelativeNames(true);
+  ASSERT_TRUE(ECtx.expandResponseFiles(Argv));
   EXPECT_THAT(Argv,
   testing::Pointwise(StringEquality(), {"test/test", "-flag"}));
 }
@@ -1026,10 +1022,10 @@
  MemoryBuffer::getMemBuffer("-Xclang -Wno-whatever\n input.cpp"));
   SmallVector Argv = {"clang", "@eols.rsp"};
   BumpPtrAllocator A;
-  StringSaver Saver(A);
-  ASSERT_TRUE(cl::ExpandResponseFiles(Saver, cl::TokenizeWindowsCommandLine,
-  Argv, true, true, false,
-  /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(A, cl::TokenizeWindowsCommandLine);
+  ECtx.setVFS(&FS).setCurrentDir(TestRoot).setMarkEOLs(true).setRelativeNames(
+  true);
+  ASSERT_TRUE(ECtx.expandResponseFiles(Argv));
   const char *Expected[] = {"clang", "-Xclang", "-Wno-whatever", nullptr,
 "input.cpp"};
   ASSERT_EQ(std::size(Expected), Argv.size());
@@ -1125,9 +1121,8 @@
   EXPECT_NE(CurrDir.str(), TestDir.path());
 
   llvm::BumpPtrAllocator A;
-  llvm::StringSaver Saver(A);
-  bool Result = llvm::cl::readConfigFile(ConfigFile.path(), Saver, Argv,
-		 *llvm::vfs::getRealFileSystem());
+  llvm::cl::ExpansionContext ECtx(A, cl::tokenizeConfigFile);
+  bool Result = ECtx.readConfigFile(ConfigFile.path(), Argv);
 
   EXPECT_TRUE(Result);
   EXPECT_EQ(Argv.size(), 13U);
Index: llvm/lib/Support/CommandLine.cpp
===
--- llvm/lib/Support/CommandLine.cpp
+++ llvm/lib/Support/CommandLine.cpp
@@ -1153,15 +1153,12 @@
 }
 
 // FName must be an absolute path.
-static llvm::Error ExpandRespo

[PATCH] D132379: [Support] Class for response file expansion

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added inline comments.



Comment at: llvm/include/llvm/Support/CommandLine.h:2098
+public:
+  ExpansionContext(StringSaver &S, TokenizerCallback T,
+   llvm::vfs::FileSystem *FS = nullptr);

rnk wrote:
> StringSaver is a stateless class that wraps a BumpPtrAllocator. To simplify 
> the call site, I suggest making this parameter into a `BumpPtrAllocator &`, 
> and construct a field StringSaver from the allocator.
Indeed in many cases StringSaver in caller can be omitted if the parameter is 
BumpPtrAllocator.



Comment at: llvm/include/llvm/Support/CommandLine.h:2099
+  ExpansionContext(StringSaver &S, TokenizerCallback T,
+   llvm::vfs::FileSystem *FS = nullptr);
+

rnk wrote:
> It feels like you are using the builder pattern to handle setting uncommon 
> options. If that's what we're doing, should we commit completely and add a 
> `.setVFS()` helper and remove the optional parameter?
You are right. Changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132379

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

[PATCH] D134468: [Driver] Ignore -fmsc-version= -fms-compatibility-version= values smaller than 19

[Tobias Hieta via Phabricator via cfe-commits]

thieta added a comment.

I think we should define a policy for this. I doubt we have many users on these 
older versions but I think maybe we should give deprecation messages for at 
least one release before we drop it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134468

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

[PATCH] D134224: [clang][modules][deps] Report modulemaps describing excluded headers

[Steven Johnson via Phabricator via cfe-commits]

srj added a comment.

This change has broken x86-32 builds, at least on Linux.

  
/usr/local/google/home/srj/GitHub/llvm-project/16/llvm/include/llvm/ADT/PointerIntPair.h:136:25:
 error: static assertion failed: PointerIntPair with integer size too large for 
pointer
136 |   static_assert(IntBits <= PtrTraits::NumLowBitsAvailable,
| ^
  
/usr/local/google/home/srj/GitHub/llvm-project/16/llvm/include/llvm/ADT/PointerIntPair.h:136:25:
 note: the comparison reduces to ‘(3 <= 2)’
  
/usr/local/google/home/srj/GitHub/llvm-project/16/llvm/include/llvm/ADT/PointerIntPair.h:151:42:
 warning: left shift count >= width of type [-Wshift-count-overflow]
151 | ShiftedIntMask = (uintptr_t)(IntMask << IntShift)
| ~^~~~
  
/usr/local/google/home/srj/GitHub/llvm-project/16/llvm/include/llvm/ADT/PointerIntPair.h:151:42:
 error: right operand of shift expression ‘(7 << 4294967295)’ is greater than 
or equal to the precision 32 of the left operand [-fpermissive]
  
/usr/local/google/home/srj/GitHub/llvm-project/16/llvm/include/llvm/ADT/PointerIntPair.h:138:8:
 error: enumerator value for ‘ShiftedIntMask’ is not an integer constant
138 |   enum MaskAndShiftConstants : uintptr_t {

Please fix or revert immediately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134224

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

[PATCH] D134550: [Clang] Make Clang driver suggest '-Xclang' for CC1 options passed to the driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: MaskRay, aaron.ballman.
Herald added a subscriber: StephenFan.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch adds an additional check for if an options passed to the
Clang driver could've been intended for the clang compiler. This is
primarily done for the times when a user attempts to pass an option like
`-ast-dump` to the driver instead.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134550

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/debug-options.c
  clang/test/Driver/unknown-arg.c
  clang/test/Misc/driver-verify.c


Index: clang/test/Misc/driver-verify.c
===
--- clang/test/Misc/driver-verify.c
+++ clang/test/Misc/driver-verify.c
@@ -3,4 +3,4 @@
 // expected-no-diagnostics
 
 // Test that -verify is strictly rejected as unknown by the driver.
-// CHECK: unknown argument: '-verify'
+// CHECK: unknown argument '-verify'; did you mean '-Xclang -verify'?
Index: clang/test/Driver/unknown-arg.c
===
--- clang/test/Driver/unknown-arg.c
+++ clang/test/Driver/unknown-arg.c
@@ -31,7 +31,7 @@
 // CHECK: error: unknown argument: '-%d'
 // CHECK: error: unknown argument: '-'
 // CHECK: error: unknown argument: '-munknown-to-clang-option'
-// CHECK: error: unknown argument: '-print-stats'
+// CHECK: error: unknown argument '-print-stats'; did you mean '-Xclang 
-print-stats'?
 // CHECK: error: unknown argument: '-funknown-to-clang-option'
 // CHECK: error: unknown argument: '-ifoo'
 // MULTILIB: warning: argument unused during compilation: '-imultilib dir'
Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -463,6 +463,6 @@
 // SIMPLE_TMPL_NAMES: -gsimple-template-names=simple
 // FWD_TMPL_PARAMS-DAG: -debug-forward-template-params
 // RUN: not %clang -### -target x86_64 -c -g -gsimple-template-names=mangled 
%s 2>&1 | FileCheck --check-prefix=MANGLED_TEMP_NAMES %s
-// MANGLED_TEMP_NAMES: error: unknown argument: 
'-gsimple-template-names=mangled'
+// MANGLED_TEMP_NAMES: error: unknown argument 
'-gsimple-template-names=mangled'; did you mean '-Xclang 
-gsimple-template-names=mangled'
 // RUN: %clang -### -target x86_64 -c -g %s 2>&1 | FileCheck 
--check-prefix=FULL_TEMP_NAMES 
--implicit-check-not=debug-forward-template-params %s
 // FULL_TEMP_NAMES-NOT: -gsimple-template-names
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -305,11 +305,17 @@
 unsigned DiagID;
 auto ArgString = A->getAsString(Args);
 std::string Nearest;
-if (getOpts().findNearest(
-  ArgString, Nearest, IncludedFlagsBitmask, ExcludedFlagsBitmask) > 1) 
{
-  DiagID = IsCLMode() ? diag::warn_drv_unknown_argument_clang_cl
-  : diag::err_drv_unknown_argument;
-  Diags.Report(DiagID) << ArgString;
+if (getOpts().findNearest(ArgString, Nearest, IncludedFlagsBitmask,
+  ExcludedFlagsBitmask) > 1) {
+  if (getOpts().findNearest(ArgString, Nearest, options::CC1Option) == 0 &&
+  !IsCLMode()) {
+DiagID = diag::err_drv_unknown_argument_with_suggestion;
+Diags.Report(DiagID) << ArgString << "-Xclang " + Nearest;
+  } else {
+DiagID = IsCLMode() ? diag::warn_drv_unknown_argument_clang_cl
+: diag::err_drv_unknown_argument;
+Diags.Report(DiagID) << ArgString;
+  }
 } else {
   DiagID = IsCLMode()
? diag::warn_drv_unknown_argument_clang_cl_with_suggestion


Index: clang/test/Misc/driver-verify.c
===
--- clang/test/Misc/driver-verify.c
+++ clang/test/Misc/driver-verify.c
@@ -3,4 +3,4 @@
 // expected-no-diagnostics
 
 // Test that -verify is strictly rejected as unknown by the driver.
-// CHECK: unknown argument: '-verify'
+// CHECK: unknown argument '-verify'; did you mean '-Xclang -verify'?
Index: clang/test/Driver/unknown-arg.c
===
--- clang/test/Driver/unknown-arg.c
+++ clang/test/Driver/unknown-arg.c
@@ -31,7 +31,7 @@
 // CHECK: error: unknown argument: '-%d'
 // CHECK: error: unknown argument: '-'
 // CHECK: error: unknown argument: '-munknown-to-clang-option'
-// CHECK: error: unknown argument: '-print-stats'
+// CHECK: error: unknown argument '-print-stats'; did you mean '-Xclang -print-stats'?
 // CHECK: error: unknown argument: '-funknown-to-clang-option'
 // CHECK: error: unknown argument: '-ifoo'
 // MULTILIB: warning: argument unused during compilation: 

[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

In D86049#3806898 , @plotfi wrote:

> 1. Do we change the existing visibility behavior of objc methods? Yes / No

I don't think we want to change the existing visibility behavior of non-direct 
objc methods. Is there a use reason or use case for making them visible outside 
the linkage unit?

> 2. If we leave hidden as the default do we change the behavior for 
> objc_direct? Yes / No

I think direct methods shouldn't be hidden by default (i.e., they should get 
the default visibility). But it's not clear to me whether we should make that 
change right away as I've heard concerns from people internally. I think I need 
more time to understand what exactly their concerns are.

> 3. If we leave objc_direct as hidden by default do we expand the existing 
> objc_direct attr to have the enum as you said so 
> `__attribute__((objc_direct("visible")))` or do we add a new attr as I have 
> done so far?

I wasn't sure why it wasn't possible to use the existing 
`__attribute__((visibility("default")))` attribute. Is it not possible to make 
only the direct methods get the default visibility?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86049

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

[PATCH] D134235: [clang-doc] Clean up *Info constructors.

[Brett Wilson via Phabricator via cfe-commits]

brettw added inline comments.



Comment at: clang-tools-extra/clang-doc/Representation.h:202
+   bool IsFileInRootDir = false)
   : LineNumber(LineNumber), Filename(std::move(Filename)),
 IsFileInRootDir(IsFileInRootDir) {}

paulkirth wrote:
> do we still want to use `std::move` here now that its a StringRef? I don't 
> think we would do that w/ `const char*`, which is what `StringRef` boils down 
> to. It should be passed by value everywhere.
> 
> see 
> https://llvm.org/docs/ProgrammersManual.html#passing-strings-the-stringref-and-twine-classes,
>  
> https://llvm.org/docs/ProgrammersManual.html#the-stringref-class 
> https://llvm.org/docs/ProgrammersManual.html#string-like-containers
The move is unnecessary and I removed it.


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

https://reviews.llvm.org/D134235

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

[PATCH] D134454: [Driver][Distro] Fix ArchLinux triplet and sysroot detection

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

Is it worth contacting the package maintainer for LLVM+clang for Arch-Linux in 
regards to this patch?




Comment at: clang/lib/Driver/Distro.cpp:210
+  // Sometimes the OS can't be detected from the triplet due to ambiguity, for
+  // eg. ArchLinux uses aarch64-linux-gnu which results in Uknonwn OS & distro,
+  // so normalize the triplet which results in aarch64-unknown-linux-gnu, such

typo



Comment at: clang/lib/Driver/Distro.cpp:213
+  // that the Linux OS and distro are properly detected in this cases.
+  llvm::Triple NormTargetOrHost = 
llvm::Triple(Twine(TargetOrHost.normalize()));
+

Twine has an intentionally non-explicit constructor that accepts a StringRef, 
which also has an intentionally non-explicit constructor that accepts a 
std::string, which is what Triple::normalize() returns.

Let's be consistent in the explicit construction of these temporary objects by 
removing the explicit call to the Twine constructor.

Also, why is it necessary to normalize the Triple? Can you give an example of 
the "bad" input and how this "fixes" it?



Comment at: clang/lib/Driver/ToolChains/Linux.cpp:377-394
+  if (Distro.IsArchLinux()) {
+std::string Path = (InstallDir + "/../../../../"  + TripleStr).str();
+if (getVFS().exists(Path))
+  return Path;
+  }
+
   if (!GCCInstallation.isValid() || !getTriple().isMIPS())

Do we need the Arch-linux test before the call to `GCCInstallation.isValid()`? 
Otherwise it seems like this duplicates a fair amount of code computing the 
`Path`.  The initial parts of the Path seem to match; there's only more to it 
if the Distro is not arch-linux.


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

https://reviews.llvm.org/D134454

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

[PATCH] D134546: [clang-offload-bundler] extracting compatible bundle entry

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/OffloadBundler.cpp:1008
+auto Output = Worklist.begin();
+for (auto E = Worklist.end(); Output != E; Output++) {
+  if (isCodeObjectCompatible(

The patch description implies that there are at least two classes of compatible 
objects -- the ones that match exactly and the ones that are not exact match, 
but are still compatible.


Here we're iterating until we find the first compatible object. What if we also 
have the object that matches exactly, but it's further down the list. Is that a 
problem that we may pick one or the other, depending on the order they happen 
to appear in the worklist? It would be good to add a test case for this 
scenario.


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

https://reviews.llvm.org/D134546

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

[PATCH] D134456: [PGO] Consider parent context when weighing branches with likelyhood.

[Mark de Wever via Phabricator via cfe-commits]

Mordante added a comment.

When I implemented P0479R5 I didn't look at earlier revisions of the paper. I'm 
a bit surprised to see revision 2 had a lot more information. (At that time I 
was less familiar with WG21 papers, so I didn't consider looking at older 
papers or notice the missing revision history.) I agree with @aaron.ballman's 
observation; revision 2 is unclear what the best solution regarding overriding 
PGO is.

I'm not really active in Clang at the moment so I feel @aaron.ballman has a 
better view of which approach to take for ``[[likely]]`` and PGO.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134456

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

[PATCH] D133801: Extraction of a matcher for an unused value from an expression from the bugprone-unused-return-value check

[Nathan James via Phabricator via cfe-commits]

njames93 added inline comments.



Comment at: clang-tools-extra/unittests/clang-tidy/MatchersTest.cpp:2
+#include "utils/Matchers.h"
+#include "../../clang/unittests/ASTMatchers/ASTMatchersTest.h"
+

kwk wrote:
> njames93 wrote:
> > @kwk I seem to recall you saying in another patch that this include will 
> > break standalone builds, would stripping the leading `../../` work?
> > @kwk I seem to recall you saying in another patch that this include will 
> > break standalone builds, 
> 
> @njames93 that's correct. But I don't recall the patch ID :/
> 
> > would stripping the leading `../../` work?
> 
> I don't know if the file is found then but it would make standalone builds 
> certainly easier.
> 
> I'm not sure if I calculate correctly but given:
> 
> `clang-tools-extra/unittests/clang-tidy/MatchersTest.cpp`
> 
> then `../../` means `clang-tools-extra/`, no? If so, that directory doesn't 
> contain a `clang` directory here. It seems as if the `../../` is relative to 
> some other directory but not this file. Or am I too tired to get it?
> 
I'll test when I get a few cycles. If not, may need to copy some of the testing 
logic for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133801

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

[PATCH] D133705: [HIP] Fix unbundling archive

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:2907-2908
+// which are not object files. Files with extension ".lib" is 
classified
+// as TY_Object but they are actually archives, therefore should not be
+// unbundled.
+const StringRef LibFileExt = ".lib";

yaxunl wrote:
> tra wrote:
> > This is confusing. I do not understand how/why `therefore should not be 
> > unbundled` is inferred from `they are actually archives`.
> > The patch description says that not unbundling the archives is that the 
> > patch is intended to fix.  The tests below with `MSVC` label show that we 
> > do unbundle the inputs with `.lib` extension.
> > 
> > Should this comment be fixed/updated?  What do I miss? 
> Here the driver is trying to unbundle bundled objects. This is different from 
> unbundle archives. clang classifies '.lib' files as objects. If we do not 
> exclude '.lib' files here, they will be incorrectly unbundled as objects 
> here. The unbundling of '.lib' as archives should be done at other places.
> 
> Since this comment is confusing, I will change it to:
> 
> 'therefore should not be unbundled as objects here. They will be handled at 
> other places.'
Thank you for the explanation. It makes more sense to me now. 


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

https://reviews.llvm.org/D133705

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

[PATCH] D134453: Introduce the `AlwaysIncludeTypeForNonTypeTemplateArgument` into printing policy

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/PrettyPrinter.h:307
+  /// decltype(s) will be printed as "S" if enabled and as 
"S<{1,2}>" if disabled,
+  /// regardless if PrintCanonicalTypes is enabled.
+  unsigned AlwaysIncludeTypeForNonTypeTemplateArgument : 1;

DoDoENT wrote:
> aaron.ballman wrote:
> > dblaikie wrote:
> > > DoDoENT wrote:
> > > > dblaikie wrote:
> > > > > What does `PrintCanonicalTypes` have to do with this? Does it overlap 
> > > > > with this functionality in some way, but doesn't provide the 
> > > > > functionality you want in particular?
> > > > Thank you for the question. If you set the `PrintCanonicalTypes` to 
> > > > `false`, the `S` would be printed as `S` even 
> > > > without this patch. However, if you set it to `true`, it will be 
> > > > printed as `S<{1, 2}>`.
> > > > 
> > > > I don't fully understand why it does that, but it's quite annoying.
> > > > 
> > > > For a better example, please take a look at the 
> > > > `TemplateIdWithComplexFullTypeNTTP` unit tests that I've added: if 
> > > > `PrintCanonicalTypes` is set to `true`, the original print output of 
> > > > type is `NDArray`, and if set to 
> > > > `false` (which is default), the output is `NDArray > > > Height{{{0}}}, Width{{{0}}}, Channels{{{0}}}>` - so the NTTP type is 
> > > > neither fully written nor fully omitted, which is weird.
> > > > 
> > > > As I said, I don't really understand the idea behind 
> > > > `PrintCanonicalTypes`, but when my new 
> > > > `AlwaysIncludeTypeForNonTypeTemplateArgument` is enabled, you will get 
> > > > the full type printed, regardless of value of `PrintCanonicalTypes` 
> > > > setting.
> > > > 
> > > Perhaps this might be more of a bug in PrintCanonicalTypes than something 
> > > to add a separate flag for.
> > > 
> > > @aaron.ballman D2 for context here... 
> > > 
> > > Hmm, actually, just adding the top level `Height{{0}}, Width{{0}}, 
> > > Channels{{0}}` is sufficient to make this code compile (whereas with the 
> > > `{{{0}}}` it doesn't form a valid identifier.
> > > 
> > > So what's your use case for needing more explicitness than that top 
> > > level? 
> > > Perhaps this might be more of a bug in PrintCanonicalTypes than something 
> > > to add a separate flag for.
> > >
> > > @aaron.ballman D2 for context here...
> > 
> > I looked over D2 again and haven't spotted anything with it that seems 
> > amiss; the change there is to grab the canonical type before trying to 
> > print it which is all the more I'd expect `PrintCanonicalTypes` to impact.
> > 
> > This looks like the behavior you'd get when you desugar the type. Check out 
> > the AST dump for `s`: https://godbolt.org/z/vxh5j6qWr
> > ```
> > `-VarDecl  col:20 s 'S':'S<{1, 2}>' callinit
> > ```
> > We generate that type information at 
> > https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/TextNodeDumper.cpp#L663
> >  for doing the AST dump, note how the second type printed is the desugared 
> > type and that matches what we're seeing from the pretty printer.
> > So what's your use case for needing more explicitness than that top level?
> 
> As I described in the [github 
> issue](https://github.com/llvm/llvm-project/issues/57562), I'm trying to 
> write a clang-based tool that will have different behavior if the printed 
> `{{{0}}}` is actually `Width` than if its `Height` or anything else.
> 
> You can see the the issue in the AST dump for `bla`: 
> https://godbolt.org/z/fMr4f13o3
> 
> The type is
> ```
> `-VarDecl  col:21 bla 'NDArray':'NDArray {{{0}}}>' callinit
>   `-CXXConstructExpr  'NDArray':'NDArray' 
> 'void () noexcept'
> ```
> 
> so it's unknown whether `{{{0}}}` represent the `Width` or `Height`. My patch 
> makes it work exactly like GCC (see the comparison of error message between 
> [clang 15 and GCC 12.1](https://godbolt.org/z/WenWe8caf).
> 
> > Perhaps this might be more of a bug in PrintCanonicalTypes than something 
> > to add a separate flag for.
> 
> This was also my first thought and the first version of my patch (before even 
> submitting it here) was to actually change the behavior of 
> `PrintCanonicalTypes`. However, that change made some tests fail, as I 
> described in the patch description:
> 
> - CodeGenCXX/debug-info-template.cpp
> - SemaCXX/constexpr-printing.cpp
> - SemaCXX/cxx2a-nttp-printing.cpp
> - SemaTemplate/temp_arg_string_printing.cpp
> 
> Of course, it's possible to simply update the tests, but I actually don't 
> fully understand what is the goal of `PrintCanonicalTypes` and whether its 
> current behavior is actually desired or not, so I played it safe and 
> introduced a new policy that is disabled by default until I get more feedback 
> from more experienced LLVM developers.
> 
> The patch does solve my problem and since I'm building LLVM from source 
> anyway, I can have it enabled in my fork.
> 
> I just want to see if it would also be beneficial to be introduced into the 
> u

[PATCH] D134546: [clang-offload-bundler] extracting compatible bundle entry

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam added a comment.

The patch looks fine to me.
Please wait for @tra 's final review.

On a different note, can this compatibility testing logic be moved to a llvm 
library instead of clang's?
I want to use it in OpenMP's AMDGPU plugin, which now links llvm libraries by 
default.




Comment at: clang/lib/Driver/OffloadBundler.cpp:1008
+auto Output = Worklist.begin();
+for (auto E = Worklist.end(); Output != E; Output++) {
+  if (isCodeObjectCompatible(

tra wrote:
> The patch description implies that there are at least two classes of 
> compatible objects -- the ones that match exactly and the ones that are not 
> exact match, but are still compatible.
> 
> 
> Here we're iterating until we find the first compatible object. What if we 
> also have the object that matches exactly, but it's further down the list. Is 
> that a problem that we may pick one or the other, depending on the order they 
> happen to appear in the worklist? It would be good to add a test case for 
> this scenario.
Though it looks plausible, such a case is not possible.
 
From [[ https://clang.llvm.org/docs/ClangOffloadBundler.html#bundle-entry-id | 
Clang Offload Bundler's Documentation]]
> If there is an entry with a target feature specified as Any, then all entries 
> must specify that target feature as Any for the same processor.




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

https://reviews.llvm.org/D134546

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

[PATCH] D134542: [Concepts] Recover properly from a RecoveryExpr in a concept

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

The patch looks good. Two high-level questions:

- Does the similar thing happen for class templates? Like a constraint expr of 
a partial specialization has an error. Maybe we don't assert in this case?
- I suppose the constraint error does not always affect the overload resolution 
results. When it does not, an alternative would be to assume the constraint is 
a satisfaction failure and the compilation continues. Do you see any value in 
this approach? Personally, I could go either way. Basically a trade-off between 
pessimistic and optimistic.




Comment at: clang/docs/ReleaseNotes.rst:213
   of FAM-like arrays.
+- Clang will now diagnose an overload set where an option has a constraint that
+  refers to an expression with a previous error as nothing viable, so that it





Comment at: clang/include/clang/Sema/Overload.h:931
 
+bool ConstraintFailureBecauseCascadingError() const;
+

How about `ConstraintExprHasError`? `Cascading` sounds like more details than 
useful.



Comment at: clang/lib/Sema/SemaOverload.cpp:10123-10127
+  if (DeductionFailure.Result != Sema::TDK_ConstraintsNotSatisfied)
+return false;
+
+  return static_cast(DeductionFailure.Data)
+  ->Satisfaction.ContainsErrors;

nit: might be easier to read


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

https://reviews.llvm.org/D134542

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

[PATCH] D134556: [Clang][OpenMP] Fix run time crash when use_device_addr is used.

[Jennifer Yu via Phabricator via cfe-commits]

jyu2 created this revision.
jyu2 added reviewers: ABataev, jdoerfert, mikerice.
jyu2 added a project: OpenMP.
Herald added subscribers: guansong, yaxunl.
Herald added a project: All.
jyu2 requested review of this revision.
Herald added subscribers: openmp-commits, cfe-commits, sstefan1.
Herald added a project: clang.

It is due to data mapping ordering.

According omp spec:
If one or more map clauses are present, the list item conversions that are 
performed for any use_device_ptr or use_device_addr clause occur after all 
variables are mapped on entry to the region according to those map clauses.

The change is to put mapping data for use_device_addr at end of data mapping 
array.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134556

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_data_codegen.cpp
  openmp/libomptarget/test/mapping/target_use_device_addr.c

Index: openmp/libomptarget/test/mapping/target_use_device_addr.c
===
--- /dev/null
+++ openmp/libomptarget/test/mapping/target_use_device_addr.c
@@ -0,0 +1,21 @@
+// RUN: %libomptarget-compile-generic -fopenmp-version=51
+// RUN: %libomptarget-run-generic 2>&1 \
+// RUN: | %fcheck-generic
+
+#include 
+int main()
+{
+  short x[10];
+  short *xp = &x[0];
+
+  x[1] = 111;
+
+  printf("%d, %p\n", xp[1],  &xp[1]);
+  #pragma omp target data use_device_addr(xp[1:3]) map(tofrom: x)
+  #pragma omp target is_device_ptr(xp)
+  {
+xp[1] = 222;
+  }
+  // CHECK: 222
+  printf("%d, %p\n", xp[1],  &xp[1]);
+}
Index: clang/test/OpenMP/target_data_codegen.cpp
===
--- clang/test/OpenMP/target_data_codegen.cpp
+++ clang/test/OpenMP/target_data_codegen.cpp
@@ -596,15 +596,18 @@
 }
 #endif
 ///==///
-// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix CK7 --check-prefix CK7-64
-// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s  --check-prefix CK7 --check-prefix CK7-64
+// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -verify -fopenmp -fopenmp-targets=x86_64 -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix CK7 --check-prefix CK7-64
+// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -fopenmp -fopenmp-targets=x86_64 -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -fopenmp-targets=x86_64 -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s  --check-prefix CK7 --check-prefix CK7-64
 
-// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -verify -fopenmp-simd -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY7 %s
-// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -fopenmp-simd -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY7 %s
+// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -verify -fopenmp-simd -fopenmp-targets=x86_64 -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY7 %s
+// RUN: %clang_cc1 -no-opaque-pointers -DCK7 -fopenmp-simd -fopenmp-targets=x86_64 -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -fopenmp-targets=x86_64 -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY7 %s
 // SIMD-ONLY7-NOT: {{__kmpc|__tgt}}
 #ifdef CK7
+// CK7: private unnamed_addr constant [2 x i64] [i64 64, i64 64]
+// CK7: private unnamed_addr constant [2 x i64] [i64 3, i64 64]
+// CK7-NOT: private unnamed_addr constant [2 x i64] [i64 64, i64 3]
 // CK7: test_device_ptr_addr
 void test_device_ptr_addr(int arg) {
   int *p;
@@ -612,6 +615,16 @@
   // CK7: add nsw i32
   #pragma omp target data use_device_ptr(p) use_device_addr(arg)
   { ++arg, ++(*p); }
+
+  short x[10];
+  short *xp = &x[0];
+
+  x[1] = 111;
+
+  #pragma omp target data map(tofrom: x) use_device_addr(xp[1:3])
+  {
+xp[1] = 222;
+  }
 }
 #endif
 ///==///
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -8556,7 +8556,7 

[PATCH] D134542: [Concepts] Recover properly from a RecoveryExpr in a concept

[Erich Keane via Phabricator via cfe-commits]

erichkeane marked 3 inline comments as done.
erichkeane added a subscriber: tahonermann.
erichkeane added a comment.

In D134542#3812211 , @ychen wrote:

> The patch looks good. Two high-level questions:
>
> - Does the similar thing happen for class templates? Like a constraint expr 
> of a partial specialization has an error. Maybe we don't assert in this case?

WE currently crash in that case as well: https://godbolt.org/z/MGMqz1x59 .  
This patch still crashes in that case, and we should fix that in a similar way. 
 I'll put it on my list of things to do soon!  I don't want to do it in the 
same patch, simply because the type resolution parts are going to be completely 
different, and would likely just double the size of this patch.

> - I suppose the constraint error does not always affect the overload 
> resolution results. When it does not, an alternative would be to assume the 
> constraint is a satisfaction failure and the compilation continues. Do you 
> see any value in this approach? Personally, I could go either way. Basically 
> a trade-off between pessimistic and optimistic.

In cases where the constraint error does not affect overload resolution (like 
with short-circuiting), this patch makes no changes, and will continue without 
it.  ONLY when a constraint that references a RecoveryExpr in some way is used 
will we 'quit' overload resolution.

I ALSO considered just marking as a failure, and continuing, but @tahonermann 
made a point in a private chat that the result is that we'll end up getting 
wacky follow-up errors.  Consider something like:

  template concept HasFoo = /*Test for has foo*/;
 template concept HasBarAlternative = /*test for has bar, but 
with a typo!*/;
  
 template requires HasFoo
 void do_thing(T &t) {
   t.Foo();
   t.Bar();
 }
 template requires HasFoo && HasBarAlternative
 void do_thing(T&t) {
   t.Foo();
   t.BarAlternative();
 }

The result of just marking `HasBarAlternative' as not satisfied, is the 1st 
`do_thing` will be called.  THEN you'd get an error on instantiating because of 
the lack of `Bar`.  This seems like a worse behavior to me, and results in just 
nonsense-errors/not useful errors most of the time.




Comment at: clang/include/clang/Sema/Overload.h:931
 
+bool ConstraintFailureBecauseCascadingError() const;
+

ychen wrote:
> How about `ConstraintExprHasError`? `Cascading` sounds like more details than 
> useful.
Yeah, my name is awful here... I'm not sure `ConstraintExprHasError` is correc 
tin this case (since this is an OverloadCandidate), so the question is "Does 
this candidate fail because this is a constraint that contains an error".  I'll 
try to come up with something better.

Feel free to help bikeshed/workshop something better!



Comment at: clang/lib/Sema/SemaOverload.cpp:10123-10127
+  if (DeductionFailure.Result != Sema::TDK_ConstraintsNotSatisfied)
+return false;
+
+  return static_cast(DeductionFailure.Data)
+  ->Satisfaction.ContainsErrors;

ychen wrote:
> nit: might be easier to read
yep! I like it.  I tend to do early exit when I can, particularly on large 
functions, but this ended up being pretty small in the final version of this 
patch.


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

https://reviews.llvm.org/D134542

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

[PATCH] D134544: [clang-cl] Implement /ZH: flag

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D134544#3811867 , @probinson wrote:

> Probably we should reject the -gsrc... option if we're emitting DWARF, which 
> requires MD5 (at least so far).

It's a cc1 option. As those aren't considered user facing, we don't do a lot of 
checking for them usually.


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

https://reviews.llvm.org/D134544

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

[PATCH] D128142: [MemProf] Memprof profile matching and annotation

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson marked an inline comment as done.
tejohnson added inline comments.



Comment at: llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:1247
+uint32_t Column) {
+  return hash_combine(Function, LineOffset, Column);
+}

MaskRay wrote:
> MaskRay wrote:
> > You may use BLAKE3 instead of MD5. BLAKE3 is much faster than LLVM's slow 
> > MD5 implementation.
> llvm/include/llvm/Support/xxhash.h is also a good choice.
Thanks for the tip! I used BLAKE3.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128142

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

[PATCH] D134542: [Concepts] Recover properly from a RecoveryExpr in a concept

[Erich Keane via Phabricator via cfe-commits]

erichkeane marked 2 inline comments as done.
erichkeane added a comment.

In D134542#3812292 , @erichkeane 
wrote:

> In D134542#3812211 , @ychen wrote:
>
>> The patch looks good. Two high-level questions:
>>
>> - Does the similar thing happen for class templates? Like a constraint expr 
>> of a partial specialization has an error. Maybe we don't assert in this case?
>
> WE currently crash in that case as well: https://godbolt.org/z/MGMqz1x59 .  
> This patch still crashes in that case, and we should fix that in a similar 
> way.  I'll put it on my list of things to do soon!  I don't want to do it in 
> the same patch, simply because the type resolution parts are going to be 
> completely different, and would likely just double the size of this patch.
>
>> - I suppose the constraint error does not always affect the overload 
>> resolution results. When it does not, an alternative would be to assume the 
>> constraint is a satisfaction failure and the compilation continues. Do you 
>> see any value in this approach? Personally, I could go either way. Basically 
>> a trade-off between pessimistic and optimistic.
>
> In cases where the constraint error does not affect overload resolution (like 
> with short-circuiting), this patch makes no changes, and will continue 
> without it.  ONLY when a constraint that references a RecoveryExpr in some 
> way is used will we 'quit' overload resolution.
>
> I ALSO considered just marking as a failure, and continuing, but @tahonermann 
> made a point in a private chat that the result is that we'll end up getting 
> wacky follow-up errors.  Consider something like:
>
>   template concept HasFoo = /*Test for has foo*/;
>  template concept HasBarAlternative = /*test for has bar, but 
> with a typo!*/;
>   
>  template requires HasFoo
>  void do_thing(T &t) {
>t.Foo();
>t.Bar();
>  }
>  template requires HasFoo && HasBarAlternative
>  void do_thing(T&t) {
>t.Foo();
>t.BarAlternative();
>  }
>
> The result of just marking `HasBarAlternative' as not satisfied, is the 1st 
> `do_thing` will be called.  THEN you'd get an error on instantiating because 
> of the lack of `Bar`.  This seems like a worse behavior to me, and results in 
> just nonsense-errors/not useful errors most of the time.

WOOPS!  I was wrong about 'still crashes' here.  I mis-applied one of your 
suggestions and it crashed for another reason!  When properly done, this stops 
that crash, and the Class-template-partial-specializations are just invalid at 
that point.  I think we should still do the same thing as far as failing-lookup 
for the same reasons, so I'll do that separately.


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

https://reviews.llvm.org/D134542

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

[clang] b1926f3 - Restore "[MemProf] Memprof profile matching and annotation"

[Teresa Johnson via cfe-commits]

Author: Teresa Johnson
Date: 2022-09-23T11:38:47-07:00
New Revision: b1926f308f0939b365ee4940c7b1bd984b45e71a

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

LOG: Restore "[MemProf] Memprof profile matching and annotation"

This reverts commit 794b7ea960ccc3222f2af582efadbc5e5c464292, and
thus restores commit a212d8da94d08e229aa8d65283e4b116310bba10, and
follow on fixes 0cd6763fa93159b84d70a5bb602c24996acaafaa,
e9ff53d42feac7fc157718523275619a8106f2f3, and
37c6a25e9ab230e5e21fa34e246d9fec55275df0.

Use a hash function (BLAKE3) instead of hash_combine/hash_code which are
not guaranteed to be stable across executions.

Additionally, it adds a "REQUIRES: x86_64-linux" to the tests that have
raw profile inputs to avoid failures on big endian bots.

Reviewers: snehasish, davidxl

Subscribers: llvm-commits

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

Added: 
clang/test/CodeGen/Inputs/memprof.exe
clang/test/CodeGen/Inputs/memprof.memprofraw
clang/test/CodeGen/memprof.cpp
llvm/test/Transforms/PGOProfile/Inputs/memprof.exe
llvm/test/Transforms/PGOProfile/Inputs/memprof.memprofraw
llvm/test/Transforms/PGOProfile/Inputs/memprof_pgo.profraw
llvm/test/Transforms/PGOProfile/memprof.ll
llvm/test/Transforms/PGOProfile/memprofmissingfunc.ll

Modified: 
clang/lib/Frontend/CompilerInvocation.cpp
llvm/include/llvm/Analysis/MemoryBuiltins.h
llvm/include/llvm/ProfileData/InstrProfReader.h
llvm/lib/Analysis/MemoryBuiltins.cpp
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp

Removed: 




diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 9f9241054b1ef..656e5950db988 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -1306,7 +1306,10 @@ static void setPGOUseInstrumentor(CodeGenOptions &Opts,
   }
   std::unique_ptr PGOReader =
 std::move(ReaderOrErr.get());
-  if (PGOReader->isIRLevelProfile()) {
+  // Currently memprof profiles are only added at the IR level. Mark the 
profile
+  // type as IR in that case as well and the subsequent matching needs to 
detect
+  // which is available (might be one or both).
+  if (PGOReader->isIRLevelProfile() || PGOReader->hasMemoryProfile()) {
 if (PGOReader->hasCSIRLevelProfile())
   Opts.setProfileUse(CodeGenOptions::ProfileCSIRInstr);
 else

diff  --git a/clang/test/CodeGen/Inputs/memprof.exe 
b/clang/test/CodeGen/Inputs/memprof.exe
new file mode 100755
index 0..955c0d6b0e87a
Binary files /dev/null and b/clang/test/CodeGen/Inputs/memprof.exe 
diff er

diff  --git a/clang/test/CodeGen/Inputs/memprof.memprofraw 
b/clang/test/CodeGen/Inputs/memprof.memprofraw
new file mode 100644
index 0..07a3310c122af
Binary files /dev/null and b/clang/test/CodeGen/Inputs/memprof.memprofraw 
diff er

diff  --git a/clang/test/CodeGen/memprof.cpp b/clang/test/CodeGen/memprof.cpp
new file mode 100644
index 0..b246d1f086942
--- /dev/null
+++ b/clang/test/CodeGen/memprof.cpp
@@ -0,0 +1,38 @@
+// Test if memprof instrumentation and use pass are invoked.
+//
+// Instrumentation:
+// Ensure Pass MemProfilerPass and ModuleMemProfilerPass are invoked.
+// RUN: %clang_cc1 -O2 -fmemory-profile %s -fdebug-pass-manager -emit-llvm -o 
- 2>&1 | FileCheck %s -check-prefix=INSTRUMENT
+// INSTRUMENT: Running pass: MemProfilerPass on main
+// INSTRUMENT: Running pass: ModuleMemProfilerPass on [module]
+
+// Avoid failures on big-endian systems that can't read the raw profile 
properly
+// REQUIRES: x86_64-linux
+
+// TODO: Use text profile inputs once that is available for memprof.
+//
+// The following commands were used to compile the source to instrumented
+// executables and collect raw binary format profiles:
+//
+// # Collect memory profile:
+// $ clang++ -fuse-ld=lld -no-pie -Wl,--no-rosegment -gmlt \
+//  -fdebug-info-for-profiling -mno-omit-leaf-frame-pointer \
+//  -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64 -Wl,-build-id 
\
+//  memprof.cpp -o memprof.exe -fmemory-profile
+// $ env MEMPROF_OPTIONS=log_path=stdout ./memprof.exe > memprof.memprofraw
+//
+// RUN: llvm-profdata merge %S/Inputs/memprof.memprofraw --profiled-binary 
%S/Inputs/memprof.exe -o %t.memprofdata
+
+// Profile use:
+// Ensure Pass PGOInstrumentationUse is invoked with the memprof-only profile.
+// RUN: %clang_cc1 -O2 -fprofile-instrument-use-path=%t.memprofdata %s 
-fdebug-pass-manager  -emit-llvm -o - 2>&1 | FileCheck %s -check-prefix=USE
+// USE: Running pass: PGOInstrumentationUse on [module]
+
+char *foo() {
+  return new char[10];
+}
+int main() {
+  char *a = foo();
+  delete[] a;
+  return 0;
+}

diff  --git a/llvm/include/llvm/Analysis/MemoryBuiltins.h 
b/llvm

[PATCH] D134546: [clang-offload-bundler] extracting compatible bundle entry

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/OffloadBundler.cpp:1008
+auto Output = Worklist.begin();
+for (auto E = Worklist.end(); Output != E; Output++) {
+  if (isCodeObjectCompatible(

saiislam wrote:
> tra wrote:
> > The patch description implies that there are at least two classes of 
> > compatible objects -- the ones that match exactly and the ones that are not 
> > exact match, but are still compatible.
> > 
> > 
> > Here we're iterating until we find the first compatible object. What if we 
> > also have the object that matches exactly, but it's further down the list. 
> > Is that a problem that we may pick one or the other, depending on the order 
> > they happen to appear in the worklist? It would be good to add a test case 
> > for this scenario.
> Though it looks plausible, such a case is not possible.
>  
> From [[ https://clang.llvm.org/docs/ClangOffloadBundler.html#bundle-entry-id 
> | Clang Offload Bundler's Documentation]]
> > If there is an entry with a target feature specified as Any, then all 
> > entries must specify that target feature as Any for the same processor.
> 
> 
Does it mean that the bundler is supposed to error out if  I pass 
`-targets=hip-amdgcn-amd-amdhsa--gfx906,hip-amdgcn-amd-amdhsa--gfx906:xnack-` ?

I've just tried it with a bundler built in recent LLVM tree and it accepts such 
a mis of targets without complaining. 




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

https://reviews.llvm.org/D134546

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

[PATCH] D134542: [Concepts] Recover properly from a RecoveryExpr in a concept

[Erich Keane via Phabricator via cfe-commits]

erichkeane updated this revision to Diff 462568.
erichkeane added a comment.

Changes as suggested by @ychen.  Thanks!


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

https://reviews.llvm.org/D134542

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ASTConcept.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Overload.h
  clang/lib/AST/ASTConcept.cpp
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/SemaTemplate/concepts-recovery-expr.cpp

Index: clang/test/SemaTemplate/concepts-recovery-expr.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-recovery-expr.cpp
@@ -0,0 +1,182 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+// expected-error@+1{{use of undeclared identifier 'b'}}
+constexpr bool CausesRecoveryExpr = b;
+
+template
+concept ReferencesCRE = CausesRecoveryExpr;
+
+template requires CausesRecoveryExpr // #NVC1REQ
+void NoViableCands1(){} // #NVC1
+
+template requires ReferencesCRE // #NVC2REQ
+void NoViableCands2(){} // #NVC2
+
+template // #NVC3REQ
+void NoViableCands3(){} // #NVC3
+
+void NVCUse() {
+  NoViableCands1();
+  // expected-error@-1 {{no matching function for call to 'NoViableCands1'}}
+  // expected-note@#NVC1{{candidate template ignored: constraints not satisfied}}
+  // expected-note@#NVC1REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+
+  NoViableCands2();
+  // expected-error@-1 {{no matching function for call to 'NoViableCands2'}}
+  // expected-note@#NVC2{{candidate template ignored: constraints not satisfied}}
+  // expected-note@#NVC2REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+  NoViableCands3();
+  // expected-error@-1 {{no matching function for call to 'NoViableCands3'}}
+  // expected-note@#NVC3{{candidate template ignored: constraints not satisfied}}
+  // expected-note@#NVC3REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+}
+
+template requires CausesRecoveryExpr // #OVC1REQ
+void OtherViableCands1(){} // #OVC1
+
+template
+void OtherViableCands1(){} // #OVC1_ALT
+
+template requires ReferencesCRE // #OVC2REQ
+void OtherViableCands2(){} // #OVC2
+
+template
+void OtherViableCands2(){} // #OVC2_ALT
+
+template // #OVC3REQ
+void OtherViableCands3(){} // #OVC3
+template
+void OtherViableCands3(){} // #OVC3_ALT
+
+void OVCUse() {
+  OtherViableCands1();
+  // expected-error@-1 {{no matching function for call to 'OtherViableCands1'}}
+  // expected-note@#OVC1_ALT {{candidate function}}
+  // expected-note@#OVC1 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OVC1REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+  OtherViableCands2();
+  // expected-error@-1 {{no matching function for call to 'OtherViableCands2'}}
+  // expected-note@#OVC2_ALT {{candidate function}}
+  // expected-note@#OVC2 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OVC2REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+  OtherViableCands3();
+  // expected-error@-1 {{no matching function for call to 'OtherViableCands3'}}
+  // expected-note@#OVC3_ALT {{candidate function}}
+  // expected-note@#OVC3 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OVC3REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+}
+
+template requires CausesRecoveryExpr // #OBNVC1REQ
+void OtherBadNoViableCands1(){} // #OBNVC1
+
+template requires false // #OBNVC1REQ_ALT
+void OtherBadNoViableCands1(){} // #OBNVC1_ALT
+
+template requires ReferencesCRE // #OBNVC2REQ
+void OtherBadNoViableCands2(){} // #OBNVC2
+
+template requires false// #OBNVC2REQ_ALT
+void OtherBadNoViableCands2(){} // #OBNVC2_ALT
+
+template // #OBNVC3REQ
+void OtherBadNoViableCands3(){} // #OBNVC3
+template requires false // #OBNVC3REQ_ALT
+void OtherBadNoViableCands3(){} // #OBNVC3_ALT
+
+void OBNVCUse() {
+  OtherBadNoViableCands1();
+  // expected-error@-1 {{no matching function for call to 'OtherBadNoViableCands1'}}
+  // expected-note@#OBNVC1_ALT {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OBNVC1REQ_ALT {{because 'false' evaluated to false}}
+  // expected-note@#OBNVC1 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@#OBNVC1REQ{{because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression}}
+  OtherBadNoViableCands2();
+  // expected-erro

[PATCH] D134550: [Clang] Make Clang driver suggest '-Xclang' for CC1 options passed to the driver

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

This is a neat idea, but I think we should think about it carefully. In 
general, `-Xclang` is not something we want to actively recommend users use, so 
do we really want to make it easier for users to use?

One potential problem that could be caused by this change is when we have a 
driver option that the user typos but happens to match a -cc1 argument; I could 
see inattentive users going "cool, I'll add -Xclang then" instead of fixing the 
driver arg; but I've not looked through our existing options to see if that 
situation is particularly *likely* or not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134550

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

[PATCH] D134544: [clang-cl] Implement /ZH: flag

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

nice!




Comment at: clang/include/clang/Basic/CodeGenOptions.def:344
 
+/// Set debug info source file hashing algorithm
+ENUM_CODEGENOPT(DebugSrcHashAlgorithm, SrcHashAlgorithm, 2, CSK_MD5)

ultra nit: period. But maybe the comment is superfluous?



Comment at: clang/include/clang/Basic/CodeGenOptions.h:106
+  enum SrcHashAlgorithm {
+CSK_MD5,
+CSK_SHA1,

what does CSK stand for here?


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

https://reviews.llvm.org/D134544

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

[PATCH] D133586: [clang] initialize type qualifiers for FunctionNoProtoType

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM aside from a minor coding style nit, thank you!




Comment at: clang/include/clang/AST/Type.h:3897-3898
+  return Qualifiers::fromFastMask(FunctionTypeBits.FastTypeQuals);
+else
+  return Qualifiers();
   }




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133586

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

[PATCH] D134550: [Clang] Make Clang driver suggest '-Xclang' for CC1 options passed to the driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D134550#3812369 , @aaron.ballman 
wrote:

> This is a neat idea, but I think we should think about it carefully. In 
> general, `-Xclang` is not something we want to actively recommend users use, 
> so do we really want to make it easier for users to use?

Thanks for the feedback, I mostly figured I'd throw out this patch since it 
took a few minutes to make and I've forgotten a few times which arguments need 
the `-Xclang` during Clang development. If you think that users shouldn't be 
exposed to that then it's probably best to hide it from them.

> One potential problem that could be caused by this change is when we have a 
> driver option that the user typos but happens to match a -cc1 argument; I 
> could see inattentive users going "cool, I'll add -Xclang then" instead of 
> fixing the driver arg; but I've not looked through our existing options to 
> see if that situation is particularly *likely* or not.

The logic outlined here should only fire if there is no close match. We only 
check if the input is a `cc1` option right before outputting the normal 
`unknown argument` warning without a suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134550

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D131465#3810070 , @hans wrote:

>> If we're all using `clang` for the command, we'd all get the same behavior, 
>> right? There's no expectation that `clang` and `cl` behave the same way, 
>> that's what `clang-cl` is for. I guess I don't see why we care about how 
>> MSVC behaves unless passing `-fms-compatibility` or using `clang-cl` as the 
>> driver and so I don't see why MSVC should dictate our behavior. (e.g., using 
>> clang and libc++ on Windows because the programmer doesn't want to use MSVC 
>> at all [except for the C runtime, I suppose] is something I believe we want 
>> to support, and with such a use case, defaulting to what MSVC defaults to 
>> seems surprising to me without other motivation.)
>
> Okay, should we key this off the driver mode then (clang-cl vs clang), or on 
> the `-fms-compatibility` version?

Does `clang-cl` set the `-fms-compatibility` version? If so, then it seems like 
we'd probably want to key it off `-fms-compatibility`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[clang] 0d18815 - Fix GH57943: Friend constraint checker didn't handle null decls.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2022-09-23T12:21:56-07:00
New Revision: 0d18815baf6dffa682b0966f311041cfc7d8ff6d

URL: 
https://github.com/llvm/llvm-project/commit/0d18815baf6dffa682b0966f311041cfc7d8ff6d
DIFF: 
https://github.com/llvm/llvm-project/commit/0d18815baf6dffa682b0966f311041cfc7d8ff6d.diff

LOG: Fix GH57943: Friend constraint checker didn't handle null decls.

Apparently TransformDecl in TreeTransform can be called with a nullptr
for a Decl, so my casts were illegal.  The fix here is to add an early
exit to my TransformDecl.

Added: 
clang/test/SemaTemplate/gh57943.cpp

Modified: 
clang/lib/Sema/SemaTemplate.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 68af353e2cc5c..cf501adbe1174 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -1716,6 +1716,8 @@ class ConstraintRefersToContainingTemplateChecker
   }
 
   Decl *TransformDecl(SourceLocation Loc, Decl *D) {
+if (!D)
+  return D;
 // FIXME : This is possibly an incomplete list, but it is unclear what 
other
 // Decl kinds could be used to refer to the template parameters.  This is a
 // best guess so far based on examples currently available, but the

diff  --git a/clang/test/SemaTemplate/gh57943.cpp 
b/clang/test/SemaTemplate/gh57943.cpp
new file mode 100644
index 0..5a9f6f4d09f8a
--- /dev/null
+++ b/clang/test/SemaTemplate/gh57943.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// expected-no-diagnostics
+struct s {
+template
+  requires requires(T x) { x.g(); }
+  friend void f(T);
+};



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

[PATCH] D134453: Introduce the `AlwaysIncludeTypeForNonTypeTemplateArgument` into printing policy

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/include/clang/AST/PrettyPrinter.h:307
+  /// decltype(s) will be printed as "S" if enabled and as 
"S<{1,2}>" if disabled,
+  /// regardless if PrintCanonicalTypes is enabled.
+  unsigned AlwaysIncludeTypeForNonTypeTemplateArgument : 1;

aaron.ballman wrote:
> DoDoENT wrote:
> > aaron.ballman wrote:
> > > dblaikie wrote:
> > > > DoDoENT wrote:
> > > > > dblaikie wrote:
> > > > > > What does `PrintCanonicalTypes` have to do with this? Does it 
> > > > > > overlap with this functionality in some way, but doesn't provide 
> > > > > > the functionality you want in particular?
> > > > > Thank you for the question. If you set the `PrintCanonicalTypes` to 
> > > > > `false`, the `S` would be printed as `S` 
> > > > > even without this patch. However, if you set it to `true`, it will be 
> > > > > printed as `S<{1, 2}>`.
> > > > > 
> > > > > I don't fully understand why it does that, but it's quite annoying.
> > > > > 
> > > > > For a better example, please take a look at the 
> > > > > `TemplateIdWithComplexFullTypeNTTP` unit tests that I've added: if 
> > > > > `PrintCanonicalTypes` is set to `true`, the original print output of 
> > > > > type is `NDArray`, and if set to 
> > > > > `false` (which is default), the output is `NDArray > > > > Height{{{0}}}, Width{{{0}}}, Channels{{{0}}}>` - so the NTTP type is 
> > > > > neither fully written nor fully omitted, which is weird.
> > > > > 
> > > > > As I said, I don't really understand the idea behind 
> > > > > `PrintCanonicalTypes`, but when my new 
> > > > > `AlwaysIncludeTypeForNonTypeTemplateArgument` is enabled, you will 
> > > > > get the full type printed, regardless of value of 
> > > > > `PrintCanonicalTypes` setting.
> > > > > 
> > > > Perhaps this might be more of a bug in PrintCanonicalTypes than 
> > > > something to add a separate flag for.
> > > > 
> > > > @aaron.ballman D2 for context here... 
> > > > 
> > > > Hmm, actually, just adding the top level `Height{{0}}, Width{{0}}, 
> > > > Channels{{0}}` is sufficient to make this code compile (whereas with 
> > > > the `{{{0}}}` it doesn't form a valid identifier.
> > > > 
> > > > So what's your use case for needing more explicitness than that top 
> > > > level? 
> > > > Perhaps this might be more of a bug in PrintCanonicalTypes than 
> > > > something to add a separate flag for.
> > > >
> > > > @aaron.ballman D2 for context here...
> > > 
> > > I looked over D2 again and haven't spotted anything with it that 
> > > seems amiss; the change there is to grab the canonical type before trying 
> > > to print it which is all the more I'd expect `PrintCanonicalTypes` to 
> > > impact.
> > > 
> > > This looks like the behavior you'd get when you desugar the type. Check 
> > > out the AST dump for `s`: https://godbolt.org/z/vxh5j6qWr
> > > ```
> > > `-VarDecl  col:20 s 'S':'S<{1, 2}>' 
> > > callinit
> > > ```
> > > We generate that type information at 
> > > https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/TextNodeDumper.cpp#L663
> > >  for doing the AST dump, note how the second type printed is the 
> > > desugared type and that matches what we're seeing from the pretty printer.
> > > So what's your use case for needing more explicitness than that top level?
> > 
> > As I described in the [github 
> > issue](https://github.com/llvm/llvm-project/issues/57562), I'm trying to 
> > write a clang-based tool that will have different behavior if the printed 
> > `{{{0}}}` is actually `Width` than if its `Height` or anything else.
> > 
> > You can see the the issue in the AST dump for `bla`: 
> > https://godbolt.org/z/fMr4f13o3
> > 
> > The type is
> > ```
> > `-VarDecl  col:21 bla 'NDArray > W>':'NDArray' callinit
> >   `-CXXConstructExpr  'NDArray':'NDArray' 
> > 'void () noexcept'
> > ```
> > 
> > so it's unknown whether `{{{0}}}` represent the `Width` or `Height`. My 
> > patch makes it work exactly like GCC (see the comparison of error message 
> > between [clang 15 and GCC 12.1](https://godbolt.org/z/WenWe8caf).
> > 
> > > Perhaps this might be more of a bug in PrintCanonicalTypes than something 
> > > to add a separate flag for.
> > 
> > This was also my first thought and the first version of my patch (before 
> > even submitting it here) was to actually change the behavior of 
> > `PrintCanonicalTypes`. However, that change made some tests fail, as I 
> > described in the patch description:
> > 
> > - CodeGenCXX/debug-info-template.cpp
> > - SemaCXX/constexpr-printing.cpp
> > - SemaCXX/cxx2a-nttp-printing.cpp
> > - SemaTemplate/temp_arg_string_printing.cpp
> > 
> > Of course, it's possible to simply update the tests, but I actually don't 
> > fully understand what is the goal of `PrintCanonicalTypes` and whether its 
> > current behavior is actually desired or not, so I played it safe and 
> > introduced a new policy that is disabled by default until I get more 
> > feedback from more experienced LLVM

[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

[Puyan Lotfi via Phabricator via cfe-commits]

plotfi added a comment.

In D86049#3812068 , @ahatanak wrote:

> In D86049#3806898 , @plotfi wrote:
>
>> 1. Do we change the existing visibility behavior of objc methods? Yes / No
>
> I don't think we want to change the existing visibility behavior of 
> non-direct objc methods. Is there a use reason or use case for making them 
> visible outside the linkage unit?
>
>> 2. If we leave hidden as the default do we change the behavior for 
>> objc_direct? Yes / No
>
> I think direct methods shouldn't be hidden by default (i.e., they should get 
> the default visibility). But it's not clear to me whether we should make that 
> change right away as I've heard concerns from people internally. I think I 
> need more time to understand what exactly their concerns are.
>
>> 3. If we leave objc_direct as hidden by default do we expand the existing 
>> objc_direct attr to have the enum as you said so 
>> `__attribute__((objc_direct("visible")))` or do we add a new attr as I have 
>> done so far?
>
> I wasn't sure why it wasn't possible to use the existing 
> `__attribute__((visibility("default")))` attribute. Is it not possible to 
> make only the direct methods get the default visibility?

This is not possible because default visibility is implicit (as far as I 
understand). It can not be checked if  `__attribute__((visibility("default")))` 
is set because it is always set unless -fvisibility=hidden is passed on the 
command line. So either we treat direct methods like everything else, and hide 
them when  `__attribute__((visibility("hidden")))` or the command line to hide 
everything by default is used, or we need a new attr or a new enum on the 
existing objc_direct attr.

Does this make sense or am I missing some details?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86049

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

[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

[Puyan Lotfi via Phabricator via cfe-commits]

plotfi added a comment.

In D86049#3812068 , @ahatanak wrote:

> In D86049#3806898 , @plotfi wrote:
>
>> 1. Do we change the existing visibility behavior of objc methods? Yes / No
>
> I don't think we want to change the existing visibility behavior of 
> non-direct objc methods. Is there a use reason or use case for making them 
> visible outside the linkage unit?
>
>> 2. If we leave hidden as the default do we change the behavior for 
>> objc_direct? Yes / No
>
> I think direct methods shouldn't be hidden by default (i.e., they should get 
> the default visibility). But it's not clear to me whether we should make that 
> change right away as I've heard concerns from people internally. I think I 
> need more time to understand what exactly their concerns are.
>
>> 3. If we leave objc_direct as hidden by default do we expand the existing 
>> objc_direct attr to have the enum as you said so 
>> `__attribute__((objc_direct("visible")))` or do we add a new attr as I have 
>> done so far?
>
> I wasn't sure why it wasn't possible to use the existing 
> `__attribute__((visibility("default")))` attribute. Is it not possible to 
> make only the direct methods get the default visibility?

Also, if we make things visible at all we still need to alter the mangling. I 
could make the mangling changes into a separate diff to land that separately. 
Would that be preferable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86049

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D131465#3812387 , @aaron.ballman 
wrote:

> Does `clang-cl` set the `-fms-compatibility` version? If so, then it seems 
> like we'd probably want to key it off `-fms-compatibility`?

I think both driver share the logic for MSVC version detection, which checks 
for cl.exe on PATH and looks at the registry if that fails.

I think we should try to lean towards making this policy easy to document and 
communicate to users, and that means our rules need to be concise. I worry that 
different defaults will surprise cross-platform projects ("hey, my code built 
with on clang Linux, but not Windows with clang-cl, why is that, let's 
debug..."). A simple rule like "clang 16.0 raised the default C++ standard 
version to 17, except on PS4" seems preferable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

[Matt D. via Phabricator via cfe-commits]

Matt added inline comments.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:239
+AARCH64_CPU_NAME("neoverse-v2", ARMV9A, FK_NEON_FP_ARMV8, false,
+ (AArch64::AEK_SVE | AArch64::AEK_SVE2 | AArch64::AEK_SSBS |
+  AArch64::AEK_FP16 | AArch64::AEK_BF16 | AArch64::AEK_RAND |

Should `AEK_SVE2BITPERM` be present? (Noticed that N2 has ` AArch64::AEK_SVE2 | 
AArch64::AEK_SVE2BITPERM`).



Comment at: llvm/lib/Target/AArch64/AArch64.td:
+   FeaturePerfMon, FeatureETE, 
FeatureMatMulInt8,
+   FeatureNEON, FeatureSVE2BitPerm, 
FeatureFP16FML,
+   FeatureMTE, FeatureRandGen];

`FeatureNEON` may be redundant (note that it's in `HasV8_3aOps`).

OTOH, `NeoverseV1` also has `FeatureCrypto`: is this no longer the case for 
`NeoverseV2`?



Comment at: llvm/lib/Target/AArch64/AArch64Subtarget.cpp:202
   case NeoverseN2:
+  case NeoverseV2:
 PrefFunctionLogAlignment = 4;

Are `CacheLineSize` (`= 0` by default) and `MaxInterleaveFactor` (`= 2` by 
default) the same / correct for both N2 and V2?


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

https://reviews.llvm.org/D134352

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

[PATCH] D130131: [HLSL] CodeGen hlsl cbuffer/tbuffer.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added reviewers: rjmccall, efriedma.
aaron.ballman added a comment.

No additional comments from me, but I don't feel comfortable signing off on the 
codegen bits; adding some codegen code owners.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130131

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

[PATCH] D134556: [Clang][OpenMP] Fix run time crash when use_device_addr is used.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8561-8617
 for (const auto *Cl : Clauses) {
   const auto *C = dyn_cast(Cl);
   if (!C)
 continue;
   for (const auto L : C->component_lists()) {
 OMPClauseMappableExprCommon::MappableExprComponentListRef Components =
 std::get<1>(L);

Can you try to merge these 2 blocks somehow, they are very similar


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134556

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