[clang] [clang-format] Add SpacesInParensOption for attributes and filtering for repeated parens (PR #77522)

2024-03-28 Thread Alibek Omarov via cfe-commits 

a1batross wrote:

Any news on this?

https://github.com/llvm/llvm-project/pull/77522
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [RFC][Clang] Enable custom type checking for printf (PR #86801)

2024-03-28 Thread Vikram Hegde via cfe-commits 

vikramRH wrote:

Thanks for the comments @AaronBallman. The core issue here is that the current 
builtin handling design does not allow multiple overloads for the same 
identifier to coexist  (ref. 
https://github.com/llvm/llvm-project/blob/eacda36c7dd842cb15c0c954eda74b67d0c73814/clang/include/clang/Basic/Builtins.h#L66),
 unless the builtins are defined in target specific namespaces which is what I 
tried in my original patch . If we want change this approach, I currently think 
of couple of ways at a top level
1. As you said, we could have OCL specific LibBuiltin and LangBuiltin TableGen 
classes (and corresponding macros in Buitlins.inc). To make this work they 
would need new builtin ID's  of different form (say "BI_OCL##"). 
This is very Language specific.
2. Probably change the current Builtin Info structure to allow vector of 
possible signatures for an identifier. The builtin type decoder could choose 
the appropriate signature based on LangOpt. (This wording is vague and could be 
a separate discussion in itself )

either way, changes in current design are required. printf is the only current 
use case I know that can benefit out of this (since OpenCL v1.2 s6.9.f says 
other library functions defined in C standard header are not available ,so 路‍♂️ 
 ). But I guess we could have more use cases in future. can this be a separate 
discussion ? This patch would unblock my current work for now. 
 


https://github.com/llvm/llvm-project/pull/86801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] add check to suggest replacement of nested std::min or std::max with initializer lists (PR #85572)

2024-03-28 Thread via cfe-commits 


@@ -0,0 +1,199 @@
+//===--- MinMaxUseInitializerListCheck.cpp - clang-tidy 
---===//
+//
+// 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 "MinMaxUseInitializerListCheck.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::modernize {
+
+MinMaxUseInitializerListCheck::MinMaxUseInitializerListCheck(
+StringRef Name, ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  Inserter(Options.getLocalOrGlobal("IncludeStyle",
+utils::IncludeSorter::IS_LLVM),
+   areDiagsSelfContained()) {}
+
+void MinMaxUseInitializerListCheck::storeOptions(
+ClangTidyOptions::OptionMap ) {
+  Options.store(Opts, "IncludeStyle", Inserter.getStyle());
+}
+
+void MinMaxUseInitializerListCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::max"))),
+  anyOf(hasArgument(
+0, callExpr(callee(functionDecl(hasName("::std::max"),
+hasArgument(
+1, callExpr(callee(functionDecl(hasName("::std::max")),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::max")))
+  .bind("topCall"),
+  this);
+
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::min"))),
+  anyOf(hasArgument(
+0, callExpr(callee(functionDecl(hasName("::std::min"),
+hasArgument(
+1, callExpr(callee(functionDecl(hasName("::std::min")),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::min")))
+  .bind("topCall"),
+  this);
+}
+
+void MinMaxUseInitializerListCheck::registerPPCallbacks(
+const SourceManager , Preprocessor *PP, Preprocessor *ModuleExpanderPP) 
{
+  Inserter.registerPreprocessor(PP);
+}
+
+void MinMaxUseInitializerListCheck::check(
+const MatchFinder::MatchResult ) {
+  const CallExpr *TopCall = Match.Nodes.getNodeAs("topCall");
+  MinMaxUseInitializerListCheck::FindArgsResult Result =
+  findArgs(Match, TopCall);
+

sopyb wrote:

@PiotrZSL, could you please provide more details about your review here? I've 
looked at my code and I haven't used any macros. Could you point out 
specifically what you're referring to? Thanks for your help.

https://github.com/llvm/llvm-project/pull/85572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] add check to suggest replacement of nested std::min or std::max with initializer lists (PR #85572)

2024-03-28 Thread via cfe-commits 


@@ -0,0 +1,199 @@
+//===--- MinMaxUseInitializerListCheck.cpp - clang-tidy 
---===//
+//
+// 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 "MinMaxUseInitializerListCheck.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::modernize {
+
+MinMaxUseInitializerListCheck::MinMaxUseInitializerListCheck(
+StringRef Name, ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  Inserter(Options.getLocalOrGlobal("IncludeStyle",
+utils::IncludeSorter::IS_LLVM),
+   areDiagsSelfContained()) {}
+
+void MinMaxUseInitializerListCheck::storeOptions(
+ClangTidyOptions::OptionMap ) {
+  Options.store(Opts, "IncludeStyle", Inserter.getStyle());
+}
+
+void MinMaxUseInitializerListCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::max"))),
+  anyOf(hasArgument(
+0, callExpr(callee(functionDecl(hasName("::std::max"),
+hasArgument(
+1, callExpr(callee(functionDecl(hasName("::std::max")),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::max")))
+  .bind("topCall"),
+  this);
+
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::min"))),
+  anyOf(hasArgument(
+0, callExpr(callee(functionDecl(hasName("::std::min"),
+hasArgument(
+1, callExpr(callee(functionDecl(hasName("::std::min")),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::min")))
+  .bind("topCall"),
+  this);
+}
+
+void MinMaxUseInitializerListCheck::registerPPCallbacks(
+const SourceManager , Preprocessor *PP, Preprocessor *ModuleExpanderPP) 
{
+  Inserter.registerPreprocessor(PP);
+}
+
+void MinMaxUseInitializerListCheck::check(
+const MatchFinder::MatchResult ) {
+  const CallExpr *TopCall = Match.Nodes.getNodeAs("topCall");
+  MinMaxUseInitializerListCheck::FindArgsResult Result =
+  findArgs(Match, TopCall);
+
+  if (!Result.First || !Result.Last || Result.Args.size() <= 2) {
+return;
+  }
+
+  std::string ReplacementText = generateReplacement(Match, TopCall, Result);
+
+  diag(TopCall->getBeginLoc(),
+   "do not use nested std::%0 calls, use %1 instead")
+  << TopCall->getDirectCallee()->getName() << ReplacementText
+  << FixItHint::CreateReplacement(
+ CharSourceRange::getTokenRange(TopCall->getBeginLoc(),
+TopCall->getEndLoc()),
+ ReplacementText)
+  << Inserter.createMainFileIncludeInsertion("");
+}
+
+MinMaxUseInitializerListCheck::FindArgsResult
+MinMaxUseInitializerListCheck::findArgs(const MatchFinder::MatchResult ,
+const CallExpr *Call) {
+  FindArgsResult Result;
+  Result.First = nullptr;
+  Result.Last = nullptr;
+  Result.Compare = nullptr;
+
+  if (Call->getNumArgs() > 2) {
+auto ArgIterator = Call->arguments().begin();
+std::advance(ArgIterator, 2);
+Result.Compare = *ArgIterator;
+  }
+
+  for (const Expr *Arg : Call->arguments()) {
+if (!Result.First)
+  Result.First = Arg;
+
+const CallExpr *InnerCall = dyn_cast(Arg);
+if (InnerCall && InnerCall->getDirectCallee() &&
+InnerCall->getDirectCallee()->getNameAsString() ==
+Call->getDirectCallee()->getNameAsString()) {
+  FindArgsResult InnerResult = findArgs(Match, InnerCall);
+
+  bool processInnerResult = false;
+
+  if (!Result.Compare && !InnerResult.Compare)
+processInnerResult = true;
+  else if (Result.Compare && InnerResult.Compare &&
+   Lexer::getSourceText(CharSourceRange::getTokenRange(
+Result.Compare->getSourceRange()),
+*Match.SourceManager,
+Match.Context->getLangOpts()) ==
+   Lexer::getSourceText(
+   CharSourceRange::getTokenRange(
+   InnerResult.Compare->getSourceRange()),
+   *Match.SourceManager, Match.Context->getLangOpts()))
+processInnerResult = true;
+
+  if (processInnerResult) {
+Result.Args.insert(Result.Args.end(), InnerResult.Args.begin(),
+   InnerResult.Args.end());
+continue;
+  }
+}
+
+if (Arg == Result.Compare)
+  continue;
+

[clang-tools-extra] [clang-tidy] add check to suggest replacement of nested std::min or std::max with initializer lists (PR #85572)

2024-03-28 Thread via cfe-commits 

https://github.com/sopyb updated https://github.com/llvm/llvm-project/pull/85572

>From 17d6ad65216237f9a325d9b608c1372cbbf83ff0 Mon Sep 17 00:00:00 2001
From: sopy 
Date: Sun, 17 Mar 2024 17:30:27 +0200
Subject: [PATCH 1/5] [clang-tidy] add check to suggest replacement of nested
 std::min or std::max with initializer lists

---
 .../clang-tidy/modernize/CMakeLists.txt   |   1 +
 .../MinMaxUseInitializerListCheck.cpp | 138 ++
 .../modernize/MinMaxUseInitializerListCheck.h |  58 
 .../modernize/ModernizeTidyModule.cpp |   3 +
 clang-tools-extra/docs/ReleaseNotes.rst   |   6 +
 .../docs/clang-tidy/checks/list.rst   |   1 +
 6 files changed, 207 insertions(+)
 create mode 100644 
clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp
 create mode 100644 
clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.h

diff --git a/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
index 6852db6c2ee311..8005d6e91c060c 100644
--- a/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
@@ -16,6 +16,7 @@ add_clang_library(clangTidyModernizeModule
   MakeSharedCheck.cpp
   MakeSmartPtrCheck.cpp
   MakeUniqueCheck.cpp
+  MinMaxUseInitializerListCheck.cpp
   ModernizeTidyModule.cpp
   PassByValueCheck.cpp
   RawStringLiteralCheck.cpp
diff --git 
a/clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp
new file mode 100644
index 00..b7dc3ff436f6e3
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp
@@ -0,0 +1,138 @@
+//===--- MinMaxUseInitializerListCheck.cpp - clang-tidy 
---===//
+//
+// 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 "MinMaxUseInitializerListCheck.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::modernize {
+
+MinMaxUseInitializerListCheck::MinMaxUseInitializerListCheck(
+StringRef Name, ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  Inserter(Options.getLocalOrGlobal("IncludeStyle",
+utils::IncludeSorter::IS_LLVM),
+   areDiagsSelfContained()) {}
+
+void MinMaxUseInitializerListCheck::storeOptions(
+ClangTidyOptions::OptionMap ) {
+  Options.store(Opts, "IncludeStyle", Inserter.getStyle());
+}
+
+void MinMaxUseInitializerListCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::max"))),
+  
hasAnyArgument(callExpr(callee(functionDecl(hasName("::std::max"),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::max")))
+  .bind("maxCall"),
+  this);
+
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::min"))),
+  
hasAnyArgument(callExpr(callee(functionDecl(hasName("::std::min"),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::min")))
+  .bind("minCall"),
+  this);
+}
+
+void MinMaxUseInitializerListCheck::registerPPCallbacks(
+const SourceManager , Preprocessor *PP, Preprocessor *ModuleExpanderPP) 
{
+  Inserter.registerPreprocessor(PP);
+}
+
+void MinMaxUseInitializerListCheck::check(
+const MatchFinder::MatchResult ) {
+  const auto *MaxCall = Result.Nodes.getNodeAs("maxCall");
+  const auto *MinCall = Result.Nodes.getNodeAs("minCall");
+
+  const CallExpr *TopCall = MaxCall ? MaxCall : MinCall;
+  if (!TopCall) {
+return;
+  }
+  const QualType ResultType =
+  TopCall->getDirectCallee()->getReturnType().getNonReferenceType();
+
+  const Expr *FirstArg = nullptr;
+  const Expr *LastArg = nullptr;
+  std::vector Args;
+  findArgs(TopCall, , , Args);
+
+  if (!FirstArg || !LastArg || Args.size() <= 2) {
+return;
+  }
+
+  std::string ReplacementText = "{";
+  for (const Expr *Arg : Args) {
+QualType ArgType = Arg->getType();
+bool CastNeeded =
+ArgType.getCanonicalType() != ResultType.getCanonicalType();
+
+if (CastNeeded)
+  ReplacementText += "static_cast<" + ResultType.getAsString() + ">(";
+
+ReplacementText += Lexer::getSourceText(
+CharSourceRange::getTokenRange(Arg->getSourceRange()),
+*Result.SourceManager, Result.Context->getLangOpts());
+
+if (CastNeeded)
+  ReplacementText += ")";
+ReplacementText += ", ";
+  }
+  ReplacementText =

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

ChuanqiXu9 wrote:

> > Yes, I explained this in Some low level details section. The size of source 
> > location won't be affected. Since the size of source location is unsigned 
> > (practically, it is 32 bits in most platforms). And we use uint64_t as a 
> > unit in the serializer. So there are 32 bit not used completely. The plan 
> > is to store the module file index in the higher 32 bits and it shouldn't be 
> > a safe problem. Maybe the original wording is not so clear. I've updated it.
> 
> Thank you, using 64 bits in the serialization format makes sense! This also 
> means that whenever Clang is configured with 64 bit `SourceLocation`, we 
> should be using 96 bits for serialization: 32 bits for the module file index 
> and 64 bits for the offset itself, correct?

If Clang is configured with 64 bit `SourceLocation`, we can't use 96 bits for 
serialization. We can at most use 64 bits for a slot. In that case, we can only 
assume the offset of source location **in its own module** (not the global 
offset!) is not large than 2^32. I hope this may not be true.

> 
> > The only trade-off I saw about this change is that it may increase the size 
> > of **on-disk** .pcm files due to we use VBR6 format to decrease the size of 
> > small numbers. But on the one side, we still need to pay for more spaces if 
> > we want to use `{local-module-index, offset-within-module} pair` (Thanks 
> > for the good name suggestion). On the other hand, from the experiment, it 
> > shows the overhead is acceptable.
> 
> Sorry, I don't quite understand. Are you saying you did or did not try to 
> encode this as two separate 32bit values?

I **tried** to encode this as two separate 32bit values. But it will break too 
many codes. Since a lot of places assume that we can encode the source location 
as an uint64_t.

What I mean is, with VBR6 format 
(https://llvm.org/docs/BitCodeFormat.html#variable-width-integer),  we can save 
more space for small integers in **on-disk** .pcm files (the memory 
representation should be the same). For example, for a 64 bits unsigned int 
`1`, VBR6 can use only 6 bits to store that `01` to represent the 64 bits 
value `1` in the on-disk representations. So that even if I don't use more 
slots to store the module file index, the size of the .pcm files will increase 
after all.

https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] add check to suggest replacement of nested std::min or std::max with initializer lists (PR #85572)

2024-03-28 Thread via cfe-commits 

https://github.com/sopyb updated https://github.com/llvm/llvm-project/pull/85572

>From 17d6ad65216237f9a325d9b608c1372cbbf83ff0 Mon Sep 17 00:00:00 2001
From: sopy 
Date: Sun, 17 Mar 2024 17:30:27 +0200
Subject: [PATCH 1/5] [clang-tidy] add check to suggest replacement of nested
 std::min or std::max with initializer lists

---
 .../clang-tidy/modernize/CMakeLists.txt   |   1 +
 .../MinMaxUseInitializerListCheck.cpp | 138 ++
 .../modernize/MinMaxUseInitializerListCheck.h |  58 
 .../modernize/ModernizeTidyModule.cpp |   3 +
 clang-tools-extra/docs/ReleaseNotes.rst   |   6 +
 .../docs/clang-tidy/checks/list.rst   |   1 +
 6 files changed, 207 insertions(+)
 create mode 100644 
clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp
 create mode 100644 
clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.h

diff --git a/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
index 6852db6c2ee311..8005d6e91c060c 100644
--- a/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
@@ -16,6 +16,7 @@ add_clang_library(clangTidyModernizeModule
   MakeSharedCheck.cpp
   MakeSmartPtrCheck.cpp
   MakeUniqueCheck.cpp
+  MinMaxUseInitializerListCheck.cpp
   ModernizeTidyModule.cpp
   PassByValueCheck.cpp
   RawStringLiteralCheck.cpp
diff --git 
a/clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp
new file mode 100644
index 00..b7dc3ff436f6e3
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/modernize/MinMaxUseInitializerListCheck.cpp
@@ -0,0 +1,138 @@
+//===--- MinMaxUseInitializerListCheck.cpp - clang-tidy 
---===//
+//
+// 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 "MinMaxUseInitializerListCheck.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::modernize {
+
+MinMaxUseInitializerListCheck::MinMaxUseInitializerListCheck(
+StringRef Name, ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  Inserter(Options.getLocalOrGlobal("IncludeStyle",
+utils::IncludeSorter::IS_LLVM),
+   areDiagsSelfContained()) {}
+
+void MinMaxUseInitializerListCheck::storeOptions(
+ClangTidyOptions::OptionMap ) {
+  Options.store(Opts, "IncludeStyle", Inserter.getStyle());
+}
+
+void MinMaxUseInitializerListCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::max"))),
+  
hasAnyArgument(callExpr(callee(functionDecl(hasName("::std::max"),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::max")))
+  .bind("maxCall"),
+  this);
+
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(hasName("::std::min"))),
+  
hasAnyArgument(callExpr(callee(functionDecl(hasName("::std::min"),
+  unless(
+  
hasParent(callExpr(callee(functionDecl(hasName("::std::min")))
+  .bind("minCall"),
+  this);
+}
+
+void MinMaxUseInitializerListCheck::registerPPCallbacks(
+const SourceManager , Preprocessor *PP, Preprocessor *ModuleExpanderPP) 
{
+  Inserter.registerPreprocessor(PP);
+}
+
+void MinMaxUseInitializerListCheck::check(
+const MatchFinder::MatchResult ) {
+  const auto *MaxCall = Result.Nodes.getNodeAs("maxCall");
+  const auto *MinCall = Result.Nodes.getNodeAs("minCall");
+
+  const CallExpr *TopCall = MaxCall ? MaxCall : MinCall;
+  if (!TopCall) {
+return;
+  }
+  const QualType ResultType =
+  TopCall->getDirectCallee()->getReturnType().getNonReferenceType();
+
+  const Expr *FirstArg = nullptr;
+  const Expr *LastArg = nullptr;
+  std::vector Args;
+  findArgs(TopCall, , , Args);
+
+  if (!FirstArg || !LastArg || Args.size() <= 2) {
+return;
+  }
+
+  std::string ReplacementText = "{";
+  for (const Expr *Arg : Args) {
+QualType ArgType = Arg->getType();
+bool CastNeeded =
+ArgType.getCanonicalType() != ResultType.getCanonicalType();
+
+if (CastNeeded)
+  ReplacementText += "static_cast<" + ResultType.getAsString() + ">(";
+
+ReplacementText += Lexer::getSourceText(
+CharSourceRange::getTokenRange(Arg->getSourceRange()),
+*Result.SourceManager, Result.Context->getLangOpts());
+
+if (CastNeeded)
+  ReplacementText += ")";
+ReplacementText += ", ";
+  }
+  ReplacementText =

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Jan Svoboda via cfe-commits 

jansvoboda11 wrote:

> Yes, I explained this in Some low level details section. The size of source 
> location won't be affected. Since the size of source location is unsigned 
> (practically, it is 32 bits in most platforms). And we use uint64_t as a unit 
> in the serializer. So there are 32 bit not used completely. The plan is to 
> store the module file index in the higher 32 bits and it shouldn't be a safe 
> problem. Maybe the original wording is not so clear. I've updated it.

Thank you, using 64 bits in the serialization format makes sense! This also 
means that whenever Clang is configured with 64 bit `SourceLocation`, we should 
be using 96 bits for serialization: 32 bits for the module file index and 64 
bits for the offset itself, correct?

> The only trade-off I saw about this change is that it may increase the size 
> of **on-disk** .pcm files due to we use VBR6 format to decrease the size of 
> small numbers. But on the one side, we still need to pay for more spaces if 
> we want to use `{local-module-index, offset-within-module} pair` (Thanks for 
> the good name suggestion). On the other hand, from the experiment, it shows 
> the overhead is acceptable.

Sorry, I don't quite understand. Are you saying you did or did not try to 
encode this as two separate 32bit values?

https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)

2024-03-28 Thread Kees Cook via cfe-commits 

kees wrote:

I guess I don't have a strong opinion here, since these helpers are specific to 
C++, and I've been generally trying to remove fixed-size 0-sized arrays in C 
projects (i.e. the Linux kernel). I do care about C flexible arrays (and their 
associated extensions), though. I suspect there is some existing weirdness for 
C++ when using static initializers, though. See https://godbolt.org/z/PnYMcxhfM

```
struct S { int a; int b[]; };
static struct S s = { .a = 42, .b = { 10, 20, 30, 40 }, };
static struct S z = { .a = 13, };
```

Specifically `z.b` is a 0-sized flexible array, but `s.b` isn't. Should they 
have different results?

https://github.com/llvm/llvm-project/pull/86652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 


@@ -60,11 +63,11 @@ int use() {
 
 // CHECK-NOT: @_ZTSW3Mod4Base = constant
 // CHECK-NOT: @_ZTIW3Mod4Base = constant
-// CHECK: @_ZTVW3Mod4Base = external unnamed_addr
+// CHECK: @_ZTVW3Mod4Base = external
 
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3Mod4Base = linkonce_odr {{.*}}constant
+// CHECK-INLINE-NOT: @_ZTSW3Mod4Base = constant

ChuanqiXu9 wrote:

They should be emitted in other TU and not emitted at all in the current TU. So 
I updated the test to `// CHECK-INLINE-NOT: @_ZTSW3Mod4Base` as suggested.

https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 


@@ -1483,10 +1483,15 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl 
*D) {
   if (D->isThisDeclarationADefinition())
 Record.AddCXXDefinitionData(D);
 
-  // Store (what we currently believe to be) the key function to avoid
-  // deserializing every method so we can compute it.
-  if (D->isCompleteDefinition())
-Record.AddDeclRef(Context.getCurrentKeyFunction(D));
+  if (D->isCompleteDefinition()) {
+if (D->getOwningModule() && D->getOwningModule()->isInterfaceOrPartition())
+  Writer.ModularCodegenDecls.push_back(Writer.GetDeclRef(D));
+else {
+  // Store (what we currently believe to be) the key function to avoid

ChuanqiXu9 wrote:

```suggestion
if (D->isCompleteDefinition() && D->getOwningModule() &&
D->getOwningModule()->isInterfaceOrPartition())
  Writer.ModularCodegenDecls.push_back(Writer.GetDeclRef(D));

  // Store (what we currently believe to be) the key function to avoid
  // deserializing every method so we can compute it.
  if (D->isCompleteDefinition())
Record.AddDeclRef(Context.getCurrentKeyFunction(D));
```

Do you mean such changes? I feel it is somewhat overkill since it looks pretty 
straight forward due to the code is pretty near and the patch itself is about 
we don't need more key functions in modules.

https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [HLSL][DXIL][SPIRV] Intrinsic unification PR (PR #87034)

2024-03-28 Thread Farzon Lotfi via cfe-commits 

https://github.com/farzonl created 
https://github.com/llvm/llvm-project/pull/87034

 DO NOT MERGE 
This is part of a proposal for how to unify spir-v and DirectX intrinsics. 
The issue tracking this work is: #83882


>From 8f7fb8ece073c251f78a2133b42d8baccb89c7f3 Mon Sep 17 00:00:00 2001
From: Farzon Lotfi 
Date: Thu, 28 Mar 2024 21:05:36 -0400
Subject: [PATCH] [HLSL][DXIL][SPIRV] Intrinsic unification PR

---
 clang/include/clang/Basic/Builtins.td |   6 +
 clang/lib/CodeGen/CGBuiltin.cpp   |   7 +
 clang/lib/CodeGen/CGHLSLRuntime.cpp   |   5 +-
 clang/lib/Headers/hlsl/hlsl_intrinsics.h  | 112 +
 clang/lib/Sema/SemaChecking.cpp   |   1 +
 clang/test/CodeGenHLSL/builtins/all.hlsl  | 233 ++
 .../semantics/DispatchThreadID.hlsl   |  13 +-
 llvm/include/llvm/IR/CMakeLists.txt   |   1 +
 llvm/include/llvm/IR/Intrinsics.td|   1 +
 llvm/include/llvm/IR/IntrinsicsDirectX.td |   1 -
 llvm/include/llvm/IR/IntrinsicsHLSL.td|  17 ++
 llvm/include/llvm/IR/IntrinsicsSPIRV.td   |   1 -
 llvm/lib/IR/Function.cpp  |   1 +
 llvm/lib/Target/DirectX/DXIL.td   |   2 +-
 llvm/lib/Target/DirectX/DXILOpLowering.cpp|   1 +
 .../Target/SPIRV/SPIRVInstructionSelector.cpp |  36 ++-
 llvm/test/CodeGen/DirectX/comput_ids.ll   |   4 +-
 .../hlsl-intrinsics/SV_DispatchThreadID.ll|   8 +-
 .../test/CodeGen/SPIRV/hlsl-intrinsics/all.ll |  95 +++
 .../secondary/llvm/include/llvm/IR/BUILD.gn   |   5 +
 20 files changed, 522 insertions(+), 28 deletions(-)
 create mode 100644 clang/test/CodeGenHLSL/builtins/all.hlsl
 create mode 100644 llvm/include/llvm/IR/IntrinsicsHLSL.td
 create mode 100644 llvm/test/CodeGen/SPIRV/hlsl-intrinsics/all.ll

diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index f421223ff087de..d6ceb450bd106b 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -4587,6 +4587,12 @@ def GetDeviceSideMangledName : LangBuiltin<"CUDA_LANG"> {
 }
 
 // HLSL
+def HLSLAll : LangBuiltin<"HLSL_LANG"> {
+  let Spellings = ["__builtin_hlsl_elementwise_all"];
+  let Attributes = [NoThrow, Const];
+  let Prototype = "bool(...)";
+}
+
 def HLSLAny : LangBuiltin<"HLSL_LANG"> {
   let Spellings = ["__builtin_hlsl_elementwise_any"];
   let Attributes = [NoThrow, Const];
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 287e763bad82dd..0a6d6b91c51e6f 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -45,6 +45,7 @@
 #include "llvm/IR/IntrinsicsARM.h"
 #include "llvm/IR/IntrinsicsBPF.h"
 #include "llvm/IR/IntrinsicsDirectX.h"
+#include "llvm/IR/IntrinsicsHLSL.h"
 #include "llvm/IR/IntrinsicsHexagon.h"
 #include "llvm/IR/IntrinsicsNVPTX.h"
 #include "llvm/IR/IntrinsicsPowerPC.h"
@@ -18192,6 +18193,12 @@ Value *CodeGenFunction::EmitHLSLBuiltinExpr(unsigned 
BuiltinID,
 return nullptr;
 
   switch (BuiltinID) {
+  case Builtin::BI__builtin_hlsl_elementwise_all: {
+Value *Op0 = EmitScalarExpr(E->getArg(0));
+return Builder.CreateIntrinsic(
+/*ReturnType=*/llvm::Type::getInt1Ty(getLLVMContext()),
+Intrinsic::hlsl_all, ArrayRef{Op0}, nullptr, "hlsl.all");
+  }
   case Builtin::BI__builtin_hlsl_elementwise_any: {
 Value *Op0 = EmitScalarExpr(E->getArg(0));
 return Builder.CreateIntrinsic(
diff --git a/clang/lib/CodeGen/CGHLSLRuntime.cpp 
b/clang/lib/CodeGen/CGHLSLRuntime.cpp
index 794d93358b0a4c..da5424e77fcdf0 100644
--- a/clang/lib/CodeGen/CGHLSLRuntime.cpp
+++ b/clang/lib/CodeGen/CGHLSLRuntime.cpp
@@ -18,6 +18,7 @@
 #include "clang/AST/Decl.h"
 #include "clang/Basic/TargetOptions.h"
 #include "llvm/IR/IntrinsicsDirectX.h"
+#include "llvm/IR/IntrinsicsHLSL.h"
 #include "llvm/IR/IntrinsicsSPIRV.h"
 #include "llvm/IR/Metadata.h"
 #include "llvm/IR/Module.h"
@@ -346,10 +347,8 @@ llvm::Value *CGHLSLRuntime::emitInputSemantic(IRBuilder<> 
,
 llvm::Function *ThreadIDIntrinsic;
 switch (CGM.getTarget().getTriple().getArch()) {
 case llvm::Triple::dxil:
-  ThreadIDIntrinsic = CGM.getIntrinsic(Intrinsic::dx_thread_id);
-  break;
 case llvm::Triple::spirv:
-  ThreadIDIntrinsic = CGM.getIntrinsic(Intrinsic::spv_thread_id);
+  ThreadIDIntrinsic = CGM.getIntrinsic(Intrinsic::hlsl_thread_id);
   break;
 default:
   llvm_unreachable("Input semantic not supported by target");
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index a34e72402c0e64..762823de523aaa 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -100,6 +100,118 @@ double3 abs(double3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_abs)
 double4 abs(double4);
 
+//===--===//
+// all builtins

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 


@@ -41,9 +43,10 @@ Base::~Base() {}
 // CHECK: @_ZTSW3Mod4Base = constant
 // CHECK: @_ZTIW3Mod4Base = constant
 
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3Mod4Base = linkonce_odr {{.*}}constant
+// With the new Itanium C++ ABI, the linkage of vtables in modules don't need 
to be linkonce ODR.

ChuanqiXu9 wrote:

If it is linkonce, as long as I understand correctly, if the vtable is not used 
in the current TU, the middle end is free to remove the unused linkonce entity. 
But this is not wanted. Since all the things in the module purview is 
potentially used. Do I misunderstand anything?

https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/75912

>From 7399d2417a4b758fa0a98da1f99f3b4ec0eb1046 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 19 Dec 2023 17:00:59 +0800
Subject: [PATCH 1/2] [C++20] [Modules] [Itanium ABI] Generate the vtable in
 the module unit of dynamic classes

Close https://github.com/llvm/llvm-project/issues/70585 and reflect
https://github.com/itanium-cxx-abi/cxx-abi/issues/170.

The significant change of the patch is: for dynamic classes attached to
module units, we generate the vtable to the attached module units
directly and the key functions for such classes is meaningless.
---
 clang/lib/CodeGen/CGVTables.cpp   | 28 ++
 clang/lib/CodeGen/CodeGenModule.cpp   |  9 +
 clang/lib/CodeGen/ItaniumCXXABI.cpp   |  6 +++
 clang/lib/Sema/SemaDecl.cpp   |  9 +
 clang/lib/Sema/SemaDeclCXX.cpp| 13 +--
 clang/lib/Serialization/ASTReaderDecl.cpp | 13 ++-
 clang/lib/Serialization/ASTWriterDecl.cpp | 13 +--
 clang/test/CodeGenCXX/modules-vtable.cppm | 27 -
 clang/test/CodeGenCXX/pr70585.cppm| 47 +++
 9 files changed, 139 insertions(+), 26 deletions(-)
 create mode 100644 clang/test/CodeGenCXX/pr70585.cppm

diff --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index 8dee3f74b44b4e..54a2c725a10ba3 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -1046,6 +1046,11 @@ CodeGenModule::getVTableLinkage(const CXXRecordDecl *RD) 
{
   if (!RD->isExternallyVisible())
 return llvm::GlobalVariable::InternalLinkage;
 
+  // V-tables for non-template classes with an owning module are always
+  // uniquely emitted in that module.
+  if (Module *M = RD->getOwningModule(); M && M->isNamedModule())
+return llvm::GlobalVariable::ExternalLinkage;
+
   // We're at the end of the translation unit, so the current key
   // function is fully correct.
   const CXXMethodDecl *keyFunction = Context.getCurrentKeyFunction(RD);
@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const 
CXXRecordDecl *RD) {
   TSK == TSK_ExplicitInstantiationDefinition)
 return false;
 
+  // Itanium C++ ABI [5.2.3]:
+  // Virtual tables for dynamic classes are emitted as follows:
+  //
+  // - If the class is templated, the tables are emitted in every object that
+  // references any of them.
+  // - Otherwise, if the class is attached to a module, the tables are uniquely
+  // emitted in the object for the module unit in which it is defined.
+  // - Otherwise, if the class has a key function (see below), the tables are
+  // emitted in the object for the translation unit containing the definition 
of
+  // the key function. This is unique if the key function is not inline.
+  // - Otherwise, the tables are emitted in every object that references any of
+  // them.
+  if (Module *M = RD->getOwningModule(); M && M->isNamedModule())
+return M != CGM.getContext().getCurrentNamedModule();
+
   // Otherwise, if the class doesn't have a key function (possibly
   // anymore), the vtable must be defined here.
   const CXXMethodDecl *keyFunction = 
CGM.getContext().getCurrentKeyFunction(RD);
@@ -1189,13 +1209,7 @@ bool CodeGenVTables::isVTableExternal(const 
CXXRecordDecl *RD) {
   const FunctionDecl *Def;
   // Otherwise, if we don't have a definition of the key function, the
   // vtable must be defined somewhere else.
-  if (!keyFunction->hasBody(Def))
-return true;
-
-  assert(Def && "The body of the key function is not assigned to Def?");
-  // If the non-inline key function comes from another module unit, the vtable
-  // must be defined there.
-  return Def->isInAnotherModuleUnit() && !Def->isInlineSpecified();
+  return !keyFunction->hasBody(Def);
 }
 
 /// Given that we're currently at the end of the translation unit, and
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index e3ed5e90f2d36b..61369bedd147eb 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -6777,6 +6777,15 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) {
 if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
   DI->completeUnusedClass(*CRD);
 }
+// If we're emitting a dynamic class from the importable module we're
+// emitting, we always need to emit the virtual table according to the ABI
+// requirement.
+if (CRD->getOwningModule() &&
+CRD->getOwningModule()->isInterfaceOrPartition() &&
+CRD->getDefinition() && CRD->isDynamicClass() &&
+CRD->getOwningModule() == getContext().getCurrentNamedModule())
+  EmitVTable(CRD);
+
 // Emit any static data members, they may be definitions.
 for (auto *I : CRD->decls())
   if (isa(I) || isa(I))
diff --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index bdd53a192f828a..6473f356d5bb19

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Fix a CTAD regression after 42239d2e9 (PR #86914)

2024-03-28 Thread Younan Zhang via cfe-commits 


@@ -1836,7 +1836,19 @@ static TemplateParameterList 
*GetTemplateParameterList(TemplateDecl *TD) {
   // Make sure we get the template parameter list from the most
   // recent declaration, since that is the only one that is guaranteed to
   // have all the default template argument information.
-  return cast(TD->getMostRecentDecl())->getTemplateParameters();
+  Decl *ND = TD->getMostRecentDecl();
+  // Skip past friend Decls because they are not supposed to contain default
+  // template arguments. Moreover, these declarations may introduce template
+  // parameters living in different template depths than the corresponding
+  // template parameters in TD, causing unmatched constraint substitution.
+  //
+  // C++23 N4950 [temp.param]p12

zyn0217 wrote:

> nit: this is not a new thing in C++23, I also find it in the C++20 spec 
> N4860. I'd remove the C++23 N4950.

I referenced that number because I'm concerned the paragraphs/wordings could 
vary across standards. :)
(Maybe I should use an earlier standard file number where this line first 
appears...?)

https://github.com/llvm/llvm-project/pull/86914
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Ignore the parentheses in the guard of DiagnoseUnexpandedParameterPack (PR #86401)

2024-03-28 Thread Younan Zhang via cfe-commits 

https://github.com/zyn0217 converted_to_draft 
https://github.com/llvm/llvm-project/pull/86401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Ignore the parentheses in the guard of DiagnoseUnexpandedParameterPack (PR #86401)

2024-03-28 Thread Younan Zhang via cfe-commits 

zyn0217 wrote:

@dwblaikie : You're right. The patch is insufficient because the 
`FunctionParmPackExpr` in your example could also be wrapped with e.g.
```
CallExpr 0x649b0cf0 ''
|-UnresolvedLookupExpr 0x649af8f8 '' lvalue (ADL) 
= 'f1' 0x64990e98
`-FunctionParmPackExpr 0x649af9c0 'Ts...' lvalue
```
... a CallExpr.

Admittedly, I don't like the way that this and previous fixes have taken: the 
assertion we have run into *really* seems unnecessary because the following 
`DiagnoseUnexpandedParameterPacks` handles the empty pack cases. In my first 
attempt, I proposed to remove these assertions, while Corentin worried that 
they could hide other issues, which I have agreed with because, indeed, we have 
many bugs that the crash locations are not where the underlying problems lurk.

Either way, I think I'm going to take a deeper look, probably I should think of 
a more optimal approach instead of adding such "whack a mole" fixes. I will 
turn it to draft, probably these issues will get fixed together with my 
https://github.com/llvm/llvm-project/pull/86265 - I'll notify you when 
everything is ready.


https://github.com/llvm/llvm-project/pull/86401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/85050

>From b46c8fa030deb980c1550edc0ff8510d4e3c4e17 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 12 Mar 2024 17:26:49 +0800
Subject: [PATCH 1/3] [C++20] [Modules] Introduce -fgen-reduced-bmi

---
 clang/include/clang/CodeGen/CodeGenAction.h   |  2 +
 clang/include/clang/Driver/Options.td |  6 +++
 .../include/clang/Frontend/FrontendOptions.h  |  9 +++-
 clang/include/clang/Serialization/ASTWriter.h |  7 +--
 clang/lib/CodeGen/CodeGenAction.cpp   | 19 +++
 clang/lib/Driver/Driver.cpp   | 27 +-
 clang/lib/Driver/ToolChains/Clang.cpp | 41 --
 clang/lib/Driver/ToolChains/Clang.h   | 14 +
 clang/lib/Frontend/FrontendActions.cpp|  7 +++
 clang/lib/Frontend/PrecompiledPreamble.cpp|  3 +-
 clang/lib/Serialization/GeneratePCH.cpp   | 23 ++--
 .../test/Driver/module-fgen-reduced-bmi.cppm  | 53 +++
 clang/test/Modules/gen-reduced-bmi.cppm   | 36 +
 13 files changed, 220 insertions(+), 27 deletions(-)
 create mode 100644 clang/test/Driver/module-fgen-reduced-bmi.cppm
 create mode 100644 clang/test/Modules/gen-reduced-bmi.cppm

diff --git a/clang/include/clang/CodeGen/CodeGenAction.h 
b/clang/include/clang/CodeGen/CodeGenAction.h
index 7ad2988e589eb2..186dbb43f01ef7 100644
--- a/clang/include/clang/CodeGen/CodeGenAction.h
+++ b/clang/include/clang/CodeGen/CodeGenAction.h
@@ -57,6 +57,8 @@ class CodeGenAction : public ASTFrontendAction {
   bool loadLinkModules(CompilerInstance );
 
 protected:
+  bool BeginSourceFileAction(CompilerInstance ) override;
+
   /// Create a new code generation action.  If the optional \p _VMContext
   /// parameter is supplied, the action uses it without taking ownership,
   /// otherwise it creates a fresh LLVM context and takes ownership.
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 29066ea14280c2..7288bb3db493ba 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3017,6 +3017,7 @@ defm prebuilt_implicit_modules : 
BoolFOption<"prebuilt-implicit-modules",
 
 def fmodule_output_EQ : Joined<["-"], "fmodule-output=">,
   Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>,
+  MarshallingInfoString>,
   HelpText<"Save intermediate module file results when compiling a standard 
C++ module unit.">;
 def fmodule_output : Flag<["-"], "fmodule-output">, Flags<[NoXarchOption]>,
   Visibility<[ClangOption, CC1Option]>,
@@ -3030,6 +3031,11 @@ defm skip_odr_check_in_gmf : BoolOption<"f", 
"skip-odr-check-in-gmf",
   "Perform ODR checks for decls in the global module fragment.">>,
   Group;
 
+def gen_reduced_bmi : Flag<["-"], "fgen-reduced-bmi">,
+  Group, Visibility<[ClangOption, CC1Option]>,
+  HelpText<"Generate the reduced BMI">,
+  MarshallingInfoFlag>;
+
 def fmodules_prune_interval : Joined<["-"], "fmodules-prune-interval=">, 
Group,
   Visibility<[ClangOption, CC1Option]>, MetaVarName<"">,
   HelpText<"Specify the interval (in seconds) between attempts to prune the 
module cache">,
diff --git a/clang/include/clang/Frontend/FrontendOptions.h 
b/clang/include/clang/Frontend/FrontendOptions.h
index 8085dbcbf671a6..ddfd4f30d1b773 100644
--- a/clang/include/clang/Frontend/FrontendOptions.h
+++ b/clang/include/clang/Frontend/FrontendOptions.h
@@ -387,6 +387,10 @@ class FrontendOptions {
   LLVM_PREFERRED_TYPE(bool)
   unsigned ModulesShareFileManager : 1;
 
+  /// Whether to generate reduced BMI for C++20 named modules.
+  LLVM_PREFERRED_TYPE(bool)
+  unsigned GenReducedBMI : 1;
+
   CodeCompleteOptions CodeCompleteOpts;
 
   /// Specifies the output format of the AST.
@@ -553,6 +557,9 @@ class FrontendOptions {
   /// Path which stores the output files for -ftime-trace
   std::string TimeTracePath;
 
+  /// Output Path for module output file.
+  std::string ModuleOutputPath;
+
 public:
   FrontendOptions()
   : DisableFree(false), RelocatablePCH(false), ShowHelp(false),
@@ -565,7 +572,7 @@ class FrontendOptions {
 BuildingImplicitModuleUsesLock(true), ModulesEmbedAllFiles(false),
 IncludeTimestamps(true), UseTemporary(true),
 AllowPCMWithCompilerErrors(false), ModulesShareFileManager(true),
-TimeTraceGranularity(500) {}
+GenReducedBMI(false), TimeTraceGranularity(500) {}
 
   /// getInputKindForExtension - Return the appropriate input kind for a file
   /// extension. For example, "c" would return Language::C.
diff --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index 3ed9803fa3745b..bd310b6c7a5cdd 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -846,7 +846,7 @@ class ASTWriter : public ASTDeserializationListener,
 /// AST and semantic-analysis consumer that generates a
 /// precompiled header from the

[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

ChuanqiXu9 wrote:

Got it. I've renamed the flag as `-fexperimental-modules-reduced-bmi`. I feel 
the suggestion like let users to use `-Xclang` options look odd..

---

> What do you mean by "symmetric"?

I mean, we always want the users to do something explicitly to enable the 
feature. But this might not be important now.


https://github.com/llvm/llvm-project/pull/85050
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/85050
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/85050
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Introduce -fmodules-reduced-bmi (PR #85050)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/85050

>From b46c8fa030deb980c1550edc0ff8510d4e3c4e17 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 12 Mar 2024 17:26:49 +0800
Subject: [PATCH 1/3] [C++20] [Modules] Introduce -fgen-reduced-bmi

---
 clang/include/clang/CodeGen/CodeGenAction.h   |  2 +
 clang/include/clang/Driver/Options.td |  6 +++
 .../include/clang/Frontend/FrontendOptions.h  |  9 +++-
 clang/include/clang/Serialization/ASTWriter.h |  7 +--
 clang/lib/CodeGen/CodeGenAction.cpp   | 19 +++
 clang/lib/Driver/Driver.cpp   | 27 +-
 clang/lib/Driver/ToolChains/Clang.cpp | 41 --
 clang/lib/Driver/ToolChains/Clang.h   | 14 +
 clang/lib/Frontend/FrontendActions.cpp|  7 +++
 clang/lib/Frontend/PrecompiledPreamble.cpp|  3 +-
 clang/lib/Serialization/GeneratePCH.cpp   | 23 ++--
 .../test/Driver/module-fgen-reduced-bmi.cppm  | 53 +++
 clang/test/Modules/gen-reduced-bmi.cppm   | 36 +
 13 files changed, 220 insertions(+), 27 deletions(-)
 create mode 100644 clang/test/Driver/module-fgen-reduced-bmi.cppm
 create mode 100644 clang/test/Modules/gen-reduced-bmi.cppm

diff --git a/clang/include/clang/CodeGen/CodeGenAction.h 
b/clang/include/clang/CodeGen/CodeGenAction.h
index 7ad2988e589eb2..186dbb43f01ef7 100644
--- a/clang/include/clang/CodeGen/CodeGenAction.h
+++ b/clang/include/clang/CodeGen/CodeGenAction.h
@@ -57,6 +57,8 @@ class CodeGenAction : public ASTFrontendAction {
   bool loadLinkModules(CompilerInstance );
 
 protected:
+  bool BeginSourceFileAction(CompilerInstance ) override;
+
   /// Create a new code generation action.  If the optional \p _VMContext
   /// parameter is supplied, the action uses it without taking ownership,
   /// otherwise it creates a fresh LLVM context and takes ownership.
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 29066ea14280c2..7288bb3db493ba 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3017,6 +3017,7 @@ defm prebuilt_implicit_modules : 
BoolFOption<"prebuilt-implicit-modules",
 
 def fmodule_output_EQ : Joined<["-"], "fmodule-output=">,
   Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>,
+  MarshallingInfoString>,
   HelpText<"Save intermediate module file results when compiling a standard 
C++ module unit.">;
 def fmodule_output : Flag<["-"], "fmodule-output">, Flags<[NoXarchOption]>,
   Visibility<[ClangOption, CC1Option]>,
@@ -3030,6 +3031,11 @@ defm skip_odr_check_in_gmf : BoolOption<"f", 
"skip-odr-check-in-gmf",
   "Perform ODR checks for decls in the global module fragment.">>,
   Group;
 
+def gen_reduced_bmi : Flag<["-"], "fgen-reduced-bmi">,
+  Group, Visibility<[ClangOption, CC1Option]>,
+  HelpText<"Generate the reduced BMI">,
+  MarshallingInfoFlag>;
+
 def fmodules_prune_interval : Joined<["-"], "fmodules-prune-interval=">, 
Group,
   Visibility<[ClangOption, CC1Option]>, MetaVarName<"">,
   HelpText<"Specify the interval (in seconds) between attempts to prune the 
module cache">,
diff --git a/clang/include/clang/Frontend/FrontendOptions.h 
b/clang/include/clang/Frontend/FrontendOptions.h
index 8085dbcbf671a6..ddfd4f30d1b773 100644
--- a/clang/include/clang/Frontend/FrontendOptions.h
+++ b/clang/include/clang/Frontend/FrontendOptions.h
@@ -387,6 +387,10 @@ class FrontendOptions {
   LLVM_PREFERRED_TYPE(bool)
   unsigned ModulesShareFileManager : 1;
 
+  /// Whether to generate reduced BMI for C++20 named modules.
+  LLVM_PREFERRED_TYPE(bool)
+  unsigned GenReducedBMI : 1;
+
   CodeCompleteOptions CodeCompleteOpts;
 
   /// Specifies the output format of the AST.
@@ -553,6 +557,9 @@ class FrontendOptions {
   /// Path which stores the output files for -ftime-trace
   std::string TimeTracePath;
 
+  /// Output Path for module output file.
+  std::string ModuleOutputPath;
+
 public:
   FrontendOptions()
   : DisableFree(false), RelocatablePCH(false), ShowHelp(false),
@@ -565,7 +572,7 @@ class FrontendOptions {
 BuildingImplicitModuleUsesLock(true), ModulesEmbedAllFiles(false),
 IncludeTimestamps(true), UseTemporary(true),
 AllowPCMWithCompilerErrors(false), ModulesShareFileManager(true),
-TimeTraceGranularity(500) {}
+GenReducedBMI(false), TimeTraceGranularity(500) {}
 
   /// getInputKindForExtension - Return the appropriate input kind for a file
   /// extension. For example, "c" would return Language::C.
diff --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index 3ed9803fa3745b..bd310b6c7a5cdd 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -846,7 +846,7 @@ class ASTWriter : public ASTDeserializationListener,
 /// AST and semantic-analysis consumer that generates a
 /// precompiled header from the

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

ChuanqiXu9 wrote:

> By default, `SourceLocation` is 32 bits. One bit is used to distinguish macro 
> expansions. Looking at libc++'s module map, it contains 999 top-level modules 
> at this moment. That's 10 bits just to be able to import the (entire) 
> standard library. That leaves 21 bits, restricting local `SourceLocation` 
> space to 2 MB. This doesn't sound feasible. Did I misunderstand?

Yes, I explained this in `Some low level details` section. The size of source 
location won't be affected. Since the size of source location is unsigned 
(practically, it is 32 bits in most platforms). And we use uint64_t as a unit 
in the serializer. So there are 32 bit not used completely. The plan is to 
store the module file index in the higher 32 bits and it shouldn't be a safe 
problem.

The only trade-off I saw about this change is that it may increase the size of 
**on-disk** .pcm files due to we use VBR6 format to decrease the size of small 
numbers. But on the one side, we still need to pay for more spaces if we want 
to use `{local-module-index, offset-within-module} pair` (Thanks for the good 
name suggestion). On the other hand, from the experiment, it shows the overhead 
is acceptable.

https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits 

https://github.com/ChuanqiXu9 edited 
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

2024-03-28 Thread Chris B via cfe-commits 

https://github.com/llvm-beanz edited 
https://github.com/llvm/llvm-project/pull/83933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

2024-03-28 Thread Chris B via cfe-commits 


@@ -0,0 +1,432 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block::
+
+#define RS "RootFlags( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT | " \ 
+  "DENY_VERTEX_SHADER_ROOT_ACCESS), " \ 
+  "CBV(b0, space = 1, flags = DATA_STATIC), " \ 
+  "SRV(t0), " \ 
+  "UAV(u0), " \ 
+  "DescriptorTable( CBV(b1), " \ 
+  " SRV(t1, numDescriptors = 8, " \ 
+  " flags = DESCRIPTORS_VOLATILE), " \ 
+  " UAV(u1, numDescriptors = unbounded, " \ 
+  " flags = DESCRIPTORS_VOLATILE)), " \ 
+  "DescriptorTable(Sampler(s0, space=1, numDescriptors = 4)), " \ 
+  "RootConstants(num32BitConstants=3, b10), " \ 
+  "StaticSampler(s1)," \ 
+  "StaticSampler(s2, " \ 
+  "  addressU = TEXTURE_ADDRESS_CLAMP, " \ 
+  "  filter = FILTER_MIN_MAG_MIP_LINEAR )"
+
+[RootSignature(RS)]
+float4 main(float4 coord : COORD) : SV_Target
+{
+…
+}
+
+The compiler will create and verify the root signature blob for the shader and 
+embed it alongside the shader byte code into the shader blob. 
+
+The other mechanism is to create a standalone root signature blob, perhaps to 
+reuse it with a large set of shaders, saving space. The name of the define 
+string is specified via the usual -E argument. For example:
+
+.. code-block:: sh
+
+  dxc.exe -T rootsig_1_1 MyRS1.hlsl -E MyRS1 -Fo MyRS1.fxo
+
+Note that the root signature string define can also be passed on the command 
+line, e.g, -D MyRS1=”…”.
+
+Root Signature Grammar
+==
+
+.. code-block:: peg
+
+RootSignature : (RootElement(,RootElement)?)?
+
+RootElement : RootFlags | RootConstants | RootCBV | RootSRV | RootUAV |
+  DescriptorTable | StaticSampler
+
+RootFlags : 'RootFlags' '(' (RootFlag(|RootFlag)?)? ')'
+
+RootFlag : 'ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT' | 
+   'DENY_VERTEX_SHADER_ROOT_ACCESS'
+
+RootConstants : 'RootConstants' '(' 'num32BitConstants' '=' NUMBER ',' 
+   bReg (',' 'space' '=' NUMBER)? 
+   (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+RootCBV : 'CBV' '(' bReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootSRV : 'SRV' '(' tReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootUAV : 'UAV' '(' uReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+DescriptorTable : 'DescriptorTable' '(' (DTClause(|DTClause)?)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+DTClause : CBV | SRV | UAV | Sampler
+
+CBV : 'CBV' '(' bReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+SRV : 'SRV' '(' tReg (',' 'numDescriptors' '=' NUMBER)? 
+(',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+UAV : 'UAV' '(' uReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+Sampler : 'Sampler' '(' sReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? (',' 'flags' '=' 
NUMBER)? ')'
+
+
+SHADER_VISIBILITY : 'SHADER_VISIBILITY_ALL' | 'SHADER_VISIBILITY_VERTEX' | 
+'SHADER_VISIBILITY_HULL' | 
+'SHADER_VISIBILITY_DOMAIN' | 
+'SHADER_VISIBILITY_GEOMETRY' | 
+'SHADER_VISIBILITY_PIXEL' | 
+'SHADER_VISIBILITY_AMPLIFICATION' | 
+'SHADER_VISIBILITY_MESH'
+
+DATA_FLAGS :

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

2024-03-28 Thread Chris B via cfe-commits 

https://github.com/llvm-beanz commented:

It might be useful to have a section in this document that briefly describes 
what is done at each phase of the compiler and what information is passed 
through to the next.

For example:
ClangSema parses the attribute and generates . ClangCodeGen reads  and 
generates .  in the DirectX backend transforms/validates  yo 
. LLVMMC emits  to .

Also we need to keep in mind that some of these structures need to be available 
in the LLVM Binary Format and Object libraries so that the object parser can 
read root signatures. We should think about what bits of code need to live 
where to maintain the correct layers in the compiler architecture.

https://github.com/llvm/llvm-project/pull/83933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ExtractAPI] Add ability to create multiple symbol graphs (PR #86676)

2024-03-28 Thread via cfe-commits 

https://github.com/QuietMisdreavus approved this pull request.

Looks good, thanks!

https://github.com/llvm/llvm-project/pull/86676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Remove barely used class 'KnownSVal' (NFC) (PR #86953)

2024-03-28 Thread Artem Dergachev via cfe-commits 

https://github.com/haoNoQ approved this pull request.

Yeah nuke it.

https://github.com/llvm/llvm-project/pull/86953
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5906b1a - [APINotes][test] Fix permissions of a file copied from a source tree

2024-03-28 Thread Dmitri Gribenko via cfe-commits 

Author: Dmitri Gribenko
Date: 2024-03-29T00:38:11+01:00
New Revision: 5906b1ad3f70586c72293d5c62eb3f26977b8b96

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

LOG: [APINotes][test] Fix permissions of a file copied from a source tree

Our CI system makes the source tree read-only. The 'cp' command that
copies a directory from the source tree into a temp directory preserves
permissions, and the copied files stay read-only. When the test tries to
append to one of these files, it fails with a "permission denied" error.

Added: 


Modified: 
clang/test/APINotes/module-cache.m

Removed: 




diff  --git a/clang/test/APINotes/module-cache.m 
b/clang/test/APINotes/module-cache.m
index 5dcaf1181f9dcf..e5920884ad860f 100644
--- a/clang/test/APINotes/module-cache.m
+++ b/clang/test/APINotes/module-cache.m
@@ -27,6 +27,7 @@
 // RUN: FileCheck -check-prefix=CHECK-ONE-ERROR %s < %t/before.log
 
 // Change the API notes file, after the module has rebuilt once.
+// RUN: chmod u+w %t/APINotes/SomeOtherKit.apinotes
 // RUN: echo '  - Selector: "methodA"' >> %t/APINotes/SomeOtherKit.apinotes
 // RUN: echo 'MethodKind: Instance' >> 
%t/APINotes/SomeOtherKit.apinotes
 // RUN: echo 'Availability: none' >> %t/APINotes/SomeOtherKit.apinotes



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

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

2024-03-28 Thread Chris B via cfe-commits 


@@ -0,0 +1,426 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 
+point):
+
+.. code-block:: hlsl
+
+#define RS "RootFlags( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT | " \ 
+  "DENY_VERTEX_SHADER_ROOT_ACCESS), " \ 
+  "CBV(b0, space = 1, flags = DATA_STATIC), " \ 
+  "SRV(t0), " \ 
+  "UAV(u0), " \ 
+  "DescriptorTable( CBV(b1), " \ 
+  " SRV(t1, numDescriptors = 8, " \ 
+  " flags = DESCRIPTORS_VOLATILE), " \ 
+  " UAV(u1, numDescriptors = unbounded, " \ 
+  " flags = DESCRIPTORS_VOLATILE)), " \ 
+  "DescriptorTable(Sampler(s0, space=1, numDescriptors = 4)), " \ 
+  "RootConstants(num32BitConstants=3, b10), " \ 
+  "StaticSampler(s1)," \ 
+  "StaticSampler(s2, " \ 
+  "  addressU = TEXTURE_ADDRESS_CLAMP, " \ 
+  "  filter = FILTER_MIN_MAG_MIP_LINEAR )"
+
+[RootSignature(RS)]
+float4 main(float4 coord : COORD) : SV_Target
+{
+"…"
+}
+
+The compiler will create and verify the root signature blob for the shader and 
+embed it alongside the shader byte code into the shader blob. 
+
+The other mechanism is to create a standalone root signature blob, perhaps to 
+reuse it with a large set of shaders, saving space. The name of the define 
+string is specified via the usual -E argument. For example:
+
+.. code-block:: sh
+
+  dxc.exe -T rootsig_1_1 MyRS1.hlsl -E MyRS1 -Fo MyRS1.fxo
+
+Note that the root signature string define can also be passed on the command 
+line, e.g, -D MyRS1=”…”.
+
+Root Signature Grammar
+==
+
+.. code-block:: peg
+
+RootSignature : (RootElement(,RootElement)?)?
+
+RootElement : RootFlags | RootConstants | RootCBV | RootSRV | RootUAV |
+  DescriptorTable | StaticSampler
+
+RootFlags : 'RootFlags' '(' (RootFlag(|RootFlag)?)? ')'
+
+RootFlag : 'ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT' | 
+   'DENY_VERTEX_SHADER_ROOT_ACCESS'
+
+RootConstants : 'RootConstants' '(' 'num32BitConstants' '=' NUMBER ',' 
+   bReg (',' 'space' '=' NUMBER)? 
+   (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+RootCBV : 'CBV' '(' bReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootSRV : 'SRV' '(' tReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+RootUAV : 'UAV' '(' uReg (',' 'space' '=' NUMBER)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+DescriptorTable : 'DescriptorTable' '(' (DTClause(|DTClause)?)? 
+  (',' 'visibility' '=' SHADER_VISIBILITY)? ')'
+
+DTClause : CBV | SRV | UAV | Sampler
+
+CBV : 'CBV' '(' bReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+SRV : 'SRV' '(' tReg (',' 'numDescriptors' '=' NUMBER)? 
+(',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+UAV : 'UAV' '(' uReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? 
+  (',' 'flags' '=' DATA_FLAGS)? ')'
+
+Sampler : 'Sampler' '(' sReg (',' 'numDescriptors' '=' NUMBER)? 
+  (',' 'space' '=' NUMBER)? 
+  (',' 'offset' '=' DESCRIPTOR_RANGE_OFFSET)? (',' 'flags' '=' 
NUMBER)? ')'
+
+
+SHADER_VISIBILITY : 'SHADER_VISIBILITY_ALL' | 'SHADER_VISIBILITY_VERTEX' | 
+'SHADER_VISIBILITY_HULL' | 
+'SHADER_VISIBILITY_DOMAIN' | 
+'SHADER_VISIBILITY_GEOMETRY' | 
+'SHADER_VISIBILITY_PIXEL' | 
+'SHADER_VISIBILITY_AMPLIFICATION' | 
+'SHADER_VISIBILITY_MESH'
+
+DATA_FLAGS :

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide edited 
https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide updated 
https://github.com/llvm/llvm-project/pull/86526

>From 98af47e8ccc633016c14b91c221f9f8fc620f068 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Mon, 25 Mar 2024 14:46:52 +0100
Subject: [PATCH 01/15] [Clang] Parse `= delete("message")`

---
 clang/include/clang/AST/Decl.h| 13 
 clang/include/clang/Parse/Parser.h|  1 +
 clang/include/clang/Sema/Sema.h   |  6 ++--
 clang/lib/AST/Decl.cpp|  4 +--
 clang/lib/AST/DeclPrinter.cpp |  9 +++--
 clang/lib/AST/TextNodeDumper.cpp  |  3 ++
 clang/lib/Parse/ParseCXXInlineMethods.cpp | 24 +-
 clang/lib/Parse/Parser.cpp|  4 ++-
 clang/lib/Sema/SemaDeclCXX.cpp| 10 +++---
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  6 
 .../test/Parser/cxx2c-delete-with-message.cpp | 33 +++
 11 files changed, 100 insertions(+), 13 deletions(-)
 create mode 100644 clang/test/Parser/cxx2c-delete-with-message.cpp

diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index a5879591f4c659..24f0394577e228 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2013,6 +2013,12 @@ class FunctionDecl : public DeclaratorDecl,
 DefaultedFunctionInfo *DefaultedInfo;
   };
 
+  /// Message that indicates why this function was deleted.
+  ///
+  /// FIXME: Figure out where to actually put this; maybe in the
+  /// 'DefaultedInfo' above?
+  StringLiteral *DeletedMessage;
+
   unsigned ODRHash;
 
   /// End part of this FunctionDecl's source range.
@@ -2483,6 +2489,10 @@ class FunctionDecl : public DeclaratorDecl,
   }
 
   void setDeletedAsWritten(bool D = true) { FunctionDeclBits.IsDeleted = D; }
+  void setDeletedWithMessage(StringLiteral* Message) {
+FunctionDeclBits.IsDeleted = true;
+DeletedMessage = Message;
+  }
 
   /// Determines whether this function is "main", which is the
   /// entry point into an executable program.
@@ -2638,6 +2648,9 @@ class FunctionDecl : public DeclaratorDecl,
   AC.push_back(TRC);
   }
 
+  /// Get the message that indicates why this function was deleted.
+  StringLiteral *getDeletedMessage() const { return DeletedMessage; }
+
   void setPreviousDeclaration(FunctionDecl * PrevDecl);
 
   FunctionDecl *getCanonicalDecl() override;
diff --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index 14df75180ef321..559e6416b7dfb3 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -1600,6 +1600,7 @@ class Parser : public CodeCompletionHandler {
  const ParsedTemplateInfo ,
  const VirtSpecifiers ,
  SourceLocation PureSpecLoc);
+  StringLiteral *ParseCXXDeletedFunctionMessage();
   void ParseCXXNonStaticMemberInitializer(Decl *VarD);
   void ParseLexedAttributes(ParsingClass );
   void ParseLexedAttributeList(LateParsedAttrList , Decl *D,
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 64de39acc72176..919f8f6b0a35a2 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4926,10 +4926,12 @@ class Sema final {
SourceLocation EqualLoc);
 
   void ActOnPureSpecifier(Decl *D, SourceLocation PureSpecLoc);
-  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc);
+  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc,
+  StringLiteral *Message = nullptr);
   void SetDeclDefaulted(Decl *dcl, SourceLocation DefaultLoc);
 
-  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind);
+  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind,
+   StringLiteral *DeletedMessage = nullptr);
   void ActOnStartTrailingRequiresClause(Scope *S, Declarator );
   ExprResult ActOnFinishTrailingRequiresClause(ExprResult ConstraintExpr);
   ExprResult ActOnRequiresClause(ExprResult ConstraintExpr);
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 95900afdd2c5d8..b5e61f0eceb6e4 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3043,8 +3043,8 @@ FunctionDecl::FunctionDecl(Kind DK, ASTContext , 
DeclContext *DC,
Expr *TrailingRequiresClause)
 : DeclaratorDecl(DK, DC, NameInfo.getLoc(), NameInfo.getName(), T, TInfo,
  StartLoc),
-  DeclContext(DK), redeclarable_base(C), Body(), ODRHash(0),
-  EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
+  DeclContext(DK), redeclarable_base(C), Body(), DeletedMessage(nullptr),
+  ODRHash(0), EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) 
{
   assert(T.isNull() || T->isFunctionType());
   FunctionDeclBits.SClass = S;
   FunctionDeclBits.IsInline = isInlineSpecified;
diff --git

[clang] [Doc][HLSL] Add documentation for root signature. (PR #83933)

2024-03-28 Thread Joshua Batista via cfe-commits 


@@ -0,0 +1,258 @@
+
+HLSL Root Signatures
+
+
+.. contents::
+   :local:
+
+Usage
+=
+
+In HLSL, the `root signature
+`_ 
+defines what types of resources are bound to the graphics pipeline. 
+
+A root signature can be specified in HLSL as a `string
+`_.
 
+The string contains a collection of comma-separated clauses that describe root 
+signature constituent components. 
+
+There are two mechanisms to compile an HLSL root signature. First, it is 
+possible to attach a root signature string to a particular shader via the 
+RootSignature attribute (in the following example, using the MyRS1 entry 

bob80905 wrote:

The following example only has "main" as an entry point right?

https://github.com/llvm/llvm-project/pull/83933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Ben Langmuir via cfe-commits 

https://github.com/benlangmuir approved this pull request.


https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (PR #86923)

2024-03-28 Thread Akira Hatanaka via cfe-commits 

ahatanak wrote:

I plan to file a bug or notify the authors of the code of the potential bug 
once I have a better understanding of the problem.

FYI, the code was crashing because the lvalue passed to 
`OpaqueValueMappingData::bind` had a larger alignment than the alignment of the 
type passed to the function.

https://github.com/llvm/llvm-project/blob/bbbcc1d99d08855069f4501c896c43a6d4d7b598/clang/lib/CodeGen/CGCoroutine.cpp#L458

https://github.com/llvm/llvm-project/pull/86923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide edited 
https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide updated 
https://github.com/llvm/llvm-project/pull/86526

>From 98af47e8ccc633016c14b91c221f9f8fc620f068 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Mon, 25 Mar 2024 14:46:52 +0100
Subject: [PATCH 01/14] [Clang] Parse `= delete("message")`

---
 clang/include/clang/AST/Decl.h| 13 
 clang/include/clang/Parse/Parser.h|  1 +
 clang/include/clang/Sema/Sema.h   |  6 ++--
 clang/lib/AST/Decl.cpp|  4 +--
 clang/lib/AST/DeclPrinter.cpp |  9 +++--
 clang/lib/AST/TextNodeDumper.cpp  |  3 ++
 clang/lib/Parse/ParseCXXInlineMethods.cpp | 24 +-
 clang/lib/Parse/Parser.cpp|  4 ++-
 clang/lib/Sema/SemaDeclCXX.cpp| 10 +++---
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  6 
 .../test/Parser/cxx2c-delete-with-message.cpp | 33 +++
 11 files changed, 100 insertions(+), 13 deletions(-)
 create mode 100644 clang/test/Parser/cxx2c-delete-with-message.cpp

diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index a5879591f4c659..24f0394577e228 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2013,6 +2013,12 @@ class FunctionDecl : public DeclaratorDecl,
 DefaultedFunctionInfo *DefaultedInfo;
   };
 
+  /// Message that indicates why this function was deleted.
+  ///
+  /// FIXME: Figure out where to actually put this; maybe in the
+  /// 'DefaultedInfo' above?
+  StringLiteral *DeletedMessage;
+
   unsigned ODRHash;
 
   /// End part of this FunctionDecl's source range.
@@ -2483,6 +2489,10 @@ class FunctionDecl : public DeclaratorDecl,
   }
 
   void setDeletedAsWritten(bool D = true) { FunctionDeclBits.IsDeleted = D; }
+  void setDeletedWithMessage(StringLiteral* Message) {
+FunctionDeclBits.IsDeleted = true;
+DeletedMessage = Message;
+  }
 
   /// Determines whether this function is "main", which is the
   /// entry point into an executable program.
@@ -2638,6 +2648,9 @@ class FunctionDecl : public DeclaratorDecl,
   AC.push_back(TRC);
   }
 
+  /// Get the message that indicates why this function was deleted.
+  StringLiteral *getDeletedMessage() const { return DeletedMessage; }
+
   void setPreviousDeclaration(FunctionDecl * PrevDecl);
 
   FunctionDecl *getCanonicalDecl() override;
diff --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index 14df75180ef321..559e6416b7dfb3 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -1600,6 +1600,7 @@ class Parser : public CodeCompletionHandler {
  const ParsedTemplateInfo ,
  const VirtSpecifiers ,
  SourceLocation PureSpecLoc);
+  StringLiteral *ParseCXXDeletedFunctionMessage();
   void ParseCXXNonStaticMemberInitializer(Decl *VarD);
   void ParseLexedAttributes(ParsingClass );
   void ParseLexedAttributeList(LateParsedAttrList , Decl *D,
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 64de39acc72176..919f8f6b0a35a2 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4926,10 +4926,12 @@ class Sema final {
SourceLocation EqualLoc);
 
   void ActOnPureSpecifier(Decl *D, SourceLocation PureSpecLoc);
-  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc);
+  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc,
+  StringLiteral *Message = nullptr);
   void SetDeclDefaulted(Decl *dcl, SourceLocation DefaultLoc);
 
-  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind);
+  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind,
+   StringLiteral *DeletedMessage = nullptr);
   void ActOnStartTrailingRequiresClause(Scope *S, Declarator );
   ExprResult ActOnFinishTrailingRequiresClause(ExprResult ConstraintExpr);
   ExprResult ActOnRequiresClause(ExprResult ConstraintExpr);
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 95900afdd2c5d8..b5e61f0eceb6e4 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3043,8 +3043,8 @@ FunctionDecl::FunctionDecl(Kind DK, ASTContext , 
DeclContext *DC,
Expr *TrailingRequiresClause)
 : DeclaratorDecl(DK, DC, NameInfo.getLoc(), NameInfo.getName(), T, TInfo,
  StartLoc),
-  DeclContext(DK), redeclarable_base(C), Body(), ODRHash(0),
-  EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
+  DeclContext(DK), redeclarable_base(C), Body(), DeletedMessage(nullptr),
+  ODRHash(0), EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) 
{
   assert(T.isNull() || T->isFunctionType());
   FunctionDeclBits.SClass = S;
   FunctionDeclBits.IsInline = isInlineSpecified;
diff --git

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide edited 
https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide updated 
https://github.com/llvm/llvm-project/pull/86526

>From 98af47e8ccc633016c14b91c221f9f8fc620f068 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Mon, 25 Mar 2024 14:46:52 +0100
Subject: [PATCH 01/13] [Clang] Parse `= delete("message")`

---
 clang/include/clang/AST/Decl.h| 13 
 clang/include/clang/Parse/Parser.h|  1 +
 clang/include/clang/Sema/Sema.h   |  6 ++--
 clang/lib/AST/Decl.cpp|  4 +--
 clang/lib/AST/DeclPrinter.cpp |  9 +++--
 clang/lib/AST/TextNodeDumper.cpp  |  3 ++
 clang/lib/Parse/ParseCXXInlineMethods.cpp | 24 +-
 clang/lib/Parse/Parser.cpp|  4 ++-
 clang/lib/Sema/SemaDeclCXX.cpp| 10 +++---
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  6 
 .../test/Parser/cxx2c-delete-with-message.cpp | 33 +++
 11 files changed, 100 insertions(+), 13 deletions(-)
 create mode 100644 clang/test/Parser/cxx2c-delete-with-message.cpp

diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index a5879591f4c659..24f0394577e228 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2013,6 +2013,12 @@ class FunctionDecl : public DeclaratorDecl,
 DefaultedFunctionInfo *DefaultedInfo;
   };
 
+  /// Message that indicates why this function was deleted.
+  ///
+  /// FIXME: Figure out where to actually put this; maybe in the
+  /// 'DefaultedInfo' above?
+  StringLiteral *DeletedMessage;
+
   unsigned ODRHash;
 
   /// End part of this FunctionDecl's source range.
@@ -2483,6 +2489,10 @@ class FunctionDecl : public DeclaratorDecl,
   }
 
   void setDeletedAsWritten(bool D = true) { FunctionDeclBits.IsDeleted = D; }
+  void setDeletedWithMessage(StringLiteral* Message) {
+FunctionDeclBits.IsDeleted = true;
+DeletedMessage = Message;
+  }
 
   /// Determines whether this function is "main", which is the
   /// entry point into an executable program.
@@ -2638,6 +2648,9 @@ class FunctionDecl : public DeclaratorDecl,
   AC.push_back(TRC);
   }
 
+  /// Get the message that indicates why this function was deleted.
+  StringLiteral *getDeletedMessage() const { return DeletedMessage; }
+
   void setPreviousDeclaration(FunctionDecl * PrevDecl);
 
   FunctionDecl *getCanonicalDecl() override;
diff --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index 14df75180ef321..559e6416b7dfb3 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -1600,6 +1600,7 @@ class Parser : public CodeCompletionHandler {
  const ParsedTemplateInfo ,
  const VirtSpecifiers ,
  SourceLocation PureSpecLoc);
+  StringLiteral *ParseCXXDeletedFunctionMessage();
   void ParseCXXNonStaticMemberInitializer(Decl *VarD);
   void ParseLexedAttributes(ParsingClass );
   void ParseLexedAttributeList(LateParsedAttrList , Decl *D,
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 64de39acc72176..919f8f6b0a35a2 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4926,10 +4926,12 @@ class Sema final {
SourceLocation EqualLoc);
 
   void ActOnPureSpecifier(Decl *D, SourceLocation PureSpecLoc);
-  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc);
+  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc,
+  StringLiteral *Message = nullptr);
   void SetDeclDefaulted(Decl *dcl, SourceLocation DefaultLoc);
 
-  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind);
+  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind,
+   StringLiteral *DeletedMessage = nullptr);
   void ActOnStartTrailingRequiresClause(Scope *S, Declarator );
   ExprResult ActOnFinishTrailingRequiresClause(ExprResult ConstraintExpr);
   ExprResult ActOnRequiresClause(ExprResult ConstraintExpr);
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 95900afdd2c5d8..b5e61f0eceb6e4 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3043,8 +3043,8 @@ FunctionDecl::FunctionDecl(Kind DK, ASTContext , 
DeclContext *DC,
Expr *TrailingRequiresClause)
 : DeclaratorDecl(DK, DC, NameInfo.getLoc(), NameInfo.getName(), T, TInfo,
  StartLoc),
-  DeclContext(DK), redeclarable_base(C), Body(), ODRHash(0),
-  EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
+  DeclContext(DK), redeclarable_base(C), Body(), DeletedMessage(nullptr),
+  ODRHash(0), EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) 
{
   assert(T.isNull() || T->isFunctionType());
   FunctionDeclBits.SClass = S;
   FunctionDeclBits.IsInline = isInlineSpecified;
diff --git

[clang] bbbcc1d - Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)"

2024-03-28 Thread Sam McCall via cfe-commits 

Author: Sam McCall
Date: 2024-03-28T23:57:09+01:00
New Revision: bbbcc1d99d08855069f4501c896c43a6d4d7b598

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

LOG: Reapply "[clang][nullability] allow _Nonnull etc on nullable class types 
(#82705)"

This reverts commit ca4c4a6758d184f209cb5d88ef42ecc011b11642.

This was intended not to introduce new consistency diagnostics for
smart pointer types, but failed to ignore sugar around types when
detecting this.
Fixed and test added.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/Features.def
clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/Type.cpp
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
clang/lib/Parse/ParseDeclCXX.cpp
clang/lib/Sema/SemaAttr.cpp
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/lib/Sema/SemaInit.cpp
clang/lib/Sema/SemaOverload.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaType.cpp
clang/test/Sema/nullability.c
clang/test/SemaCXX/nullability.cpp
clang/test/SemaObjCXX/nullability-consistency.mm

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 232de0d7d8bb735..c303eee7be79277 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -253,6 +253,21 @@ Attribute Changes in Clang
   added a new extension query ``__has_extension(swiftcc)`` corresponding to the
   ``__attribute__((swiftcc))`` attribute.
 
+- The ``_Nullable`` and ``_Nonnull`` family of type attributes can now apply
+  to certain C++ class types, such as smart pointers:
+  ``void useObject(std::unique_ptr _Nonnull obj);``.
+
+  This works for standard library types including ``unique_ptr``, 
``shared_ptr``,
+  and ``function``. See
+  `the attribute reference documentation 
`_
+  for the full list.
+
+- The ``_Nullable`` attribute can be applied to C++ class declarations:
+  ``template  class _Nullable MySmartPointer {};``.
+
+  This allows the ``_Nullable`` and ``_Nonnull`` family of type attributes to
+  apply to this class.
+
 Improvements to Clang's diagnostics
 ---
 - Clang now applies syntax highlighting to the code snippets it

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 80e607525a0a37d..6584460cf5685ea 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2178,9 +2178,10 @@ def TypeNonNull : TypeAttr {
   let Documentation = [TypeNonNullDocs];
 }
 
-def TypeNullable : TypeAttr {
+def TypeNullable : DeclOrTypeAttr {
   let Spellings = [CustomKeyword<"_Nullable">];
   let Documentation = [TypeNullableDocs];
+//  let Subjects = SubjectList<[CXXRecord], ErrorDiag>;
 }
 
 def TypeNullableResult : TypeAttr {

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 3ea4d676b4f89d3..0ca4ea377fc36ac 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -4151,6 +4151,20 @@ non-underscored keywords. For example:
   @property (assign, nullable) NSView *superview;
   @property (readonly, nonnull) NSArray *subviews;
 @end
+
+As well as built-in pointer types, the nullability attributes can be attached
+to C++ classes marked with the ``_Nullable`` attribute.
+
+The following C++ standard library types are considered nullable:
+``unique_ptr``, ``shared_ptr``, ``auto_ptr``, ``exception_ptr``, ``function``,
+``move_only_function`` and ``coroutine_handle``.
+
+Types should be marked nullable only where the type itself leaves nullability
+ambiguous. For example, ``std::optional`` is not marked ``_Nullable``, because
+``optional _Nullable`` is redundant and ``optional _Nonnull`` is
+not a useful type. ``std::weak_ptr`` is not nullable, because its nullability
+can change with no visible modification, so static annotation is unlikely to be
+unhelpful.
   }];
 }
 
@@ -4185,6 +4199,17 @@ The ``_Nullable`` nullability qualifier indicates that a 
value of the
 int fetch_or_zero(int * _Nullable ptr);
 
 a caller of ``fetch_or_zero`` can provide null.
+
+The ``_Nullable`` attribute on classes indicates that the given class can
+represent null values, and so the ``_Nullable``, ``_Nonnull`` etc qualifiers
+make sense for this type. For example:
+
+  .. code-block:: c
+
+class _Nullable ArenaPointer { ... };
+
+ArenaPointer _Nonnull x = ...;
+ArenaPointer _Nullable y = nullptr;
   }];
 }
 

diff  --git

[clang] [DebugInfo] Add flag to only emit referenced member functions (PR #87018)

2024-03-28 Thread David Blaikie via cfe-commits 

dwblaikie wrote:

Cleaning up some old branches - @pogo59 @rnk who commented on the original 
https://reviews.llvm.org/D152017

I think the only outstanding thing was the flag name, I've renamed it from 
`-gincomplete-types` to `-gomit-unreferenced-members` to try to address the 
feedback. It's not totally precise (it's only member functions that are 
affected, not member variables, for instance) but seems close enough.

https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [DebugInfo] Add flag to only emit referenced member functions (PR #87018)

2024-03-28 Thread via cfe-commits 

llvmbot wrote:




@llvm/pr-subscribers-clang-driver

Author: David Blaikie (dwblaikie)


Changes

Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member function
anyway). So add a flag to opt out of this behavior for experimenting
with this more terse behavior.

I think Sony already does this by default, so perhaps with a change to
the defaults, Sony can migrate to this rather than a downstream patch.

This breaks current debuggers in some expected ways - but those
breakages are visible without this feature too. Consider member function
template instantiations - they can't be consistently enumerated in every
translation unit:

a.h:
```
struct t1 {
  template int i
  static int f1() {
return i;
  }
};
namespace ns {
template int i
int f1() {
  return i;
}
}  // namespace ns
```
a.cpp:
```
void f1() {
  t1::f10();
  ns::f10();
}
```
b.cpp:
```
void f1();
int main() {
  f1();
  t1::f11();
  ns::f11();
}
```
```
(gdb) p ns::f10()
$1 = 0
(gdb) p ns::f11()
$2 = 1
(gdb) p t1::f10()
Couldn't find method t1::f10
(gdb) p t1::f11()
$3 = 1
(gdb) s
f1 () at a.cpp:3
3 t1::f10();
(gdb) p t1::f10()
$4 = 0
(gdb) p t1::f11()
Couldn't find method t1::f11
(gdb)
```

(other similar non-canonical features are implicit special members
(copy/move ctor/assignment operator, default ctor) and nested types (eg:
pimpl idiom, where the nested type is declared-but-not-defined in one
TU, and defined in another TU))

lldb can't parse the template expressions above, so I'm not sure how to
test it there, but I'd guess it has similar problems. (
https://stackoverflow.com/questions/64602475/how-to-print-value-returned-by-template-member-function-in-gdb-lldb-debugging
so... I guess that's just totally not supported in lldb, how
unfortunate. And implicit special members are instantiated implicitly by
lldb, so missing those doesn't tickle the same issue)

Some very rudimentary numbers for a clang debug build:
.debug_info section size:
-g: 476MiB
-g -fdebug-types-section: 357MiB
-g -gomit-unreferenced-members: 340MiB

Though it also means a major reduction in .debug_str size,
-fdebug-types-section doesn't reduce string usage (so the first two
examples have the same .debug_str size, 247MiB), down to 175MiB.

So for total clang binary size (I don't have a quick "debug section size
reduction" on-hand): 1.45 (no type units) GiB - 1.34 - 1.22, so it
saves about 120MiB of binary size.

Also open to any riffing on the flag name for sure.

@probinson - would this be an accurate upstreaming of your internal 
handling/would you use this functionality? If it wouldn't be useful to you, 
it's maybe not worth adding upstream yet - not sure we'll use it at Google, but 
if it was useful to you folks and meant other folks could test with it it 
seemed maybe useful.

Original Differential Revision: https://reviews.llvm.org/D152017


---
Full diff: https://github.com/llvm/llvm-project/pull/87018.diff


6 Files Affected:

- (modified) clang/include/clang/Basic/DebugOptions.def (+2) 
- (modified) clang/include/clang/Driver/Options.td (+7) 
- (modified) clang/lib/CodeGen/CGDebugInfo.cpp (+1-1) 
- (modified) clang/lib/Driver/ToolChains/Clang.cpp (+6) 
- (added) clang/test/CodeGenCXX/debug-info-incomplete-types.cpp (+12) 
- (modified) clang/test/Driver/debug-options.c (+6) 


``diff
diff --git a/clang/include/clang/Basic/DebugOptions.def 
b/clang/include/clang/Basic/DebugOptions.def
index 7cd3edf08a17ea..fe2adaa20f4e3a 100644
--- a/clang/include/clang/Basic/DebugOptions.def
+++ b/clang/include/clang/Basic/DebugOptions.def
@@ -68,6 +68,8 @@ BENIGN_DEBUGOPT(NoInlineLineTables, 1, 0) ///< Whether debug 
info should contain
   ///< inline line tables.
 
 DEBUGOPT(DebugStrictDwarf, 1, 1) ///< Whether or not to use strict DWARF info.
+DEBUGOPT(DebugOmitUnreferencedMembers, 1, 0) ///< Omit unreferenced member
+///< functions in type debug info.
 
 /// Control the Assignment Tracking debug info feature.
 BENIGN_ENUM_DEBUGOPT(AssignmentTrackingMode, AssignmentTrackingOpts, 2,
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 29066ea14280c2..4000403a1991d2 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4260,6 +4260,13 @@ defm strict_dwarf : BoolOption<"g", "strict-dwarf",
   "the specified version, avoiding features from later versions.">,
   NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
   Group;
+defm omit_unreferenced_members : BoolOption<"g", "omit-unreferenced-members",
+  CodeGenOpts<"DebugOmitUnreferencedMembers">, DefaultFalse,
+  PosFlag,
+  NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
+  Group;
 defm column_info : BoolOption<"g", "column-info",
   CodeGenOpts<"DebugColumnInfo">,

[clang] [DebugInfo] Add flag to only emit referenced member functions (PR #87018)

2024-03-28 Thread David Blaikie via cfe-commits 

https://github.com/dwblaikie created 
https://github.com/llvm/llvm-project/pull/87018

Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member function
anyway). So add a flag to opt out of this behavior for experimenting
with this more terse behavior.

I think Sony already does this by default, so perhaps with a change to
the defaults, Sony can migrate to this rather than a downstream patch.

This breaks current debuggers in some expected ways - but those
breakages are visible without this feature too. Consider member function
template instantiations - they can't be consistently enumerated in every
translation unit:

a.h:
```
struct t1 {
  template 
  static int f1() {
return i;
  }
};
namespace ns {
template 
int f1() {
  return i;
}
}  // namespace ns
```
a.cpp:
```
void f1() {
  t1::f1<0>();
  ns::f1<0>();
}
```
b.cpp:
```
void f1();
int main() {
  f1();
  t1::f1<1>();
  ns::f1<1>();
}
```
```
(gdb) p ns::f1<0>()
$1 = 0
(gdb) p ns::f1<1>()
$2 = 1
(gdb) p t1::f1<0>()
Couldn't find method t1::f1<0>
(gdb) p t1::f1<1>()
$3 = 1
(gdb) s
f1 () at a.cpp:3
3 t1::f1<0>();
(gdb) p t1::f1<0>()
$4 = 0
(gdb) p t1::f1<1>()
Couldn't find method t1::f1<1>
(gdb)
```

(other similar non-canonical features are implicit special members
(copy/move ctor/assignment operator, default ctor) and nested types (eg:
pimpl idiom, where the nested type is declared-but-not-defined in one
TU, and defined in another TU))

lldb can't parse the template expressions above, so I'm not sure how to
test it there, but I'd guess it has similar problems. (
https://stackoverflow.com/questions/64602475/how-to-print-value-returned-by-template-member-function-in-gdb-lldb-debugging
so... I guess that's just totally not supported in lldb, how
unfortunate. And implicit special members are instantiated implicitly by
lldb, so missing those doesn't tickle the same issue)

Some very rudimentary numbers for a clang debug build:
.debug_info section size:
-g: 476MiB
-g -fdebug-types-section: 357MiB
-g -gomit-unreferenced-members: 340MiB

Though it also means a major reduction in .debug_str size,
-fdebug-types-section doesn't reduce string usage (so the first two
examples have the same .debug_str size, 247MiB), down to 175MiB.

So for total clang binary size (I don't have a quick "debug section size
reduction" on-hand): 1.45 (no type units) GiB -> 1.34 -> 1.22, so it
saves about 120MiB of binary size.

Also open to any riffing on the flag name for sure.

@probinson - would this be an accurate upstreaming of your internal 
handling/would you use this functionality? If it wouldn't be useful to you, 
it's maybe not worth adding upstream yet - not sure we'll use it at Google, but 
if it was useful to you folks and meant other folks could test with it it 
seemed maybe useful.

Original Differential Revision: https://reviews.llvm.org/D152017


>From 6834c245205d1e38a615e97217dada3cd941ed03 Mon Sep 17 00:00:00 2001
From: David Blaikie 
Date: Fri, 2 Jun 2023 15:04:14 +
Subject: [PATCH] [DebugInfo] Add flag to only emit referenced member functions

Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member function
anyway). So add a flag to opt out of this behavior for experimenting
with this more terse behavior.

I think Sony already does this by default, so perhaps with a change to
the defaults, Sony can migrate to this rather than a downstream patch.

This breaks current debuggers in some expected ways - but those
breakages are visible without this feature too. Consider member function
template instantiations - they can't be consistently enumerated in every
translation unit:

a.h:
```
struct t1 {
  template 
  static int f1() {
return i;
  }
};
namespace ns {
template 
int f1() {
  return i;
}
}  // namespace ns
```
a.cpp:
```
void f1() {
  t1::f1<0>();
  ns::f1<0>();
}
```
b.cpp:
```
void f1();
int main() {
  f1();
  t1::f1<1>();
  ns::f1<1>();
}
```
```
(gdb) p ns::f1<0>()
$1 = 0
(gdb) p ns::f1<1>()
$2 = 1
(gdb) p t1::f1<0>()
Couldn't find method t1::f1<0>
(gdb) p t1::f1<1>()
$3 = 1
(gdb) s
f1 () at a.cpp:3
3 t1::f1<0>();
(gdb) p t1::f1<0>()
$4 = 0
(gdb) p t1::f1<1>()
Couldn't find method t1::f1<1>
(gdb)
```

(other similar non-canonical features are implicit special members
(copy/move ctor/assignment operator, default ctor) and nested types (eg:
pimpl idiom, where the nested type is declared-but-not-defined in one
TU, and defined in another TU))

lldb can't parse the template expressions above, so I'm not sure how to
test it there, but I'd guess it has similar problems. (
https://stackoverflow.com/questions/64602475/how-to-print-value-returned-by-template-member-function-in-gdb-lldb-debugging
so... I guess that's just totally not supported in lldb, how

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide edited 
https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)

2024-03-28 Thread Nikolas Klauser via cfe-commits 

philnik777 wrote:

Another option would be to to not acknowledge zero-sized arrays in the type 
traits at all, just like vector types: https://godbolt.org/z/aP685vz8q. That 
may be the most consistent stance on this. Basically "It's non-standard and 
doesn't fit neatly in any of the standard categories, so it's in no category at 
all."

https://github.com/llvm/llvm-project/pull/86652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 


@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -std=c++2c -fsyntax-only -verify %s

Sirraide wrote:

Done.

https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide edited 
https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Resolve FIXME: Look at E, not M (PR #85541)

2024-03-28 Thread John McCall via cfe-commits 

rjmccall wrote:

Hmm.  Well, you'd have to ask @zygoloid what he was thinking in 
r183721/r183859, but I don't think it's correct in general to be looking at E 
(the MTE sub-expression) for most of the logic here.  IIRC, the MTE 
sub-expression is essentially the initializer for the materialized temporary, 
so it should be a pr-value, which means that for ARC (and any similar features 
in the future that we might add with qualifier-specific ownership) it won't 
have the right type information to set up the destructor for the temporary.  
The MTE is going to tell us the type of the I assume that's why the proposed 
patch in this PR ends up ignoring the half of the function that handles the ARC 
qualifiers.  Maybe Richard had some better representation in mind, though.

https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide updated 
https://github.com/llvm/llvm-project/pull/86526

>From 98af47e8ccc633016c14b91c221f9f8fc620f068 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Mon, 25 Mar 2024 14:46:52 +0100
Subject: [PATCH 01/11] [Clang] Parse `= delete("message")`

---
 clang/include/clang/AST/Decl.h| 13 
 clang/include/clang/Parse/Parser.h|  1 +
 clang/include/clang/Sema/Sema.h   |  6 ++--
 clang/lib/AST/Decl.cpp|  4 +--
 clang/lib/AST/DeclPrinter.cpp |  9 +++--
 clang/lib/AST/TextNodeDumper.cpp  |  3 ++
 clang/lib/Parse/ParseCXXInlineMethods.cpp | 24 +-
 clang/lib/Parse/Parser.cpp|  4 ++-
 clang/lib/Sema/SemaDeclCXX.cpp| 10 +++---
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  6 
 .../test/Parser/cxx2c-delete-with-message.cpp | 33 +++
 11 files changed, 100 insertions(+), 13 deletions(-)
 create mode 100644 clang/test/Parser/cxx2c-delete-with-message.cpp

diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index a5879591f4c659..24f0394577e228 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2013,6 +2013,12 @@ class FunctionDecl : public DeclaratorDecl,
 DefaultedFunctionInfo *DefaultedInfo;
   };
 
+  /// Message that indicates why this function was deleted.
+  ///
+  /// FIXME: Figure out where to actually put this; maybe in the
+  /// 'DefaultedInfo' above?
+  StringLiteral *DeletedMessage;
+
   unsigned ODRHash;
 
   /// End part of this FunctionDecl's source range.
@@ -2483,6 +2489,10 @@ class FunctionDecl : public DeclaratorDecl,
   }
 
   void setDeletedAsWritten(bool D = true) { FunctionDeclBits.IsDeleted = D; }
+  void setDeletedWithMessage(StringLiteral* Message) {
+FunctionDeclBits.IsDeleted = true;
+DeletedMessage = Message;
+  }
 
   /// Determines whether this function is "main", which is the
   /// entry point into an executable program.
@@ -2638,6 +2648,9 @@ class FunctionDecl : public DeclaratorDecl,
   AC.push_back(TRC);
   }
 
+  /// Get the message that indicates why this function was deleted.
+  StringLiteral *getDeletedMessage() const { return DeletedMessage; }
+
   void setPreviousDeclaration(FunctionDecl * PrevDecl);
 
   FunctionDecl *getCanonicalDecl() override;
diff --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index 14df75180ef321..559e6416b7dfb3 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -1600,6 +1600,7 @@ class Parser : public CodeCompletionHandler {
  const ParsedTemplateInfo ,
  const VirtSpecifiers ,
  SourceLocation PureSpecLoc);
+  StringLiteral *ParseCXXDeletedFunctionMessage();
   void ParseCXXNonStaticMemberInitializer(Decl *VarD);
   void ParseLexedAttributes(ParsingClass );
   void ParseLexedAttributeList(LateParsedAttrList , Decl *D,
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 64de39acc72176..919f8f6b0a35a2 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4926,10 +4926,12 @@ class Sema final {
SourceLocation EqualLoc);
 
   void ActOnPureSpecifier(Decl *D, SourceLocation PureSpecLoc);
-  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc);
+  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc,
+  StringLiteral *Message = nullptr);
   void SetDeclDefaulted(Decl *dcl, SourceLocation DefaultLoc);
 
-  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind);
+  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind,
+   StringLiteral *DeletedMessage = nullptr);
   void ActOnStartTrailingRequiresClause(Scope *S, Declarator );
   ExprResult ActOnFinishTrailingRequiresClause(ExprResult ConstraintExpr);
   ExprResult ActOnRequiresClause(ExprResult ConstraintExpr);
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 95900afdd2c5d8..b5e61f0eceb6e4 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3043,8 +3043,8 @@ FunctionDecl::FunctionDecl(Kind DK, ASTContext , 
DeclContext *DC,
Expr *TrailingRequiresClause)
 : DeclaratorDecl(DK, DC, NameInfo.getLoc(), NameInfo.getName(), T, TInfo,
  StartLoc),
-  DeclContext(DK), redeclarable_base(C), Body(), ODRHash(0),
-  EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
+  DeclContext(DK), redeclarable_base(C), Body(), DeletedMessage(nullptr),
+  ODRHash(0), EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) 
{
   assert(T.isNull() || T->isFunctionType());
   FunctionDeclBits.SClass = S;
   FunctionDeclBits.IsInline = isInlineSpecified;
diff --git

[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)

2024-03-28 Thread Nikolas Klauser via cfe-commits 

philnik777 wrote:

> I wonder if we should be considering making zero-length arrays into a 
> non-conforming extension behind a flag? e.g., `-fzero-sized-arrays` and then 
> it does report true for `__is_array`, `__is_bounded_array`, and handles 
> template specializations, etc as though it were really an array. That solves 
> two problems: 1) we can make the feature regular as opposed to having so many 
> sharp edges, 2) it pushes a surprising and questionable extension behind an 
> opt-in feature flag, and it creates at least one problem: 1) potentially 
> would change behavior of existing code in C++. So maybe this isn't a tenable 
> idea, but do we think it's worth exploring?

I think it may be worth exploring, but I'm not sure it's feasible. We've been 
using them accidentally a lot in the test suite in libc++ simply because it's 
really easy to miss that it's an extension, and we're also using it in our 
`string` implementation for padding.

> > My natural inclination is that it is array-like, but... that just makes me 
> > want `__is_array` to return `true` for it all the more.
> 
> Yes. An array is an array, regardless of its size. The size is just a storage 
> characteristic. It'd almost be like arguing that `NaN` isn't a float.

I don't think the float analogy really works here. The fact is that zero-sized 
arrays aren't acknowledged as being valid by the standard, so they don't behave 
like other arrays. It's _not_ just a storage characteristic. Having 
`-ffast-math` and then passing `NAN` somewhere seems like a better analogy to 
me. Things are mostly treated as if `NAN` didn't exist, and `NAN` also doesn't 
work like other floats.

> > I wonder if we should be considering making zero-length arrays into a 
> > non-conforming extension behind a flag?
> 
> It was never as simple as zero-length arrays. It was also _trailing arrays of 
> any size_ in structures. Those extensions create huge problems with being 
> able to reason about the characteristics of arrays, and we do have a flag for 
> this: `-fstrict-flex-arrays=3`. It is designed to disable all of the "treat 
> it like a flexible array" logic for the old "fake flexible array" objects. 
> But a flexible array is _still an array_. And also note that its size can 
> _change at runtime_ (see the `counted_by` attribute), which even more clearly 
> argues that you can't claim a flexible array isn't an array.

I'm not sure how the array being able to change its size at runtime makes it 
harder to claim it isn't one? non-zero-sized arrays don't do that. It's 
actually another thing that is different from the rest of the arrays.
I'm also not sure that it makes a ton of sense to talk about flexible arrays, 
since they aren't part of the type system, but `T[0]` happen to become flexible 
arrays if it is at the end of a struct (IIUC).

Another option (that I haven't thought deeply about): Make `T[0]` not be a type 
at all, i.e. make it illegal to `decltype`, `sizeof` etc. uses of it. I don't 
know how breaking that would be, and it's probably just as confusing as the 
current state of things, or even more so. Just wanted to throw it out.


https://github.com/llvm/llvm-project/pull/86652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [ObjC] Fix jmp_buf sizing for ObjC exceptions (PR #85481)

2024-03-28 Thread Eli Friedman via cfe-commits 

efriedma-quic wrote:

As far as I can tell, the code in question only actually runs for 32-bit x86 
targets (it's tied to the old ABI, which was replaced on newer targets).  So 
there's no point to modifying it.

https://github.com/llvm/llvm-project/pull/85481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 219511a - [APINotes] Make an assert in a std::sort call tolerate self-comparisons

2024-03-28 Thread Dmitri Gribenko via cfe-commits 

Author: Dmitri Gribenko
Date: 2024-03-28T23:11:58+01:00
New Revision: 219511aee21cc652e1ede0458de4a4a66f04c81c

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

LOG: [APINotes] Make an assert in a std::sort call tolerate self-comparisons

libc++ debug mode verifies that a comparator passed to std::sort defines
a strict weak order by calling it with the same element.

See also:

- RFC that introduced the feature:
  
https://discourse.llvm.org/t/rfc-strict-weak-ordering-checks-in-the-debug-libc/70217

- `strict_weak_ordering_check.h` in libc++ sources.

Added: 


Modified: 
clang/lib/APINotes/APINotesWriter.cpp

Removed: 




diff  --git a/clang/lib/APINotes/APINotesWriter.cpp 
b/clang/lib/APINotes/APINotesWriter.cpp
index 76fd24ccfae984..e3f5d102fcd07f 100644
--- a/clang/lib/APINotes/APINotesWriter.cpp
+++ b/clang/lib/APINotes/APINotesWriter.cpp
@@ -441,7 +441,7 @@ void emitVersionedInfo(
   std::sort(VI.begin(), VI.end(),
 [](const std::pair ,
const std::pair ) -> bool {
-  assert(LHS.first != RHS.first &&
+  assert(( ==  || LHS.first != RHS.first) &&
  "two entries for the same version");
   return LHS.first < RHS.first;
 });



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

[clang] Resolve FIXME: Look at E, not M (PR #85541)

2024-03-28 Thread Eli Friedman via cfe-commits 

efriedma-quic wrote:

https://github.com/llvm/llvm-project/blob/c0f8be4fcfb725d53841d4b17a68685e2a79/clang/lib/CodeGen/CGExpr.cpp#L277

https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 380f0fb - [CodeGen/DWARF] Introduce DWARF tag for SwiftTail and emit it in CodeGen.

2024-03-28 Thread Adrian Prantl via cfe-commits 

Author: Adrian Prantl
Date: 2024-03-28T14:54:51-07:00
New Revision: 380f0fb682041aca3d682d9f1be9d3021f4b2daa

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

LOG: [CodeGen/DWARF] Introduce DWARF tag for SwiftTail and emit it in CodeGen.

swifttailcc is a new calling convention in LLVM introduced in
https://reviews.llvm.org/D95443. We add a new DWARF tag to capture
this in debuginfo.

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

[Note: This patch seems to have been forgotten about, landing it now with 
considerable delay]

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGen/debug-info-cc.c
llvm/include/llvm/BinaryFormat/Dwarf.def

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 2a385d85aa2bc3..691fde8b0d8b82 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1440,8 +1440,7 @@ static unsigned getDwarfCC(CallingConv CC) {
   case CC_Swift:
 return llvm::dwarf::DW_CC_LLVM_Swift;
   case CC_SwiftAsync:
-// [FIXME: swiftasynccc] Update to SwiftAsync once LLVM support lands.
-return llvm::dwarf::DW_CC_LLVM_Swift;
+return llvm::dwarf::DW_CC_LLVM_SwiftTail;
   case CC_PreserveMost:
 return llvm::dwarf::DW_CC_LLVM_PreserveMost;
   case CC_PreserveAll:

diff  --git a/clang/test/CodeGen/debug-info-cc.c 
b/clang/test/CodeGen/debug-info-cc.c
index 2664bcd4cb6b2d..2bfb1c28e9353b 100644
--- a/clang/test/CodeGen/debug-info-cc.c
+++ b/clang/test/CodeGen/debug-info-cc.c
@@ -64,11 +64,10 @@ __attribute__((swiftcall)) int add_swiftcall(int a, int b) {
   return a+b;
 }
 
-// [FIXME: swiftasynccc] Update debuginfo tag to SwiftAsync once LLVM support 
lands.
 // LINUX: !DISubprogram({{.*}}"add_swiftasynccall", {{.*}}type: ![[FTY:[0-9]+]]
-// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_Swift,
-__attribute__((swiftasynccall)) int add_swiftasynccall(int a, int b, int c) {
-  return a+b+c;
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_SwiftTail,
+__attribute__((swiftasynccall)) int add_swiftasynccall(int a, int b) {
+  return a+b;
 }
 
 // LINUX: !DISubprogram({{.*}}"add_inteloclbicc", {{.*}}type: ![[FTY:[0-9]+]]

diff  --git a/llvm/include/llvm/BinaryFormat/Dwarf.def 
b/llvm/include/llvm/BinaryFormat/Dwarf.def
index d8927c6202fd57..8cf90de637a3d5 100644
--- a/llvm/include/llvm/BinaryFormat/Dwarf.def
+++ b/llvm/include/llvm/BinaryFormat/Dwarf.def
@@ -1041,6 +1041,7 @@ HANDLE_DW_CC(0xcb, LLVM_X86RegCall)
 HANDLE_DW_CC(0xcc, LLVM_M68kRTD)
 HANDLE_DW_CC(0xcd, LLVM_PreserveNone)
 HANDLE_DW_CC(0xce, LLVM_RISCVVectorCall)
+HANDLE_DW_CC(0xcf, LLVM_SwiftTail)
 // From GCC source code (include/dwarf2.h): This DW_CC_ value is not currently
 // generated by any toolchain.  It is used internally to GDB to indicate OpenCL
 // C functions that have been compiled with the IBM XL C for OpenCL compiler 
and



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

[clang] [Clang][objectsize] Generate object size calculation for sub-objects (PR #86858)

2024-03-28 Thread Kees Cook via cfe-commits 

https://github.com/kees commented:

I can't speak to the implementation details, but this passes my PoC tests that 
examine subobjects.

https://github.com/llvm/llvm-project/pull/86858
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix __is_array returning true for zero-sized arrays (PR #86652)

2024-03-28 Thread Kees Cook via cfe-commits 

kees wrote:

> My natural inclination is that it is array-like, but... that just makes me 
> want `__is_array` to return `true` for it all the more.

Yes. An array is an array, regardless of its size. The size is just a storage 
characteristic. It'd almost be like arguing that `NaN` isn't a float.

> I wonder if we should be considering making zero-length arrays into a 
> non-conforming extension behind a flag?

It was never as simple as zero-length arrays. It was also _trailing arrays of 
any size_ in structures. Those extensions create huge problems with being able 
to reason about the characteristics of arrays, and we do have a flag for this: 
`-fstrict-flex-arrays=3`. It is designed to disable all of the "treat it like a 
flexible array" logic for the old "fake flexible array" objects. But a flexible 
array is _still an array_. And also note that its size can _change at runtime_ 
(see the `counted_by` attribute), which even more clearly argues that you can't 
claim a flexible array isn't an array.

https://github.com/llvm/llvm-project/pull/86652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Jan Svoboda via cfe-commits 

https://github.com/jansvoboda11 updated 
https://github.com/llvm/llvm-project/pull/86358

>From 109e6039abe8bd3b598f1fdc2dbd7bca783ff4e6 Mon Sep 17 00:00:00 2001
From: Jan Svoboda 
Date: Fri, 22 Mar 2024 15:54:14 -0700
Subject: [PATCH 1/4] [clang] Move state out of `PreprocessorOptions` (1/n)

An instance of `PreprocessorOptions` is part of `CompilerInvocation` which is 
supposed to be a value type. The `DependencyDirectivesForFile` member is 
problematic, since it holds an owning reference of the scanning VFS. This makes 
it not a true value type, and it can keep potentially large chunk of memory 
(the local cache in the scanning VFS) alive for longer than clients might 
expect. Let's move it into the `Preprocessor` instead.
---
 .../include/clang/Frontend/FrontendActions.h  | 12 +--
 clang/include/clang/Lex/Preprocessor.h| 18 
 clang/include/clang/Lex/PreprocessorOptions.h | 13 
 clang/lib/Frontend/FrontendActions.cpp|  7 ++-
 clang/lib/Lex/PPLexerChange.cpp   | 12 +++
 .../DependencyScanningWorker.cpp  | 21 +++
 6 files changed, 49 insertions(+), 34 deletions(-)

diff --git a/clang/include/clang/Frontend/FrontendActions.h 
b/clang/include/clang/Frontend/FrontendActions.h
index a620ddfc40447d..575cf9ed2ac777 100644
--- a/clang/include/clang/Frontend/FrontendActions.h
+++ b/clang/include/clang/Frontend/FrontendActions.h
@@ -34,12 +34,17 @@ class InitOnlyAction : public FrontendAction {
 
 /// Preprocessor-based frontend action that also loads PCH files.
 class ReadPCHAndPreprocessAction : public FrontendAction {
+  llvm::function_ref OnCI;
+
   void ExecuteAction() override;
 
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
 
 public:
+  ReadPCHAndPreprocessAction(llvm::function_ref OnCI)
+  : OnCI(OnCI) {}
+
   bool usesPreprocessorOnly() const override { return false; }
 };
 
@@ -321,11 +326,14 @@ class PrintPreprocessedAction : public 
PreprocessorFrontendAction {
 
 class GetDependenciesByModuleNameAction : public PreprocessOnlyAction {
   StringRef ModuleName;
+  llvm::function_ref OnCI;
+
   void ExecuteAction() override;
 
 public:
-  GetDependenciesByModuleNameAction(StringRef ModuleName)
-  : ModuleName(ModuleName) {}
+  GetDependenciesByModuleNameAction(
+  StringRef ModuleName, llvm::function_ref OnCI)
+  : ModuleName(ModuleName), OnCI(OnCI) {}
 };
 
 }  // end namespace clang
diff --git a/clang/include/clang/Lex/Preprocessor.h 
b/clang/include/clang/Lex/Preprocessor.h
index 0836b7d439bb04..10a7ba4db25625 100644
--- a/clang/include/clang/Lex/Preprocessor.h
+++ b/clang/include/clang/Lex/Preprocessor.h
@@ -736,6 +736,19 @@ class Preprocessor {
 State ConditionalStackState = Off;
   } PreambleConditionalStack;
 
+  /// Function for getting the dependency preprocessor directives of a file.
+  ///
+  /// These are directives derived from a special form of lexing where the
+  /// source input is scanned for the preprocessor directives that might have 
an
+  /// effect on the dependencies for a compilation unit.
+  ///
+  /// Enables a client to cache the directives for a file and provide them
+  /// across multiple compiler invocations.
+  /// FIXME: Allow returning an error.
+  using DependencyDirectivesFn = std::function>(FileEntryRef)>;
+  DependencyDirectivesFn DependencyDirectivesForFile;
+
   /// The current top of the stack that we're lexing from if
   /// not expanding a macro and we are lexing directly from source code.
   ///
@@ -1270,6 +1283,11 @@ class Preprocessor {
   /// false if it is producing tokens to be consumed by Parse and Sema.
   bool isPreprocessedOutput() const { return PreprocessedOutput; }
 
+  /// Set the function used to get dependency directives for a file.
+  void setDependencyDirectivesFn(DependencyDirectivesFn Fn) {
+DependencyDirectivesForFile = std::move(Fn);
+  }
+
   /// Return true if we are lexing directly from the specified lexer.
   bool isCurrentLexer(const PreprocessorLexer *L) const {
 return CurPPLexer == L;
diff --git a/clang/include/clang/Lex/PreprocessorOptions.h 
b/clang/include/clang/Lex/PreprocessorOptions.h
index f841e4a028df50..24e0ca61d41432 100644
--- a/clang/include/clang/Lex/PreprocessorOptions.h
+++ b/clang/include/clang/Lex/PreprocessorOptions.h
@@ -208,19 +208,6 @@ class PreprocessorOptions {
   /// build it again.
   std::shared_ptr FailedModules;
 
-  /// Function for getting the dependency preprocessor directives of a file.
-  ///
-  /// These are directives derived from a special form of lexing where the
-  /// source input is scanned for the preprocessor directives that might have 
an
-  /// effect on the dependencies for a compilation unit.
-  ///
-  /// Enables a client to cache the directives for a file and provide them
-  /// across multiple compiler invocations.
-  /// FIXME: Allow returning an error.
-

[clang] [llvm] [openmp] [Libomptarget] Statically link all plugin runtimes (PR #87009)

2024-03-28 Thread Joseph Huber via cfe-commits 

https://github.com/jhuber6 updated 
https://github.com/llvm/llvm-project/pull/87009

>From fe0b6725e9aa89cc378ffd97f19354d59ab4fa93 Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Wed, 27 Mar 2024 15:27:16 -0500
Subject: [PATCH 1/4] [Libomptarget] Rename `libomptarget.rtl.x86_64` to
 `libomptarget.rtl.host`

Summary:
All of these are functionally the same code, just compiled for separate
architectures. We currently do not expose a way to execute these on
separate architectures as the host plugin works using `dlopen` into the
same process, and therefore cannot possibly be an incompatible
architecture. (This could work with a remote plugin, but this is not
supported yet).

This patch simply renames all of these to the same thing so we no longer
need to check around for its varying definitions.
---
 .../plugins-nextgen/host/CMakeLists.txt   | 36 +--
 openmp/libomptarget/src/CMakeLists.txt|  5 +--
 2 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt 
b/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt
index ccbf7d033fd663..0954f8367654f6 100644
--- a/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt
+++ b/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt
@@ -14,36 +14,36 @@ if(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le$")
 endif()
 
 # Create the library and add the default arguments.
-add_target_library(omptarget.rtl.${machine} ${machine})
+add_target_library(omptarget.rtl.host ${machine})
 
-target_sources(omptarget.rtl.${machine} PRIVATE src/rtl.cpp)
+target_sources(omptarget.rtl.host PRIVATE src/rtl.cpp)
 
 if(LIBOMPTARGET_DEP_LIBFFI_FOUND)
   libomptarget_say("Building ${machine} plugin linked with libffi")
   if(FFI_STATIC_LIBRARIES)
-target_link_libraries(omptarget.rtl.${machine} PRIVATE FFI::ffi_static)
+target_link_libraries(omptarget.rtl.host PRIVATE FFI::ffi_static)
   else()
-target_link_libraries(omptarget.rtl.${machine} PRIVATE FFI::ffi)
+target_link_libraries(omptarget.rtl.host PRIVATE FFI::ffi)
   endif()
 else()
   libomptarget_say("Building ${machine} plugin for dlopened libffi")
-  target_sources(omptarget.rtl.${machine} PRIVATE dynamic_ffi/ffi.cpp)
-  target_include_directories(omptarget.rtl.${machine} PRIVATE dynamic_ffi)
+  target_sources(omptarget.rtl.host PRIVATE dynamic_ffi/ffi.cpp)
+  target_include_directories(omptarget.rtl.host PRIVATE dynamic_ffi)
 endif()
 
 # Install plugin under the lib destination folder.
-install(TARGETS omptarget.rtl.${machine}
+install(TARGETS omptarget.rtl.host
 LIBRARY DESTINATION "${OPENMP_INSTALL_LIBDIR}")
-set_target_properties(omptarget.rtl.${machine} PROPERTIES
+set_target_properties(omptarget.rtl.host PROPERTIES
   INSTALL_RPATH "$ORIGIN" BUILD_RPATH "$ORIGIN:${CMAKE_CURRENT_BINARY_DIR}/.."
   POSITION_INDEPENDENT_CODE ON
   CXX_VISIBILITY_PRESET protected)
 
-target_include_directories(omptarget.rtl.${machine} PRIVATE
+target_include_directories(omptarget.rtl.host PRIVATE
${LIBOMPTARGET_INCLUDE_DIR})
 
 if(LIBOMPTARGET_DEP_LIBFFI_FOUND)
-  list(APPEND LIBOMPTARGET_TESTED_PLUGINS omptarget.rtl.${machine})
+  list(APPEND LIBOMPTARGET_TESTED_PLUGINS omptarget.rtl.host)
   set(LIBOMPTARGET_TESTED_PLUGINS
   "${LIBOMPTARGET_TESTED_PLUGINS}" PARENT_SCOPE)
 else()
@@ -53,29 +53,29 @@ endif()
 # Define the target specific triples and ELF machine values.
 if(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le$" OR
CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE 
TARGET_ELF_ID=EM_PPC64)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE TARGET_ELF_ID=EM_PPC64)
+  target_compile_definitions(omptarget.rtl.host PRIVATE
   LIBOMPTARGET_NEXTGEN_GENERIC_PLUGIN_TRIPLE="powerpc64-ibm-linux-gnu")
   list(APPEND LIBOMPTARGET_SYSTEM_TARGETS 
"powerpc64-ibm-linux-gnu" "powerpc64-ibm-linux-gnu-LTO")
   set(LIBOMPTARGET_SYSTEM_TARGETS "${LIBOMPTARGET_SYSTEM_TARGETS}" 
PARENT_SCOPE)
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE 
TARGET_ELF_ID=EM_X86_64)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE 
TARGET_ELF_ID=EM_X86_64)
+  target_compile_definitions(omptarget.rtl.host PRIVATE
   LIBOMPTARGET_NEXTGEN_GENERIC_PLUGIN_TRIPLE="x86_64-pc-linux-gnu")
   list(APPEND LIBOMPTARGET_SYSTEM_TARGETS 
"x86_64-pc-linux-gnu" "x86_64-pc-linux-gnu-LTO")
   set(LIBOMPTARGET_SYSTEM_TARGETS "${LIBOMPTARGET_SYSTEM_TARGETS}" 
PARENT_SCOPE)
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "aarch64$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE 
TARGET_ELF_ID=EM_AARCH64)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE 
TARGET_ELF_ID=EM_AARCH64)
+

[clang] [llvm] [openmp] [Libomptarget] Statically link all plugin runtimes (PR #87009)

2024-03-28 Thread Joseph Huber via cfe-commits 

jhuber6 wrote:

This contains three other dependent commits until they land. For now just 
browse the most recent commit for the relevant changes.

https://github.com/llvm/llvm-project/pull/87009
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [openmp] [Libomptarget] Statically link all plugin runtimes (PR #87009)

2024-03-28 Thread via cfe-commits 

llvmbot wrote:



@llvm/pr-subscribers-clang-driver
@llvm/pr-subscribers-backend-amdgpu

@llvm/pr-subscribers-clang

Author: Joseph Huber (jhuber6)


Changes

This patch overhauls the `libomptarget` and plugin interface. Currently,
we define a C API and compile each plugin as a separate shared library.
Then, `libomptarget` loads these API functions and forwards its internal
calls to them. This was originally designed to allow multiple
implementations of a library to be live. However, since then no one has
used this functionality and it prevents us from using much nicer
interfaces. If the old behavior is desired it should instead be
implemented as a separate plugin.

This patch replaces the `PluginAdaptorTy` interface with the
`GenericPluginTy` that is used by the plugins. Each plugin exports a
`createPlugin_name` function that is used to get the specific
implementation. This code is now shared with `libomptarget`.

There are some notable improvements to this.
1. Massively improved lifetimes of life runtime objects
2. The plugins can use a C++ interface
3. Global state does not need to be duplicated for each plugin +
   libomptarget
4. Easier to use and add features and improve error handling
5. Less function call overhead / Improved LTO performance.

Additional changes in this plugin are related to contending with the
fact that state is now shared. Initialization and deinitialization is
now handled correctly and in phase with the underlying runtime, allowing
us to actually know when something is getting deallocated.

Depends on https://github.com/llvm/llvm-project/pull/86971 
https://github.com/llvm/llvm-project/pull/86875 
https://github.com/llvm/llvm-project/pull/86868


---

Patch is 71.10 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/87009.diff


28 Files Affected:

- (modified) clang/test/Driver/linker-wrapper-image.c (+1-1) 
- (modified) llvm/lib/Frontend/Offloading/OffloadWrapper.cpp (+4-3) 
- (modified) openmp/libomptarget/CMakeLists.txt (+26) 
- (modified) openmp/libomptarget/include/PluginManager.h (+24-70) 
- (removed) openmp/libomptarget/include/Shared/PluginAPI.h (-232) 
- (removed) openmp/libomptarget/include/Shared/PluginAPI.inc (-51) 
- (added) openmp/libomptarget/include/Shared/Targets.def.in (+20) 
- (modified) openmp/libomptarget/include/device.h (+5-3) 
- (modified) openmp/libomptarget/plugins-nextgen/CMakeLists.txt (+9-19) 
- (modified) openmp/libomptarget/plugins-nextgen/amdgpu/CMakeLists.txt (-5) 
- (modified) openmp/libomptarget/plugins-nextgen/amdgpu/src/rtl.cpp (+8-6) 
- (modified) openmp/libomptarget/plugins-nextgen/common/CMakeLists.txt (+2-3) 
- (modified) 
openmp/libomptarget/plugins-nextgen/common/include/PluginInterface.h (+4-90) 
- (modified) openmp/libomptarget/plugins-nextgen/common/include/Utils/ELF.h 
(-2) 
- (modified) openmp/libomptarget/plugins-nextgen/common/src/JIT.cpp (+17-23) 
- (modified) openmp/libomptarget/plugins-nextgen/common/src/PluginInterface.cpp 
(-205) 
- (modified) openmp/libomptarget/plugins-nextgen/cuda/CMakeLists.txt (-5) 
- (modified) openmp/libomptarget/plugins-nextgen/cuda/src/rtl.cpp (+8-6) 
- (modified) openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt (+16-24) 
- (modified) openmp/libomptarget/plugins-nextgen/host/src/rtl.cpp (+8-6) 
- (modified) openmp/libomptarget/src/CMakeLists.txt (+8-18) 
- (modified) openmp/libomptarget/src/OffloadRTL.cpp (+1) 
- (modified) openmp/libomptarget/src/OpenMP/InteropAPI.cpp (+2-2) 
- (modified) openmp/libomptarget/src/PluginManager.cpp (+72-113) 
- (modified) openmp/libomptarget/src/device.cpp (+1-2) 
- (modified) openmp/libomptarget/src/interface.cpp (+1-1) 
- (modified) openmp/libomptarget/tools/kernelreplay/llvm-omp-kernel-replay.cpp 
(-2) 
- (modified) openmp/libomptarget/unittests/Plugins/NextgenPluginsTest.cpp (-1) 


``diff
diff --git a/clang/test/Driver/linker-wrapper-image.c 
b/clang/test/Driver/linker-wrapper-image.c
index d01445e3aed04e..5d5d62805e174d 100644
--- a/clang/test/Driver/linker-wrapper-image.c
+++ b/clang/test/Driver/linker-wrapper-image.c
@@ -30,8 +30,8 @@
 
 //  OPENMP: define internal void @.omp_offloading.descriptor_reg() section 
".text.startup" {
 // OPENMP-NEXT: entry:
-// OPENMP-NEXT:   %0 = call i32 @atexit(ptr @.omp_offloading.descriptor_unreg)
 // OPENMP-NEXT:   call void @__tgt_register_lib(ptr 
@.omp_offloading.descriptor)
+// OPENMP-NEXT:   %0 = call i32 @atexit(ptr @.omp_offloading.descriptor_unreg)
 // OPENMP-NEXT:   ret void
 // OPENMP-NEXT: }
 
diff --git a/llvm/lib/Frontend/Offloading/OffloadWrapper.cpp 
b/llvm/lib/Frontend/Offloading/OffloadWrapper.cpp
index 7241d15ed1c670..8b6f9ea1f4cca3 100644
--- a/llvm/lib/Frontend/Offloading/OffloadWrapper.cpp
+++ b/llvm/lib/Frontend/Offloading/OffloadWrapper.cpp
@@ -232,12 +232,13 @@ void createRegisterFunction(Module , GlobalVariable 
*BinDesc,
   // Construct function body
   IRBuilder<> Builder(BasicBlock::Create(C, "entry", Func));
 
+

[clang] [llvm] [openmp] [Libomptarget] Statically link all plugin runtimes (PR #87009)

2024-03-28 Thread Joseph Huber via cfe-commits 

https://github.com/jhuber6 created 
https://github.com/llvm/llvm-project/pull/87009

This patch overhauls the `libomptarget` and plugin interface. Currently,
we define a C API and compile each plugin as a separate shared library.
Then, `libomptarget` loads these API functions and forwards its internal
calls to them. This was originally designed to allow multiple
implementations of a library to be live. However, since then no one has
used this functionality and it prevents us from using much nicer
interfaces. If the old behavior is desired it should instead be
implemented as a separate plugin.

This patch replaces the `PluginAdaptorTy` interface with the
`GenericPluginTy` that is used by the plugins. Each plugin exports a
`createPlugin_` function that is used to get the specific
implementation. This code is now shared with `libomptarget`.

There are some notable improvements to this.
1. Massively improved lifetimes of life runtime objects
2. The plugins can use a C++ interface
3. Global state does not need to be duplicated for each plugin +
   libomptarget
4. Easier to use and add features and improve error handling
5. Less function call overhead / Improved LTO performance.

Additional changes in this plugin are related to contending with the
fact that state is now shared. Initialization and deinitialization is
now handled correctly and in phase with the underlying runtime, allowing
us to actually know when something is getting deallocated.

Depends on https://github.com/llvm/llvm-project/pull/86971 
https://github.com/llvm/llvm-project/pull/86875 
https://github.com/llvm/llvm-project/pull/86868


>From fe0b6725e9aa89cc378ffd97f19354d59ab4fa93 Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Wed, 27 Mar 2024 15:27:16 -0500
Subject: [PATCH 1/4] [Libomptarget] Rename `libomptarget.rtl.x86_64` to
 `libomptarget.rtl.host`

Summary:
All of these are functionally the same code, just compiled for separate
architectures. We currently do not expose a way to execute these on
separate architectures as the host plugin works using `dlopen` into the
same process, and therefore cannot possibly be an incompatible
architecture. (This could work with a remote plugin, but this is not
supported yet).

This patch simply renames all of these to the same thing so we no longer
need to check around for its varying definitions.
---
 .../plugins-nextgen/host/CMakeLists.txt   | 36 +--
 openmp/libomptarget/src/CMakeLists.txt|  5 +--
 2 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt 
b/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt
index ccbf7d033fd663..0954f8367654f6 100644
--- a/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt
+++ b/openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt
@@ -14,36 +14,36 @@ if(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le$")
 endif()
 
 # Create the library and add the default arguments.
-add_target_library(omptarget.rtl.${machine} ${machine})
+add_target_library(omptarget.rtl.host ${machine})
 
-target_sources(omptarget.rtl.${machine} PRIVATE src/rtl.cpp)
+target_sources(omptarget.rtl.host PRIVATE src/rtl.cpp)
 
 if(LIBOMPTARGET_DEP_LIBFFI_FOUND)
   libomptarget_say("Building ${machine} plugin linked with libffi")
   if(FFI_STATIC_LIBRARIES)
-target_link_libraries(omptarget.rtl.${machine} PRIVATE FFI::ffi_static)
+target_link_libraries(omptarget.rtl.host PRIVATE FFI::ffi_static)
   else()
-target_link_libraries(omptarget.rtl.${machine} PRIVATE FFI::ffi)
+target_link_libraries(omptarget.rtl.host PRIVATE FFI::ffi)
   endif()
 else()
   libomptarget_say("Building ${machine} plugin for dlopened libffi")
-  target_sources(omptarget.rtl.${machine} PRIVATE dynamic_ffi/ffi.cpp)
-  target_include_directories(omptarget.rtl.${machine} PRIVATE dynamic_ffi)
+  target_sources(omptarget.rtl.host PRIVATE dynamic_ffi/ffi.cpp)
+  target_include_directories(omptarget.rtl.host PRIVATE dynamic_ffi)
 endif()
 
 # Install plugin under the lib destination folder.
-install(TARGETS omptarget.rtl.${machine}
+install(TARGETS omptarget.rtl.host
 LIBRARY DESTINATION "${OPENMP_INSTALL_LIBDIR}")
-set_target_properties(omptarget.rtl.${machine} PROPERTIES
+set_target_properties(omptarget.rtl.host PROPERTIES
   INSTALL_RPATH "$ORIGIN" BUILD_RPATH "$ORIGIN:${CMAKE_CURRENT_BINARY_DIR}/.."
   POSITION_INDEPENDENT_CODE ON
   CXX_VISIBILITY_PRESET protected)
 
-target_include_directories(omptarget.rtl.${machine} PRIVATE
+target_include_directories(omptarget.rtl.host PRIVATE
${LIBOMPTARGET_INCLUDE_DIR})
 
 if(LIBOMPTARGET_DEP_LIBFFI_FOUND)
-  list(APPEND LIBOMPTARGET_TESTED_PLUGINS omptarget.rtl.${machine})
+  list(APPEND LIBOMPTARGET_TESTED_PLUGINS omptarget.rtl.host)
   set(LIBOMPTARGET_TESTED_PLUGINS
   "${LIBOMPTARGET_TESTED_PLUGINS}" PARENT_SCOPE)
 else()
@@ -53,29 +53,29 @@ endif()
 # Define the target specific triples and ELF machine values.

[clang] Resolve FIXME: Look at E, not M (PR #85541)

2024-03-28 Thread John McCall via cfe-commits 

rjmccall wrote:

Well, sometimes we do leave FIXMEs that end up being suprisingly easy to fix.  
But what FIXME are we talking about here?  The patch doesn't remove any FIXMEs, 
or for that matter include any tests.

https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Jan Svoboda via cfe-commits 


@@ -34,12 +34,17 @@ class InitOnlyAction : public FrontendAction {
 
 /// Preprocessor-based frontend action that also loads PCH files.
 class ReadPCHAndPreprocessAction : public FrontendAction {
+  llvm::function_ref OnCI;

jansvoboda11 wrote:

Sounds good.

https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 


@@ -18157,7 +18158,7 @@ void Sema::SetDeclDeleted(Decl *Dcl, SourceLocation 
DelLoc) {
   // C++11 [dcl.fct.def.delete]p4:
   //  A deleted function is implicitly inline.
   Fn->setImplicitlyInline();
-  Fn->setDeletedAsWritten();
+  Fn->setDeletedWithMessage(Message);

Sirraide wrote:

> I think we should just add the Message as parameter to `setDeletedAsWritten`

I don’t think that would work too well after all now that the message is stored 
in the `DefaultFunctionInfo`, because `setDeletedAsWritten()` is called in many 
places, but the `DefaultFunctionInfo` needs to be constructed separately in 
some. Currently, there is only one place where `setDeletedAsWritten()` is 
called and then immediately after `setDeletedMessage()`, so I don’t thing it’s 
worth merging the two.


https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

Sirraide wrote:

So, the message is now stored in the `DefaultFunctionInfo`, which I’ve renamed 
to `ExtraFunctionInfo`; because setting the deleted message may require 
allocating a `DefaultFunctionInfo`, I’ve added a separate function for that 
(`FunctionDecl::setDeletedMessage()`).

https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 


@@ -2013,6 +2013,12 @@ class FunctionDecl : public DeclaratorDecl,
 DefaultedFunctionInfo *DefaultedInfo;
   };
 
+  /// Message that indicates why this function was deleted.
+  ///
+  /// FIXME: Figure out where to actually put this; maybe in the
+  /// 'DefaultedInfo' above?
+  StringLiteral *DeletedMessage;

Sirraide wrote:

Just refactored that; see my comment below.

https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 

https://github.com/Sirraide updated 
https://github.com/llvm/llvm-project/pull/86526

>From 98af47e8ccc633016c14b91c221f9f8fc620f068 Mon Sep 17 00:00:00 2001
From: Sirraide 
Date: Mon, 25 Mar 2024 14:46:52 +0100
Subject: [PATCH 01/10] [Clang] Parse `= delete("message")`

---
 clang/include/clang/AST/Decl.h| 13 
 clang/include/clang/Parse/Parser.h|  1 +
 clang/include/clang/Sema/Sema.h   |  6 ++--
 clang/lib/AST/Decl.cpp|  4 +--
 clang/lib/AST/DeclPrinter.cpp |  9 +++--
 clang/lib/AST/TextNodeDumper.cpp  |  3 ++
 clang/lib/Parse/ParseCXXInlineMethods.cpp | 24 +-
 clang/lib/Parse/Parser.cpp|  4 ++-
 clang/lib/Sema/SemaDeclCXX.cpp| 10 +++---
 .../lib/Sema/SemaTemplateInstantiateDecl.cpp  |  6 
 .../test/Parser/cxx2c-delete-with-message.cpp | 33 +++
 11 files changed, 100 insertions(+), 13 deletions(-)
 create mode 100644 clang/test/Parser/cxx2c-delete-with-message.cpp

diff --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index a5879591f4c659..24f0394577e228 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2013,6 +2013,12 @@ class FunctionDecl : public DeclaratorDecl,
 DefaultedFunctionInfo *DefaultedInfo;
   };
 
+  /// Message that indicates why this function was deleted.
+  ///
+  /// FIXME: Figure out where to actually put this; maybe in the
+  /// 'DefaultedInfo' above?
+  StringLiteral *DeletedMessage;
+
   unsigned ODRHash;
 
   /// End part of this FunctionDecl's source range.
@@ -2483,6 +2489,10 @@ class FunctionDecl : public DeclaratorDecl,
   }
 
   void setDeletedAsWritten(bool D = true) { FunctionDeclBits.IsDeleted = D; }
+  void setDeletedWithMessage(StringLiteral* Message) {
+FunctionDeclBits.IsDeleted = true;
+DeletedMessage = Message;
+  }
 
   /// Determines whether this function is "main", which is the
   /// entry point into an executable program.
@@ -2638,6 +2648,9 @@ class FunctionDecl : public DeclaratorDecl,
   AC.push_back(TRC);
   }
 
+  /// Get the message that indicates why this function was deleted.
+  StringLiteral *getDeletedMessage() const { return DeletedMessage; }
+
   void setPreviousDeclaration(FunctionDecl * PrevDecl);
 
   FunctionDecl *getCanonicalDecl() override;
diff --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index 14df75180ef321..559e6416b7dfb3 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -1600,6 +1600,7 @@ class Parser : public CodeCompletionHandler {
  const ParsedTemplateInfo ,
  const VirtSpecifiers ,
  SourceLocation PureSpecLoc);
+  StringLiteral *ParseCXXDeletedFunctionMessage();
   void ParseCXXNonStaticMemberInitializer(Decl *VarD);
   void ParseLexedAttributes(ParsingClass );
   void ParseLexedAttributeList(LateParsedAttrList , Decl *D,
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 64de39acc72176..919f8f6b0a35a2 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4926,10 +4926,12 @@ class Sema final {
SourceLocation EqualLoc);
 
   void ActOnPureSpecifier(Decl *D, SourceLocation PureSpecLoc);
-  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc);
+  void SetDeclDeleted(Decl *dcl, SourceLocation DelLoc,
+  StringLiteral *Message = nullptr);
   void SetDeclDefaulted(Decl *dcl, SourceLocation DefaultLoc);
 
-  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind);
+  void SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind,
+   StringLiteral *DeletedMessage = nullptr);
   void ActOnStartTrailingRequiresClause(Scope *S, Declarator );
   ExprResult ActOnFinishTrailingRequiresClause(ExprResult ConstraintExpr);
   ExprResult ActOnRequiresClause(ExprResult ConstraintExpr);
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 95900afdd2c5d8..b5e61f0eceb6e4 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3043,8 +3043,8 @@ FunctionDecl::FunctionDecl(Kind DK, ASTContext , 
DeclContext *DC,
Expr *TrailingRequiresClause)
 : DeclaratorDecl(DK, DC, NameInfo.getLoc(), NameInfo.getName(), T, TInfo,
  StartLoc),
-  DeclContext(DK), redeclarable_base(C), Body(), ODRHash(0),
-  EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) {
+  DeclContext(DK), redeclarable_base(C), Body(), DeletedMessage(nullptr),
+  ODRHash(0), EndRangeLoc(NameInfo.getEndLoc()), DNLoc(NameInfo.getInfo()) 
{
   assert(T.isNull() || T->isFunctionType());
   FunctionDeclBits.SClass = S;
   FunctionDeclBits.IsInline = isInlineSpecified;
diff --git

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Jan Svoboda via cfe-commits 

https://github.com/jansvoboda11 edited 
https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Ben Langmuir via cfe-commits 


@@ -34,12 +34,17 @@ class InitOnlyAction : public FrontendAction {
 
 /// Preprocessor-based frontend action that also loads PCH files.
 class ReadPCHAndPreprocessAction : public FrontendAction {
+  llvm::function_ref OnCI;

benlangmuir wrote:

My concern is that nothing prevents using this frontend action from some other 
code where it wouldn't be safe.  Maybe we can make it a unique_function?

https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Resolve FIXME: Look at E, not M (PR #85541)

2024-03-28 Thread Eli Friedman via cfe-commits 

efriedma-quic wrote:

I assume the FIXME is referring to some deeper change here? If it were that 
easy, the FIXME wouldn't be there in the first place.

CC @zygoloid @rjmccall

https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Jan Svoboda via cfe-commits 


@@ -736,6 +736,19 @@ class Preprocessor {
 State ConditionalStackState = Off;
   } PreambleConditionalStack;
 
+  /// Function for getting the dependency preprocessor directives of a file.
+  ///
+  /// These are directives derived from a special form of lexing where the
+  /// source input is scanned for the preprocessor directives that might have 
an
+  /// effect on the dependencies for a compilation unit.
+  ///
+  /// Enables a client to cache the directives for a file and provide them
+  /// across multiple compiler invocations.
+  /// FIXME: Allow returning an error.
+  using DependencyDirectivesFn = std::functionhttps://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Jan Svoboda via cfe-commits 


@@ -34,12 +34,17 @@ class InitOnlyAction : public FrontendAction {
 
 /// Preprocessor-based frontend action that also loads PCH files.
 class ReadPCHAndPreprocessAction : public FrontendAction {
+  llvm::function_ref OnCI;

jansvoboda11 wrote:

`function_ref` is safe here because `ReadPCHAndPreprocessAction ` is a stack 
variable in `DependencyScanningAction::runInvocation()` where it's clear the 
callback live long enough. I don't mind being on the safe side and turning this 
into `std::function` if you'd prefer.

https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Jan Svoboda via cfe-commits 


@@ -34,12 +34,17 @@ class InitOnlyAction : public FrontendAction {
 
 /// Preprocessor-based frontend action that also loads PCH files.
 class ReadPCHAndPreprocessAction : public FrontendAction {
+  llvm::function_ref OnCI;

jansvoboda11 wrote:

The function acts on `CompilerInstance`, so I figured `OnCI` fits. But I guess 
it's a bit too terse. How about `AdjustCI`? It's basically here to be able to 
tweak the `CompilerInstance` in a way that `CompilerInvocation` alone can't 
(and neither can this `FrontendAction` without some additional context).

https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Ben Langmuir via cfe-commits 


@@ -736,6 +736,19 @@ class Preprocessor {
 State ConditionalStackState = Off;
   } PreambleConditionalStack;
 
+  /// Function for getting the dependency preprocessor directives of a file.
+  ///
+  /// These are directives derived from a special form of lexing where the
+  /// source input is scanned for the preprocessor directives that might have 
an
+  /// effect on the dependencies for a compilation unit.
+  ///
+  /// Enables a client to cache the directives for a file and provide them
+  /// across multiple compiler invocations.
+  /// FIXME: Allow returning an error.
+  using DependencyDirectivesFn = std::functionhttps://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Ben Langmuir via cfe-commits 


@@ -34,12 +34,17 @@ class InitOnlyAction : public FrontendAction {
 
 /// Preprocessor-based frontend action that also loads PCH files.
 class ReadPCHAndPreprocessAction : public FrontendAction {
+  llvm::function_ref OnCI;

benlangmuir wrote:

What does `OnCI` mean? Is there a clearer name we could choose and/or could we 
document the role of this callback?

Also, how do we know function_ref is safe here?

https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-28 Thread Louis Dionne via cfe-commits 

ldionne wrote:

> > Thanks for the explanation, @AaronBallman . I think I am generally deeply 
> > confused about what should be provided by the compiler and what should be 
> > provided by the C Standard Library on any given platform. From your reply, 
> > it looks like there's no clear rule and Clang basically provides anything 
> > that seems "easy enough" to provide. I still don't understand how that 
> > works in case you do end up including a header from the platform that 
> > (re)defines `unreachable`, for example.
> 
> For C17 and earlier, the rule was that we provided everything required for 
> freestanding by the standard, and anything else the user wanted had to come 
> from a library the user supplied. For C23, which we're still in the process 
> of implementing, the situation is different and we've not documented what the 
> expectations are yet. I suspect we're going to end up requiring the user to 
> provide their own freestanding library implementation and the compiler will 
> provide only the bits that the compiler has to provide (things like 
> `limits.h`).

Thanks, this clarifies a lot of things in my head.

> 
> Definitely agreed that we need to document this, but we need to figure out 
> what we want to document in the first place -- some of this is new-ish 
> territory because of the additional interfaces. `unreachable` is morally 
> similar to `offsetof` in that it's a macro interface where the implementation 
> can give better results by expanding to a builtin than a library is likely to 
> be able to give via a naive implementation, but the interfaces _can_ be 
> provided by a CRT. So which one _should_ win? Today, if something else 
> defined `offsetof` or `unreachable` before including `stddef.h`, Clang's 
> headers won't bother re-defining the macro.
> 
> I think we may need to look at what existing freestanding CRTs and hosted 
> CRTs expect to help give us a path forward?

Personally, my naive take on this is that Clang should basically define the 
least amount of things from the C Standard Library, and let a proper C Standard 
Library implement it. Having interacted with a good number of folks who work on 
C libraries (including embedded flavors), I think they all expect that they 
need to provide basically all the declarations/definitions in the C Standard, 
except perhaps stuff from `` and a few other oddities. Doing 
otherwise and trying to be "helpful" in Clang only creates confusion and forces 
C libraries to jump through hoops to avoid colliding with stuff already defines 
in Clang builtin headers.

A C library is not super complicated in the first place, so I don't think we're 
saving a lot of people a lot of time by trying to give them a few definitions 
here and there. Additionally, there's many freestanding-friendly C libraries 
around so it's not like most people have to write their own.

That's just my immediate reaction to this. It's pretty naive but at this 
specific point I believe we should basically not provide any Clang builtin 
headers except the ones that clearly provide compiler-related stuff (e.g. 
`` or `tmmintrin.h` & friends). I'm eager to hear other people's 
takes on this.

SLA note: I'll be OOO for a few days so I'll only see replies early next week.

https://github.com/llvm/llvm-project/pull/86748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [APINotes] Add test for C++ class templates (PR #87006)

2024-03-28 Thread Saleem Abdulrasool via cfe-commits 

https://github.com/compnerd approved this pull request.


https://github.com/llvm/llvm-project/pull/87006
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [APINotes] Add test for C++ class templates (PR #87006)

2024-03-28 Thread via cfe-commits 

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Egor Zhdan (egorzhdan)


Changes

This upstreams https://github.com/apple/llvm-project/pull/7930.

This adds a test to verify that we can apply attributes to C++ class templates 
using API Notes. Doing the same for function templates is not currently 
possible and requires more work.

---
Full diff: https://github.com/llvm/llvm-project/pull/87006.diff


4 Files Affected:

- (added) clang/test/APINotes/Inputs/Headers/Templates.apinotes (+5) 
- (added) clang/test/APINotes/Inputs/Headers/Templates.h (+9) 
- (modified) clang/test/APINotes/Inputs/Headers/module.modulemap (+4) 
- (added) clang/test/APINotes/templates.cpp (+9) 


``diff
diff --git a/clang/test/APINotes/Inputs/Headers/Templates.apinotes 
b/clang/test/APINotes/Inputs/Headers/Templates.apinotes
new file mode 100644
index 00..b7336484da0c79
--- /dev/null
+++ b/clang/test/APINotes/Inputs/Headers/Templates.apinotes
@@ -0,0 +1,5 @@
+---
+Name: Templates
+Tags:
+- Name: Box
+  SwiftImportAs: owned
diff --git a/clang/test/APINotes/Inputs/Headers/Templates.h 
b/clang/test/APINotes/Inputs/Headers/Templates.h
new file mode 100644
index 00..862035fee363f7
--- /dev/null
+++ b/clang/test/APINotes/Inputs/Headers/Templates.h
@@ -0,0 +1,9 @@
+template 
+struct Box {
+  T value;
+
+  const T& get_value() const { return value; }
+  const T* get_ptr() const { return  }
+};
+
+using IntBox = Box;
diff --git a/clang/test/APINotes/Inputs/Headers/module.modulemap 
b/clang/test/APINotes/Inputs/Headers/module.modulemap
index 99fb1aec86481a..d515169184f4f0 100644
--- a/clang/test/APINotes/Inputs/Headers/module.modulemap
+++ b/clang/test/APINotes/Inputs/Headers/module.modulemap
@@ -36,6 +36,10 @@ module Namespaces {
   header "Namespaces.h"
 }
 
+module Templates {
+  header "Templates.h"
+}
+
 module SwiftImportAs {
   header "SwiftImportAs.h"
 }
diff --git a/clang/test/APINotes/templates.cpp 
b/clang/test/APINotes/templates.cpp
new file mode 100644
index 00..d4dce291615e18
--- /dev/null
+++ b/clang/test/APINotes/templates.cpp
@@ -0,0 +1,9 @@
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: %clang_cc1 -fmodules -fblocks -fimplicit-module-maps 
-fmodules-cache-path=%t/ModulesCache/Tmpl -fdisable-module-hash 
-fapinotes-modules -fsyntax-only -I %S/Inputs/Headers -F %S/Inputs/Frameworks 
%s -x c++
+// RUN: %clang_cc1 -fmodules -fblocks -fimplicit-module-maps 
-fmodules-cache-path=%t/ModulesCache/Tmpl -fdisable-module-hash 
-fapinotes-modules -fsyntax-only -I %S/Inputs/Headers -F %S/Inputs/Frameworks 
%s -ast-dump -ast-dump-filter Box -x c++ | FileCheck -check-prefix=CHECK-BOX %s
+
+#include "Templates.h"
+
+// CHECK-BOX: Dumping Box:
+// CHECK-BOX-NEXT: ClassTemplateDecl {{.+}} imported in Templates Box
+// CHECK-BOX: SwiftAttrAttr {{.+}} <> "import_owned"

``




https://github.com/llvm/llvm-project/pull/87006
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [APINotes] Add test for C++ class templates (PR #87006)

2024-03-28 Thread Egor Zhdan via cfe-commits 

https://github.com/egorzhdan created 
https://github.com/llvm/llvm-project/pull/87006

This upstreams https://github.com/apple/llvm-project/pull/7930.

This adds a test to verify that we can apply attributes to C++ class templates 
using API Notes. Doing the same for function templates is not currently 
possible and requires more work.

>From f7713493fcde4ce149aa91e3782040f709f9b10f Mon Sep 17 00:00:00 2001
From: Egor Zhdan 
Date: Thu, 28 Mar 2024 20:41:29 +
Subject: [PATCH] [APINotes] Add test for C++ class templates

This upstreams https://github.com/apple/llvm-project/pull/7930.

This adds a test to verify that we can apply attributes to C++ class templates 
using API Notes. Doing the same for function templates is not currently 
possible and requires more work.
---
 clang/test/APINotes/Inputs/Headers/Templates.apinotes | 5 +
 clang/test/APINotes/Inputs/Headers/Templates.h| 9 +
 clang/test/APINotes/Inputs/Headers/module.modulemap   | 4 
 clang/test/APINotes/templates.cpp | 9 +
 4 files changed, 27 insertions(+)
 create mode 100644 clang/test/APINotes/Inputs/Headers/Templates.apinotes
 create mode 100644 clang/test/APINotes/Inputs/Headers/Templates.h
 create mode 100644 clang/test/APINotes/templates.cpp

diff --git a/clang/test/APINotes/Inputs/Headers/Templates.apinotes 
b/clang/test/APINotes/Inputs/Headers/Templates.apinotes
new file mode 100644
index 00..b7336484da0c79
--- /dev/null
+++ b/clang/test/APINotes/Inputs/Headers/Templates.apinotes
@@ -0,0 +1,5 @@
+---
+Name: Templates
+Tags:
+- Name: Box
+  SwiftImportAs: owned
diff --git a/clang/test/APINotes/Inputs/Headers/Templates.h 
b/clang/test/APINotes/Inputs/Headers/Templates.h
new file mode 100644
index 00..862035fee363f7
--- /dev/null
+++ b/clang/test/APINotes/Inputs/Headers/Templates.h
@@ -0,0 +1,9 @@
+template 
+struct Box {
+  T value;
+
+  const T& get_value() const { return value; }
+  const T* get_ptr() const { return  }
+};
+
+using IntBox = Box;
diff --git a/clang/test/APINotes/Inputs/Headers/module.modulemap 
b/clang/test/APINotes/Inputs/Headers/module.modulemap
index 99fb1aec86481a..d515169184f4f0 100644
--- a/clang/test/APINotes/Inputs/Headers/module.modulemap
+++ b/clang/test/APINotes/Inputs/Headers/module.modulemap
@@ -36,6 +36,10 @@ module Namespaces {
   header "Namespaces.h"
 }
 
+module Templates {
+  header "Templates.h"
+}
+
 module SwiftImportAs {
   header "SwiftImportAs.h"
 }
diff --git a/clang/test/APINotes/templates.cpp 
b/clang/test/APINotes/templates.cpp
new file mode 100644
index 00..d4dce291615e18
--- /dev/null
+++ b/clang/test/APINotes/templates.cpp
@@ -0,0 +1,9 @@
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: %clang_cc1 -fmodules -fblocks -fimplicit-module-maps 
-fmodules-cache-path=%t/ModulesCache/Tmpl -fdisable-module-hash 
-fapinotes-modules -fsyntax-only -I %S/Inputs/Headers -F %S/Inputs/Frameworks 
%s -x c++
+// RUN: %clang_cc1 -fmodules -fblocks -fimplicit-module-maps 
-fmodules-cache-path=%t/ModulesCache/Tmpl -fdisable-module-hash 
-fapinotes-modules -fsyntax-only -I %S/Inputs/Headers -F %S/Inputs/Frameworks 
%s -ast-dump -ast-dump-filter Box -x c++ | FileCheck -check-prefix=CHECK-BOX %s
+
+#include "Templates.h"
+
+// CHECK-BOX: Dumping Box:
+// CHECK-BOX-NEXT: ClassTemplateDecl {{.+}} imported in Templates Box
+// CHECK-BOX: SwiftAttrAttr {{.+}} <> "import_owned"

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

[clang] [clang] Move state out of `PreprocessorOptions` (1/n) (PR #86358)

2024-03-28 Thread Jan Svoboda via cfe-commits 

jansvoboda11 wrote:

Ping.

https://github.com/llvm/llvm-project/pull/86358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libclc] [libclc] Track dependencies through dependency files (PR #86965)

2024-03-28 Thread Fraser Cormack via cfe-commits 

https://github.com/frasercrmck closed 
https://github.com/llvm/llvm-project/pull/86965
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libclc] 688d71e - [libclc] Track dependencies through dependency files (#86965)

2024-03-28 Thread via cfe-commits 

Author: Fraser Cormack
Date: 2024-03-28T20:29:25Z
New Revision: 688d71ea8817ace88955671c1af7c80fbfba2c7f

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

LOG: [libclc] Track dependencies through dependency files (#86965)

This commit fixes the problem of missing build dependencies between
libclc source files and their various includes (namely headers and .inc
files).

We would like to do this with compiler-generated dependency files
because then the dependencies are accurate and there are no false
positives, leading to unnecessary rebuilds. This is how regular C/C++
dependencies are usually tracked by CMake.

Note that this variable is an internal API so is not guaranteed to work,
but then again *all* of CMake's support for new languages (which we use
for CLC/LL languages) is an internal API. On balance this change is
probably worth it due to how minimally invasive it is. It should work
with all supported compilers and CMake generators.

Added: 


Modified: 
libclc/cmake/CMakeCLCInformation.cmake

Removed: 




diff  --git a/libclc/cmake/CMakeCLCInformation.cmake 
b/libclc/cmake/CMakeCLCInformation.cmake
index 6eecf4edf0e7bb..95327e44397222 100644
--- a/libclc/cmake/CMakeCLCInformation.cmake
+++ b/libclc/cmake/CMakeCLCInformation.cmake
@@ -9,3 +9,4 @@ if(NOT CMAKE_CLC_CREATE_STATIC_LIBRARY)
 endif()
 
 set(CMAKE_INCLUDE_FLAG_CLC "-I")
+set(CMAKE_DEPFILE_FLAGS_CLC "-MD -MT  -MF ")



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

[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-28 Thread via cfe-commits 


@@ -1473,7 +1475,7 @@ Decl *Parser::ParseFunctionDefinition(ParsingDeclarator 
,
   D.getMutableDeclSpec().abort();
 
   if (BodyKind != Sema::FnBodyKind::Other) {
-Actions.SetFunctionBodyKind(Res, KWLoc, BodyKind);
+Actions.SetFunctionBodyKind(Res, KWLoc, BodyKind, DeletedMessage);

Sirraide wrote:

So after looking into this a bit, I don’t think we want to do that because 
`Res` is not a `FunctionDecl*` here, it’s a `Decl*`. Specifically, it could 
also be a template, which means we’d need to first dig out the actual function 
using `Sema::AdjustDeclIfTemplate`; the same is also true in at least one other 
place. `SetFunctionBodyKind` calls `SetDeclDeleted`, which already takes care 
of all of that, so I think it’d make more sense to put that there (however, a 
`setDeletedMessage()` on `FunctionDecl` is still useful, and I’ll still be 
using that in other places).

https://github.com/llvm/llvm-project/pull/86526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] RFC: Implementing new mechanism for hard register operands to inline asm as a constraint. (PR #85846)

2024-03-28 Thread via cfe-commits 

https://github.com/tltao updated https://github.com/llvm/llvm-project/pull/85846

>From 71c2e7959cff33f9cd6fc98a99b7261d535183af Mon Sep 17 00:00:00 2001
From: Tony Tao 
Date: Tue, 19 Mar 2024 14:32:48 -0400
Subject: [PATCH 1/5] Revisiting the hard register constraint PR on
 phabricator: https://reviews.llvm.org/D105142

The main idea is to allow Clang to support the ability to
specify specific hardware registers in inline assembly
constraints via the use of curly braces ``{}``. As such,
this is mainly a Clang change.

Relevant RFCs posted here

https://lists.llvm.org/pipermail/llvm-dev/2021-June/151370.html
https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html
---
 clang/docs/LanguageExtensions.rst |  43 ++
 .../clang/Basic/DiagnosticSemaKinds.td|   2 +
 clang/include/clang/Basic/TargetInfo.h|  18 +-
 clang/lib/Basic/TargetInfo.cpp|  54 ++
 clang/lib/Basic/Targets/AArch64.h |   5 -
 clang/lib/Basic/Targets/ARM.h |   5 -
 clang/lib/Basic/Targets/RISCV.h   |   5 -
 clang/lib/Basic/Targets/X86.h |   2 +-
 clang/lib/CodeGen/CGStmt.cpp  | 101 +++-
 .../CodeGen/SystemZ/systemz-inline-asm-02.c   |  10 +-
 .../test/CodeGen/SystemZ/systemz-inline-asm.c |  19 +-
 clang/test/CodeGen/aarch64-inline-asm.c   |  12 +-
 clang/test/CodeGen/asm-goto.c |   6 +-
 clang/test/CodeGen/ms-intrinsics.c|  32 +-
 clang/test/CodeGen/ms-intrinsics.ll   | 533 ++
 .../CodeGen/x86-asm-register-constraint-mix.c |  62 ++
 .../test/CodeGen/z-hard-register-inline-asm.c |  52 ++
 clang/test/Sema/z-hard-register-inline-asm.c  |  50 ++
 llvm/test/CodeGen/SystemZ/zos-inline-asm.ll   | 250 
 19 files changed, 1200 insertions(+), 61 deletions(-)
 create mode 100644 clang/test/CodeGen/ms-intrinsics.ll
 create mode 100644 clang/test/CodeGen/x86-asm-register-constraint-mix.c
 create mode 100644 clang/test/CodeGen/z-hard-register-inline-asm.c
 create mode 100644 clang/test/Sema/z-hard-register-inline-asm.c
 create mode 100644 llvm/test/CodeGen/SystemZ/zos-inline-asm.ll

diff --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 13d7261d83d7f1..39d1981a068992 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1760,6 +1760,49 @@ references can be used instead of numeric references.
   return -1;
   }
 
+Hard Register Operands for ASM Constraints
+==
+
+Clang supports the ability to specify specific hardware registers in inline
+assembly constraints via the use of curly braces ``{}``.
+
+Prior to clang-19, the only way to associate an inline assembly constraint
+with a specific register is via the local register variable feature (`GCC
+Specifying Registers for Local Variables 
`_).
 However, the local register variable association lasts for the entire
+scope of the variable.
+
+Hard register operands will instead only apply to the specific inline ASM
+statement which improves readability and solves a few other issues experienced
+by local register variables, such as:
+
+* function calls might clobber register variables
+* the constraints for the register operands are superfluous
+* one register variable cannot be used for 2 different inline
+  assemblies if the value is expected in different hard regs
+
+The code below is an example of an inline assembly statement using local
+register variables.
+
+.. code-block:: c++
+
+  void foo() {
+register int *p1 asm ("r0") = bar();
+register int *p2 asm ("r1") = bar();
+register int *result asm ("r0");
+asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
+  }
+Below is the same code but using hard register operands.
+
+.. code-block:: c++
+
+  void foo() {
+int *p1 = bar();
+int *p2 = bar();
+int *result;
+asm ("sysint" : "={r0}" (result) : "0" (p1), "{r1}" (p2));
+  }
+
+
 Objective-C Features
 
 
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 8e97902564af08..09672eb3865742 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9235,6 +9235,8 @@ let CategoryName = "Inline Assembly Issue" in {
 "more than one input constraint matches the same output '%0'">;
   def err_store_value_to_reg : Error<
 "impossible constraint in asm: can't store value into a register">;
+  def err_asm_hard_reg_variable_duplicate : Error<
+"hard register operand already defined as register variable">;
 
   def warn_asm_label_on_auto_decl : Warning<
 "ignored asm label '%0' on automatic variable">;
diff --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 374595edd2ce4a..01d43b838414b7 100644
---

[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)

2024-03-28 Thread David Blaikie via cfe-commits 

dwblaikie wrote:

> > Reading LLVM IR lit CHECK lines from clang codegen is a bit difficult - 
> > could you include some simple examples (perhaps from the new clang tests in 
> > this patch) showing the DWARF output just as comments in this review for 
> > something more easily glanceable?
> 
> Attached is the output of the following command
> 
> `clang ~/llvm-project/clang/test/CodeGenCXX/debug-info-ptr-to-ptr.cpp 
> -fdebug-info-for-pointer-type -g2 -S -O3 -o /tmp/debug-info-ptr-to-ptr.txt`
> 
> [debug-info-ptr-to-ptr.txt](https://github.com/llvm/llvm-project/files/14659111/debug-info-ptr-to-ptr.txt)

Thanks - OK, so this only applies to intermediate structures and arrays (is it 
useful for arrays? You can't really reorder them - learning that the hot part 
of an array is the 5th-10th element might be of limited (or at least 
sufficiently different from the struct layout stuff) value - and it's a more 
dynamic property/has a runtime parameter component that might be harder to use?)

Do you have size impact numbers for this? I wouldn't put this under a (possibly 
cc1) flag for now unless we've got some pretty compelling data that this 
doesn't substantially change debug info size, which would be a bit surprising 
to me - I'd assume this would be quite expensive, but it's just a guess.

https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] RFC: Implementing new mechanism for hard register operands to inline asm as a constraint. (PR #85846)

2024-03-28 Thread via cfe-commits 


@@ -770,6 +770,18 @@ bool TargetInfo::validateOutputConstraint(ConstraintInfo 
) const {
 case 'E':
 case 'F':
   break;  // Pass them.
+case '{': {

tltao wrote:

Yes, we should be using the same names. The register asm variable is parsed in 
`clang/lib/Sema/SemaDecl.cpp` using:
```
case SC_Register:
  // Local Named register
  if (!Context.getTargetInfo().isValidGCCRegisterName(Label) &&
  DeclAttrsMatchCUDAMode(getLangOpts(), getCurFunctionDecl()))
Diag(E->getExprLoc(), diag::err_asm_unknown_register_name) << Label;
  break;
```


https://github.com/llvm/llvm-project/pull/85846
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-03-28 Thread David Blaikie via cfe-commits 


@@ -60,11 +63,11 @@ int use() {
 
 // CHECK-NOT: @_ZTSW3Mod4Base = constant
 // CHECK-NOT: @_ZTIW3Mod4Base = constant
-// CHECK: @_ZTVW3Mod4Base = external unnamed_addr
+// CHECK: @_ZTVW3Mod4Base = external
 
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3Mod4Base = linkonce_odr {{.*}}constant
+// CHECK-INLINE-NOT: @_ZTSW3Mod4Base = constant

dwblaikie wrote:

`NOT` checks should be pretty broad - for instance these `NOT` checks would've 
passed with the old code too (since it was linkonce_odr, not constant) - 
perhaps these should just be non-NOT checks, affirmatively checking for the 
linkage of these globals (which I assume they are emitted, as declarations - if 
they aren't emitted at all, then `NOT: @foo` might be enough, without the ` = 
constant`?)

https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] Avoid calling expensive `SourceManager::translateFile()` (PR #86216)

2024-03-28 Thread Jan Svoboda via cfe-commits 

https://github.com/jansvoboda11 closed 
https://github.com/llvm/llvm-project/pull/86216
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 44af53b - [clang][modules] Avoid calling expensive `SourceManager::translateFile()` (#86216)

2024-03-28 Thread via cfe-commits 

Author: Jan Svoboda
Date: 2024-03-28T13:02:48-07:00
New Revision: 44af53b22aaa1fe382b22329bbc7e4610ecbacc8

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

LOG: [clang][modules] Avoid calling expensive `SourceManager::translateFile()` 
(#86216)

The `ASTWriter` algorithm for computing affecting module maps uses
`SourceManager::translateFile()` to get a `FileID` from a `FileEntry`.
This is slow (O(n)) since the function performs a linear walk over
`SLocEntries` until it finds one with a matching `FileEntry`.

This patch removes this use of `SourceManager::translateFile()` by
tracking `FileID` instead of `FileEntry` in couple of places in
`ModuleMap`, giving `ASTWriter` the desired `FileID` directly. There are
no changes required for clients that still want a `FileEntry` from
`ModuleMap`: the existing APIs internally use `SourceManager` to perform
the reverse `FileID` to `FileEntry` conversion in O(1).

Added: 


Modified: 
clang/include/clang/Lex/ModuleMap.h
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Frontend/FrontendAction.cpp
clang/lib/Lex/ModuleMap.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/test/ClangScanDeps/modules-extern-unrelated.m

Removed: 




diff  --git a/clang/include/clang/Lex/ModuleMap.h 
b/clang/include/clang/Lex/ModuleMap.h
index 867cb6eab42f2d..2e28ff6823cb2a 100644
--- a/clang/include/clang/Lex/ModuleMap.h
+++ b/clang/include/clang/Lex/ModuleMap.h
@@ -263,8 +263,8 @@ class ModuleMap {
 Attributes Attrs;
 
 /// If \c InferModules is non-zero, the module map file that allowed
-/// inferred modules.  Otherwise, nullopt.
-OptionalFileEntryRef ModuleMapFile;
+/// inferred modules.  Otherwise, invalid.
+FileID ModuleMapFID;
 
 /// The names of modules that cannot be inferred within this
 /// directory.
@@ -279,8 +279,7 @@ class ModuleMap {
 
   /// A mapping from an inferred module to the module map that allowed the
   /// inference.
-  // FIXME: Consider making the values non-optional.
-  llvm::DenseMap InferredModuleAllowedBy;
+  llvm::DenseMap InferredModuleAllowedBy;
 
   llvm::DenseMap AdditionalModMaps;
 
@@ -618,8 +617,9 @@ class ModuleMap {
   ///
   /// \param Module The module whose module map file will be returned, if 
known.
   ///
-  /// \returns The file entry for the module map file containing the given
-  /// module, or nullptr if the module definition was inferred.
+  /// \returns The FileID for the module map file containing the given module,
+  /// invalid if the module definition was inferred.
+  FileID getContainingModuleMapFileID(const Module *Module) const;
   OptionalFileEntryRef getContainingModuleMapFile(const Module *Module) const;
 
   /// Get the module map file that (along with the module name) uniquely
@@ -631,9 +631,10 @@ class ModuleMap {
   /// of inferred modules, returns the module map that allowed the inference
   /// (e.g. contained 'module *'). Otherwise, returns
   /// getContainingModuleMapFile().
+  FileID getModuleMapFileIDForUniquing(const Module *M) const;
   OptionalFileEntryRef getModuleMapFileForUniquing(const Module *M) const;
 
-  void setInferredModuleAllowedBy(Module *M, OptionalFileEntryRef ModMap);
+  void setInferredModuleAllowedBy(Module *M, FileID ModMapFID);
 
   /// Canonicalize \p Path in a manner suitable for a module map file. In
   /// particular, this canonicalizes the parent directory separately from the

diff  --git a/clang/lib/Frontend/CompilerInstance.cpp 
b/clang/lib/Frontend/CompilerInstance.cpp
index 019f847ccbaad0..79ebb0ae0ee98f 100644
--- a/clang/lib/Frontend/CompilerInstance.cpp
+++ b/clang/lib/Frontend/CompilerInstance.cpp
@@ -1337,9 +1337,24 @@ static bool compileModule(CompilerInstance 
,
   // Get or create the module map that we'll use to build this module.
   ModuleMap 
 = ImportingInstance.getPreprocessor().getHeaderSearchInfo().getModuleMap();
+  SourceManager  = ImportingInstance.getSourceManager();
   bool Result;
-  if (OptionalFileEntryRef ModuleMapFile =
-  ModMap.getContainingModuleMapFile(Module)) {
+  if (FileID ModuleMapFID = ModMap.getContainingModuleMapFileID(Module);
+  ModuleMapFID.isValid()) {
+// We want to use the top-level module map. If we don't, the compiling
+// instance may think the containing module map is a top-level one, while
+// the importing instance knows it's included from a parent module map via
+// the extern directive. This mismatch could bite us later.
+SourceLocation Loc = SourceMgr.getIncludeLoc(ModuleMapFID);
+while (Loc.isValid() && isModuleMap(SourceMgr.getFileCharacteristic(Loc))) 
{
+  ModuleMapFID = SourceMgr.getFileID(Loc);
+  Loc = SourceMgr.getIncludeLoc(ModuleMapFID);
+}
+
+OptionalFileEntryRef ModuleMapFile =
+

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-03-28 Thread David Blaikie via cfe-commits 


@@ -41,9 +43,10 @@ Base::~Base() {}
 // CHECK: @_ZTSW3Mod4Base = constant
 // CHECK: @_ZTIW3Mod4Base = constant
 
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3Mod4Base = linkonce_odr {{.*}}constant
+// With the new Itanium C++ ABI, the linkage of vtables in modules don't need 
to be linkonce ODR.

dwblaikie wrote:

Would they benefit from still being linkonce? What if the vtable is never used? 
Or do we leave that up to `--gc-sections` linker behavior? (I'm not clear on 
when we use linkage to let things be dropped, and when we use the linker 
function-sections/data-sections/gc-sections behavior to drop unused stuff)

https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Darwin] Handle reexported library arguments in driver (PR #86980)

2024-03-28 Thread Cyndy Ishida via cfe-commits 

cyndyishida wrote:

Thanks for the reviews!

https://github.com/llvm/llvm-project/pull/86980
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-03-28 Thread David Blaikie via cfe-commits 


@@ -1483,10 +1483,15 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl 
*D) {
   if (D->isThisDeclarationADefinition())
 Record.AddCXXDefinitionData(D);
 
-  // Store (what we currently believe to be) the key function to avoid
-  // deserializing every method so we can compute it.
-  if (D->isCompleteDefinition())
-Record.AddDeclRef(Context.getCurrentKeyFunction(D));
+  if (D->isCompleteDefinition()) {
+if (D->getOwningModule() && D->getOwningModule()->isInterfaceOrPartition())
+  Writer.ModularCodegenDecls.push_back(Writer.GetDeclRef(D));
+else {
+  // Store (what we currently believe to be) the key function to avoid

dwblaikie wrote:

This seems like a serialization optimization that'd be separate/good to go in 
its own PR (make it easier to see what the change is, how it's tested, etc) 
separate from this one?

https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

2024-03-28 Thread Aaron Ballman via cfe-commits 

AaronBallman wrote:

> Thanks for the explanation, @AaronBallman . I think I am generally deeply 
> confused about what should be provided by the compiler and what should be 
> provided by the C Standard Library on any given platform. From your reply, it 
> looks like there's no clear rule and Clang basically provides anything that 
> seems "easy enough" to provide. I still don't understand how that works in 
> case you do end up including a header from the platform that (re)defines 
> `unreachable`, for example.

For C17 and earlier, the rule was that we provided everything required for 
freestanding by the standard, and anything else the user wanted had to come 
from a library the user supplied. For C23, which we're still in the process of 
implementing, the situation is different and we've not documented what the 
expectations are yet. I suspect we're going to end up requiring the user to 
provide their own freestanding library implementation and the compiler will 
provide only the bits that the compiler has to provide (things like `limits.h`).

The `unreachable` macro is interesting in that it could be provided by either a 
CRT implementation or the compiler. The whole point to the macro is "if the 
expansion is reached, you have undefined behavior", which fits naturally with 
`__builtin_unreachable()` which the backend knows how to do optimizations 
around. However, a CRT implementation could decide the macro expands to `*(int 
*)nullptr` or the likes, which also triggers undefined behavior.

> The same problem also applies today to e.g. `size_t` and anything else 
> provided by the Clang builtin headers. If a platform decides to define 
> `size_t` differently than what the Clang builtin headers define it to, I 
> guess we run into issues? I assume it's not something that happens often 
> because it's pretty unambiguous what these typedefs should be, but still.

If the platform defines `size_t` to be different from the Clang builtin headers 
define it to, there are Serious Problems™ because `sizeof()` suddenly returns 
strange things, interfaces like `printf` will find ABI issues with `%z`, etc.

> Anyway, this might turn out to be nothing more than a documentation issue, 
> but in any case I think it would be valuable to write down how this is 
> intended to work somewhere (even if only in a comment), since I suspect it's 
> not clear to most people. I work on the C++ Standard Library and I don't 
> understand how this works in our own implementation :-)

Definitely agreed that we need to document this, but we need to figure out what 
we want to document in the first place -- some of this is new-ish territory 
because of the additional interfaces. `unreachable` is morally similar to 
`offsetof` in that it's a macro interface where the implementation can give 
better results by expanding to a builtin than a library is likely to be able to 
give via a naive implementation, but the interfaces *can* be provided by a CRT. 
So which one *should* win? Today, if something else defined `offsetof` or 
`unreachable` before including `stddef.h`, Clang's headers won't bother 
re-defining the macro.

I think we may need to look at what existing freestanding CRTs and hosted CRTs 
expect to help give us a path forward?

https://github.com/llvm/llvm-project/pull/86748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Add clang_elementwise_builtin_alias (PR #86175)

2024-03-28 Thread Joshua Batista via cfe-commits 

https://github.com/bob80905 updated 
https://github.com/llvm/llvm-project/pull/86175

>From 5e10b1e42a20a39c9a3d5ff332591713511832c8 Mon Sep 17 00:00:00 2001
From: Joshua Batista 
Date: Wed, 20 Mar 2024 13:24:07 -0700
Subject: [PATCH 1/8] make elemnetwise alias an alias of builtin alias

---
 clang/include/clang/Basic/Attr.td |  9 
 clang/include/clang/Basic/AttrDocs.td | 22 +++
 .../clang/Basic/DiagnosticSemaKinds.td|  3 ++-
 clang/lib/AST/Decl.cpp|  2 ++
 clang/lib/Headers/hlsl/hlsl_intrinsics.h  |  2 ++
 5 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index fd7970d0451acd..160e8ef730ef92 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -759,6 +759,15 @@ def BuiltinAlias : Attr {
   let Documentation = [BuiltinAliasDocs];
 }
 
+def ElementwiseBuiltinAlias : Attr {
+  let Spellings = [CXX11<"clang", "elementwise_builtin_alias">,
+   C23<"clang", "elementwise_builtin_alias">,
+   GNU<"clang_elementwise_builtin_alias">];
+  let Args = [IdentifierArgument<"BuiltinName">];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+  let Documentation = [ElementwiseBuiltinAliasDocs];
+}
+
 def ArmBuiltinAlias : InheritableAttr, TargetSpecificAttr {
   let Spellings = [Clang<"__clang_arm_builtin_alias">];
   let Args = [IdentifierArgument<"BuiltinName">];
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 2c07cd09b0d5b7..7ce83bc881f064 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5462,6 +5462,28 @@ for clang builtin functions.
   }];
 }
 
+def ElementwiseBuiltinAliasDocs : Documentation {
+  let Category = DocCatFunction;
+  let Heading = "clang::elementwise_builtin_alias, 
clang_elementwise_builtin_alias";
+  let Content = [{
+This attribute is used in the implementation of the C intrinsics.
+It allows the C intrinsic functions to be declared using the names defined
+in target builtins, and still be recognized as clang builtins equivalent to the
+underlying name. It also declares that the given C intrinsic can accept 
+vector arguments. For example, ``hlsl_intrinsics.h`` declares the function 
``abs``
+with ``__attribute__((clang_elementwise_builtin_alias(__builtin_abs)))``.
+This ensures that both functions are recognized as that clang builtin,
+and in the latter case, the choice of which builtin to identify the
+function as can be deferred until after overload resolution. It also enables
+the ``abs`` function to take vector arguments.
+
+This attribute can only be used to set up the aliases for certain ARM/RISC-V
+C intrinsic functions; it is intended for use only inside ``arm_*.h`` and
+``riscv_*.h`` and is not a general mechanism for declaring arbitrary aliases
+for clang builtin functions.
+  }];
+}
+
 def PreferredNameDocs : Documentation {
   let Category = DocCatDecl;
   let Content = [{
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c54105507753eb..1252d3804131a6 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -4412,7 +4412,8 @@ def err_attribute_preferred_name_arg_invalid : Error<
   "a specialization of %1">;
 def err_attribute_builtin_alias : Error<
   "%0 attribute can only be applied to a ARM, HLSL or RISC-V builtin">;
-
+def err_attribute_elementwise_builtin_alias : Error<
+  "%0 attribute can only be applied to a ARM, HLSL or RISC-V builtin">;
 // called-once attribute diagnostics.
 def err_called_once_attribute_wrong_type : Error<
   "'called_once' attribute only applies to function-like parameters">;
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 8626f04012f7d4..cb2c5cf6ceaf49 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3598,6 +3598,8 @@ unsigned FunctionDecl::getBuiltinID(bool 
ConsiderWrapperFunctions) const {
 BuiltinID = ABAA->getBuiltinName()->getBuiltinID();
   } else if (const auto *BAA = getAttr()) {
 BuiltinID = BAA->getBuiltinName()->getBuiltinID();
+  } else if (const auto *EBAA = getAttr()) {
+BuiltinID = EBAA->getBuiltinName()->getBuiltinID();
   } else if (const auto *A = getAttr()) {
 BuiltinID = A->getID();
   }
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index 45f8544392584e..b37c4d13b26e62 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -18,6 +18,8 @@ namespace hlsl {
 
 #define _HLSL_BUILTIN_ALIAS(builtin)   
\
   __attribute__((clang_builtin_alias(builtin)))
+#define _HLSL_ELEMENTWISE_BUILTIN_ALIAS(builtin)   
\
+

  1   2   3   4   >