[llvm-branch-commits] [clang] release/19.x: [ExprConstant] Handle shift overflow the same way as other kinds of overflow (#99579) (PR #100452)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

Just what was hopefully already merged: 
- Clang now diagnoses undefined behavior in constant expressions more 
consistently. This includes invalid shifts, and signed overflow in arithmetic.

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

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

Thank you for working on this!

I think we need these changes to be against `main` and not `19.x`, aside from 
the release notes (otherwise we're losing the documentation in 20.x). For the 
release notes, I think we can talk to @tstellar and @tru about getting the 19.x 
notes updated once we've finalized the wording for it.

One other change we should probably make at the same time is to update 
`Options.td` to use `HelpTextForVariants` so the help text for Flang does not 
suggest the option is deprecated in their driver.

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

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

[Aaron Ballman via llvm-branch-commits]

@@ -495,10 +495,12 @@ New Compiler Flags
 Deprecated Compiler Flags
 -
 
-- The ``-Ofast`` command-line option has been deprecated. This option both
-  enables the ``-O3`` optimization-level, as well as enabling non-standard
-  ``-ffast-math`` behaviors. As such, it is somewhat misleading as an
-  "optimization level". Users are advised to switch to ``-O3 -ffast-math`` if
+- The ``-Ofast`` command-line option has been deprecated, but there is no
+  timeline for removal yet. Thus, the main effect of emitting a deprecation
+  warning message is to discourage its usage due to the problems of ``-Ofast``:
+  it enables both the ``-O3`` optimization-level as well as non-standard
+  ``-ffast-math`` behaviors and as such it is perceived to be misleading as an
+  optimization level.  Users are advised to switch to ``-O3 -ffast-math`` if

AaronBallman wrote:

```suggestion
- The ``-Ofast`` command-line option has been deprecated, but there is no
  timeline for removal. Deprecation is intended to discourage use of the flag
  due to the problems of ``-Ofast``: it enables both the ``-O3`` optimization
  level as well as non-standard ``-ffast-math`` behaviors and as such it is
  misleading as an optimization level.  Users are advised to switch to
  ``-O3 -ffast-math`` if
```

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

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

[Aaron Ballman via llvm-branch-commits]

@@ -429,8 +429,11 @@ Code Generation Options
 
 :option:`-Ofast` Enables all the optimizations from :option:`-O3` along
 with other aggressive optimizations that may violate strict compliance with
-language standards. This is deprecated in favor of :option:`-O3`
-in combination with :option:`-ffast-math`.
+language standards. This is deprecated in Clang-19 and a warning is emitted
+that :option:`-O3` in combination with :option:`-ffast-math` should be used
+instead if the request for non-standard math behavior is intended. Thus, as
+there is no timeline yet for removal, the aim is to discourage its usage
+due to the compliance violating optimizations.

AaronBallman wrote:

```suggestion
instead if the request for non-standard math behavior is intended. 
There is no timeline yet for removal; the aim is to discourage use of 
:option:`-Ofast`
due to the surprising behavior of an optimization flag changing the 
observable
behavior of correct code.

```

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

[llvm-branch-commits] [clang] Ofast deprecation clarifications (PR #101005)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/101005
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [clang][Sema] Add support for OpenBSD's syslog format attribute (#97366) (PR #100703)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

I don't see a need to backport this for 19.x, it seems reasonable to let it 
bake for a while in 20.x (though I would be surprised if there was significant 
negative fallout from the changes).

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

[llvm-branch-commits] [clang] release/19.x: [clang][headers] Including stddef.h always redefines NULL (#99727) (PR #100191)

[Aaron Ballman via llvm-branch-commits]

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

LGTM, I think the CI failures are unrelated to this patch.

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> > Do you need me to land the changes on your behalf?
> 
> No need, I can do that. However, this PR is in a stack and depends on two 
> small PRs: #94244 and #94243 that need to be reviewed before this PR can be 
> merged

Ah thank you for pointing this out, I hadn't realized this was a patch stack.

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

[llvm-branch-commits] [clang] [clang][test] remove unused `run` overload in `BoundNodesCallback` (PR #94244)

[Aaron Ballman via llvm-branch-commits]

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

LGTM!

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> Thanks.
> 
> > ... how this impacts build times for Clang itself? I'm assuming that if 
> > ASTMatchers.h isn't modified, CMake won't re-run 
> > generate_ast_matcher_doc_tests.py and so the compile time performance hit 
> > is only on full rebuilds or when changing the header?
> 
> The 'state' of the generated file is only checked when the `ASTMatchersTests` 
> target is built, because it's the only thing that depends on the generated 
> file. And the file is only generated when: the file does not exist or 
> `ASTMatchers.h` has changed (excluding transitive changes in includes) or 
> `generate_ast_matcher_doc_tests.py` has changed.

Excellent, thank you for the confirmation! That sounds reasonable to me.

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

The changes generally LGTM, though I would appreciate a second set of eyes on 
the CMake and Python changes because I have a bit less confidence in my review 
abilities there.

Thank you for adding the documentation to the header file, I think that will 
help folks when working on their own matchers.

One question I have is: do you happen to know how this impacts build times for 
Clang itself? I'm assuming that if ASTMatchers.h isn't modified, CMake won't 
re-run `generate_ast_matcher_doc_tests.py` and so the compile time performance 
hit is only on full rebuilds or when changing the header?

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

@@ -330,35 +377,46 @@ AST_POLYMORPHIC_MATCHER_P(isExpandedFromMacro,
 
 /// Matches declarations.
 ///
-/// Examples matches \c X, \c C, and the friend declaration inside \c C;
+/// Given
 /// \code
 ///   void X();
 ///   class C {
-/// friend X;
+/// friend void X();
 ///   };
 /// \endcode
+/// \compile_args{-std=c++}
+/// The matcher \matcher{decl()}
+/// matches \match{void X()}, \match{type=name;count=2$C}
+/// and \match{count=2$friend void X()}.

AaronBallman wrote:

okay, thank you! I kind of figured it was the implicit class declaration.

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

@@ -176,11 +176,13 @@ inline internal::TrueMatcher anything() { return 
internal::TrueMatcher(); }
 /// \code
 ///   int X;
 ///   namespace NS {
-///   int Y;
+/// int Y;
 ///   }  // namespace NS
 /// \endcode
-/// decl(hasDeclContext(translationUnitDecl()))
-///   matches "int X", but not "int Y".
+/// \compile_args{-std=c++}
+/// The matcher \matcher{namedDecl(hasDeclContext(translationUnitDecl()))}
+/// matches \match{type=name$X} and \match{type=name$NS},

AaronBallman wrote:

Under what circumstances do you need to use this special `type=name$foo` syntax?

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/94248
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

I wonder if we should add some documentation to ASTMatchers.h about the new 
special syntax for comments so that users who hit test failures with the new 
automatic tests have some more help getting to a solution.

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

@@ -330,35 +377,46 @@ AST_POLYMORPHIC_MATCHER_P(isExpandedFromMacro,
 
 /// Matches declarations.
 ///
-/// Examples matches \c X, \c C, and the friend declaration inside \c C;
+/// Given
 /// \code
 ///   void X();
 ///   class C {
-/// friend X;
+/// friend void X();
 ///   };
 /// \endcode
+/// \compile_args{-std=c++}
+/// The matcher \matcher{decl()}
+/// matches \match{void X()}, \match{type=name;count=2$C}
+/// and \match{count=2$friend void X()}.

AaronBallman wrote:

Can you explain `\match{type=name;count=2$C}`? I can see it matching `class C`, 
but I'm wondering what the second match is (and should we add a comment 
explaining that other match?).

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

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/94248
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

It looks like precommit CI found relevant failures:
```
_bk;t=1717501095887FAILED: 
tools/clang/unittests/ASTMatchers/ASTMatchersDocTests.cpp 
_bk;t=1717501095887cmd.exe /C "cd /D 
C:\ws\src\build\tools\clang\unittests\ASTMatchers && 
C:\ws\src\clang\utils\generate_ast_matcher_doc_tests.py --input-file 
C:/ws/src/clang/include/clang/ASTMatchers/ASTMatchers.h --output-file 
C:/ws/src/build/tools/clang/unittests/ASTMatchers/ASTMatchersDocTests.cpp"
_bk;t=1717501095887  File 
"C:\ws\src\clang\utils\generate_ast_matcher_doc_tests.py", line 613
_bk;t=1717501099131const StringRef Code = R"cpp(\n{"\t#include 
\"cuda.h\"\n" if has_cuda else ""}{self.code})cpp";\n"""

_bk;t=1717501099131   
 ^

_bk;t=1717501099131SyntaxError: f-string expression part cannot include a 
backslash
```


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

[llvm-branch-commits] [NFCI][metadata][clang] Use create{Unlikely, Likely}BranchWeights (PR #89467)

[Aaron Ballman via llvm-branch-commits]

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

LGTM!

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

[llvm-branch-commits] [NFCI][metadata][clang] Use create{Unlikely, Likely}BranchWeights (PR #89467)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/89467
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

[Aaron Ballman via llvm-branch-commits]

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

I verified the layout seems reasonable in Visual Studio 2022; LGTM!

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

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> @AaronBallman Would you mind reviewing D89741 ? I was convinced a stakeholder 
> there but they decided to drop out instead of approving it.

Oh the fun of PR numbers now lining up with Phabricator numbers. I thought you 
meant https://reviews.llvm.org/D89741 and was very confused until I saw 
https://github.com/llvm/llvm-project/pull/89741. :-D I'll take a look!

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

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> @AaronBallman Thanks for having a look.
> 
> > With this patch, I get errors when loading a visual studio solution 
> > generated with these change, and all of clang's libraries are placed at the 
> > top level. The error is a dialog box saying "The solution already contains 
> > an item named 'clang'."
> 
> I got similar errors with "Unittest" and "UnitTest". I only solved it by 
> using "Unit". I am assuming this is because there is something else already 
> with that name but inconsistent case. I never seen this for this for 
> "Clang"/"clang", but it could be when not all patches from the series are 
> applied. Specifically I think clang-tools-extra may use "Clang"/"clang".
> 
> > Another thing (that is existing behavior) worth noting is that at some 
> > point, we lost the ability to browse directly to files in Visual Studio. 
> > Instead of going to `Clang Libraries->clangDriver->Source 
> > Files->ToolChain.cpp`, you have to go to `Object 
> > Libraries->obj.clangDriver->Source Files->ToolChain.cpp` which is pretty 
> > strange. Your patch doesn't change this, but if we're correcting folder 
> > structure behavior, we should probably address that at the same time if we 
> > can.
> 
> This is how CMake handles object libraries. There is one target 
> `obj.clangDriver` that builds all the *.obj file, and a library that is not 
> used. The target `clangDriver` then has a dependency on `obj.clangDriver` and 
> has its *.obj files added, but not the source files. This is to be able to 
> link a static library (`clangDriver_static.a`) and a dynamic library 
> (`clangDriver.so`) at the [same 
> time](https://github.com/llvm/llvm-project/blob/ca1bd5995f6ed934f9187305190a5abfac049173/llvm/cmake/modules/AddLLVM.cmake#L547)
>  but compiling the source files just once. I don't know the reason, but in 
> contrast to other subprojects Clang uses this build mode [even when building 
> just one 
> library](https://github.com/llvm/llvm-project/blob/ca1bd5995f6ed934f9187305190a5abfac049173/clang/cmake/modules/AddClang.cmake#L102).

Ah interesting, thank you for the explanation! I know at one point in time, 
this used to generate a more obvious layout for the solution file, so I was 
surprised by the change.

> There is an exception for XCode, and we could do the same for MSVC (or add 
> the source files as non-compiled sources to make them show up like 
> `ADDITIONAL_HEADERS` ). However, for this patch series I did not intent to 
> change anything about how the build system works.

SGTM! It might be useful to explore doing that, but I don't know how many folks 
are still generating solution files these days. Personally, I use MSVC's 
integrated CMake support which has its own set of problems but tends to be 
better than using a solution file (esp in terms of compilation times).

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

[llvm-branch-commits] [clang] [clang] Revise IDE folder structure (PR #89743)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

With this patch, I get errors when loading a visual studio solution generated 
with these change, and all of clang's libraries are placed at the top level. 
The error is a dialog box saying "The solution already contains an item named 
'clang'."

Another thing (that is existing behavior) worth noting is that at some point, 
we lost the ability to browse directly to files in Visual Studio. Instead of 
going to `Clang Libraries->clangDriver->Source Files->ToolChain.cpp`, you have 
to go to `Object Libraries->obj.clangDriver->Source Files->ToolChain.cpp` which 
is pretty strange. Your patch doesn't change this, but if we're correcting 
folder structure behavior, we should probably address that at the same time if 
we can.

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

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

[Aaron Ballman via llvm-branch-commits]

@@ -3464,6 +3464,34 @@ Query for this feature with 
``__has_builtin(__builtin_trap)``.
 
 ``__builtin_arm_trap`` is lowered to the ``llvm.aarch64.break`` builtin, and 
then to ``brk #payload``.
 
+``__builtin_allow_runtime_check``

AaronBallman wrote:

> It needs to be compiler time lowered, so I think it should literals.

In that case, I think we want *constant expression* not just literal, right? 
e.g.,
```
constexpr const char *name = "name of check";
if (__builtin_allow_runtime_check(name)) {
}
```
is still able to be lowered at compile time. The reason I ask is because I'm 
thinking about template metaprogramming cases where you might want to do 
something along the lines of:
```
template 
struct S {
  void mem_fun() {
if (__builtin_allow_runtime_check(Ty::check_name) && stuff) {
}
  }
};
```
but maybe this is not a compelling use case? I don't insist on constant 
expression support, more just trying to verify that we support the expected 
usage patterns.

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

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

[Aaron Ballman via llvm-branch-commits]

@@ -3464,6 +3464,54 @@ Query for this feature with 
``__has_builtin(__builtin_trap)``.
 
 ``__builtin_arm_trap`` is lowered to the ``llvm.aarch64.break`` builtin, and 
then to ``brk #payload``.
 
+``__builtin_allow_runtime_check``
+-
+
+``__builtin_allow_runtime_check`` return true if the check at the current
+program location should be executed. It is expected to be used to implement
+``assert`` like checks which can be safely removed by optimizer.
+
+**Syntax**:
+
+.. code-block:: c++
+
+bool __builtin_allow_runtime_check(const char* kind)
+
+**Example of use**:
+
+.. code-block:: c++
+
+  if (__builtin_allow_runtime_check("mycheck") && !ExpensiveCheck()) {
+ abort();
+  }
+
+**Description**
+
+``__builtin_allow_runtime_check`` is lowered to ` ``llvm.allow.runtime.check``
+`_
+builtin.
+
+The ``__builtin_allow_runtime_check()`` is expected to be used with control
+flow conditions such as in ``if`` to guard expensive runtime checks. The
+specific rules for selecting permitted checks can differ and are controlled by
+the compiler options.
+
+Flags to control checks:
+* ``-mllvm -lower-allow-check-percentile-cutoff-hot=N`` where N is PGO hotness
+cutoff in range ``[0, 99]`` to disallow checks in hot code.
+* ``-mllvm -lower-allow-check-random-rate=P`` where P is number in range
+``[0.0, 1.0]`` representation probability of keeping a check.
+* If both flags are specified, ``-lower-allow-check-random-rate`` takes
+precedence.
+* If none is specified, ``__builtin_allow_runtime_check`` is lowered as
+``true``, allowing all checks.
+
+Parameter ``kind`` is a string literal representing a user selected kind for
+guarded check. It's unused now. It will enable kind specific lowering in 
future.

AaronBallman wrote:

```suggestion
guarded check. It's unused now. It will enable kind-specific lowering in future.
```

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

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

[Aaron Ballman via llvm-branch-commits]

@@ -3464,6 +3464,34 @@ Query for this feature with 
``__has_builtin(__builtin_trap)``.
 
 ``__builtin_arm_trap`` is lowered to the ``llvm.aarch64.break`` builtin, and 
then to ``brk #payload``.
 
+``__builtin_allow_runtime_check``

AaronBallman wrote:

The docs aren't particularly clear to me -- why would the check at the current 
program location ever NOT be executed? What strings can be passed in? What 
compiler options impact it? Will it only accept string literals or are runtime 
values fine?

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

[llvm-branch-commits] [clang] [clang][builtin] Implement __builtin_allow_runtime_check (PR #87568)

[Aaron Ballman via llvm-branch-commits]

@@ -3233,6 +3233,17 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, 
unsigned BuiltinID,
 if (BuiltinCountZeroBitsGeneric(*this, TheCall))
   return ExprError();
 break;
+
+  case Builtin::BI__builtin_allow_runtime_check: {
+Expr *Arg = TheCall->getArg(0);
+// Check if the argument is a string literal.
+if (!isa(Arg->IgnoreParenImpCasts())) {

AaronBallman wrote:

This might be a reasonable restriction, but consider other cases like: 
`constexpr` variable of string type, `constexpr` function call that returns a 
`const char *`, `_Generic` that results in a string constant, etc. Would those 
be reasonable to support?

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> > LGTM, though it would be nice if @petrhosek or @Ericson2314 could validate 
> > the cmake changes (they look sensible to me, but I never know if there's a 
> > better way to do things in CMake).
> 
> We already did that above. Petr left a comment and it was fixed :p

Ah, I missed that entirely because the conversations were resolved. Phew, then 
yeah, LGTM!

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/86080
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

@@ -0,0 +1,44 @@
+//===- CIRDialect.td - CIR dialect -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file declares the CIR dialect.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_CIR_DIALECT_IR_CIRDIALECT
+#define LLVM_CLANG_CIR_DIALECT_IR_CIRDIALECT
+
+include "mlir/IR/OpBase.td"
+
+def CIR_Dialect : Dialect {
+  let name = "cir";
+
+  // A short one-line summary of our dialect.
+  let summary = "A high-level dialect for analyzing and optimizing Clang "
+"supported languages";
+
+  let cppNamespace = "::mlir::cir";
+
+  let useDefaultAttributePrinterParser = 0;
+  let useDefaultTypePrinterParser = 0;
+
+  let extraClassDeclaration = [{
+void registerAttributes();
+void registerTypes();
+
+Type parseType(DialectAsmParser ) const override;

AaronBallman wrote:

> This will be added to generated class which have lower-case starting APIs: 
> consistency within the class seems to prevail to me.

Ah, then yeah, I agree. Thank you!

> You should really expect that all the MLIR code will follow this convention, 
> because it'll be intertwined closely with the MLIR framework.

MLIR isn't old enough to really get "grandfathered" in with their own style, so 
that's pretty surprising. That said, I *fully support* letting projects have 
project-specific policies including coding style, so I see no reason for MLIR 
to change either. Interfacing closely with MLIR does make this a bit awkward 
however, because it's also intertwined with the Clang code base. On balance, I 
think it's fine to follow the MLIR convention because I think there will be 
more surface area in common between CIR + MLIR than CIR + Clang (and Clang has 
plenty of inconsistency with coding style already so this is not really novel).

tl;dr: nothing needs to change here.

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

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

LGTM, though it would be nice if @petrhosek or @Ericson2314 could validate the 
cmake changes (they look sensible to me, but I never know if there's a better 
way to do things in CMake).

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

@@ -0,0 +1,44 @@
+//===- CIRDialect.td - CIR dialect -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file declares the CIR dialect.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_CIR_DIALECT_IR_CIRDIALECT
+#define LLVM_CLANG_CIR_DIALECT_IR_CIRDIALECT
+
+include "mlir/IR/OpBase.td"
+
+def CIR_Dialect : Dialect {
+  let name = "cir";
+
+  // A short one-line summary of our dialect.
+  let summary = "A high-level dialect for analyzing and optimizing Clang "
+"supported languages";
+
+  let cppNamespace = "::mlir::cir";
+
+  let useDefaultAttributePrinterParser = 0;
+  let useDefaultTypePrinterParser = 0;
+
+  let extraClassDeclaration = [{
+void registerAttributes();
+void registerTypes();
+
+Type parseType(DialectAsmParser ) const override;

AaronBallman wrote:

Because this is new code, the parameter names should match the usual coding 
style for naming (start with a capital letter) for consistency with the rest of 
the code base.

Where do the definitions for these come from?

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

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

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

Sorry about leaving it in a "requests changes" state, LGTM!

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

[llvm-branch-commits] [clang] release/18.x [X86_64] fix SSE type error in vaarg (PR #86698)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> What are the current rules on cherry picks for old bugs? AFAICT this patch 
> wasn't fixing a bug introduced in the 17.x-18.x development region.

https://releases.llvm.org/17.0.1/docs/HowToReleaseLLVM.html#release-patch-rules 
has the documented rules.

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

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

I think this is reasonable, but leaving it to @erichkeane to make the final 
call.

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

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

Ah that's right, it was with definitions that we ran into the issue! Sorry for 
being slow today. Okay, I retract my concerns, this is a safe and targeted fix.

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

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

I think the 18.1 behavior is already correct?

https://godbolt.org/z/v3G7h44E1

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

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman milestoned 
https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

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

I don't think we should add this to the 18.x release -- we're already getting 
requests from users to not do that: 
https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20240408/566402.html

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

[llvm-branch-commits] [clang] release/18.x: [Headers] Don't declare unreachable() from stddef.h in C++ (#86748) (PR #87696)

[Aaron Ballman via llvm-branch-commits]

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

LGTM for backporting

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

[llvm-branch-commits] [clang] release/18.x: backport PR84230 (PR #86106)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> Hi @antoniofrighetto (or anyone else). If you would like to add a note about 
> this fix in the release notes (completely optional). Please reply to this 
> comment with a one or two sentence description of the fix.

How about we go with something along the lines of:

Fixed a Clang 18.x regression which increased binary size and stack usage with 
`-ftrivial-auto-var-init`. Fixes #GH84178.

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

[llvm-branch-commits] [clang] release/18.x: backport PR84230 (PR #86106)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman milestoned 
https://github.com/llvm/llvm-project/pull/86106
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

@@ -0,0 +1,18 @@
+//===-- CIROps.td - CIR dialect definition -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// Definition of the CIR dialect
+///
+//===--===//
+
+#ifndef MLIR_CIR_DIALECT_CIR_OPS

AaronBallman wrote:

Sorry I was unclear, I meant "as well" in reference to an earlier suggestion: 
https://github.com/llvm/llvm-project/pull/86080#discussion_r1533453807

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

@@ -0,0 +1,46 @@
+//===- CIRTypes.td - CIR dialect types -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file declares the CIR dialect.
+//
+//===--===//
+
+#ifndef MLIR_CIR_DIALECT_CIR
+#define MLIR_CIR_DIALECT_CIR
+
+include "mlir/IR/OpBase.td"
+
+def CIR_Dialect : Dialect {
+  let name = "cir";
+
+  // A short one-line summary of our dialect.
+  let summary = "A high-level dialect for analyzing and optimizing Clang "
+"supported languages";
+
+  let cppNamespace = "::mlir::cir";
+
+  let useDefaultAttributePrinterParser = 0;
+  let useDefaultTypePrinterParser = 0;

AaronBallman wrote:

Okay. so this is another case of MLIR not following the usual community 
policies, so this is outside of the scope of these patches and that's fine by 
me. Thanks for the explanation!

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

[llvm-branch-commits] [clang] [CIR][Basic][NFC] Add the CIR language to the Language enum (PR #86072)

[Aaron Ballman via llvm-branch-commits]

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

LGTM!

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

Generally LGTM as well, but added the CMake code owners for their opinions on 
those bits.

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

@@ -0,0 +1,18 @@
+//===-- CIROps.td - CIR dialect definition -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// Definition of the CIR dialect
+///
+//===--===//
+
+#ifndef MLIR_CIR_DIALECT_CIR_OPS

AaronBallman wrote:

Prefix with `CLANG_` as well?

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

@@ -0,0 +1,46 @@
+//===- CIRTypes.td - CIR dialect types -*- tablegen 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file declares the CIR dialect.
+//
+//===--===//
+
+#ifndef MLIR_CIR_DIALECT_CIR
+#define MLIR_CIR_DIALECT_CIR
+
+include "mlir/IR/OpBase.td"
+
+def CIR_Dialect : Dialect {
+  let name = "cir";
+
+  // A short one-line summary of our dialect.
+  let summary = "A high-level dialect for analyzing and optimizing Clang "
+"supported languages";
+
+  let cppNamespace = "::mlir::cir";
+
+  let useDefaultAttributePrinterParser = 0;
+  let useDefaultTypePrinterParser = 0;

AaronBallman wrote:

Should these follow the usual style guide for naming of member variables (start 
with a capital letter)?

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

[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/86080
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [CIR][cmake] Add support for cmake variable CLANG_ENABLE_CIR (PR #86078)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

The changes seem reasonable to me, but I've added the CMake code owners for 
final approval.

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

[llvm-branch-commits] [clang] release/18.x: backport PR84230 (PR #86106)

[Aaron Ballman via llvm-branch-commits]

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

LGTM!

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

[llvm-branch-commits] [clang] fix links on clang 18.1.0rc release page (PR #82739)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman milestoned 
https://github.com/llvm/llvm-project/pull/82739
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] fix links on clang 18.1.0rc release page (PR #82739)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman updated 
https://github.com/llvm/llvm-project/pull/82739

>From d3ae59831c804f18b3a415c71a7b392d07c40f94 Mon Sep 17 00:00:00 2001
From: "H. Vetinari" 
Date: Fri, 23 Feb 2024 19:03:59 +1100
Subject: [PATCH] fix links on clang 18.1.0rc release page

---
 clang/docs/ReleaseNotes.rst | 46 ++---
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 93a67e7a895592..2f590a51c959dd 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -58,12 +58,12 @@ code bases.
 
   To reduce such widespread breakages, as an extension, Clang accepts this code
   with an existing warning ``-Wambiguous-reversed-operator`` warning.
-  Fixes `GH `_.
+  Fixes `#53954 `_.
 
 - The CMake variable ``GCC_INSTALL_PREFIX`` (which sets the default
   ``--gcc-toolchain=``) is deprecated and will be removed. Specify
   ``--gcc-install-dir=`` or ``--gcc-triple=`` in a `configuration file
-  ` as a
+  `_ as a
   replacement.
   (`#77537 `_)
 
@@ -95,7 +95,7 @@ C/C++ Language Potentially Breaking Changes
 
 - Fixed a bug in finding matching `operator!=` while adding reversed 
`operator==` as
   outlined in "The Equality Operator You Are Looking For" (`P2468 
`_).
-  Fixes (`#68901: `_).
+  Fixes (`#68901 `_).
 
 C++ Specific Potentially Breaking Changes
 -
@@ -139,10 +139,10 @@ C++ Specific Potentially Breaking Changes
 
 - Remove the hardcoded path to the imported modules for C++20 named modules. 
Now we
   require all the dependent modules to specified from the command line.
-  See (`#62707: `_).
+  See (`#62707 `_).
 
 - Forbid `import XXX;` in C++ to find module `XXX` comes from explicit clang 
modules.
-  See (`#64755: `_).
+  See (`#64755 `_).
 
 ABI Changes in This Version
 ---
@@ -199,7 +199,7 @@ C++ Language Changes
 
 C++20 Feature Support
 ^
-- Implemented `P1907R1 ` which extends allowed 
non-type template argument
+- Implemented `P1907R1 `_ which extends allowed 
non-type template argument
   kinds with e.g. floating point values and pointers and references to 
subobjects.
   This feature is still experimental. Accordingly, 
``__cpp_nontype_template_args`` was not updated.
   However, its support can be tested with 
``__has_extension(cxx_generalized_nttp)``.
@@ -259,7 +259,7 @@ Resolutions to C++ Defect Reports
 
 - Implemented `CWG2598 `_ and `CWG2096 
`_,
   making unions (that have either no members or at least one literal member) 
literal types.
-  (`#77924: `_).
+  (`#77924 `_).
 
 
 C Language Changes
@@ -415,7 +415,7 @@ Attribute Changes in Clang
   types after default argument promotion. As a result, it's no longer an
   automatic diagnostic to use parameters of types that the format style
   supports but that are never the result of default argument promotion, such as
-  ``float``. (`#59824: `_)
+  ``float``. (`#59824 `_)
 
 - Clang now supports ``[[clang::preferred_type(type-name)]]`` as an attribute
   which can be applied to a bit-field. This attribute helps to map a bit-field
@@ -483,13 +483,13 @@ Improvements to Clang's diagnostics
 - Clang's ``-Wtautological-negation-compare`` flag now diagnoses logical
   tautologies like ``x && !x`` and ``!x || x`` in expressions. This also
   makes ``-Winfinite-recursion`` diagnose more cases.
-  (`#56035: `_).
+  (`#56035 `_).
 - Clang constexpr evaluator now diagnoses compound assignment operators against
   uninitialized variables as a read of uninitialized object.
   (`#51536 `_)
 - Clang's ``-Wformat-truncation`` now diagnoses ``snprintf`` call that is 
known to
   result in string truncation.
-  (`#64871: `_).
+  (`#64871 `_).
   Existing warnings that similarly warn about 

[llvm-branch-commits] [clang] fix links on clang 18.1.0rc release page (PR #82739)

[Aaron Ballman via llvm-branch-commits]

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

LGTM!

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

[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> > I'm OK with this kind of change if the AArch64 maintainers are on board. 
> > @AaronBallman Do you have a strong objection to this PR?
> 
> We don't typically backport _features_ unless there's some strongly 
> compelling case. This sounds like a nice-to-have but I'm not certain why it 
> can't wait for Clang 19 (and have more in-tree time to bake), especially 
> since rc3 is already out the door: 
> https://llvm.org/docs/HowToReleaseLLVM.html#release-patch-rules

To be clear, I'm not strongly opposed, I'm just trying to understand whether 
this meets our usual criteria and if it doesn't, what about this situation 
warrants an exception.

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

[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

> I'm OK with this kind of change if the AArch64 maintainers are on board. 
> @AaronBallman Do you have a strong objection to this PR?

We don't typically backport *features* unless there's some strongly compelling 
case. This sounds like a nice-to-have but I'm not certain why it can't wait for 
Clang 19 (and have more in-tree time to bake), especially since rc3 is already 
out the door: https://llvm.org/docs/HowToReleaseLLVM.html#release-patch-rules

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

[llvm-branch-commits] [clang] [llvm] release/18.x: [AArch64] Backport Ampere1B support (#81297 , #81341, and #81744) (PR #81857)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

Is this fixing a regression introduced in Clang 18? I'm wondering why the 
backport is needed in the first place, as this seems to be making potentially 
significant changes during the RC ("Make +pauth enabled in Armv8.3-a by 
default").

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

[llvm-branch-commits] [clang] PR for llvm/llvm-project#80961 (PR #80962)

[Aaron Ballman via llvm-branch-commits]

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

LGTM!

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

[llvm-branch-commits] [clang] PR for llvm/llvm-project#80843 (PR #80845)

[Aaron Ballman via llvm-branch-commits]

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

LGTM!

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

[llvm-branch-commits] [clang-tools-extra] [clang] Backport '[clang] static operators should evaluate object argument (reland)' to release/18.x (PR #80109)

[Aaron Ballman via llvm-branch-commits]

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

LGTM for 18.x, but another set of eyes verifying the fix looks safe would not 
be a bad thing, either.

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

[llvm-branch-commits] [clang] [clang-tools-extra] Backport '[clang] static operators should evaluate object argument (reland)' to release/18.x (PR #80109)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman milestoned 
https://github.com/llvm/llvm-project/pull/80109
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang-tools-extra] d6d36ba - Add a --use-color option to clang-query to allow forcing the behavior

[Aaron Ballman via llvm-branch-commits]

Author: Tom Ritter
Date: 2021-01-25T08:06:54-05:00
New Revision: d6d36baa33e76ace11ac20c03de1097d48bd9246

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

LOG: Add a --use-color option to clang-query to allow forcing the behavior

D62056 makes the output color if clang auto-detects a tty, but if it
does not, there is no way to force it to use colors anyway.

This patch adjusts the command-lines given to ClangTool which will
force color on or off if --use-color is specified.

Added: 


Modified: 
clang-tools-extra/clang-query/Query.cpp
clang-tools-extra/clang-query/tool/ClangQuery.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-query/Query.cpp 
b/clang-tools-extra/clang-query/Query.cpp
index ca2a285e9eb7..e33612a2e16d 100644
--- a/clang-tools-extra/clang-query/Query.cpp
+++ b/clang-tools-extra/clang-query/Query.cpp
@@ -156,8 +156,7 @@ bool MatchQuery::run(llvm::raw_ostream , QuerySession 
) const {
 if (QS.DetailedASTOutput) {
   OS << "Binding for \"" << BI->first << "\":\n";
   const ASTContext  = AST->getASTContext();
-  const SourceManager  = Ctx.getSourceManager();
-  ASTDumper Dumper(OS, Ctx, SM.getDiagnostics().getShowColors());
+  ASTDumper Dumper(OS, Ctx, AST->getDiagnostics().getShowColors());
   Dumper.SetTraversalKind(QS.TK);
   Dumper.Visit(BI->second);
   OS << "\n";

diff  --git a/clang-tools-extra/clang-query/tool/ClangQuery.cpp 
b/clang-tools-extra/clang-query/tool/ClangQuery.cpp
index 31c7f12251c9..45a355073945 100644
--- a/clang-tools-extra/clang-query/tool/ClangQuery.cpp
+++ b/clang-tools-extra/clang-query/tool/ClangQuery.cpp
@@ -49,6 +49,14 @@ using namespace llvm;
 static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);
 static cl::OptionCategory ClangQueryCategory("clang-query options");
 
+static cl::opt
+UseColor("use-color",
+ cl::desc(
+ R"(Use colors in detailed AST output. If not set, colors
+will be used if the terminal connected to
+standard output supports colors.)"),
+ cl::init(false), cl::cat(ClangQueryCategory));
+
 static cl::list Commands("c", cl::desc("Specify command to run"),
   cl::value_desc("command"),
   cl::cat(ClangQueryCategory));
@@ -109,6 +117,19 @@ int main(int argc, const char **argv) {
 
   ClangTool Tool(OptionsParser->getCompilations(),
  OptionsParser->getSourcePathList());
+
+  if (UseColor.getNumOccurrences() > 0) {
+ArgumentsAdjuster colorAdjustor = [](const CommandLineArguments , 
StringRef /*unused*/) {
+  CommandLineArguments AdjustedArgs = Args;
+  if (UseColor)
+AdjustedArgs.push_back("-fdiagnostics-color");
+  else
+AdjustedArgs.push_back("-fno-diagnostics-color");
+  return AdjustedArgs;
+};
+Tool.appendArgumentsAdjuster(colorAdjustor);
+  }
+
   std::vector> ASTs;
   int ASTStatus = 0;
   switch (Tool.buildASTs(ASTs)) {



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

[llvm-branch-commits] [clang] ef3800e - Return false from __has_declspec_attribute() if not explicitly enabled

[Aaron Ballman via llvm-branch-commits]

Author: Timm Bäder
Date: 2021-01-12T13:20:08-05:00
New Revision: ef3800e82169c674219501d9ac09ef12b28e6359

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

LOG: Return false from __has_declspec_attribute() if not explicitly enabled

Currently, projects can check for __has_declspec_attribute() and use
it accordingly, but the check for __has_declspec_attribute will return
true even if declspec attributes are not enabled for the target.

This changes Clang to instead return false when declspec attributes are
not supported for the target.

Added: 


Modified: 
clang/lib/Lex/PPMacroExpansion.cpp

Removed: 




diff  --git a/clang/lib/Lex/PPMacroExpansion.cpp 
b/clang/lib/Lex/PPMacroExpansion.cpp
index 3969630f2002..43d31d6c5732 100644
--- a/clang/lib/Lex/PPMacroExpansion.cpp
+++ b/clang/lib/Lex/PPMacroExpansion.cpp
@@ -1693,8 +1693,14 @@ void Preprocessor::ExpandBuiltinMacro(Token ) {
   [this](Token , bool ) -> int {
 IdentifierInfo *II = ExpectFeatureIdentifierInfo(Tok, *this,
diag::err_feature_check_malformed);
-return II ? hasAttribute(AttrSyntax::Declspec, nullptr, II,
- getTargetInfo(), getLangOpts()) : 0;
+if (II) {
+  const LangOptions  = getLangOpts();
+  return LangOpts.DeclSpecKeyword &&
+ hasAttribute(AttrSyntax::Declspec, nullptr, II,
+  getTargetInfo(), LangOpts);
+}
+
+return false;
   });
   } else if (II == Ident__has_cpp_attribute ||
  II == Ident__has_c_attribute) {



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

[llvm-branch-commits] [clang] 3484715 - Add -ansi option to CompileOnly group

[Aaron Ballman via llvm-branch-commits]

Author: Timm Bäder
Date: 2021-01-12T13:16:49-05:00
New Revision: 348471575d9c24bbfb124ca5eac1589de075da88

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

LOG: Add -ansi option to CompileOnly group

-ansi is documented as being the "same as -std=c89", but there are
differences when passing it to a link.

Adding -ansi to said group makes sense since it's supposed to be an
alias for -std=c89 and resolves this inconsistency.

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 d9586e086a9c..b441c1b4c169 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -800,7 +800,7 @@ def Z_Flag : Flag<["-"], "Z">, Group;
 def Z_Joined : Joined<["-"], "Z">;
 def all__load : Flag<["-"], "all_load">;
 def allowable__client : Separate<["-"], "allowable_client">;
-def ansi : Flag<["-", "--"], "ansi">;
+def ansi : Flag<["-", "--"], "ansi">, Group;
 def arch__errors__fatal : Flag<["-"], "arch_errors_fatal">;
 def arch : Separate<["-"], "arch">, Flags<[NoXarchOption]>;
 def arch__only : Separate<["-"], "arch_only">;



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

[llvm-branch-commits] [clang] b2ba686 - Refactoring the attribute plugin example to fit the new API

[Aaron Ballman via llvm-branch-commits]

Author: Yafei Liu
Date: 2020-12-21T08:24:09-05:00
New Revision: b2ba6867eac10874bd279c739639bdb9e60c1996

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

LOG: Refactoring the attribute plugin example to fit the new API

Make the example compile and the test case pass.

Added: 


Modified: 
clang/examples/Attribute/Attribute.cpp
clang/test/Frontend/plugin-attribute.cpp

Removed: 




diff  --git a/clang/examples/Attribute/Attribute.cpp 
b/clang/examples/Attribute/Attribute.cpp
index 998f175dae54..159b09e4b154 100644
--- a/clang/examples/Attribute/Attribute.cpp
+++ b/clang/examples/Attribute/Attribute.cpp
@@ -23,9 +23,10 @@ namespace {
 
 struct ExampleAttrInfo : public ParsedAttrInfo {
   ExampleAttrInfo() {
-// Can take an optional string argument (the check that the argument
-// actually is a string happens in handleDeclAttribute).
-OptArgs = 1;
+// Can take up to 15 optional arguments, to emulate accepting a variadic
+// number of arguments. This just illustrates how many arguments a
+// `ParsedAttrInfo` can hold, we will not use that much in this example.
+OptArgs = 15;
 // GNU-style __attribute__(("example")) and C++-style [[example]] and
 // [[plugin::example]] supported.
 static constexpr Spelling S[] = {{ParsedAttr::AS_GNU, "example"},
@@ -39,7 +40,7 @@ struct ExampleAttrInfo : public ParsedAttrInfo {
 // This attribute appertains to functions only.
 if (!isa(D)) {
   S.Diag(Attr.getLoc(), diag::warn_attribute_wrong_decl_type_str)
-<< Attr << "functions";
+  << Attr << "functions";
   return false;
 }
 return true;
@@ -55,23 +56,39 @@ struct ExampleAttrInfo : public ParsedAttrInfo {
   S.Diag(Attr.getLoc(), ID);
   return AttributeNotApplied;
 }
-// Check if we have an optional string argument.
-StringRef Str = "";
+// We make some rules here:
+// 1. Only accept at most 3 arguments here.
+// 2. The first argument must be a string literal if it exists.
+if (Attr.getNumArgs() > 3) {
+  unsigned ID = S.getDiagnostics().getCustomDiagID(
+  DiagnosticsEngine::Error,
+  "'example' attribute only accepts at most three arguments");
+  S.Diag(Attr.getLoc(), ID);
+  return AttributeNotApplied;
+}
+// If there are arguments, the first argument should be a string literal.
 if (Attr.getNumArgs() > 0) {
-  Expr *ArgExpr = Attr.getArgAsExpr(0);
+  auto *Arg0 = Attr.getArgAsExpr(0);
   StringLiteral *Literal =
-  dyn_cast(ArgExpr->IgnoreParenCasts());
-  if (Literal) {
-Str = Literal->getString();
-  } else {
-S.Diag(ArgExpr->getExprLoc(), diag::err_attribute_argument_type)
-<< Attr.getAttrName() << AANT_ArgumentString;
+  dyn_cast(Arg0->IgnoreParenCasts());
+  if (!Literal) {
+unsigned ID = S.getDiagnostics().getCustomDiagID(
+DiagnosticsEngine::Error, "first argument to the 'example' "
+  "attribute must be a string literal");
+S.Diag(Attr.getLoc(), ID);
 return AttributeNotApplied;
   }
+  SmallVector ArgsBuf;
+  for (unsigned i = 0; i < Attr.getNumArgs(); i++) {
+ArgsBuf.push_back(Attr.getArgAsExpr(i));
+  }
+  D->addAttr(AnnotateAttr::Create(S.Context, "example", ArgsBuf.data(),
+  ArgsBuf.size(), Attr.getRange()));
+} else {
+  // Attach an annotate attribute to the Decl.
+  D->addAttr(AnnotateAttr::Create(S.Context, "example", nullptr, 0,
+  Attr.getRange()));
 }
-// Attach an annotate attribute to the Decl.
-D->addAttr(AnnotateAttr::Create(S.Context, "example(" + Str.str() + ")",
-Attr.getRange()));
 return AttributeApplied;
   }
 };

diff  --git a/clang/test/Frontend/plugin-attribute.cpp 
b/clang/test/Frontend/plugin-attribute.cpp
index 571ede3dc0b1..969105927be5 100644
--- a/clang/test/Frontend/plugin-attribute.cpp
+++ b/clang/test/Frontend/plugin-attribute.cpp
@@ -1,25 +1,22 @@
-// RUN: %clang -fplugin=%llvmshlibdir/Attribute%pluginext -emit-llvm -S %s -o 
- 2>&1 | FileCheck %s --check-prefix=ATTRIBUTE
-// RUN: not %clang -fplugin=%llvmshlibdir/Attribute%pluginext -emit-llvm 
-DBAD_ATTRIBUTE -S %s -o - 2>&1 | FileCheck %s --check-prefix=BADATTRIBUTE
+// RUN: split-file %s %t
+// RUN: %clang -cc1 -load %llvmshlibdir/Attribute%pluginext -fsyntax-only 
-ast-dump -verify %t/good_attr.cpp | FileCheck %s
+// RUN: %clang -fplugin=%llvmshlibdir/Attribute%pluginext -fsyntax-only 
-Xclang -verify %t/bad_attr.cpp
 // REQUIRES: plugins, examples
+//--- good_attr.cpp
+// expected-no-diagnostics
+void fn1a() __attribute__((example)) 

[llvm-branch-commits] [clang] 2d2498e - No longer reject tag declarations in the clause-1 of a for loop.

[Aaron Ballman via llvm-branch-commits]

Author: Aaron Ballman
Date: 2020-12-18T07:56:17-05:00
New Revision: 2d2498ec6c42b12eae873257e6ddcefe8348

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

LOG: No longer reject tag declarations in the clause-1 of a for loop.

We currently reject this valid C construct by claiming it declares a
non-local variable: for (struct { int i; } s={0}; s.i != 0; s.i--) ;

We expected all declaration in the clause-1 declaration statement to be
a local VarDecl, but there can be other declarations involved such as a
tag declaration. This fixes PR35757.

Added: 


Modified: 
clang/lib/Sema/SemaStmt.cpp
clang/test/Sema/for.c

Removed: 




diff  --git a/clang/lib/Sema/SemaStmt.cpp b/clang/lib/Sema/SemaStmt.cpp
index d89dfaf78a9c..8d0ebe7e2409 100644
--- a/clang/lib/Sema/SemaStmt.cpp
+++ b/clang/lib/Sema/SemaStmt.cpp
@@ -1822,15 +1822,27 @@ StmtResult Sema::ActOnForStmt(SourceLocation ForLoc, 
SourceLocation LParenLoc,
   // C99 6.8.5p3: The declaration part of a 'for' statement shall only
   // declare identifiers for objects having storage class 'auto' or
   // 'register'.
+  const Decl *NonVarSeen = nullptr;
+  bool VarDeclSeen = false;
   for (auto *DI : DS->decls()) {
-VarDecl *VD = dyn_cast(DI);
-if (VD && VD->isLocalVarDecl() && !VD->hasLocalStorage())
-  VD = nullptr;
-if (!VD) {
-  Diag(DI->getLocation(), diag::err_non_local_variable_decl_in_for);
-  DI->setInvalidDecl();
+if (VarDecl *VD = dyn_cast(DI)) {
+  VarDeclSeen = true;
+  if (VD->isLocalVarDecl() && !VD->hasLocalStorage()) {
+Diag(DI->getLocation(), diag::err_non_local_variable_decl_in_for);
+DI->setInvalidDecl();
+  }
+} else if (!NonVarSeen) {
+  // Keep track of the first non-variable declaration we saw so that
+  // we can diagnose if we don't see any variable declarations. This
+  // covers a case like declaring a typedef, function, or structure
+  // type rather than a variable.
+  NonVarSeen = DI;
 }
   }
+  // Diagnose if we saw a non-variable declaration but no variable
+  // declarations.
+  if (NonVarSeen && !VarDeclSeen)
+Diag(NonVarSeen->getLocation(), diag::err_non_variable_decl_in_for);
 }
   }
 

diff  --git a/clang/test/Sema/for.c b/clang/test/Sema/for.c
index b998f4b07cf0..d0c2f7f21a96 100644
--- a/clang/test/Sema/for.c
+++ b/clang/test/Sema/for.c
@@ -2,6 +2,12 @@
 
 // Check C99 6.8.5p3
 void b1 (void) { for (void (*f) (void);;); }
-void b2 (void) { for (void f (void);;); }   // expected-error {{declaration of 
non-local variable}}
+void b2 (void) { for (void f (void);;); }   // expected-error {{non-variable 
declaration in 'for' loop}}
 void b3 (void) { for (static int f;;); }// expected-error {{declaration of 
non-local variable}}
-void b4 (void) { for (typedef int f;;); }   // expected-error {{declaration of 
non-local variable}}
+void b4 (void) { for (typedef int f;;); }   // expected-error {{non-variable 
declaration in 'for' loop}}
+void b5 (void) { for (struct { int i; } s;;); }
+void b6 (void) { for (enum { zero, ten = 10 } i;;); }
+void b7 (void) { for (struct s { int i; };;); } // expected-error 
{{non-variable declaration in 'for' loop}}
+void b8 (void) { for (static struct { int i; } s;;); } // expected-error 
{{declaration of non-local variable}}
+void b9 (void) { for (struct { int i; } (*s)(struct { int j; } o) = 0;;); }
+void b10(void) { for (typedef struct { int i; } (*s)(struct { int j; });;); } 
// expected-error {{non-variable declaration in 'for' loop}}



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

[llvm-branch-commits] [clang-tools-extra] e69e551 - new altera single work item barrier check

[Aaron Ballman via llvm-branch-commits]

Author: Frank Derry Wanye
Date: 2020-12-18T07:52:20-05:00
New Revision: e69e551e0e5fddffb6479da6a2998457104ba9e6

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

LOG: new altera single work item barrier check

This lint check is a part of the FLOCL (FPGA Linters for OpenCL)
project out of the Synergy Lab at Virginia Tech.

FLOCL is a set of lint checks aimed at FPGA developers who write code
in OpenCL.

The altera single work item barrier check finds OpenCL kernel functions
that call a barrier function but do not call an ID function. These
kernel functions will be treated as single work-item kernels, which
could be inefficient or lead to errors.

Based on the "Altera SDK for OpenCL: Best Practices Guide."

Added: 
clang-tools-extra/clang-tidy/altera/SingleWorkItemBarrierCheck.cpp
clang-tools-extra/clang-tidy/altera/SingleWorkItemBarrierCheck.h
clang-tools-extra/docs/clang-tidy/checks/altera-single-work-item-barrier.rst

clang-tools-extra/test/clang-tidy/checkers/altera-single-work-item-barrier.cpp

Modified: 
clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
clang-tools-extra/clang-tidy/altera/CMakeLists.txt
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp 
b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
index d3e906b673ce..a328f05da5d0 100644
--- a/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
+++ b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
@@ -10,6 +10,7 @@
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
 #include "KernelNameRestrictionCheck.h"
+#include "SingleWorkItemBarrierCheck.h"
 #include "StructPackAlignCheck.h"
 
 using namespace clang::ast_matchers;
@@ -23,6 +24,8 @@ class AlteraModule : public ClangTidyModule {
   void addCheckFactories(ClangTidyCheckFactories ) override {
 CheckFactories.registerCheck(
 "altera-kernel-name-restriction");
+CheckFactories.registerCheck(
+"altera-single-work-item-barrier");
 CheckFactories.registerCheck(
 "altera-struct-pack-align");
   }

diff  --git a/clang-tools-extra/clang-tidy/altera/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/altera/CMakeLists.txt
index 8ab5cc1aa4ad..0765b9735cf9 100644
--- a/clang-tools-extra/clang-tidy/altera/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/altera/CMakeLists.txt
@@ -6,6 +6,7 @@ set(LLVM_LINK_COMPONENTS
 add_clang_library(clangTidyAlteraModule
   AlteraTidyModule.cpp
   KernelNameRestrictionCheck.cpp
+  SingleWorkItemBarrierCheck.cpp
   StructPackAlignCheck.cpp
 
   LINK_LIBS

diff  --git 
a/clang-tools-extra/clang-tidy/altera/SingleWorkItemBarrierCheck.cpp 
b/clang-tools-extra/clang-tidy/altera/SingleWorkItemBarrierCheck.cpp
new file mode 100644
index ..759c81c34ca6
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/altera/SingleWorkItemBarrierCheck.cpp
@@ -0,0 +1,84 @@
+//===--- SingleWorkItemBarrierCheck.cpp - 
clang-tidy---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "SingleWorkItemBarrierCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace altera {
+
+void SingleWorkItemBarrierCheck::registerMatchers(MatchFinder *Finder) {
+  // Find any function that calls barrier but does not call an ID function.
+  // hasAttr(attr::Kind::OpenCLKernel) restricts it to only kernel functions.
+  // FIXME: Have it accept all functions but check for a parameter that gets an
+  // ID from one of the four ID functions.
+  Finder->addMatcher(
+  // Find function declarations...
+  functionDecl(
+  allOf(
+  // That are OpenCL kernels...
+  hasAttr(attr::Kind::OpenCLKernel),
+  // And call a barrier function (either 1.x or 2.x version)...
+  forEachDescendant(callExpr(callee(functionDecl(hasAnyName(
+ "barrier", 
"work_group_barrier"
+.bind("barrier")),
+  // But do not call an ID function.
+  unless(hasDescendant(callExpr(callee(functionDecl(
+  hasAnyName("get_global_id", "get_local_id", "get_group_id",
+ "get_local_linear_id"
+  .bind("function"),
+  this);
+}
+
+void 

[llvm-branch-commits] [clang] f500662 - Detect section type conflicts between functions and variables

[Aaron Ballman via llvm-branch-commits]

Author: Tomas Matheson
Date: 2020-12-17T11:43:47-05:00
New Revision: f50066292477fb26806336e5604615d0eddde399

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

LOG: Detect section type conflicts between functions and variables

If two variables are declared with __attribute__((section(name))) and
the implicit section types (e.g. read only vs writeable) conflict, an
error is raised. Extend this mechanism so that an error is raised if the
section type implied by a function's __attribute__((section)) conflicts
with that of another variable.

Added: 


Modified: 
clang/include/clang/AST/ASTContext.h
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaAttr.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/CodeGen/attributes.c
clang/test/Sema/attr-section.c
clang/test/SemaCXX/attr-section.cpp
clang/test/SemaObjC/method-attributes.m

Removed: 




diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index ff84eb52e96e..0c5d82b3e9aa 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -3086,13 +3086,12 @@ OPT_LIST(V)
   };
 
   struct SectionInfo {
-DeclaratorDecl *Decl;
+NamedDecl *Decl;
 SourceLocation PragmaSectionLocation;
 int SectionFlags;
 
 SectionInfo() = default;
-SectionInfo(DeclaratorDecl *Decl,
-SourceLocation PragmaSectionLocation,
+SectionInfo(NamedDecl *Decl, SourceLocation PragmaSectionLocation,
 int SectionFlags)
 : Decl(Decl), PragmaSectionLocation(PragmaSectionLocation),
   SectionFlags(SectionFlags) {}

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index ff0257634d9d..6b81494e8eff 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -9757,9 +9757,8 @@ class Sema final {
 PSK_CodeSeg,
   };
 
-  bool UnifySection(StringRef SectionName,
-int SectionFlags,
-DeclaratorDecl *TheDecl);
+  bool UnifySection(StringRef SectionName, int SectionFlags,
+NamedDecl *TheDecl);
   bool UnifySection(StringRef SectionName,
 int SectionFlags,
 SourceLocation PragmaSectionLocation);

diff  --git a/clang/lib/Sema/SemaAttr.cpp b/clang/lib/Sema/SemaAttr.cpp
index ae6c3ea7313e..5901bd66b7a6 100644
--- a/clang/lib/Sema/SemaAttr.cpp
+++ b/clang/lib/Sema/SemaAttr.cpp
@@ -481,9 +481,8 @@ void Sema::ActOnPragmaMSVtorDisp(PragmaMsStackAction Action,
   VtorDispStack.Act(PragmaLoc, Action, StringRef(), Mode);
 }
 
-bool Sema::UnifySection(StringRef SectionName,
-int SectionFlags,
-DeclaratorDecl *Decl) {
+bool Sema::UnifySection(StringRef SectionName, int SectionFlags,
+NamedDecl *Decl) {
   SourceLocation PragmaLocation;
   if (auto A = Decl->getAttr())
 if (A->isImplicit())

diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 954388dda82e..7750d713f927 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -3081,8 +3081,14 @@ static void handleSectionAttr(Sema , Decl *D, const 
ParsedAttr ) {
   }
 
   SectionAttr *NewAttr = S.mergeSectionAttr(D, AL, Str);
-  if (NewAttr)
+  if (NewAttr) {
 D->addAttr(NewAttr);
+if (isa(D))
+  S.UnifySection(NewAttr->getName(),
+ ASTContext::PSF_Execute | ASTContext::PSF_Read,
+ cast(D));
+  }
 }
 
 // This is used for `__declspec(code_seg("segname"))` on a decl.

diff  --git a/clang/test/CodeGen/attributes.c b/clang/test/CodeGen/attributes.c
index f6323e9be548..0c1455d3c612 100644
--- a/clang/test/CodeGen/attributes.c
+++ b/clang/test/CodeGen/attributes.c
@@ -63,11 +63,11 @@ void t72() { t71(); }
 // CHECK: call void @t71() [[COLDSITE:#[0-9]+]]
 // CHECK: declare void @t71() [[COLDDECL:#[0-9]+]]
 
-// CHECK: define void @t10() [[NUW]] section "SECT" {
-void t10(void) __attribute__((section("SECT")));
+// CHECK: define void @t10() [[NUW]] section "xSECT" {
+void t10(void) __attribute__((section("xSECT")));
 void t10(void) {}
-// CHECK: define void @t11() [[NUW]] section "SECT" {
-void __attribute__((section("SECT"))) t11(void) {}
+// CHECK: define void @t11() [[NUW]] section "xSECT" {
+void __attribute__((section("xSECT"))) t11(void) {}
 
 // CHECK: define i32 @t19() [[NUW]] {
 extern int t19(void) __attribute__((weak_import));

diff  --git a/clang/test/Sema/attr-section.c b/clang/test/Sema/attr-section.c
index bc4247411130..509c9752d8c3 100644
--- a/clang/test/Sema/attr-section.c
+++ b/clang/test/Sema/attr-section.c
@@ -26,9 +26,27 @@ extern int a __attribute__((section("foo,zed"))); // 
expected-warning {{section
 
 // Not 

[llvm-branch-commits] [clang] 7685d81 - Mark implicit coroutine variables as being implicit

[Aaron Ballman via llvm-branch-commits]

Author: Emma Blink
Date: 2020-12-16T14:42:07-05:00
New Revision: 7685d818ef329cd3f6ef121af1208be409eb59db

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

LOG: Mark implicit coroutine variables as being implicit

This prevents the clang-tidy readability-identifier-naming check from
triggering on implicit __coro_gro and __promise variables in coroutines.

Added: 

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/system/coroutines.h

Modified: 
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
clang/lib/Sema/SemaCoroutine.cpp

Removed: 




diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/system/coroutines.h
 
b/clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/system/coroutines.h
new file mode 100644
index ..b38dac52
--- /dev/null
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/system/coroutines.h
@@ -0,0 +1,34 @@
+#pragma once
+
+namespace std {
+namespace experimental {
+
+template 
+struct coroutine_traits {
+  using promise_type = typename ret_t::promise_type;
+};
+
+template 
+struct coroutine_handle {
+  static constexpr coroutine_handle from_address(void *addr) noexcept { return 
{}; };
+};
+
+} // namespace experimental
+} // namespace std
+
+struct never_suspend {
+  bool await_ready() noexcept { return false; }
+  template 
+  void await_suspend(coro_t handle) noexcept {}
+  void await_resume() noexcept {}
+};
+
+struct task {
+  struct promise_type {
+task get_return_object() noexcept { return {}; }
+never_suspend initial_suspend() noexcept { return {}; }
+never_suspend final_suspend() noexcept { return {}; }
+void return_void() {}
+void unhandled_exception() {}
+  };
+};

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
index 66b6009d62ae..f66202ecd11b 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
@@ -81,13 +81,14 @@
 // RUN: {key: readability-identifier-naming.LocalPointerPrefix, value: 
'l_'}, \
 // RUN: {key: readability-identifier-naming.LocalConstantPointerCase, 
value: CamelCase}, \
 // RUN: {key: readability-identifier-naming.LocalConstantPointerPrefix, 
value: 'lc_'}, \
-// RUN:   ]}' -- -fno-delayed-template-parsing -Dbad_macro \
+// RUN:   ]}' -- -fno-delayed-template-parsing -Dbad_macro -std=c++17 
-fcoroutines-ts \
 // RUN:   -I%S/Inputs/readability-identifier-naming \
 // RUN:   -isystem %S/Inputs/readability-identifier-naming/system
 
 // clang-format off
 
 #include 
+#include 
 #include "user-header.h"
 // NO warnings or fixes expected from declarations within header files without
 // the -header-filter= option
@@ -287,7 +288,7 @@ class COverriding : public AOverridden {
   // Overriding a badly-named base isn't a new violation.
   void BadBaseMethod() override {}
   // CHECK-FIXES: {{^}}  void v_Bad_Base_Method() override {}
-  
+
   void foo() {
 BadBaseMethod();
 // CHECK-FIXES: {{^}}v_Bad_Base_Method();
@@ -614,3 +615,14 @@ template
 auto GetRes(type_t& Param) -> decltype(Param.res());
 // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: invalid case style for parameter 
'Param'
 // CHECK-FIXES: auto GetRes(type_t& a_param) -> decltype(a_param.res());
+
+// Check implicit declarations in coroutines
+
+struct async_obj {
+public:
+  never_suspend operator co_await() const noexcept;
+};
+
+task ImplicitDeclTest(async_obj _object) {
+  co_await a_object;  // CHECK-MESSAGES-NOT: warning: invalid case style for 
local variable
+}

diff  --git a/clang/lib/Sema/SemaCoroutine.cpp 
b/clang/lib/Sema/SemaCoroutine.cpp
index 76820616fb9d..7a48bfa429e9 100644
--- a/clang/lib/Sema/SemaCoroutine.cpp
+++ b/clang/lib/Sema/SemaCoroutine.cpp
@@ -544,6 +544,7 @@ VarDecl *Sema::buildCoroutinePromise(SourceLocation Loc) {
   auto *VD = VarDecl::Create(Context, FD, FD->getLocation(), FD->getLocation(),
  ().get("__promise"), T,
  Context.getTrivialTypeSourceInfo(T, Loc), 
SC_None);
+  VD->setImplicit();
   CheckVariableDeclarationType(VD);
   if (VD->isInvalidDecl())
 return nullptr;
@@ -1577,6 +1578,7 @@ bool CoroutineStmtBuilder::makeGroDeclAndReturnStmt() {
   S.Context, , FD.getLocation(), FD.getLocation(),
   ().get("__coro_gro"), GroType,
   S.Context.getTrivialTypeSourceInfo(GroType, Loc), SC_None);
+  GroDecl->setImplicit();
 
   S.CheckVariableDeclarationType(GroDecl);
   if (GroDecl->isInvalidDecl())

[llvm-branch-commits] [clang] ef40d52 - Adding a test case that I accidentally dropped from 27ea7d0a6e0dc51e0214707bcc265fa6f9dc9bc6

[Aaron Ballman via llvm-branch-commits]

Author: Aaron Ballman
Date: 2020-12-15T14:56:44-05:00
New Revision: ef40d5233b8b6f82927128c5b255cdc3aed9021d

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

LOG: Adding a test case that I accidentally dropped from 
27ea7d0a6e0dc51e0214707bcc265fa6f9dc9bc6

Added: 
clang/test/Parser/attr-availability-xcore.c

Modified: 


Removed: 




diff  --git a/clang/test/Parser/attr-availability-xcore.c 
b/clang/test/Parser/attr-availability-xcore.c
new file mode 100644
index ..0b354a3d01e8
--- /dev/null
+++ b/clang/test/Parser/attr-availability-xcore.c
@@ -0,0 +1,11 @@
+// Test availability message string type when wide characters are 1 byte.
+// REQUIRES: xcore-registered-target
+// RUN: %clang_cc1 -triple xcore -fsyntax-only -verify %s
+
+#if !__has_feature(attribute_availability)
+#  error 'availability' attribute is not available
+#endif
+
+void f7() __attribute__((availability(macosx,message=L"wide"))); // 
expected-error {{expected string literal for optional message in 'availability' 
attribute}}
+
+void f8() __attribute__((availability(macosx,message="a" L"b"))); // 
expected-error {{expected string literal for optional message in 'availability' 
attribute}}



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

[llvm-branch-commits] [clang-tools-extra] c6348e8 - cppcoreguidelines Narrowing Conversions Check: detect narrowing conversions involving typedefs

[Aaron Ballman via llvm-branch-commits]

Author: Eric Seidel
Date: 2020-12-08T13:10:41-05:00
New Revision: c6348e8c95ee1eaa9dd2322b278def7a4127ff26

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

LOG: cppcoreguidelines Narrowing Conversions Check: detect narrowing 
conversions involving typedefs

The check 'cppcoreguidelines-narrowing-conversions' does not detect conversions
involving typedef. This notably includes the standard fixed-width integer types
like int32_t, uint64_t, etc. Now look through the typedefs at the desugared 
type.

Added: 


Modified: 
clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
index 1837ccb6002f..3ab300dc499f 100644
--- 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
+++ 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
@@ -48,8 +48,10 @@ void NarrowingConversionsCheck::registerMatchers(MatchFinder 
*Finder) {
   Finder->addMatcher(
   traverse(
   ast_type_traits::TK_AsIs,
-  implicitCastExpr(hasImplicitDestinationType(builtinType()),
-   hasSourceExpression(hasType(builtinType())),
+  implicitCastExpr(hasImplicitDestinationType(
+   hasUnqualifiedDesugaredType(builtinType())),
+   hasSourceExpression(hasType(
+   hasUnqualifiedDesugaredType(builtinType(,
unless(hasSourceExpression(IsCeilFloorCallExpr)),
unless(hasParent(castExpr())),
unless(isInTemplateInstantiation()))
@@ -58,16 +60,18 @@ void 
NarrowingConversionsCheck::registerMatchers(MatchFinder *Finder) {
 
   // Binary operators:
   //   i += 0.5;
-  Finder->addMatcher(binaryOperator(isAssignmentOperator(),
-hasLHS(expr(hasType(builtinType(,
-hasRHS(expr(hasType(builtinType(,
-unless(hasRHS(IsCeilFloorCallExpr)),
-unless(isInTemplateInstantiation()),
-// The `=` case generates an implicit cast
-// which is covered by the previous 
matcher.
-unless(hasOperatorName("=")))
- .bind("binary_op"),
- this);
+  Finder->addMatcher(
+  binaryOperator(
+  isAssignmentOperator(),
+  hasLHS(expr(hasType(hasUnqualifiedDesugaredType(builtinType(),
+  hasRHS(expr(hasType(hasUnqualifiedDesugaredType(builtinType(),
+  unless(hasRHS(IsCeilFloorCallExpr)),
+  unless(isInTemplateInstantiation()),
+  // The `=` case generates an implicit cast
+  // which is covered by the previous matcher.
+  unless(hasOperatorName("=")))
+  .bind("binary_op"),
+  this);
 }
 
 static const BuiltinType *getBuiltinType(const Expr ) {

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions.cpp
index cc817a021fde..493a447913bd 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions.cpp
@@ -343,4 +343,17 @@ void macro_context() {
   DERP(i, .5l);
 }
 
+// We understand typedefs.
+void typedef_context() {
+  typedef long long myint64_t;
+  int i;
+  myint64_t i64;
+
+  i64 = i64; // Okay, no conversion.
+  i64 = i;   // Okay, no narrowing.
+
+  i = i64;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 
'myint64_t' (aka 'long long') to signed type 'int' is implementation-defined 
[cppcoreguidelines-narrowing-conversions]
+}
+
 } // namespace floats



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

[llvm-branch-commits] [clang] 27ea7d0 - Fix inconsistent availability attribute message string literal check.

[Aaron Ballman via llvm-branch-commits]

Author: Nigel Perks
Date: 2020-12-08T12:33:59-05:00
New Revision: 27ea7d0a6e0dc51e0214707bcc265fa6f9dc9bc6

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

LOG: Fix inconsistent availability attribute message string literal check.

Function Parser::ParseAvailabilityAttribute checks that the message string of
an availability attribute is not a wide string literal. Test case
clang/test/Parser/attr-availability.c specifies that a string literal is
expected.

The code checked that the first token in a string concatenation is a string
literal, and then that the concatenated string consists of 1-byte characters.
On a target where wide character is 1 byte, a string concatenation "a" L"b"
passes both those checks, but L"b" alone is rejected. More generally, "a" u8"b"
passes the checks, but u8"b" alone is rejected.

So check isAscii() instead of character size.

Added: 


Modified: 
clang/lib/Parse/ParseDecl.cpp
clang/test/Parser/attr-availability.c

Removed: 




diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 7ebf06a04fa7..780d48958cb9 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -1119,7 +1119,7 @@ void Parser::ParseAvailabilityAttribute(IdentifierInfo 
,
   // Also reject wide string literals.
   if (StringLiteral *MessageStringLiteral =
   cast_or_null(MessageExpr.get())) {
-if (MessageStringLiteral->getCharByteWidth() != 1) {
+if (!MessageStringLiteral->isAscii()) {
   Diag(MessageStringLiteral->getSourceRange().getBegin(),
diag::err_expected_string_literal)
 << /*Source='availability attribute'*/ 2;

diff  --git a/clang/test/Parser/attr-availability.c 
b/clang/test/Parser/attr-availability.c
index d812296d9354..d3b640a2feea 100644
--- a/clang/test/Parser/attr-availability.c
+++ b/clang/test/Parser/attr-availability.c
@@ -22,6 +22,14 @@ void f7() 
__attribute__((availability(macosx,message=L"wide"))); // expected-err
 
 void f8() __attribute__((availability(macosx,message="a" L"b"))); // 
expected-error {{expected string literal for optional message in 'availability' 
attribute}}
 
+void f9() __attribute__((availability(macosx,message=u8"b"))); // 
expected-error {{expected string literal for optional message in 'availability' 
attribute}}
+
+void f10() __attribute__((availability(macosx,message="a" u8"b"))); // 
expected-error {{expected string literal for optional message in 'availability' 
attribute}}
+
+void f11() __attribute__((availability(macosx,message=u"b"))); // 
expected-error {{expected string literal for optional message in 'availability' 
attribute}}
+
+void f12() __attribute__((availability(macosx,message="a" u"b"))); // 
expected-error {{expected string literal for optional message in 'availability' 
attribute}}
+
 // rdar://10095131
 enum E{
 gorf __attribute__((availability(macosx,introduced=8.5, message = 10.0))), 
// expected-error {{expected string literal for optional message in 
'availability' attribute}}



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

[llvm-branch-commits] [clang-tools-extra] ed242da - Fix a typo in the documentation to unbreak the sphinx builder.

[Aaron Ballman via llvm-branch-commits]

Author: Aaron Ballman
Date: 2020-11-25T07:34:08-05:00
New Revision: ed242da0ffa28493d8a5ee6b80ecbe2441ca48a7

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

LOG: Fix a typo in the documentation to unbreak the sphinx builder.

Added: 


Modified: 
clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst 
b/clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst
index b744d21b6ff8..68c0abfcbdf6 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst
@@ -680,7 +680,7 @@ After:
 When defined, the check will ensure enumeration names will add the
 prefixed with the given value (regardless of casing).
 
-.. option:: EnumConstantIgnoredRegexp
+.. option:: EnumIgnoredRegexp
 
 Identifier naming checks won't be enforced for enumeration names
 matching this regular expression.



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

[llvm-branch-commits] [clang] 00dad9d - Ignore noderef attribute in unevaluated context

[Aaron Ballman via llvm-branch-commits]

Author: Jann Horn
Date: 2020-11-23T08:10:35-05:00
New Revision: 00dad9d028ce31739b992a3ce2df5de054a9fa3c

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

LOG: Ignore noderef attribute in unevaluated context

The noderef attribute is for catching code that accesses pointers in
a different address space. Unevaluated code is always safe in that regard.

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaExprMember.cpp
clang/test/Frontend/noderef.c
clang/test/Frontend/noderef.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 60a685bfdf15..5580cdf13691 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -4751,6 +4751,9 @@ void Sema::CheckAddressOfNoDeref(const Expr *E) {
 }
 
 void Sema::CheckSubscriptAccessOfNoDeref(const ArraySubscriptExpr *E) {
+  if (isUnevaluatedContext())
+return;
+
   QualType ResultTy = E->getType();
   ExpressionEvaluationContextRecord  = ExprEvalContexts.back();
 
@@ -14666,7 +14669,8 @@ ExprResult Sema::CreateBuiltinUnaryOp(SourceLocation 
OpLoc,
 OpLoc, CanOverflow, CurFPFeatureOverrides());
 
   if (Opc == UO_Deref && UO->getType()->hasAttr(attr::NoDeref) &&
-  !isa(UO->getType().getDesugaredType(Context)))
+  !isa(UO->getType().getDesugaredType(Context)) &&
+  !isUnevaluatedContext())
 ExprEvalContexts.back().PossibleDerefs.insert(UO);
 
   // Convert the result back to a half vector.

diff  --git a/clang/lib/Sema/SemaExprMember.cpp 
b/clang/lib/Sema/SemaExprMember.cpp
index 93ed756e084b..23cfae81df46 100644
--- a/clang/lib/Sema/SemaExprMember.cpp
+++ b/clang/lib/Sema/SemaExprMember.cpp
@@ -1734,6 +1734,9 @@ ExprResult Sema::ActOnMemberAccessExpr(Scope *S, Expr 
*Base,
 }
 
 void Sema::CheckMemberAccessOfNoDeref(const MemberExpr *E) {
+  if (isUnevaluatedContext())
+return;
+
   QualType ResultTy = E->getType();
 
   // Do not warn on member accesses to arrays since this returns an array

diff  --git a/clang/test/Frontend/noderef.c b/clang/test/Frontend/noderef.c
index b072b995fcf6..3388f2a39992 100644
--- a/clang/test/Frontend/noderef.c
+++ b/clang/test/Frontend/noderef.c
@@ -57,12 +57,19 @@ int test() {
   p = &*(p + 1);
 
   // Struct member access
-  struct S NODEREF *s;  // expected-note 2 {{s declared here}}
+  struct S NODEREF *s; // expected-note 3 {{s declared here}}
   x = s->a;   // expected-warning{{dereferencing s; was declared with a 
'noderef' type}}
   x = (*s).b; // expected-warning{{dereferencing s; was declared with a 
'noderef' type}}
   p = >a;
   p = &(*s).b;
 
+  // Most things in sizeof() can't actually access memory
+  x = sizeof(s->a);  // ok
+  x = sizeof(*s);// ok
+  x = sizeof(s[0]);  // ok
+  x = sizeof(s->a + (s->b)); // ok
+  x = sizeof(int[++s->a]);   // expected-warning{{dereferencing s; was 
declared with a 'noderef' type}}
+
   // Nested struct access
   struct S2 NODEREF *s2_noderef;// expected-note 5 {{s2_noderef declared 
here}}
   p = s2_noderef->a;  // ok since result is an array in a struct

diff  --git a/clang/test/Frontend/noderef.cpp b/clang/test/Frontend/noderef.cpp
index 32d5ca34d1b1..68342a8e6467 100644
--- a/clang/test/Frontend/noderef.cpp
+++ b/clang/test/Frontend/noderef.cpp
@@ -6,6 +6,11 @@
 
 #define NODEREF __attribute__((noderef))
 
+// Stub out types for 'typeid' to work.
+namespace std {
+class type_info {};
+} // namespace std
+
 void Normal() {
   int NODEREF i;// expected-warning{{'noderef' can only be used on an 
array or pointer type}}
   int NODEREF *i_ptr;   // expected-note 2 {{i_ptr declared here}}
@@ -102,6 +107,18 @@ int ChildCall(NODEREF Child *child) { // 
expected-note{{child declared here}}
   return child->func();   // expected-warning{{dereferencing 
child; was declared with a 'noderef' type}}
 }
 
+std::type_info TypeIdPolymorphic(NODEREF A *a) { // expected-note{{a declared 
here}}
+  return typeid(*a); // 
expected-warning{{dereferencing a; was declared with a 'noderef' type}}
+}
+
+class SimpleClass {
+  int a;
+};
+
+std::type_info TypeIdNonPolymorphic(NODEREF SimpleClass *simple) {
+  return typeid(*simple);
+}
+
 template 
 class B {
   Ty NODEREF *member;



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