[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

2023-11-09 Thread Tobias Hieta via cfe-commits

tru wrote:

Can this be merged and ready for a backport next week?

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


[clang] [clang-format] Option to ignore PP directives (PR #70338)

2023-11-10 Thread Tobias Hieta via cfe-commits

tru wrote:

@tomekpaszek do you plan to finish this PR? we have been testing it internally 
on our code and would really like this to land in upstream LLVM.

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


[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

2023-11-12 Thread Tobias Hieta via cfe-commits

tru wrote:

17.0.5 is going to be released tomorrow, is this fix good to go for the 
backport?

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


[clang] [clang-cl] Add support for [[msvc::constexpr]] C++11 attribute (PR #71300)

2023-12-06 Thread Tobias Hieta via cfe-commits

tru wrote:

@rnk @amykhuang might be interested in reviewing as well. 

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


[clang-tools-extra] [clang] [llvm] code-format: Improve the code-format-helper to be able to run as a git hook (PR #73957)

2023-12-11 Thread Tobias Hieta via cfe-commits

https://github.com/tru updated https://github.com/llvm/llvm-project/pull/73957

>From 2791b93517fbffec8757ab994246a98b4fd9d727 Mon Sep 17 00:00:00 2001
From: Tobias Hieta 
Date: Mon, 2 Oct 2023 09:42:33 +0200
Subject: [PATCH 1/4] [workflow] Fix abi checker in llvm-tests. Same fix as in
 99fb0af80d16b0ff886f032441392219e1cac452

---
 .github/workflows/llvm-tests.yml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.github/workflows/llvm-tests.yml b/.github/workflows/llvm-tests.yml
index 428235b72fa5ad..cc9855ce182b2b 100644
--- a/.github/workflows/llvm-tests.yml
+++ b/.github/workflows/llvm-tests.yml
@@ -170,14 +170,17 @@ jobs:
 uses: actions/download-artifact@v3
 with:
   name: build-baseline
+  path: build-baseline
   - name: Download latest
 uses: actions/download-artifact@v3
 with:
   name: build-latest
+  path: build-latest
   - name: Download symbol list
 uses: actions/download-artifact@v3
 with:
   name: symbol-list
+  path: symbol-list
 
   - name: Install abi-compliance-checker
 run: sudo apt-get install abi-compliance-checker

>From 1e5407c86845c580864d0b4d998622b5fc04f3cc Mon Sep 17 00:00:00 2001
From: Tobias Hieta 
Date: Thu, 30 Nov 2023 16:50:40 +0100
Subject: [PATCH 2/4] code-format: Improve the code-format-helper to be able to
 run as a git hook

As part of #73798 there was some discussion about using the format
helper to run from a git-hook. That was not possible for a number of
reasons, but with these changes it can now be installed as a hook and
then run on the local cache in git instead of a diff between revisions.

This also checks for two environment variables DARKER_FORMAT_PATH and
CLANG_FORMAT_PATH where you can specify the path to the program you want
to use.
---
 llvm/utils/git/code-format-helper.py | 179 ---
 1 file changed, 134 insertions(+), 45 deletions(-)
 mode change 100644 => 100755 llvm/utils/git/code-format-helper.py

diff --git a/llvm/utils/git/code-format-helper.py 
b/llvm/utils/git/code-format-helper.py
old mode 100644
new mode 100755
index f89f060b3fe5e8..409b8cc790efd4
--- a/llvm/utils/git/code-format-helper.py
+++ b/llvm/utils/git/code-format-helper.py
@@ -14,8 +14,22 @@
 import sys
 from functools import cached_property
 
-import github
-from github import IssueComment, PullRequest
+
+class FormatArgs:
+start_rev: str = None
+end_rev: str = None
+repo: str = None
+changed_files: list[str] = []
+token: str = None
+verbose: bool = True
+
+def __init__(self, args: argparse.Namespace = None) -> None:
+if not args is None:
+self.start_rev = args.start_rev
+self.end_rev = args.end_rev
+self.repo = args.repo
+self.token = args.token
+self.changed_files = args.changed_files
 
 
 class FormatHelper:
@@ -31,9 +45,10 @@ def comment_tag(self) -> str:
 def instructions(self) -> str:
 raise NotImplementedError()
 
-def format_run(
-self, changed_files: list[str], args: argparse.Namespace
-) -> str | None:
+def has_tool(self) -> bool:
+raise NotImplementedError()
+
+def format_run(self, changed_files: list[str], args: FormatArgs) -> str | 
None:
 raise NotImplementedError()
 
 def pr_comment_text_for_diff(self, diff: str) -> str:
@@ -63,17 +78,16 @@ def pr_comment_text_for_diff(self, diff: str) -> str:
 
 """
 
-def find_comment(
-self, pr: PullRequest.PullRequest
-) -> IssueComment.IssueComment | None:
+def find_comment(self, pr: any) -> any:
 for comment in pr.as_issue().get_comments():
 if self.comment_tag in comment.body:
 return comment
 return None
 
-def update_pr(
-self, comment_text: str, args: argparse.Namespace, create_new: bool
-) -> None:
+def update_pr(self, comment_text: str, args: FormatArgs, create_new: bool) 
-> None:
+import github
+from github import IssueComment, PullRequest
+
 repo = github.Github(args.token).get_repo(args.repo)
 pr = repo.get_issue(args.issue_number).as_pull_request()
 
@@ -85,17 +99,25 @@ def update_pr(
 elif create_new:
 pr.as_issue().create_comment(comment_text)
 
-def run(self, changed_files: list[str], args: argparse.Namespace) -> bool:
+def run(self, changed_files: list[str], args: FormatArgs) -> bool:
 diff = self.format_run(changed_files, args)
+should_update_gh = args.token is not None and args.repo is not None
+
 if diff is None:
-comment_text = f"""
-:white_check_mark: With the latest revision this PR passed the 
{self.friendly_name}.
-"""
-self.update_pr(comment_text, args, create_new=False)
+if should_update_gh:
+comment_text = f"""
+:white_check_mark: With the latest revision this PR passed the 
{self.friendly_name}

[clang-tools-extra] [llvm] [clang] code-format: Improve the code-format-helper to be able to run as a git hook (PR #73957)

2023-12-11 Thread Tobias Hieta via cfe-commits

tru wrote:

This should be good now - a last look @boomanaiden154 ?

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


[clang] [clang-format] Fix crashes in AlignArrayOfStructures (PR #72520)

2023-11-17 Thread Tobias Hieta via cfe-commits

tru wrote:

> We probably should backport it to 17.0.6. What do you all think? @tru

Yep - seems like a good and small fix to have in 17.x

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


[clang] [clang-format] Fix crashes in AlignArrayOfStructures (PR #72520)

2023-11-17 Thread Tobias Hieta via cfe-commits

tru wrote:

@owenca I picked da1b1fba5cfd41521a840202d8cf4c3796c5e10b on top of the 17.x 
branch and my test case was not fixed, it still crashes in the same way as 
described in #72628 

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


[clang] [clang-format] Fix crashes in AlignArrayOfStructures (PR #72520)

2023-11-17 Thread Tobias Hieta via cfe-commits

tru wrote:

> Thanks for trying it on 17.x. We can't backport it then.

Any idea if there is another workaround or fix that we could do to target 17.x? 
18 is still pretty far off and clang-format for 17 will soon be included in a 
lot of downstream tools. Happy to help out fixing it if you have any pointers.

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


[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

2023-10-30 Thread Tobias Hieta via cfe-commits

tru wrote:

Thanks for the patch @spavloff - I will make sure to try it today!

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


[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

2023-10-30 Thread Tobias Hieta via cfe-commits

tru wrote:

Our code compiles without warnings with this patch!

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


[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread Tobias Hieta via cfe-commits

tru wrote:

This needs to be cleaned up before it can be merged. There needs to be only one 
commit in this PR without the merge commits from main.

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


[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread Tobias Hieta via cfe-commits

tru wrote:

It also needs tests.

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


[clang] [llvm] test-release.sh: Add a CMake cache file for 3-stage release builds (PR #75903)

2023-12-19 Thread Tobias Hieta via cfe-commits

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


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


[clang] 3f0578d - [clang-cl] Add -emit-ast to clang-cl driver

2022-06-28 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-06-28T09:11:34+02:00
New Revision: 3f0578dd87ee5539eccae507b6a77cfe3354d705

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

LOG: [clang-cl] Add -emit-ast to clang-cl driver

Also make the output of -emit-ast end up where /o points.
The same with .plist files from the static analyzer.

These are changes needed to make it possible to do CTU static
analysing work with clang-cl.

Reviewed By: hans

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/test/Driver/ast.c
clang/test/Driver/cl-outputs.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index d379ec8285103..f4fe08aa1a5b3 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1097,7 +1097,7 @@ def dynamiclib : Flag<["-"], "dynamiclib">;
 def dynamic : Flag<["-"], "dynamic">, Flags<[NoArgumentUnused]>;
 def d_Flag : Flag<["-"], "d">, Group;
 def d_Joined : Joined<["-"], "d">, Group;
-def emit_ast : Flag<["-"], "emit-ast">,
+def emit_ast : Flag<["-"], "emit-ast">, Flags<[CoreOption]>,
   HelpText<"Emit Clang AST files for source inputs">;
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option, FC1Option, 
FlangOption]>, Group,
   HelpText<"Use the LLVM representation for assembler and object files">;

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index c34da3a67a2e0..0da32dae2ef60 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -5661,6 +5661,14 @@ const char *Driver::GetNamedOutputPath(Compilation &C, 
const JobAction &JA,
 }
   } else if (JA.getType() == types::TY_PCH && IsCLMode()) {
 NamedOutput = C.getArgs().MakeArgString(GetClPchPath(C, BaseName));
+  } else if ((JA.getType() == types::TY_Plist || JA.getType() == 
types::TY_AST) &&
+ C.getArgs().hasArg(options::OPT__SLASH_o)) {
+StringRef Val =
+C.getArgs()
+.getLastArg(options::OPT__SLASH_o)
+->getValue();
+NamedOutput =
+MakeCLOutputFilename(C.getArgs(), Val, BaseName, types::TY_Object);
   } else {
 const char *Suffix = types::getTypeTempSuffix(JA.getType(), IsCLMode());
 assert(Suffix && "All types used for output should have a suffix.");

diff  --git a/clang/test/Driver/ast.c b/clang/test/Driver/ast.c
index c1d7b1a6d7b03..7187454bf90e8 100644
--- a/clang/test/Driver/ast.c
+++ b/clang/test/Driver/ast.c
@@ -25,3 +25,15 @@
 // FIXME: There is a problem with compiling AST's in that the input language is
 // not available for use by other tools (for example, to automatically add
 // -lstdc++). We may need -x [objective-]c++-ast and all that goodness. :(
+
+// Also check clang-cl since the driver is slightly 
diff erent
+// RUN: %clang_cl -ccc-print-phases -emit-ast -- %s 2> %t
+// RUN: echo 'END' >> %t
+// RUN: FileCheck -check-prefix EMIT-AST-PHASES-CLANGCL -input-file %t %s
+
+// EMIT-AST-PHASES-CLANGCL: 0: input,
+// EMIT-AST-PHASES-CLANGCL: , c
+// EMIT-AST-PHASES-CLANGCL: 1: preprocessor, {0}, cpp-output
+// EMIT-AST-PHASES-CLANGCL: 2: compiler, {1}, ast
+// EMIT-AST-PHASES-CLANGCL-NOT: 3:
+// EMIT-AST-PHASES-CLANGCL: END

diff  --git a/clang/test/Driver/cl-outputs.c b/clang/test/Driver/cl-outputs.c
index abca67b12e55e..972e4499dbd9c 100644
--- a/clang/test/Driver/cl-outputs.c
+++ b/clang/test/Driver/cl-outputs.c
@@ -82,6 +82,11 @@
 // RUN: %clang_cl /c /o mydir/ -### -- %s %s 2>&1 | FileCheck 
-check-prefix=CHECK-oMULTIPLESOURCEOK2 %s
 // CHECK-oMULTIPLESOURCEOK2: "-o" "mydir{{[/\\]+}}cl-outputs.obj"
 
+// RUN: %clang_cl -emit-ast /otest.ast -###  -- %s  2>&1 | FileCheck 
-check-prefix=oASTNAME %s
+// oASTNAME:  "-o" "test.ast"
+
+// RUN: %clang_cl --analyze /otest.plist -###  -- %s  2>&1 | FileCheck 
-check-prefix=oPLIST %s
+// oPLIST:  "-o" "test.plist"
 
 // RUN: %clang_cl /c /obar /Fofoo -### -- %s 2>&1 | FileCheck 
-check-prefix=FooRACE1 %s
 // FooRACE1: "-o" "foo.obj"



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


[clang] e6ff553 - [clang-extdef-mapping] Directly process .ast files

2022-07-05 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-07-05T13:45:52+02:00
New Revision: e6ff553979e850eeb7f0bbe77deab1c88fc764b3

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

LOG: [clang-extdef-mapping] Directly process .ast files

When doing CTU analysis setup you pre-compile .cpp to .ast and then
you run clang-extdef-mapping on the .cpp file as well. This is a
pretty slow process since we have to recompile the file each time.

With this patch you can now run clang-extdef-mapping directly on
the .ast file. That saves a lot of time.

I tried this on llvm/lib/AsmParser/Parser.cpp and running
extdef-mapping on the .cpp file took 5.4s on my machine.

While running it on the .ast file it took 2s.

This can save a lot of time for the setup phase of CTU analysis.

Reviewed By: martong

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/test/Analysis/func-mapping-test.cpp
clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f074d1bf204f..1be63b539441 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -587,6 +587,13 @@ clang-format
 - Option ``InsertBraces`` has been added to insert optional braces after 
control
   statements.
 
+clang-extdef-mapping
+
+
+- clang-extdef-mapping now accepts .ast files as input. This is faster than to
+  recompile the files from sources when extracting method definitons. This can
+  be really beneficial when creating .ast files for input to the 
clang-static-analyzer.
+
 libclang
 
 

diff  --git a/clang/test/Analysis/func-mapping-test.cpp 
b/clang/test/Analysis/func-mapping-test.cpp
index a56c0075db1a..e5d242d67758 100644
--- a/clang/test/Analysis/func-mapping-test.cpp
+++ b/clang/test/Analysis/func-mapping-test.cpp
@@ -1,4 +1,6 @@
 // RUN: %clang_extdef_map %s -- | FileCheck --implicit-check-not "c:@y" 
--implicit-check-not "c:@z" %s
+// RUN: %clang -emit-ast %s -o %t.ast
+// RUN: %clang_extdef_map %t.ast -- | FileCheck --implicit-check-not "c:@y" 
--implicit-check-not "c:@z" %s
 
 int f(int) {
   return 0;

diff  --git a/clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp 
b/clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp
index bc8d2581c1b9..ebeef5dce1eb 100644
--- a/clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp
+++ b/clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp
@@ -1,4 +1,4 @@
-//===- ClangExtDefMapGen.cpp 
---===//
+//===- ClangExtDefMapGen.cpp -===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -13,10 +13,12 @@
 
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/CrossTU/CrossTranslationUnit.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendActions.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/Support/CommandLine.h"
@@ -29,12 +31,16 @@ using namespace clang;
 using namespace clang::cross_tu;
 using namespace clang::tooling;
 
-static cl::OptionCategory ClangExtDefMapGenCategory("clang-extdefmapgen 
options");
+static cl::OptionCategory
+ClangExtDefMapGenCategory("clang-extdefmapgen options");
 
 class MapExtDefNamesConsumer : public ASTConsumer {
 public:
-  MapExtDefNamesConsumer(ASTContext &Context)
-  : Ctx(Context), SM(Context.getSourceManager()) {}
+  MapExtDefNamesConsumer(ASTContext &Context,
+ StringRef astFilePath = StringRef())
+  : Ctx(Context), SM(Context.getSourceManager()) {
+CurrentFileName = astFilePath.str();
+  }
 
   ~MapExtDefNamesConsumer() {
 // Flush results to standard output.
@@ -111,6 +117,82 @@ class MapExtDefNamesAction : public ASTFrontendAction {
 
 static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);
 
+static IntrusiveRefCntPtr Diags;
+
+IntrusiveRefCntPtr GetDiagnosticsEngine() {
+  if (Diags) {
+// Call reset to make sure we don't mix errors
+Diags->Reset(false);
+return Diags;
+  }
+
+  IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
+  TextDiagnosticPrinter *DiagClient =
+  new TextDiagnosticPrinter(llvm::errs(), &*DiagOpts);
+  DiagClient->setPrefix("clang-extdef-mappping");
+  IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+
+  IntrusiveRefCntPtr DiagEngine(
+  new DiagnosticsEngine(DiagID, &*DiagOpts, DiagClient));
+  Diags.swap(DiagEngine);
+
+  // 

[clang] 67d9276 - [clang-cl] Ignore /Wv and /Wv:17 flags

2022-03-24 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-03-24T09:42:34+01:00
New Revision: 67d9276b16024bae66dfc2fcb739d947637b8c52

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

LOG: [clang-cl] Ignore /Wv and /Wv:17 flags

MSVC supports passing /Wv and /Wv:17 to ignore warnings added
since that version. Clang doesn't have a option like this - but
we can ignore this flag instead of error.

MSVC documentation: 
https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level

Reviewed By: hans, mstorsjo

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/test/Driver/cl-options.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index b5bd2d6c3e1bd..114b230b39e8f 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -6530,6 +6530,7 @@ def _SLASH_sdl_ : CLIgnoredFlag<"sdl-">;
 def _SLASH_utf8 : CLIgnoredFlag<"utf-8">,
   HelpText<"Set source and runtime encoding to UTF-8 (default)">;
 def _SLASH_w : CLIgnoredJoined<"w">;
+def _SLASH_Wv_ : CLIgnoredJoined<"Wv">;
 def _SLASH_Zc___cplusplus : CLIgnoredFlag<"Zc:__cplusplus">;
 def _SLASH_Zc_auto : CLIgnoredFlag<"Zc:auto">;
 def _SLASH_Zc_forScope : CLIgnoredFlag<"Zc:forScope">;

diff  --git a/clang/test/Driver/cl-options.c b/clang/test/Driver/cl-options.c
index f332cd83b26e4..244b4430dd0dc 100644
--- a/clang/test/Driver/cl-options.c
+++ b/clang/test/Driver/cl-options.c
@@ -396,6 +396,8 @@
 // RUN:/volatile:iso \
 // RUN:/w12345 \
 // RUN:/wd1234 \
+// RUN:/Wv \
+// RUN:/Wv:17 \
 // RUN:/Zc:__cplusplus \
 // RUN:/Zc:auto \
 // RUN:/Zc:forScope \



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


[clang] 09c0685 - [NFC] Remove trailing whitespaces in clang/Driver/Options.td

2022-03-23 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-03-23T10:23:33+01:00
New Revision: 09c0685a043dd4028545c134b562c2605e294855

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

LOG: [NFC] Remove trailing whitespaces in clang/Driver/Options.td

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 2a23695c149fa..c56578b34641a 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2493,12 +2493,12 @@ def fno_openmp_assume_teams_oversubscription : 
Flag<["-"], "fno-openmp-assume-te
   Group, Flags<[CC1Option, NoArgumentUnused, HelpHidden]>;
 def fno_openmp_assume_threads_oversubscription : Flag<["-"], 
"fno-openmp-assume-threads-oversubscription">,
   Group, Flags<[CC1Option, NoArgumentUnused, HelpHidden]>;
-def fopenmp_assume_no_thread_state : Flag<["-"], 
"fopenmp-assume-no-thread-state">, Group, 
-  Flags<[CC1Option, NoArgumentUnused, HelpHidden]>, 
+def fopenmp_assume_no_thread_state : Flag<["-"], 
"fopenmp-assume-no-thread-state">, Group,
+  Flags<[CC1Option, NoArgumentUnused, HelpHidden]>,
   HelpText<"Assert no thread in a parallel region modifies an ICV">,
   MarshallingInfoFlag>;
-def fopenmp_offload_mandatory : Flag<["-"], "fopenmp-offload-mandatory">, 
Group, 
-  Flags<[CC1Option, NoArgumentUnused]>, 
+def fopenmp_offload_mandatory : Flag<["-"], "fopenmp-offload-mandatory">, 
Group,
+  Flags<[CC1Option, NoArgumentUnused]>,
   HelpText<"Do not create a host fallback if offloading to the device fails.">,
   MarshallingInfoFlag>;
 defm openmp_target_new_runtime: BoolFOption<"openmp-target-new-runtime",



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


[clang] 749fb33 - [clang-format] Don't break lines after pragma region

2022-05-20 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-05-20T16:11:20+02:00
New Revision: 749fb33e82ff19d656af9c9205f3ac81c1ce52d8

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

LOG: [clang-format] Don't break lines after pragma region

We have autogenerated pragma regions in our code
which where awkwardly broken up like this:

```
#pragma region foo(bar : hello)
```
becomes

```
#pragma region foo(bar \
   : hello)
```

This fixes the problem by adding region as a keyword
and handling it the same way as pragma mark

Reviewed By: curdeius

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

Added: 


Modified: 
clang/lib/Format/FormatToken.h
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatToken.h b/clang/lib/Format/FormatToken.h
index 9990933fcb20..71acdf2f094b 100644
--- a/clang/lib/Format/FormatToken.h
+++ b/clang/lib/Format/FormatToken.h
@@ -930,6 +930,7 @@ struct AdditionalKeywords {
 kw___has_include_next = &IdentTable.get("__has_include_next");
 
 kw_mark = &IdentTable.get("mark");
+kw_region = &IdentTable.get("region");
 
 kw_extend = &IdentTable.get("extend");
 kw_option = &IdentTable.get("option");
@@ -1053,6 +1054,7 @@ struct AdditionalKeywords {
 
   // Pragma keywords.
   IdentifierInfo *kw_mark;
+  IdentifierInfo *kw_region;
 
   // Proto keywords.
   IdentifierInfo *kw_extend;

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 68f35643bbf2..9afe4f8fb086 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -1251,9 +1251,9 @@ class AnnotatingParser {
   void parsePragma() {
 next(); // Consume "pragma".
 if (CurrentToken &&
-CurrentToken->isOneOf(Keywords.kw_mark, Keywords.kw_option)) {
+CurrentToken->isOneOf(Keywords.kw_mark, Keywords.kw_option, 
Keywords.kw_region)) {
   bool IsMark = CurrentToken->is(Keywords.kw_mark);
-  next(); // Consume "mark".
+  next();
   next(); // Consume first token (so we fix leading whitespace).
   while (CurrentToken) {
 if (IsMark || CurrentToken->Previous->is(TT_BinaryOperator))

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index e54a6db2ca46..762ccf7dbd8d 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -19597,6 +19597,13 @@ TEST_F(FormatTest, UnderstandPragmaOption) {
   EXPECT_EQ("#pragma option -C -A", format("#pragmaoption   -C   -A"));
 }
 
+TEST_F(FormatTest, UnderstandPragmaRegion) {
+  auto Style = getLLVMStyleWithColumns(0);
+  verifyFormat("#pragma region TEST(FOO : BAR)", Style);
+
+  EXPECT_EQ("#pragma region TEST(FOO : BAR)", format("#pragma region TEST(FOO 
: BAR)", Style));
+}
+
 TEST_F(FormatTest, OptimizeBreakPenaltyVsExcess) {
   FormatStyle Style = getLLVMStyleWithColumns(20);
 



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


[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-03-25 Thread Tobias Hieta via cfe-commits

tru wrote:

> I think .natvis files should be CRLF (those are used with Visual Studio for 
> debug visualizers).

Agreed, Visual Studio should handle this correctly, but who knows 🤷🏼 

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


[clang] [llvm] Update documentation and release notes for llvm-profgen COFF support (PR #84864)

2024-03-12 Thread Tobias Hieta via cfe-commits

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


[clang] [llvm] Update documentation and release notes for llvm-profgen COFF support (PR #84864)

2024-03-12 Thread Tobias Hieta via cfe-commits

https://github.com/tru commented:

Thanks for working on documentation!

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


[clang] [llvm] Update documentation and release notes for llvm-profgen COFF support (PR #84864)

2024-03-12 Thread Tobias Hieta via cfe-commits


@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for 
optimization:
 
 1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
-   requirement is that you add ``-gline-tables-only`` or ``-g`` to the
-   command line. This is important for the profiler to be able to map
-   instructions back to source line locations.
+   requirement is that DWARF debug info including source line information is
+   generated. This DWARF information is important for the profiler to be able
+   to map instructions back to source line locations.
+
+   On Linux, ``-g`` or just ``-gline-tables-only`` is sufficient:
 
.. code-block:: console
 
  $ clang++ -O2 -gline-tables-only code.cc -o code
 
+   It is also possible to include DWARF in Windows binaries:

tru wrote:

Maybe this should be worded that while codeview is the standard on Windows, you 
can use DWARF instead.

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


[clang] [llvm] Update documentation and release notes for llvm-profgen COFF support (PR #84864)

2024-03-12 Thread Tobias Hieta via cfe-commits


@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for 
optimization:
 
 1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
-   requirement is that you add ``-gline-tables-only`` or ``-g`` to the
-   command line. This is important for the profiler to be able to map
-   instructions back to source line locations.
+   requirement is that DWARF debug info including source line information is
+   generated. This DWARF information is important for the profiler to be able
+   to map instructions back to source line locations.
+
+   On Linux, ``-g`` or just ``-gline-tables-only`` is sufficient:
 
.. code-block:: console
 
  $ clang++ -O2 -gline-tables-only code.cc -o code
 
+   It is also possible to include DWARF in Windows binaries:
+
+   .. code-block:: console
+
+ $ clang-cl -O2 -gdwarf -gline-tables-only coff-profile.cpp -fuse-ld=lld 
-link -debug:dwarf
+
 2. Run the executable under a sampling profiler. The specific profiler
you use does not really matter, as long as its output can be converted
-   into the format that the LLVM optimizer understands. Currently, there
-   exists a conversion tool for the Linux Perf profiler
-   (https://perf.wiki.kernel.org/), so these examples assume that you
-   are using Linux Perf to profile your code.
+   into the format that the LLVM optimizer understands.
+
+   Two such profilers are the the Linux Perf profiler
+   (https://perf.wiki.kernel.org/) and Intel's Sampling Enabling Product (SEP),

tru wrote:

I think we can make it clear that perf is only on Linux while SEP is Linux and 
Windows.

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


[clang] [llvm] Update documentation and release notes for llvm-profgen COFF support (PR #84864)

2024-03-12 Thread Tobias Hieta via cfe-commits


@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for 
optimization:
 
 1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
-   requirement is that you add ``-gline-tables-only`` or ``-g`` to the
-   command line. This is important for the profiler to be able to map
-   instructions back to source line locations.
+   requirement is that DWARF debug info including source line information is
+   generated. This DWARF information is important for the profiler to be able
+   to map instructions back to source line locations.
+
+   On Linux, ``-g`` or just ``-gline-tables-only`` is sufficient:
 
.. code-block:: console
 
  $ clang++ -O2 -gline-tables-only code.cc -o code
 
+   It is also possible to include DWARF in Windows binaries:
+
+   .. code-block:: console
+
+ $ clang-cl -O2 -gdwarf -gline-tables-only coff-profile.cpp -fuse-ld=lld 
-link -debug:dwarf
+
 2. Run the executable under a sampling profiler. The specific profiler
you use does not really matter, as long as its output can be converted
-   into the format that the LLVM optimizer understands. Currently, there
-   exists a conversion tool for the Linux Perf profiler
-   (https://perf.wiki.kernel.org/), so these examples assume that you
-   are using Linux Perf to profile your code.
+   into the format that the LLVM optimizer understands.
+
+   Two such profilers are the the Linux Perf profiler
+   (https://perf.wiki.kernel.org/) and Intel's Sampling Enabling Product (SEP),
+   available as part of `Intel VTune
+   
`_.
+
+   The LLVM tool ``llvm-profgen`` can convert output of either Perf or SEP. An
+   external tool, AutoFDO, also supports Linux Perf output.

tru wrote:

maybe link to AutoFDO or explain what it's used for here?

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


[clang] [Driver] Improve error when a compiler-rt library is not found (PR #81037)

2024-02-26 Thread Tobias Hieta via cfe-commits

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

This seems good to me, it worked in my internal test as I expected it!

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


[llvm] [lld] [clang] Embed the command line arguments during LTO (PR #79390)

2024-01-24 Thread Tobias Hieta via cfe-commits

tru wrote:

I haven't checked closely yet, but it seems like you need to add tests. 

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


[clang-tools-extra] [llvm] [clang] workflows: Refactor release-tasks.yml (PR #69523)

2024-01-15 Thread Tobias Hieta via cfe-commits


@@ -0,0 +1,74 @@
+name: Release Lit
+
+permissions:
+  contents: read
+
+on:
+  workflow_dispatch:
+inputs:
+  release-version:
+description: 'Release Version'
+required: true
+type: string
+
+  workflow_call:
+inputs:
+  release-version:
+description: 'Release Version'
+required: true
+type: string
+
+jobs:
+  release-lit:
+name: Release Lit
+runs-on: ubuntu-latest
+steps:
+  - name: Checkout LLVM
+uses: actions/checkout@v4
+with:
+  ref: "llvmorg-${{ inputs.release-version }}"
+
+  - name: Install dependencies
+run: |
+  sudo apt-get update
+  sudo apt-get install -y python3-setuptools python3-psutil 
python3-github
+
+  - name: Check Permissions
+env:
+  GITHUB_TOKEN: ${{ github.token }}
+run: |
+  ./llvm/utils/release/./github-upload-release.py --token 
"$GITHUB_TOKEN" --user ${{ github.actor }} check-permissions
+
+  - name: Setup Cpp
+uses: aminya/setup-cpp@v1
+with:
+  compiler: llvm-16.0.6

tru wrote:

I think it needs FileCheck.

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


[clang-tools-extra] [llvm] [clang] workflows: Refactor release-tasks.yml (PR #69523)

2024-01-15 Thread Tobias Hieta via cfe-commits


@@ -10,112 +10,70 @@ on:
   - 'llvmorg-*'
 
 jobs:
-  release-tasks:
-permissions:
-  contents: write # To upload assets to release.
+  validate-tag:
+name: Validate Tag
 runs-on: ubuntu-latest
 if: github.repository == 'llvm/llvm-project'
+outputs:
+  release-version: ${{ steps.validate-tag.outputs.release-version }}
 steps:
   - name: Validate Tag
 id: validate-tag
 run: |
-  test "${{ github.actor }}" = "tstellar" || test "${{ github.actor 
}}" = "tru"
   echo "${{ github.ref_name }}" | grep -e 
'^llvmorg-[0-9]\+\.[0-9]\+\.[0-9]\+\(-rc[0-9]\+\)\?$'
   release_version=$(echo "${{ github.ref_name }}" | sed 
's/llvmorg-//g')
   echo "release-version=$release_version" >> "$GITHUB_OUTPUT"
 
-  - name: Checkout LLVM
-uses: actions/checkout@v4
-
+  release-create:
+name: Create a New Release
+runs-on: ubuntu-latest
+needs: validate-tag
+steps:
   - name: Install Dependencies
 run: |
   sudo apt-get update
-  sudo apt-get install -y \
-  doxygen \
-  graphviz \
-  python3-github \
-  ninja-build \
-  texlive-font-utils
-  pip3 install --user -r ./llvm/docs/requirements.txt
-
-  - name: Create Release
-run: |
-  ./llvm/utils/release/./github-upload-release.py --token ${{ 
github.token }} --release ${{ steps.validate-tag.outputs.release-version }} 
create
-
-  - name: Build Documentation
-run: |
-  ./llvm/utils/release/build-docs.sh -release ${{ 
steps.validate-tag.outputs.release-version }}
-  ./llvm/utils/release/github-upload-release.py --token ${{ 
github.token }} --release ${{ steps.validate-tag.outputs.release-version }} 
upload --files ./*doxygen*.tar.xz
-
-  - name: Create Release Notes Artifact
-uses: actions/upload-artifact@v3
-with:
-  name: release-notes
-  path: docs-build/html-export/
-
-  - name: Clone www-releases
-if: ${{ !contains(steps.validate-tag.outputs.release-version, 'rc') }}
-uses: actions/checkout@v4
-with:
-  repository: ${{ github.repository_owner }}/www-releases
-  ref: main
-  fetch-depth: 0
-  path: www-releases
-
-  - name: Upload Release Notes
-if: ${{ !contains(steps.validate-tag.outputs.release-version, 'rc') }}
-run: |
-  mkdir -p ../www-releases/${{ 
steps.validate-tag.outputs.release-version }}
-  mv ./docs-build/html-export/* ../www-releases/${{ 
steps.validate-tag.outputs.release-version }}
-  cd ../www-releases
-  git add ${{ steps.validate-tag.outputs.release-version }}
-  git config user.email "llvm...@llvm.org"
-  git config user.name "llvmbot"
-  git commit -a -m "Add ${{ steps.validate-tag.outputs.release-version 
}} documentation"
-  git push https://${{ secrets.WWW_RELEASES_TOKEN }}@github.com/${{ 
github.repository_owner }}/www-releases main:main
+  sudo apt-get install python3-github

tru wrote:

Yeah I was thinking about that, actually in general in this file. Shouldn't we 
try to hashpin all the dependencies since we have started to do that in other 
workflows?

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


[clang] [clang-format] Option to ignore macro definitions (PR #70338)

2024-01-18 Thread Tobias Hieta via cfe-commits

tru wrote:

@tomekpaszek Hi Tomek, do you think you will have time to work on this soon? 
Otherwise, I can probably finish it off for you since we also want this feature.

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


[clang] [clang-format] Option to ignore macro definitions (PR #70338)

2024-01-18 Thread Tobias Hieta via cfe-commits

tru wrote:

@owenca What's the things that still needs to be addressed for this to land?

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


[clang] [clang-format] Add SkipMacroDefinitionBody option (PR #78682)

2024-01-20 Thread Tobias Hieta via cfe-commits

tru wrote:

Thanks @owenca !

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


[clang] [llvm] [CMake][Release] Add option for enabling PGO to release cache file. (PR #78823)

2024-01-20 Thread Tobias Hieta via cfe-commits

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


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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-10-20 Thread Tobias Hieta via cfe-commits

tru wrote:

Yep. Want me to do it or do you have access now?

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


[clang] [clang-format]: Split alignment of declarations around assignment (PR #69340)

2023-10-27 Thread Tobias Hieta via cfe-commits

tru wrote:

@gedare can you fix the merge conflict on this one?

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


[clang] fd1d93d - [clang-format] Mark pragma region lines as StringLiterals

2022-10-25 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-10-25T09:59:39+02:00
New Revision: fd1d93db71066bedc11944bd32f3540b8084b060

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

LOG: [clang-format] Mark pragma region lines as StringLiterals

In our code-base we auto-generate pragma regions the regions
look like method signatures like:

`#pragma region MYREGION(Foo: bar)`

The problem here was that the rest of the line after region
was not marked as stringliteral as in the case of pragma mark
so clang-format tried to change the formatting based on the
method signature.

Added test and mark it similar as pragma mark.

Reviewed By: owenpan

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

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index f226e8ffa61c1..fba1a125dc57e 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -1337,14 +1337,15 @@ class AnnotatingParser {
 if (CurrentToken &&
 CurrentToken->isOneOf(Keywords.kw_mark, Keywords.kw_option,
   Keywords.kw_region)) {
-  bool IsMark = CurrentToken->is(Keywords.kw_mark);
+  bool IsMarkOrRegion =
+  CurrentToken->isOneOf(Keywords.kw_mark, Keywords.kw_region);
   next();
   next(); // Consume first token (so we fix leading whitespace).
   while (CurrentToken) {
-if (IsMark || CurrentToken->Previous->is(TT_BinaryOperator))
+if (IsMarkOrRegion || CurrentToken->Previous->is(TT_BinaryOperator)) {
   CurrentToken->setType(TT_ImplicitStringLiteral);
 next();
-  }
+}
 }
   }
 

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index d7aca687ab40d..00803cd3a230f 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -19965,9 +19965,7 @@ TEST_F(FormatTest, UnderstandPragmaOption) {
 TEST_F(FormatTest, UnderstandPragmaRegion) {
   auto Style = getLLVMStyleWithColumns(0);
   verifyFormat("#pragma region TEST(FOO : BAR)", Style);
-
-  EXPECT_EQ("#pragma region TEST(FOO : BAR)",
-format("#pragma region TEST(FOO : BAR)", Style));
+  verifyFormat("#pragma region TEST(FOO: NOSPACE)", Style);
 }
 
 TEST_F(FormatTest, OptimizeBreakPenaltyVsExcess) {

diff  --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index 14918c7e6ff96..999feca0913d6 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -649,6 +649,22 @@ TEST_F(TokenAnnotatorTest, UnderstandsRequiresExpressions) 
{
   EXPECT_TOKEN(Tokens[14], tok::l_brace, TT_RequiresExpressionLBrace);
 }
 
+TEST_F(TokenAnnotatorTest, UnderstandsPragmaRegion) {
+  // Everything after #pragma region should be ImplicitStringLiteral
+  auto Tokens = annotate("#pragma region Foo(Bar: Hello)");
+  ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[5], tok::identifier, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[6], tok::colon, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[7], tok::identifier, TT_ImplicitStringLiteral);
+
+  // Make sure it's annotated correctly inside a function as well
+  Tokens = annotate("void test(){\n#pragma region Foo(Bar: Hello)\n}");
+  ASSERT_EQ(Tokens.size(), 16u) << Tokens;
+  EXPECT_TOKEN(Tokens[10], tok::identifier, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[11], tok::colon, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[12], tok::identifier, TT_ImplicitStringLiteral);
+}
+
 TEST_F(TokenAnnotatorTest, RequiresDoesNotChangeParsingOfTheRest) {
   const char *BaseCode = nullptr;
   const char *ConstrainedCode = nullptr;



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


[clang] 885dadf - [NFC] Fix merge mistake in TokenAnnotator.cpp

2022-10-25 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-10-25T10:08:51+02:00
New Revision: 885dadf648fc5b174e21175f726917e1528df218

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

LOG: [NFC] Fix merge mistake in TokenAnnotator.cpp

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index fba1a125dc57..0b613c95110f 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -1346,6 +1346,7 @@ class AnnotatingParser {
   CurrentToken->setType(TT_ImplicitStringLiteral);
 next();
 }
+  }
 }
   }
 



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


[clang] 0f28d48 - SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

2022-08-24 Thread Tobias Hieta via cfe-commits

Author: H. Vetinari
Date: 2022-08-25T08:36:01+02:00
New Revision: 0f28d4856630f8b5c6708069b4e35d7345838d6b

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

LOG: SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

This reverts commit bc39d7bdd4977a953b2e102f8f7eb479ad78984e.

rename CLANG_SONAME to LIBCLANG_SOVERSION

[clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

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

Added: 
clang/tools/libclang/libclang.map
clang/tools/libclang/linker-script-to-export-list.py

Modified: 
clang/CMakeLists.txt
clang/docs/ReleaseNotes.rst
clang/tools/libclang/CMakeLists.txt

Removed: 
clang/tools/libclang/libclang.exports



diff  --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 332df8f3b8bf5..2b1e968da3960 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -463,6 +463,12 @@ if(CLANG_ENABLE_ARCMT)
   set(CLANG_ENABLE_OBJC_REWRITER ON)
 endif()
 
+# This option is a stop-gap, we should commit to removing this as
+# soon as possible. See discussion:
+# 
https://discourse.llvm.org/t/rationale-for-removing-versioned-libclang-middle-ground-to-keep-it-behind-option/
+option(CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION
+  "Force the SOVERSION of libclang to be equal to CLANG_MAJOR" ON)
+
 # Clang version information
 set(CLANG_EXECUTABLE_VERSION
 "${CLANG_VERSION_MAJOR}" CACHE STRING

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 46339ff9ce8d1..d40f56f3f3891 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -235,6 +235,8 @@ clang-extdef-mapping
 libclang
 
 
+- ...
+
 Static Analyzer
 ---
 

diff  --git a/clang/tools/libclang/CMakeLists.txt 
b/clang/tools/libclang/CMakeLists.txt
index 8d95d0900e8c4..9a874ae6f85dc 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -1,3 +1,21 @@
+# The SOVERSION should be updated only if a change is made to the libclang
+# ABI, and when it is updated, it should be updated to the current
+# LLVM_VERSION_MAJOR.
+# Please also see clang/tools/libclang/libclang.map
+
+if(NOT CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION)
+  # default is to use the SOVERSION according to ABI...
+  set(LIBCLANG_SOVERSION 13)
+else()
+  # ... unless explicily overridden
+  set(LIBCLANG_SOVERSION ${CLANG_VERSION_MAJOR})
+endif()
+
+# TODO: harmonize usage of LIBCLANG_SOVERSION / LIBCLANG_LIBARY_VERSION
+#   below; this was added under time-pressure to avoid reverting the
+#   better default from LLVM 14 for LLVM 15.0.0-rc3, hence no time
+#   to clean up previous inconsistencies.
+
 set(SOURCES
   ARCMigrate.cpp
   BuildSystem.cpp
@@ -64,7 +82,8 @@ endif ()
 option(LIBCLANG_BUILD_STATIC
   "Build libclang as a static library (in addition to a shared one)" OFF)
 
-set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/libclang.exports)
+set(LLVM_EXPORTED_SYMBOL_FILE 
${CMAKE_CURRENT_BINARY_DIR}/libclang-generic.exports)
+set(LIBCLANG_VERSION_SCRIPT_FILE ${CMAKE_CURRENT_SOURCE_DIR}/libclang.map)
 
 if(MSVC)
   # Avoid LNK4197 by not specifying libclang.exports here.
@@ -73,6 +92,20 @@ if(MSVC)
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
+if (UNIX AND NOT APPLE)
+  set(LLVM_EXPORTED_SYMBOL_FILE)
+  set(USE_VERSION_SCRIPT ${LLVM_HAVE_LINK_VERSION_SCRIPT})
+endif()
+
+if (LLVM_EXPORTED_SYMBOL_FILE)
+  add_custom_command(OUTPUT ${LLVM_EXPORTED_SYMBOL_FILE}
+ COMMAND "${Python3_EXECUTABLE}"
+   ARGS 
${CMAKE_CURRENT_SOURCE_DIR}/linker-script-to-export-list.py
+${LIBCLANG_VERSION_SCRIPT_FILE}
+${LLVM_EXPORTED_SYMBOL_FILE}
+ DEPENDS ${LIBCLANG_VERSION_SCRIPT_FILE})
+endif()
+
 if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
   set(ENABLE_SHARED SHARED)
 endif()
@@ -145,6 +178,21 @@ if(ENABLE_SHARED)
 )
 endif()
   endif()
+  if (USE_VERSION_SCRIPT)
+target_link_options(libclang PRIVATE 
"-Wl,--version-script,${CMAKE_CURRENT_SOURCE_DIR}/libclang.map")
+# The Solaris 11.4 linker supports a subset of GNU ld version scripts,
+# but requires a special option to enable it.
+if (${CMAKE_SYSTEM_NAME} MATCHES "SunOS")
+  target_link_options(libclang PRIVATE "-Wl,-z,gnu-version-script-compat")
+endif()
+# Ensure that libclang.so gets rebuilt when the linker script changes.
+set_property(SOURCE ARCMigrate.cpp APPEND PROPERTY
+ OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/libclang.map)
+
+set_target_properties(libclang PROPERTIES
+  VERSION 
${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}
+   

[clang] 5218a54 - [NFC] Fix a misleading comment CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

2022-08-25 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-08-25T09:56:55+02:00
New Revision: 5218a542ac09ea97f78681f4f1b90a3b835c

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

LOG: [NFC] Fix a misleading comment CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

Added: 


Modified: 
clang/tools/libclang/CMakeLists.txt

Removed: 




diff  --git a/clang/tools/libclang/CMakeLists.txt 
b/clang/tools/libclang/CMakeLists.txt
index 9a874ae6f85dc..c6b3b44a76334 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -3,11 +3,15 @@
 # LLVM_VERSION_MAJOR.
 # Please also see clang/tools/libclang/libclang.map
 
+# This option defaults to CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION
+# to ON - which means that it by default matches CLANG_VERSION_MAJOR
+#
+# TODO: This should probably not be a option going forward but we
+# we should commit to a way to do it. But due to getting this out
+# in LLVM 15.x we opted for a option.
 if(NOT CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION)
-  # default is to use the SOVERSION according to ABI...
   set(LIBCLANG_SOVERSION 13)
 else()
-  # ... unless explicily overridden
   set(LIBCLANG_SOVERSION ${CLANG_VERSION_MAJOR})
 endif()
 



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


[clang] 70de684 - [clang-format] Handle object instansiation in if-statements

2022-11-06 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-11-07T08:34:57+01:00
New Revision: 70de684d44135b4025d92b2b36ad387cf5ab8b5a

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

LOG: [clang-format] Handle object instansiation in if-statements

Before this patch code like this:

```
if (Class* obj{getObject()}) { }
```

would be mis-formated since the * would be annotated as a
binaryoperator.

This patch changes the * to become a PointerOrReference instead
and fixes the formatting issues.

Reviewed By: HazardyKnusperkeks

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

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 3d76cc171b0dc..dbfe88c531322 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -362,7 +362,8 @@ class AnnotatingParser {
   FormatToken *Next = CurrentToken->Next;
   if (PrevPrev && PrevPrev->is(tok::identifier) &&
   Prev->isOneOf(tok::star, tok::amp, tok::ampamp) &&
-  CurrentToken->is(tok::identifier) && Next->isNot(tok::equal)) {
+  CurrentToken->is(tok::identifier) &&
+  !Next->isOneOf(tok::equal, tok::l_brace)) {
 Prev->setType(TT_BinaryOperator);
 LookForDecls = false;
   }
@@ -2387,6 +2388,12 @@ class AnnotatingParser {
   return TT_PointerOrReference;
 }
 
+// if (Class* obj { function() })
+if (PrevToken->Tok.isAnyIdentifier() && NextToken->Tok.isAnyIdentifier() &&
+NextToken->Next && NextToken->Next->is(tok::l_brace)) {
+  return TT_PointerOrReference;
+}
+
 if (PrevToken->endsSequence(tok::r_square, tok::l_square, tok::kw_delete))
   return TT_UnaryOperator;
 

diff  --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index fa95f6845f077..65ecb12c46cd7 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -145,6 +145,18 @@ TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmp) {
   EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_FunctionTypeLParen);
   EXPECT_TOKEN(Tokens[7], tok::star, TT_UnaryOperator);
   EXPECT_TOKEN(Tokens[12], tok::star, TT_PointerOrReference);
+
+  Tokens = annotate("if (Foo * Bar / Test)");
+  ASSERT_EQ(Tokens.size(), 9u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_BinaryOperator);
+
+  Tokens = annotate("if (Class* obj {getObj()})");
+  ASSERT_EQ(Tokens.size(), 12u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+
+  Tokens = annotate("if (Foo* Bar = getObj())");
+  ASSERT_EQ(Tokens.size(), 11u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsUsesOfPlusAndMinus) {



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


[clang] aa99b60 - [clang][pdb] Don't include -fmessage-length in PDB buildinfo

2022-11-08 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-11-08T10:05:59+01:00
New Revision: aa99b607b5cf8ef1260f5661dcbf077f26ee797c

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

LOG: [clang][pdb] Don't include -fmessage-length in PDB buildinfo

As discussed in https://reviews.llvm.org/D136474 -fmessage-length
creates problems with reproduciability in the PDB files.

This patch just drops that argument when writing the PDB file.

Reviewed By: hans

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

Added: 


Modified: 
clang/test/CodeGen/debug-info-codeview-buildinfo.c
llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

Removed: 




diff  --git a/clang/test/CodeGen/debug-info-codeview-buildinfo.c 
b/clang/test/CodeGen/debug-info-codeview-buildinfo.c
index 71c0e7b6f6ac2..e1c6f3655f379 100644
--- a/clang/test/CodeGen/debug-info-codeview-buildinfo.c
+++ b/clang/test/CodeGen/debug-info-codeview-buildinfo.c
@@ -8,6 +8,10 @@
 // RUN: %clang_cl -gno-codeview-command-line --target=i686-windows-msvc /c /Z7 
/Fo%t.obj -- %s
 // RUN: llvm-pdbutil dump --types %t.obj | FileCheck %s --check-prefix DISABLE
 
+// -fmessage-length shouldn't be included in the command line since it breaks 
reproducibility
+// RUN: %clang_cl -gcodeview-command-line --target=i686-windows-msvc -Xclang 
-fmessage-length=100 /c /Z7 /Fo%t.obj -- %s
+// RUN: llvm-pdbutil dump --types %t.obj | FileCheck %s --check-prefix 
MESSAGELEN
+
 int main(void) { return 42; }
 
 // CHECK:   Types (.debug$T)
@@ -36,3 +40,8 @@ int main(void) { return 42; }
 // DISABLE-NEXT:  0x{{.+}}: `{{.*}}`
 // DISABLE-NEXT:  0x{{.+}}: ``
 // DISABLE-NEXT:  : ``
+
+// MESSAGELEN:   Types (.debug$T)
+// MESSAGELEN: 
+// MESSAGELEN: 0x{{.+}} | LF_BUILDINFO [size = {{.+}}]
+// MESSAGELEN-NOT: -fmessage-length

diff  --git a/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp 
b/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
index a6f1fbc9d32ae..3bb0df4eeac93 100644
--- a/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
@@ -908,6 +908,9 @@ static std::string flattenCommandLine(ArrayRef 
Args,
 }
 if (Arg.startswith("-object-file-name") || Arg == MainFilename)
   continue;
+// Skip fmessage-length for reproduciability.
+if (Arg.startswith("-fmessage-length"))
+  continue;
 if (PrintedOneArg)
   OS << " ";
 llvm::sys::printArg(OS, Arg, /*Quote=*/true);



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


[clang] b6a33ce - [NFC] remove trailing whitespace

2022-06-23 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-06-23T14:04:23+02:00
New Revision: b6a33cec3830b6c9ea35faf35b4a5889c22c6ae9

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

LOG: [NFC] remove trailing whitespace

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 4c0f0ada36547..c79b748acbfc0 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -831,7 +831,7 @@ def Xlinker : Separate<["-"], "Xlinker">, 
Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass  to the linker">, MetaVarName<"">,
   Group;
 def Xoffload_linker : JoinedAndSeparate<["-"], "Xoffload-linker">,
-  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">, 
+  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">,
   MetaVarName<" ">, Group;
 def Xpreprocessor : Separate<["-"], "Xpreprocessor">, 
Group,
   HelpText<"Pass  to the preprocessor">, MetaVarName<"">;



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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-18 Thread Tobias Hieta via cfe-commits

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

LGTM

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


[clang] [cmake] Add LLVM_FORCE_VC_REVISION option (PR #67125)

2023-09-22 Thread Tobias Hieta via cfe-commits

https://github.com/tru commented:

It looks fine to me, but maybe we should have an entry for it in the 
`CMake.rst` documentation since the other `LLVM_*_VC` options are documented.

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


[clang] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)

2023-09-25 Thread Tobias Hieta via cfe-commits

tru wrote:

No I don't think it's job's fault. I ran clang-format on this file and it's not 
formatted at all, so I think when we ask it to just format a patch like we do 
in the job, it gets a bit confused and give you a bit of non-sense formatting. 
This is just a limitation of not running formatting on the whole file. 

Two solutions:
1) just ignore it, it looks fine in general.
2) Push a NFC commit that fixes the formatting of this file and then 
rebase/merge to get that commit in your branch and it should look fine.


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


[clang] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)

2023-09-25 Thread Tobias Hieta via cfe-commits

tru wrote:

Looking at it - it seems like none of Tablegen is correctly clang-formatted. If 
that's not desired, maybe it should have a local .clang-format file to disable 
the formatting of these files.

Do we have a clang-tblgen maintainer? Couldn't find anything in the codeowners 
and git log history seems to be very split.

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


[clang] [clang] [MinGW] Tolerate mingw specific linker options during compilation (PR #67891)

2023-10-01 Thread Tobias Hieta via cfe-commits

tru wrote:

Did you plan to backport this as well @mstorsjo ?

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


[clang] [clang-format] Fix a bug in RemoveParentheses: ReturnStatement (PR #67911)

2023-10-02 Thread Tobias Hieta via cfe-commits

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


[clang] [clang-format] Fix a bug in RemoveParentheses: ReturnStatement (PR #67911)

2023-10-02 Thread Tobias Hieta via cfe-commits

tru wrote:

oh sorry for merging this @owenca - it was tagged for the 17.x release and I 
thought it was a PR towards the backport branch so ti wasn't my intention to 
merge it into main for you. 

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


[clang] [clang] [MinGW] Tolerate mingw specific linker options during compilation (PR #67891)

2023-10-02 Thread Tobias Hieta via cfe-commits

tru wrote:

Yeah i noticed when I got further down in my notification stack :)

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


[clang] -fsanitize=function: fix MSVC hashing to sugared type (PR #66816)

2023-10-02 Thread Tobias Hieta via cfe-commits

tru wrote:

We guarantee abi/api stability between the patch versions, so I would say no. 
Maybe if we think it's critical enough we could do a 17.1.0, but this doesn't 
seem to be the case when reading the description at least. Is this a regression 
from LLVM 16?

I could be convinced, but my default outlook would be NO abi/api breaks unless 
absolutely 100% necessary.

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


[clang] -fsanitize=function: fix MSVC hashing to sugared type (PR #66816)

2023-10-02 Thread Tobias Hieta via cfe-commits

tru wrote:

cc @mstorsjo @sylvain-audi @aganea 

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


[clang] 4706251 - Clear release notes for 18.x

2023-07-25 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-07-25T13:58:49+02:00
New Revision: 4706251a3186c34da0ee8fd894f7e6b095da8fdc

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

LOG: Clear release notes for 18.x

Added: 


Modified: 
clang-tools-extra/docs/ReleaseNotes.rst
clang/docs/ReleaseNotes.rst
flang/docs/ReleaseNotes.md
lld/docs/ReleaseNotes.rst
llvm/docs/ReleaseNotes.rst
openmp/docs/ReleaseNotes.rst
polly/docs/ReleaseNotes.rst
pstl/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 236226e8b73a94..e602fceda6b1f7 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -94,451 +94,15 @@ The improvements are...
 Improvements to clang-tidy
 --
 
-- New global configuration file options `HeaderFileExtensions` and
-  `ImplementationFileExtensions`, replacing the check-local options of the
-  same name.
-
-- Support specifying `Checks` as a YAML list in the `.clang-tidy` configuration
-  file.
-
-- Fix a potential crash when using the `--dump-config` option.
-
-- Support specifying `SystemHeaders` in the `.clang-tidy` configuration file,
-  with the same functionality as the command-line option `--system-headers`.
-
-- `WarningsAsErrors` (`--warnings-as-errors=`) no longer promotes unlisted
-  warnings to errors. Only the warnings listed in `Checks` (`--checks=`) will
-  be promoted to errors. For custom error promotion, use `-Werror=`
-  on the compiler command-line, irrespective of `Checks` (`--checks=`) 
settings.
-
-- Fixed an issue where compiler warnings couldn't be suppressed using
-  `-Wno-` under C++20 and above.
-
 New checks
 ^^
 
-- New :doc:`bugprone-empty-catch
-  ` check.
-
-  Detects and suggests addressing issues with empty catch statements.
-
-- New :doc:`bugprone-multiple-new-in-one-expression
-  ` check.
-
-  Finds multiple ``new`` operator calls in a single expression, where the 
allocated
-  memory by the first ``new`` may leak if the second allocation fails and 
throws exception.
-
-- New :doc:`bugprone-non-zero-enum-to-bool-conversion
-  ` check.
-
-  Detect implicit and explicit casts of ``enum`` type into ``bool`` where 
``enum`` type
-  doesn't have a zero-value enumerator.
-
-- New :doc:`bugprone-switch-missing-default-case
-  ` check.
-
-  Ensures that switch statements without default cases are flagged, focuses 
only
-  on covering cases with non-enums where the compiler may not issue warnings.
-
-- New :doc:`bugprone-unique-ptr-array-mismatch
-  ` check.
-
-  Finds initializations of C++ unique pointers to non-array type that are
-  initialized with an array.
-
-- New :doc:`bugprone-unsafe-functions
-  ` check.
-
-  Checks for functions that have safer, more secure replacements available, or
-  are considered deprecated due to design flaws.
-  This check relies heavily on, but is not exclusive to, the functions from
-  the *Annex K. "Bounds-checking interfaces"* of C11.
-
-- New :doc:`cppcoreguidelines-avoid-capturing-lambda-coroutines
-  ` 
check.
-
-  Flags C++20 coroutine lambdas with non-empty capture lists that may cause
-  use-after-free errors and suggests avoiding captures or ensuring the lambda
-  closure object has a guaranteed lifetime.
-
-- New :doc:`cppcoreguidelines-misleading-capture-default-by-value
-  ` 
check.
-
-  Warns when lambda specify a by-value capture default and capture ``this``.
-
-- New :doc:`cppcoreguidelines-missing-std-forward
-  ` check.
-
-  Warns when a forwarding reference parameter is not forwarded within the
-  function body.
-
-- New :doc:`cppcoreguidelines-rvalue-reference-param-not-moved
-  ` 
check.
-
-  Warns when an rvalue reference function parameter is never moved within
-  the function body.
-
-- New :doc:`llvmlibc-inline-function-decl
-  ` check.
-
-  Checks that all implicit and explicit inline functions in header files are
-  tagged with the ``LIBC_INLINE`` macro.
-
-- New :doc:`misc-header-include-cycle
-  ` check.
-
-  Check detects cyclic ``#include`` dependencies between user-defined headers.
-
-- New :doc:`misc-include-cleaner
-  ` check.
-
-  Checks for unused and missing includes.
-
-- New :doc:`modernize-type-traits
-  ` check.
-
-  Converts standard library type traits of the form ``traits<...>::type`` and
-  ``traits<...>::value`` into ``traits_t<...>`` and ``traits_v<...>`` 
respectively.
-
-- New :doc:`modernize-use-std-print
-  ` check.
-
-  Converts calls to ``printf``, ``fprintf``, ``absl::PrintF``,
-  ``absl::FPrintf`` or other functions via configuration options, to
-  equivalent calls to C++23's ``std::print`` and ``std::println``, or other
-  functions via a configuration option, modifying the format string

[clang-tools-extra] 4706251 - Clear release notes for 18.x

2023-07-25 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-07-25T13:58:49+02:00
New Revision: 4706251a3186c34da0ee8fd894f7e6b095da8fdc

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

LOG: Clear release notes for 18.x

Added: 


Modified: 
clang-tools-extra/docs/ReleaseNotes.rst
clang/docs/ReleaseNotes.rst
flang/docs/ReleaseNotes.md
lld/docs/ReleaseNotes.rst
llvm/docs/ReleaseNotes.rst
openmp/docs/ReleaseNotes.rst
polly/docs/ReleaseNotes.rst
pstl/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 236226e8b73a94..e602fceda6b1f7 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -94,451 +94,15 @@ The improvements are...
 Improvements to clang-tidy
 --
 
-- New global configuration file options `HeaderFileExtensions` and
-  `ImplementationFileExtensions`, replacing the check-local options of the
-  same name.
-
-- Support specifying `Checks` as a YAML list in the `.clang-tidy` configuration
-  file.
-
-- Fix a potential crash when using the `--dump-config` option.
-
-- Support specifying `SystemHeaders` in the `.clang-tidy` configuration file,
-  with the same functionality as the command-line option `--system-headers`.
-
-- `WarningsAsErrors` (`--warnings-as-errors=`) no longer promotes unlisted
-  warnings to errors. Only the warnings listed in `Checks` (`--checks=`) will
-  be promoted to errors. For custom error promotion, use `-Werror=`
-  on the compiler command-line, irrespective of `Checks` (`--checks=`) 
settings.
-
-- Fixed an issue where compiler warnings couldn't be suppressed using
-  `-Wno-` under C++20 and above.
-
 New checks
 ^^
 
-- New :doc:`bugprone-empty-catch
-  ` check.
-
-  Detects and suggests addressing issues with empty catch statements.
-
-- New :doc:`bugprone-multiple-new-in-one-expression
-  ` check.
-
-  Finds multiple ``new`` operator calls in a single expression, where the 
allocated
-  memory by the first ``new`` may leak if the second allocation fails and 
throws exception.
-
-- New :doc:`bugprone-non-zero-enum-to-bool-conversion
-  ` check.
-
-  Detect implicit and explicit casts of ``enum`` type into ``bool`` where 
``enum`` type
-  doesn't have a zero-value enumerator.
-
-- New :doc:`bugprone-switch-missing-default-case
-  ` check.
-
-  Ensures that switch statements without default cases are flagged, focuses 
only
-  on covering cases with non-enums where the compiler may not issue warnings.
-
-- New :doc:`bugprone-unique-ptr-array-mismatch
-  ` check.
-
-  Finds initializations of C++ unique pointers to non-array type that are
-  initialized with an array.
-
-- New :doc:`bugprone-unsafe-functions
-  ` check.
-
-  Checks for functions that have safer, more secure replacements available, or
-  are considered deprecated due to design flaws.
-  This check relies heavily on, but is not exclusive to, the functions from
-  the *Annex K. "Bounds-checking interfaces"* of C11.
-
-- New :doc:`cppcoreguidelines-avoid-capturing-lambda-coroutines
-  ` 
check.
-
-  Flags C++20 coroutine lambdas with non-empty capture lists that may cause
-  use-after-free errors and suggests avoiding captures or ensuring the lambda
-  closure object has a guaranteed lifetime.
-
-- New :doc:`cppcoreguidelines-misleading-capture-default-by-value
-  ` 
check.
-
-  Warns when lambda specify a by-value capture default and capture ``this``.
-
-- New :doc:`cppcoreguidelines-missing-std-forward
-  ` check.
-
-  Warns when a forwarding reference parameter is not forwarded within the
-  function body.
-
-- New :doc:`cppcoreguidelines-rvalue-reference-param-not-moved
-  ` 
check.
-
-  Warns when an rvalue reference function parameter is never moved within
-  the function body.
-
-- New :doc:`llvmlibc-inline-function-decl
-  ` check.
-
-  Checks that all implicit and explicit inline functions in header files are
-  tagged with the ``LIBC_INLINE`` macro.
-
-- New :doc:`misc-header-include-cycle
-  ` check.
-
-  Check detects cyclic ``#include`` dependencies between user-defined headers.
-
-- New :doc:`misc-include-cleaner
-  ` check.
-
-  Checks for unused and missing includes.
-
-- New :doc:`modernize-type-traits
-  ` check.
-
-  Converts standard library type traits of the form ``traits<...>::type`` and
-  ``traits<...>::value`` into ``traits_t<...>`` and ``traits_v<...>`` 
respectively.
-
-- New :doc:`modernize-use-std-print
-  ` check.
-
-  Converts calls to ``printf``, ``fprintf``, ``absl::PrintF``,
-  ``absl::FPrintf`` or other functions via configuration options, to
-  equivalent calls to C++23's ``std::print`` and ``std::println``, or other
-  functions via a configuration option, modifying the format string

[clang] [Documentation] Replace recommonmark by myst-parser (PR #65664)

2023-09-07 Thread Tobias Hieta via cfe-commits

tru wrote:

Seems like a nice cleanup on top of the fact that we don't have to use a 
deprecated module. I am guessing it didn't cause any output errors.

Regarding build-bots, I am unsure where we automatically build the 
documentation. Pushing the docs to the main branch will rebuild and put them on 
llvm.org, But not sure where that happens. Maybe we should have a 
`requirements.txt` for documentation building and add that somewhere in the 
tree and have our bots always install that instead of each bot having its own 
list of python modules.

cc @tstellar 


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


[clang] [Documentation] Replace recommonmark by myst-parser (PR #65664)

2023-09-12 Thread Tobias Hieta via cfe-commits

tru wrote:

Instead of updating the module manually on the bot, I still think it's a good 
idea to add a requirements.txt that should be installed before running the 
build, ideally in a virtualenv. WDYT @andreil99 

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


[clang] [clang] Setup whitespace detection and clang-format as Github actions (PR #66509)

2023-09-15 Thread Tobias Hieta via cfe-commits

tru wrote:

@ldionne thanks for the whitespace check! I have already put some work into the 
clang-format action on my end. Would you mind dropping it from this PR and let 
me push mine first? My action is not just restricted to the clang subdir. 

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


[clang-tools-extra] [llvm][documentation] Fix coroutines documentation (PR #66420)

2023-09-18 Thread Tobias Hieta via cfe-commits

tru wrote:

ping @tstellar - guess it can be a wrong team name / label name?

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


[clang] af744f0 - [LLD][COFF] Add LLVM toolchain library paths by default.

2023-07-14 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-07-14T14:37:24+02:00
New Revision: af744f0b84e2b6410be65277068b9033124c73b2

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

LOG: [LLD][COFF] Add LLVM toolchain library paths by default.

We want lld-link to automatically find compiler-rt's and
libc++ when it's in the same directory as the rest of the
toolchain. This is because on Windows linking isn't done
via the clang driver - but instead invoked directly.

This prepends: /lib /lib/clang/XX/lib and
/lib/clang/XX/lib/windows automatically to the library
search paths.

Related to #63827

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
lld/COFF/Driver.cpp
lld/COFF/Driver.h
lld/docs/ReleaseNotes.rst
lld/test/COFF/print-search-paths.s

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index f7d28ab46b680c..be8632b0954983 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -184,6 +184,8 @@ std::string Driver::GetResourcesPath(StringRef BinaryPath,
 // path of the embedding binary, which for LLVM binaries will be in bin/.
 // ../lib gets us to lib/ in both cases.
 P = llvm::sys::path::parent_path(Dir);
+// This search path is also created in the COFF driver of lld, so any
+// changes here also needs to happen in lld/COFF/Driver.cpp
 llvm::sys::path::append(P, CLANG_INSTALL_LIBDIR_BASENAME, "clang",
 CLANG_VERSION_MAJOR_STRING);
   }

diff  --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp
index 5f11d11ea72538..d7476e91e03e38 100644
--- a/lld/COFF/Driver.cpp
+++ b/lld/COFF/Driver.cpp
@@ -637,6 +637,31 @@ void LinkerDriver::detectWinSysRoot(const 
opt::InputArgList &Args) {
   }
 }
 
+void LinkerDriver::addClangLibSearchPaths(const std::string &argv0) {
+  std::string lldBinary = sys::fs::getMainExecutable(argv0.c_str(), nullptr);
+  SmallString<128> binDir(lldBinary);
+  sys::path::remove_filename(binDir); // remove lld-link.exe
+  StringRef rootDir = sys::path::parent_path(binDir); // remove 'bin'
+
+  SmallString<128> libDir(rootDir);
+  sys::path::append(libDir, "lib");
+  // We need to prepend the paths here in order to make sure that we always
+  // try to link the clang versions of the builtins over the ones supplied by 
MSVC.
+  searchPaths.insert(searchPaths.begin(), saver().save(libDir.str()));
+
+  // Add the resource dir library path
+  SmallString<128> runtimeLibDir(rootDir);
+  sys::path::append(runtimeLibDir, "lib", "clang", 
std::to_string(LLVM_VERSION_MAJOR), "lib");
+  searchPaths.insert(searchPaths.begin(), saver().save(runtimeLibDir.str()));
+
+  // Resource dir + osname, which is hardcoded to windows since we are in the
+  // COFF driver.
+  SmallString<128> runtimeLibDirWithOS(runtimeLibDir);
+  sys::path::append(runtimeLibDirWithOS, "windows");
+  searchPaths.insert(searchPaths.begin(), 
saver().save(runtimeLibDirWithOS.str()));
+
+}
+
 void LinkerDriver::addWinSysRootLibSearchPaths() {
   if (!diaPath.empty()) {
 // The DIA SDK always uses the legacy vc arch, even in new MSVC versions.
@@ -1543,6 +1568,7 @@ void LinkerDriver::linkerMain(ArrayRef 
argsArr) {
   detectWinSysRoot(args);
   if (!args.hasArg(OPT_lldignoreenv) && !args.hasArg(OPT_winsysroot))
 addLibSearchPaths();
+  addClangLibSearchPaths(argsArr[0]);
 
   // Handle /ignore
   for (auto *arg : args.filtered(OPT_ignore)) {

diff  --git a/lld/COFF/Driver.h b/lld/COFF/Driver.h
index 6fb3abf260d6cf..17d2e6a483dc33 100644
--- a/lld/COFF/Driver.h
+++ b/lld/COFF/Driver.h
@@ -84,6 +84,8 @@ class LinkerDriver {
   // config->machine has been set.
   void addWinSysRootLibSearchPaths();
 
+  void addClangLibSearchPaths(const std::string &argv0);
+
   // Used by the resolver to parse .drectve section contents.
   void parseDirectives(InputFile *file);
 

diff  --git a/lld/docs/ReleaseNotes.rst b/lld/docs/ReleaseNotes.rst
index 4bd5a628d2b902..9435f23a7af616 100644
--- a/lld/docs/ReleaseNotes.rst
+++ b/lld/docs/ReleaseNotes.rst
@@ -42,6 +42,12 @@ COFF Improvements
   current directory.
   I.e. ``lld-link /libpath:c:\relative\root relative\path\my.lib`` where before
   we would have to do ``lld-link /libpath:c:\relative\root\relative\path 
my.lib``
+* lld-link learned -print-search-paths that will print all the paths where it 
will
+  search for libraries.
+* By default lld-link will now search for libraries in the toolchain 
directories.
+  Specifically it will search:
+  ``/lib``, ``/lib/clang//lib`` and
+  ``/lib/clang//lib/windows``.
 
 MinGW Improvements
 --

diff  --git a/lld/test/COFF/print-search-paths.s 
b/lld/test/COFF/print-search-paths.s
index a484ac5b0fb164..5c292aafc68a11 100644
--- a/lld/test/COFF/print-sea

[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits

https://github.com/tru requested changes to this pull request.

Thanks for the PR, I think we at least need to make sure that we don't erase 
flags that have been set by the user manually.

Another option would just to say that this configuration ARM64 + MSVC of this 
version is not a valid configuration for MSVC and add it to 
ProblematicConfigurations here: 
https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/CheckProblematicConfigurations.cmake

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits


@@ -30,6 +30,15 @@ set(LLVM_LINK_COMPONENTS
   TransformUtils
   )
 
+# Workaround for MSVC ARM64 performance regression: disable all optimizations 
(/Od)
+# and then enable back all /O2 options except one.
+if(NOT CMAKE_BUILD_TYPE MATCHES Debug 
+AND MSVC 
+AND MSVC_VERSION VERSION_GREATER_EQUAL 1932
+AND CMAKE_SYSTEM_PROCESSOR MATCHES "ARM64")
+  set_source_files_properties(CGBuiltin.cpp PROPERTIES COMPILE_FLAGS "/Od /Gw 
/Oi /Oy /Gy /Ob2 /Ot /GF")

tru wrote:

You are setting these settings for all configurations and erasing the other 
flags set for these files. I don't think that's the right solution. I would 
rather you grab the current compile_flags and then substitute the optimization 
flags only.

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits


@@ -30,6 +30,15 @@ set(LLVM_LINK_COMPONENTS
   TransformUtils
   )
 
+# Workaround for MSVC ARM64 performance regression: disable all optimizations 
(/Od)

tru wrote:

I think this comment also should link to the issue on the Microsoft side so 
that we can know to remove this later.

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-03 Thread Tobias Hieta via cfe-commits


@@ -30,6 +30,15 @@ set(LLVM_LINK_COMPONENTS
   TransformUtils
   )
 
+# Workaround for MSVC ARM64 performance regression: disable all optimizations 
(/Od)
+# and then enable back all /O2 options except one.
+if(NOT CMAKE_BUILD_TYPE MATCHES Debug 
+AND MSVC 
+AND MSVC_VERSION VERSION_GREATER_EQUAL 1932
+AND CMAKE_SYSTEM_PROCESSOR MATCHES "ARM64")
+  set_source_files_properties(CGBuiltin.cpp PROPERTIES COMPILE_FLAGS "/Od /Gw 
/Oi /Oy /Gy /Ob2 /Ot /GF")

tru wrote:

Yeah I think this is what we want. We don't want to assume what the current 
flags are. Does it only happen in Release and RelWithDebInfo configurations? In 
that case you can maybe use generator expressions to only happen for those 
configurations?

Btw I noticed that COMPILE_FLAGS is deprecated and COMPILE_OPTIONS should be 
used instead, so maybe look into that as well?

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


[clang] Workaround for MSVC ARM64 build performance regression (PR #65215)

2023-09-04 Thread Tobias Hieta via cfe-commits

tru wrote:

I suspect maybe the MSVC_VERSION check might exclude clang-cl, but we should 
make sure, because @omjavaid is correct, we shouldn't apply this to clang-cl 
unless it shows the same problems.

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


[clang] [Clang] Fix missing diagnostic for non-standard layout type in (PR #65246)

2023-09-04 Thread Tobias Hieta via cfe-commits


@@ -39,6 +40,4 @@ struct C {
 
 static_assert(__builtin_offsetof(C, n) == 8,
   "long long field in ms_struct should be 8-byte aligned");
-#if !defined(TEST_FOR_ERROR) && !defined(TEST_FOR_WARNING)
-// expected-no-diagnostics
-#endif
+// expected-warning@-2 {{offset of on non-standard-layout type 'C'}}

tru wrote:

Missing EOL. Did you run `clang-format`?

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


[clang] [Clang] Fix missing diagnostic for non-standard layout type in `offsetof` (PR #65246)

2023-09-04 Thread Tobias Hieta via cfe-commits


@@ -39,6 +40,4 @@ struct C {
 
 static_assert(__builtin_offsetof(C, n) == 8,
   "long long field in ms_struct should be 8-byte aligned");
-#if !defined(TEST_FOR_ERROR) && !defined(TEST_FOR_WARNING)
-// expected-no-diagnostics
-#endif
+// expected-warning@-2 {{offset of on non-standard-layout type 'C'}}

tru wrote:

Ah I missed that it was in a test. We shouldn't run clang-format then. But the 
EOL should be fixed! Sorry for the drive-by review :)

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


[clang] [Clang] Fix missing diagnostic for non-standard layout type in `offsetof` (PR #65246)

2023-09-05 Thread Tobias Hieta via cfe-commits

tru wrote:

Ping @llvm/pr-subscribers-libcxx 

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


[clang] 104cd74 - Revert "[clang-format] Handle object instansiation in if-statements"

2023-04-14 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-04-14T09:48:24+02:00
New Revision: 104cd749f5cca609a79303c0dad22bc041b5448a

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

LOG: Revert "[clang-format] Handle object instansiation in if-statements"

This reverts commit 70de684d44135b4025d92b2b36ad387cf5ab8b5a.

This causes a regression as described in #61785

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 18fccca622ca..526eb2413526 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -421,8 +421,7 @@ class AnnotatingParser {
   FormatToken *Next = CurrentToken->Next;
   if (PrevPrev && PrevPrev->is(tok::identifier) &&
   Prev->isOneOf(tok::star, tok::amp, tok::ampamp) &&
-  CurrentToken->is(tok::identifier) &&
-  !Next->isOneOf(tok::equal, tok::l_brace)) {
+  CurrentToken->is(tok::identifier) && Next->isNot(tok::equal)) {
 Prev->setType(TT_BinaryOperator);
 LookForDecls = false;
   }
@@ -2517,12 +2516,6 @@ class AnnotatingParser {
   return TT_PointerOrReference;
 }
 
-// if (Class* obj { function() })
-if (PrevToken->Tok.isAnyIdentifier() && NextToken->Tok.isAnyIdentifier() &&
-NextToken->Next && NextToken->Next->is(tok::l_brace)) {
-  return TT_PointerOrReference;
-}
-
 if (PrevToken->endsSequence(tok::r_square, tok::l_square, tok::kw_delete))
   return TT_UnaryOperator;
 

diff  --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index facd0060d0fd..2d1d7749a8e8 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -146,18 +146,6 @@ TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmp) {
   EXPECT_TOKEN(Tokens[7], tok::star, TT_UnaryOperator);
   EXPECT_TOKEN(Tokens[12], tok::star, TT_PointerOrReference);
 
-  Tokens = annotate("if (Foo * Bar / Test)");
-  ASSERT_EQ(Tokens.size(), 9u) << Tokens;
-  EXPECT_TOKEN(Tokens[3], tok::star, TT_BinaryOperator);
-
-  Tokens = annotate("if (Class* obj {getObj()})");
-  ASSERT_EQ(Tokens.size(), 12u) << Tokens;
-  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
-
-  Tokens = annotate("if (Foo* Bar = getObj())");
-  ASSERT_EQ(Tokens.size(), 11u) << Tokens;
-  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
-
   Tokens = annotate("int f3() { return sizeof(Foo&); }");
   ASSERT_EQ(Tokens.size(), 14u) << Tokens;
   EXPECT_TOKEN(Tokens[9], tok::amp, TT_PointerOrReference);



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


[clang] 877859a - [clang] Handle __declspec() attributes in using

2023-02-13 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-02-13T15:43:08+01:00
New Revision: 877859a09bda29fe9a7f1a9016b06cf80661a032

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

LOG: [clang] Handle __declspec() attributes in using

This patch fixes so that declspec attributes are forwarded
to the alias declaration.

Before this patch this would assert:

class Test { int a; };
using AlignedTest = __declspec(align(16)) const Test;
static_assert(alignof(AlignedTest) == 16, "error");

But afterwards it behaves the same as MSVC does and doesn't
assert.

Fixes: llvm/llvm-project#60513

Reviewed By: aaron.ballman

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

Added: 
clang/test/SemaCXX/using-declspec.cpp

Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Parse/ParseDecl.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 4fef5f883655..06f0bdcc796d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -109,6 +109,10 @@ to be worn by functions containing buffer operations that 
could cause out of
 bounds memory accesses. It emits warnings at call sites to such functions when
 the flag ``-Wunsafe-buffer-usage`` is enabled.
 
+``__declspec`` attributes can now be used together with the using keyword. 
Before
+the attributes on ``__declspec`` was ignored, while now it will be forwarded 
to the
+point where the alias is used.
+
 Windows Support
 ---
 

diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 96c25ba0c853..d32f26b9c32e 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -56,6 +56,18 @@ TypeResult Parser::ParseTypeName(SourceRange *Range, 
DeclaratorContext Context,
   if (OwnedType)
 *OwnedType = DS.isTypeSpecOwned() ? DS.getRepAsDecl() : nullptr;
 
+  // Move declspec attributes to ParsedAttributes
+  if (Attrs) {
+llvm::SmallVector ToBeMoved;
+for (ParsedAttr &AL : DS.getAttributes()) {
+  if (AL.isDeclspecAttribute())
+ToBeMoved.push_back(&AL);
+}
+
+for (ParsedAttr *AL : ToBeMoved)
+  Attrs->takeOneFrom(DS.getAttributes(), AL);
+  }
+
   // Parse the abstract-declarator, if present.
   Declarator DeclaratorInfo(DS, ParsedAttributesView::none(), Context);
   ParseDeclarator(DeclaratorInfo);

diff  --git a/clang/test/SemaCXX/using-declspec.cpp 
b/clang/test/SemaCXX/using-declspec.cpp
new file mode 100644
index ..a903bc93c9b4
--- /dev/null
+++ b/clang/test/SemaCXX/using-declspec.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
+
+// This should ignore the alignment and issue a warning about
+// align not being used
+auto func() -> __declspec(align(16)) int; // expected-warning{{attribute 
ignored when parsing type}}
+static_assert(alignof(decltype(func())) == alignof(int));
+
+// The following should NOT assert since alignment should
+// follow the type
+struct Test { int a; };
+using AlignedTest = __declspec(align(16)) const Test;
+static_assert(alignof(AlignedTest) == 16, "error");
+
+// Same here, no declaration to shift to
+int i = (__declspec(align(16))int)12; // expected-warning{{attribute ignored 
when parsing type}}
+
+// But there is a declaration here!
+typedef __declspec(align(16)) int Foo;
+static_assert(alignof(Foo) == 16);



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


[clang] b8c2ba1 - [NFC] Fix using-declspec.cpp test with non-C++17 compilers

2023-02-13 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-02-13T16:58:13+01:00
New Revision: b8c2ba138ef689710efaa6331a618620058057fb

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

LOG: [NFC] Fix using-declspec.cpp test with non-C++17 compilers

Added: 


Modified: 
clang/test/SemaCXX/using-declspec.cpp

Removed: 




diff  --git a/clang/test/SemaCXX/using-declspec.cpp 
b/clang/test/SemaCXX/using-declspec.cpp
index a903bc93c9b44..f4cc8d3736ca4 100644
--- a/clang/test/SemaCXX/using-declspec.cpp
+++ b/clang/test/SemaCXX/using-declspec.cpp
@@ -3,7 +3,7 @@
 // This should ignore the alignment and issue a warning about
 // align not being used
 auto func() -> __declspec(align(16)) int; // expected-warning{{attribute 
ignored when parsing type}}
-static_assert(alignof(decltype(func())) == alignof(int));
+static_assert(alignof(decltype(func())) == alignof(int), "error");
 
 // The following should NOT assert since alignment should
 // follow the type
@@ -16,4 +16,5 @@ int i = (__declspec(align(16))int)12; // 
expected-warning{{attribute ignored whe
 
 // But there is a declaration here!
 typedef __declspec(align(16)) int Foo;
-static_assert(alignof(Foo) == 16);
+static_assert(alignof(Foo) == 16, "error");
+



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


[clang] 3b6c883 - Revert "[Clang] Implement fix for DR2628"

2023-02-23 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-02-23T16:07:35+01:00
New Revision: 3b6c88331bcd0531d627fe27de5dbd0ac3165300

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

LOG: Revert "[Clang] Implement fix for DR2628"

This reverts commit 368b6832de33b366d4eb155f940e7476daace6a8.

See https://github.com/llvm/llvm-project/issues/60777 for details

Added: 


Modified: 
clang/lib/Sema/SemaTemplate.cpp
clang/test/CXX/drs/dr26xx.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 8df8eadad3fef..c3338e4eaed28 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -2540,8 +2540,6 @@ struct ConvertConstructorToDeductionGuideTransform {
   TInfo->getType(), TInfo, LocEnd, Ctor);
 Guide->setImplicit();
 Guide->setParams(Params);
-if (Ctor && Ctor->getTrailingRequiresClause())
-  Guide->setTrailingRequiresClause(Ctor->getTrailingRequiresClause());
 
 for (auto *Param : Params)
   Param->setDeclContext(Guide);

diff  --git a/clang/test/CXX/drs/dr26xx.cpp b/clang/test/CXX/drs/dr26xx.cpp
index 36aea39824740..e69a151b9d029 100644
--- a/clang/test/CXX/drs/dr26xx.cpp
+++ b/clang/test/CXX/drs/dr26xx.cpp
@@ -14,17 +14,23 @@ using enum E; // expected-error {{unknown type name E}}
 }
 }
 
-namespace dr2628 { // dr2628: yes open
+namespace dr2628 { // dr2628: no, this was reverted for the 16.x release
+   // due to regressions, see the issue for more details:
+   // https://github.com/llvm/llvm-project/issues/60777
 
 template 
 struct foo {
-  constexpr foo() requires (!A && !B) = delete; // #DR2628_CTOR
-  constexpr foo() requires (A || B) = delete;
+  // The expected notes below should be removed when dr2628 is fully 
implemented again
+  constexpr foo() requires (!A && !B) = delete; // expected-note {{candidate 
function [with A = false, B = false]}} #DR2628_CTOR
+  constexpr foo() requires (A || B) = delete; // expected-note {{candidate 
function [with A = false, B = false]}}
 };
 
 void f() {
-  foo fooable; // expected-error {{call to deleted}}
-  // expected-note@#DR2628_CTOR {{marked deleted here}}
+  // The FIXME's below should be the expected errors when dr2628 is
+  // fully implemented again.
+  // FIXME-expected-error {{call to deleted}}
+  foo fooable; // expected-error {{ambiguous deduction for template arguments 
of 'foo'}}
+  // FIXME-expected-note@#DR2628_CTOR {{marked deleted here}}
 }
 
 }



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


[clang] [compiler-rt] [asan][windows] Eliminate the static asan runtime on windows (PR #81677)

2024-02-14 Thread Tobias Hieta via cfe-commits

tru wrote:

cc @sylvain-audi 

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


[clang] [Driver] Have getTargetSubDirPath better match get_compiler_rt_target (PR #100091)

2024-08-10 Thread Tobias Hieta via cfe-commits

tru wrote:

Do we still need to fix this for 19.1.0-final?

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


[clang] [llvm] [CMake][Release] Use the TXZ cpack generator for binaries (PR #90138)

2024-06-06 Thread Tobias Hieta via cfe-commits

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


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


[clang] [llvm] [Driver] Add option to select compiler-rt arch suffix (PR #89775)

2024-06-11 Thread Tobias Hieta via cfe-commits

tru wrote:

I don't have the bandwidth to get a RFC through right now. If this is broken 
and no-one wants to take care of getting consensus for something new, I suggest 
you revert to the previous state. For my toolchain I can continue to carry a 
patch until this is all sorted.

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


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-16 Thread Tobias Hieta via cfe-commits

https://github.com/tru created https://github.com/llvm/llvm-project/pull/88857

Previously the trivial_abi was ignored for records when targetting the 
microsoft abi, the MSVC rules where always enforced to ensure compatibility 
with MSVC. This commit changes it to be closer to the itanium abi when a record 
is marked with the trivial_abi attribute.

Fixes #87993

>From 22f627cac7b2ea08a5569bb25d9c1d054b3a7cae Mon Sep 17 00:00:00 2001
From: Tobias Hieta 
Date: Tue, 16 Apr 2024 09:38:53 +0200
Subject: [PATCH] [clang] Handle trivial_abi attribute for Microsoft ABI.

Previously the trivial_abi was ignored for records when targetting
the microsoft abi, the MSVC rules where always enforced to ensure
compatibility with MSVC. This commit changes it to be closer to
the itanium abi when a record is marked with the trivial_abi attribute.

Fixes #87993
---
 clang/docs/ReleaseNotes.rst|  4 
 clang/lib/CodeGen/MicrosoftCXXABI.cpp  |  5 +
 clang/test/CodeGenCXX/trivial_abi_msvc.cpp | 21 +
 3 files changed, 30 insertions(+)
 create mode 100644 clang/test/CodeGenCXX/trivial_abi_msvc.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 76701dc723b6c3..c5241403711726 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -63,6 +63,10 @@ ABI Changes in This Version
   MSVC uses a different mangling for these objects, compatibility is not 
affected.
   (#GH85423).
 
+- The attribute ``trivial_abi`` now works when targetting the Microsoft ABI. 
Marking
+  a struct with this attribute will now cause clang to emit ABI similar to the 
Itanium
+  ABI. This is not compatible with the Microsoft ABI. (#GH87993).
+
 AST Dumping Potentially Breaking Changes
 
 
diff --git a/clang/lib/CodeGen/MicrosoftCXXABI.cpp 
b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
index d38a26940a3cb6..b930913badcd3f 100644
--- a/clang/lib/CodeGen/MicrosoftCXXABI.cpp
+++ b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl 
GD) const {
 
 static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
  CodeGenModule &CGM) {
+  // If the record is marked with the trivial_abi attribute, we don't
+  // have to conform to the standard MSVC ABI.
+  if (RD->hasAttr())
+return true;
+
   // On AArch64, HVAs that can be passed in registers can also be returned
   // in registers. (Note this is using the MSVC definition of an HVA; see
   // isPermittedToBeHomogeneousAggregate().)
diff --git a/clang/test/CodeGenCXX/trivial_abi_msvc.cpp 
b/clang/test/CodeGenCXX/trivial_abi_msvc.cpp
new file mode 100644
index 00..8826a8224c6671
--- /dev/null
+++ b/clang/test/CodeGenCXX/trivial_abi_msvc.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions 
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+  int *p;
+  Trivial() : p(0) {}
+  Trivial(const Trivial &) noexcept = default;
+};
+
+// CHECK-LABEL: define{{.*}} i64 @"?retTrivial@@YA?AUTrivial@@XZ"(
+// CHECK: %retval = alloca %[[STRUCT_TRIVIAL]], align 8
+// CHECK: %call = call noundef ptr @"??0Trivial@@QEAA@XZ"(ptr noundef nonnull 
align 8 dereferenceable(8) %retval)
+// CHECK: %coerce.dive = getelementptr inbounds %[[STRUCT_TRIVIAL]], ptr 
%retval, i32 0, i32 0
+// CHECK: %0 = load ptr, ptr %coerce.dive, align 8
+// CHECK: %coerce.val.pi = ptrtoint ptr %0 to i64
+// CHECK: ret i64 %coerce.val.pi
+Trivial retTrivial() {
+  Trivial s;
+  return s;
+}
+

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


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-16 Thread Tobias Hieta via cfe-commits


@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions 
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+  int *p;
+  Trivial() : p(0) {}
+  Trivial(const Trivial &) noexcept = default;
+};
+
+// CHECK-LABEL: define{{.*}} i64 @"?retTrivial@@YA?AUTrivial@@XZ"(
+// CHECK: %retval = alloca %[[STRUCT_TRIVIAL]], align 8
+// CHECK: %call = call noundef ptr @"??0Trivial@@QEAA@XZ"(ptr noundef nonnull 
align 8 dereferenceable(8) %retval)
+// CHECK: %coerce.dive = getelementptr inbounds %[[STRUCT_TRIVIAL]], ptr 
%retval, i32 0, i32 0
+// CHECK: %0 = load ptr, ptr %coerce.dive, align 8
+// CHECK: %coerce.val.pi = ptrtoint ptr %0 to i64
+// CHECK: ret i64 %coerce.val.pi
+Trivial retTrivial() {
+  Trivial s;
+  return s;
+}
+

tru wrote:

I checked your example there and the instanceMethod is no problem, but I 
noticed that the staticMethod doesn't contain a `sret` return value with this 
patch. Since we are not passing `this` to it - I think this is expected, but 
just want to make sure.

```
; Function Attrs: mustprogress noinline optnone uwtable
define dso_local i64 @"?staticMethod@TrivialInstance@@SA?AUTrivial@@XZ"() #0 
align 2 {
entry:
  %retval = alloca %struct.Trivial, align 8
  %call = call noundef ptr @"??0Trivial@@QEAA@XZ"(ptr noundef nonnull align 8 
dereferenceable(8) %retval)
  %coerce.dive = getelementptr inbounds %struct.Trivial, ptr %retval, i32 0, 
i32 0
  %0 = load ptr, ptr %coerce.dive, align 8
  %coerce.val.pi = ptrtoint ptr %0 to i64
  ret i64 %coerce.val.pi
}
```

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


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-16 Thread Tobias Hieta via cfe-commits

https://github.com/tru updated https://github.com/llvm/llvm-project/pull/88857

>From 08214d87d1a7c83ea25eef3bf18de1568a20a152 Mon Sep 17 00:00:00 2001
From: Tobias Hieta 
Date: Tue, 16 Apr 2024 09:38:53 +0200
Subject: [PATCH] [clang] Handle trivial_abi attribute for Microsoft ABI.

Previously the trivial_abi was ignored for records when targetting
the microsoft abi, the MSVC rules where always enforced to ensure
compatibility with MSVC. This commit changes it to be closer to
the itanium abi when a record is marked with the trivial_abi attribute.

Fixes #87993
---
 clang/docs/ReleaseNotes.rst|  5 
 clang/lib/CodeGen/MicrosoftCXXABI.cpp  |  5 
 clang/test/CodeGenCXX/trivial_abi_msvc.cpp | 31 ++
 3 files changed, 41 insertions(+)
 create mode 100644 clang/test/CodeGenCXX/trivial_abi_msvc.cpp

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 76701dc723b6c3..2b653e5af6f5ae 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -63,6 +63,11 @@ ABI Changes in This Version
   MSVC uses a different mangling for these objects, compatibility is not 
affected.
   (#GH85423).
 
+- Records carrying the trivial_abi attribute are now returned directly in 
registers
+  in more cases when using the Microsoft ABI. It is not possible to pass 
trivial_abi
+  records between MSVC and Clang, so there is no ABI compatibility 
requirement. This
+  is an ABI break with old versions of Clang. (#GH87993)
+
 AST Dumping Potentially Breaking Changes
 
 
diff --git a/clang/lib/CodeGen/MicrosoftCXXABI.cpp 
b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
index d38a26940a3cb6..b930913badcd3f 100644
--- a/clang/lib/CodeGen/MicrosoftCXXABI.cpp
+++ b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl 
GD) const {
 
 static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
  CodeGenModule &CGM) {
+  // If the record is marked with the trivial_abi attribute, we don't
+  // have to conform to the standard MSVC ABI.
+  if (RD->hasAttr())
+return true;
+
   // On AArch64, HVAs that can be passed in registers can also be returned
   // in registers. (Note this is using the MSVC definition of an HVA; see
   // isPermittedToBeHomogeneousAggregate().)
diff --git a/clang/test/CodeGenCXX/trivial_abi_msvc.cpp 
b/clang/test/CodeGenCXX/trivial_abi_msvc.cpp
new file mode 100644
index 00..0af1d63acd1a5e
--- /dev/null
+++ b/clang/test/CodeGenCXX/trivial_abi_msvc.cpp
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions 
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+  int *p;
+  Trivial() : p(0) {}
+  Trivial(const Trivial &) noexcept = default;
+};
+
+// CHECK-LABEL: define{{.*}} i64 @"?retTrivial@@YA?AUTrivial@@XZ"(
+// CHECK: %retval = alloca %[[STRUCT_TRIVIAL]], align 8
+// CHECK: %call = call noundef ptr @"??0Trivial@@QEAA@XZ"(ptr noundef nonnull 
align 8 dereferenceable(8) %retval)
+// CHECK: %coerce.dive = getelementptr inbounds %[[STRUCT_TRIVIAL]], ptr 
%retval, i32 0, i32 0
+// CHECK: %0 = load ptr, ptr %coerce.dive, align 8
+// CHECK: %coerce.val.pi = ptrtoint ptr %0 to i64
+// CHECK: ret i64 %coerce.val.pi
+Trivial retTrivial() {
+  Trivial s;
+  return s;
+}
+
+struct TrivialInstance {
+Trivial instanceMethod();
+static Trivial staticMethod();
+};
+
+// We need to make sure that instanceMethod has a sret return value since 
`this` will always go in the register.
+// CHECK-LABEL: define{{.*}} void 
@"?instanceMethod@TrivialInstance@@QEAA?AUTrivial@@XZ"({{.*}} 
sret(%struct.Trivial{{.*}}
+Trivial TrivialInstance::instanceMethod() { return {}; }
+// CHECK-LABEL: define{{.*}} i64 
@"?staticMethod@TrivialInstance@@SA?AUTrivial@@XZ"(
+Trivial TrivialInstance::staticMethod() { return {}; }

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


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-16 Thread Tobias Hieta via cfe-commits

tru wrote:

@efriedma-quic are you ok with this change?

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


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-18 Thread Tobias Hieta via cfe-commits


@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl 
GD) const {
 
 static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
  CodeGenModule &CGM) {
+  // If the record is marked with the trivial_abi attribute, we don't
+  // have to conform to the standard MSVC ABI.
+  if (RD->hasAttr())

tru wrote:

So if I understand correctly:

- There are additional places in the microsoft code path where we don't handle 
trivial cases without the attribute.
- The glaring issue here with this PR is that if you put a trivial_abi struct 
in a struct it won't be marked as trivial itself since it doesn't search 
recursively.

Seems like there are many more places where we can do better, do we want to 
block this PR on the recursive search? What would the rules for that be? It 
can't just be that if you have a struct with a trivial_abi attribute inside any 
struct the parent should also be considered trivial. Would it be that 
isTrivialForMicrosoft would return true if the current struct passes the checks 
there and only contains a struct with a trivial_abi attribute?

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


[clang] [clang] Support __typeof_unqual__ in all C modes (PR #87392)

2024-04-20 Thread Tobias Hieta via cfe-commits

tru wrote:

The final decision is Toms, but I don't think it qualifies since we are so late 
in the current process and that 19 will start in just a few months. 

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


[clang] [llvm] Build release binaries for multiple targets (PR #98431)

2024-07-26 Thread Tobias Hieta via cfe-commits

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


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


[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)

2024-04-23 Thread Tobias Hieta via cfe-commits

tru wrote:

We have a custom toolchain that uses the new style on windows and if you build 
with runtimes on windows (which is the suggested way) it will end up with the 
new style without arch suffix. I don't think we can assume this is correct for 
windows in all setups. I am fine with this change on PlayStation, but I wonder 
if we should have a switch for this in CMake so the builder can control it 
instead of assuming stuff. 

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


[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)

2024-04-23 Thread Tobias Hieta via cfe-commits

tru wrote:

It's been like that for maybe 2-3 years now and no one has complained about it, 
so I think that change is solid. I can suggest a CMake change, but last time it 
was discussed I think @maskray was against a new variable, but since we might 
need to have some different behaviour it might be warrented. 

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


[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)

2024-04-23 Thread Tobias Hieta via cfe-commits

tru wrote:

I agree that if downstream want to change stuff, they need to engage. We can't 
guess what microsoft wants to do (or sony) unless we have a discussion about 
it. This is also documented in the developer policy. If there are missed 
release notes, they need to be added of course.

That said - if I understand your problem correctly @pogo59 you are building 
clang yourself, but you are using the asan libraries from MSVC? I am not sure 
that would ever be a supported configuration if the compiler isn't built from 
the same source as the runtime libraries. If you would have built 
compiler-rt/asan yourself it should have been found and used correctly.

I think it might make sense to make a RFC (again I guess) to remove the old 
paths and have a grace period where there is a cmake option to force the old 
layout. This would harmonize so that we have just one layout and remove the 
biggest problem (in my mind) which is the fallback that can load the wrong 
runtime library if you are unlucky.

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


[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)

2024-04-24 Thread Tobias Hieta via cfe-commits

tru wrote:

Honestly - I think going back to *one* style of runtime path is to be preferred 
now. But I don't think it's fair to say that it doesn't solve any problems, 
because we switched to it so that we could ship more platforms in one toolchain 
package without having to add cfg files and similar things to point it to the 
right path. There was some kind of collision we ran into when we where using 
the old path.

I do think the current status quo is confusing and bad, so I rather we go back 
to the old layout if that's what people prefer and I'll have to work around 
that in that case. But it sounds like this needs a RFC.

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


[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)

2024-04-24 Thread Tobias Hieta via cfe-commits

tru wrote:

And I think it's better to revert it all instead of implementing this 
half-revert in this PR in that case and then we should discuss how to move 
forward.

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


[clang] [CMake][Release] Add stage2-package target (PR #89517)

2024-04-24 Thread Tobias Hieta via cfe-commits

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


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


[clang] [CMake][Release] Refactor cache file and use two stages for non-PGO builds (PR #89812)

2024-04-24 Thread Tobias Hieta via cfe-commits

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

I find changes to the multi-stage build caches a bit confusing to review 
without being able to see the cache that's generated. But I trust that you have 
tested this and it works as expected, In that case you can merge this.

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


[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)

2024-04-25 Thread Tobias Hieta via cfe-commits

tru wrote:

> > LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on 
> 
> 
> 
> I'm unable to find what code this affects. I don't see it mentioned anywhere 
> in clang/lib or clang/include.
> 
> 
> 
> It does seem like it should control the behavior of 
> `ToolChain::getCompilerRT`; where I had added the Windows/PS check, seems 
> like it should check the config variable instead. It's obvious that OS-based 
> checks are not appropriate, as @tru reports using the new scheme but MSVC 
> clearly uses the old scheme, both on Windows.
> 
> 
> 
> How do CMake variables turn into something that controls code behavior?

IIRC - the CMake variable doesn't change any driver code. It just changes the 
install path of compiler-rt, you can probably find references to it in 
compiler-rt CMake files.

The driver always probes both paths. Before this latest patch it probes the new 
layout first, then fell back to the old _arch suffix files and it lead to bad 
behaviour where it unexpectedly fell back (and the error message really didn't 
make any sense). This new patch was intended to change so the error message 
made more sense, but seems to have changed some specific behaviours as well.


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


[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)

2024-04-25 Thread Tobias Hieta via cfe-commits

tru wrote:

I think I suggested that we should make the CMake variable change the driver 
behaviour to reflect the setting in order to remove unexpected fallbacks and 
that the vendor could select the layout. I still think that's probably the 
better solution. 

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


[clang] [llvm] [CMake][Release] Enable CMAKE_POSITION_INDEPENDENT_CODE (PR #90139)

2024-04-26 Thread Tobias Hieta via cfe-commits

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


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


[clang] [CMake][Release] Use the TGZ cpack generator for binaries (PR #90138)

2024-04-26 Thread Tobias Hieta via cfe-commits

tru wrote:

If this is for permanent storage I suggest we use TXZ instead, since it has 
better compression. You should also set CPACK_ARCHIVE_THREADS to something 
higher than the default (1). Since xz really benefits from this.

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


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-29 Thread Tobias Hieta via cfe-commits

tru wrote:

ping on this.


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


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-29 Thread Tobias Hieta via cfe-commits


@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl 
GD) const {
 
 static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
  CodeGenModule &CGM) {
+  // If the record is marked with the trivial_abi attribute, we don't
+  // have to conform to the standard MSVC ABI.
+  if (RD->hasAttr())

tru wrote:

Happy to add this. Can you point me to an example where we search recursively 
or give some pseudo code example and I should be able to take it from there 
pretty soon. 

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


[clang] [llvm] Build release binaries for multiple targets (PR #98431)

2024-07-11 Thread Tobias Hieta via cfe-commits

tru wrote:

Hmm. It's a bit worrying that we can't have the tests running... I wonder what 
the workflow would be here since we need to verify before we run the binaries. 
What's the problem with the tests currently?

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


  1   2   >