Before this commit, expression statements could not be annotated
with statement attributes. Whenever parser found attribute, it
unconditionally assumed that it was followed by a declaration.
This not only doesn't allow expression attributes to have attributes,
but also produces spurious error diagnostics.
In order to maintain all previously compiled code, we still assume
that GNU attributes are followed by declarations unless ALL of those
are statement attributes. And even in this case we are not forcing
the parser to think that it should parse a statement, but rather
let it proceed as if no attributes were found.
Differential Revision: https://reviews.llvm.org/D93630
This reverts commit e48f444751cf781c42934b242b81f549da77bad0.
thakis noticed false reports, so reverting this change for now until
those can be sorted out.
See https://reviews.llvm.org/D71714
The attribute definition claimed the attribute was inheritable (which
only applies to declaration attributes) and not a statement attribute.
Further, it treats subject appertainment errors as being parse errors
rather than semantic errors, which leads to us accepting invalid code.
For instance, we currently fail to reject:
void foo() {
int i = 1000;
__attribute__((nomerge, opencl_unroll_hint(8)))
if (i) { foo(); }
}
This addresses the issues by clarifying that opencl_unroll_hint is a
statement attribute and handles its appertainment checks in the
semantic layer instead of the parsing layer. This changes the output of
the diagnostic text to be more consistent with other appertainment
errors.
In Clang today, we parse the different attribute syntaxes
(__attribute__, __declspec, and [[]]) in a fairly rigid order. This
leads to confusion for users when they guess the order incorrectly,
and leads to bug reports like PR24559 or necessitates changes like
D94788.
This patch adds a helper function to allow us to more easily parse
attributes in arbitrary order, and then updates all of the places
where we would parse two or more different syntaxes in a rigid order to
use the helper method. The patch does not attempt to handle Microsoft
attributes ([]) because those are ambiguous with other code constructs
and we don't have any attributes that use the syntax.
This test will fail with any toolchains that don't default to C11.
Adding this switch to the clang invocation in the test fixes the issue.
Patch by Justice Adams!
Reviewed By: dyung
Differential Revision: https://reviews.llvm.org/D94829
This patch removes the -f[no-]trapping-math flags from the -cc1 command line. These flags are ignored in the command line parser and their semantics is fully handled by -ffp-exception-mode.
This patch does not remove -f[no-]trapping-math from the driver command line. The driver flags are being used and do affect compilation.
Reviewed By: dexonsmith, SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D93395
This patch adds support for two new variants of the vectorize_width
pragma:
1. vectorize_width(X[, fixed|scalable]) where an optional second
parameter is passed to the vectorize_width pragma, which indicates if
the user wishes to use fixed width or scalable vectorization. For
example the user can now write something like:
#pragma clang loop vectorize_width(4, fixed)
or
#pragma clang loop vectorize_width(4, scalable)
In the absence of a second parameter it is assumed the user wants
fixed width vectorization, in order to maintain compatibility with
existing code.
2. vectorize_width(fixed|scalable) where the width is left unspecified,
but the user hints what type of vectorization they prefer, either
fixed width or scalable.
I have implemented this by making use of the LLVM loop hint attribute:
llvm.loop.vectorize.scalable.enable
Tests were added to
clang/test/CodeGenCXX/pragma-loop.cpp
for both the 'fixed' and 'scalable' optional parameter.
See this thread for context: http://lists.llvm.org/pipermail/cfe-dev/2020-November/067262.html
Differential Revision: https://reviews.llvm.org/D89031
The new clang internal extension '__cl_clang_function_pointers'
allows use of function pointers and other features that have
the same functionality:
- Use of member function pointers;
- Unrestricted use of references to functions;
- Virtual member functions.
This not a vendor extension and therefore it doesn't require any
special target support. Exposing this functionality fully
will require vendor or Khronos extension.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D94021
For a default visibility external linkage definition, dso_local is set for ELF
-fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar
to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences.
To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition,
which sets dso_local for default visibility external linkage definitions.
To make this flip smooth and enable future (dso_local as definition default),
this patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
Given the following code:
```
void Foo(int);
void Baz()
{
Bar(sizeof int);
}
```
The error message which is printed today is this:
```
error: expected parentheses around type name in sizeof expression
```
There is no source location printed whatsoever, so fixing a compile break like this becomes extremely hard in a large codebase.
My change improves the error message. But it doesn't output a FixItHint because I wasn't able to figure out how to get the locations for left and right parens. So any tips would be appreciated.
```
<source>:7:6: error: expected parentheses around type name in sizeof expression
Bar(sizeof int);
^
```
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D91129
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.
The dependency mechanism for C has been implemented, and we have rolled out
this to all internal users, didn't see crashy issues, we consider it is stable
enough.
Differential Revision: https://reviews.llvm.org/D89046
to synchronize with tools/clang-format/git-clang-format
tra: Keeping them in sync does have a minor benefit of not raising a question why the two maps are different.
Differential Revision: https://reviews.llvm.org/D91034
Pragma 'clang fp' is extended to support a new option, 'exceptions'. It
allows to specify floating point exception behavior more flexibly.
Differential Revision: https://reviews.llvm.org/D89849
This allows using annotation in a much more contexts than it currently has.
especially when annotation with template or constexpr.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D88645
The semantics associated with `__vector [un]signed long` are neither
consistently specified nor consistently implemented.
The IBM XL compilers on AIX traditionally treated these as deprecated
aliases for the corresponding `__vector int` type in both 32-bit and
64-bit modes. The newer, Clang-based, IBM XL compilers on AIX make usage
of the previously deprecated types an error. This is also consistent
with IBM XL C/C++ for Linux on Power (on little endian distributions).
In line with the above, this patch upgrades (on AIX) the deprecation of
`__vector long` to become removal.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D89443
The current C++ grammar allows an anonymous bit-field with an attribute,
but this is ambiguous (the attribute in that case could appertain to the
type instead of the bit-field). The current thinking in the Core Working
Group is that it's better to disallow attributes in that position at the
grammar level so that the ambiguity resolves in favor of applying to the
type.
During discussions about the behavior of the attribute, the Core Working
Group also felt it was better to disallow anonymous bit-fields from
specifying a default member initializer.
This implements both sets of related grammar changes.
This changes some diagnostics to use terminology from the standard
rather than invented terminology, which improves consistency with other
diagnostics as well. There are no functional changes intended other
than wording and naming.
This change implements pragma STDC FENV_ROUND, which is introduced by
the extension to standard (TS 18661-1). The pragma is implemented only
in frontend, it sets apprpriate state of FPOptions stored in Sema. Use
of these bits in constant evaluation adn/or code generator is not in the
scope of this change.
Parser issues warning on unsuppored pragma when it encounteres pragma
STDC FENV_ROUND, however it makes syntax checks and updates Sema state
as if the pragma were supported.
Primary purpose of the partial implementation is to facilitate
development of non-default floating poin environment. Previously a
developer cannot set non-default rounding mode in sources, this mades
preparing tests for say constant evaluation substantially complicated.
Differential Revision: https://reviews.llvm.org/D86921
-frewrite-includes.
Remove the special-case (and highly implausible) diagnostic for a
compound token that crosses a file boundary, and instead model that case
the same as a compound token separated by whitespace, so that file
transitions and presumed file transitions behave the same way.
Use of a linebreak between the `(` and `{` in a GNU statement-expression
appears to be too common to include this warning in -Wall -- this occurs
in some Linux kernel headers, for example.
For example:
#define FOO(x) (x)
FOO({});
... forms a statement-expression after macro expansion. This warning
applies to '({' and '})' delimiting statement-expressions, '[[' and ']]'
delimiting attributes, and '::*' introducing a pointer-to-member.
The warning for forming these compound tokens across macro expansions
(or across files!) is enabled by default; the warning for whitespace
within the tokens is not, but is included in -Wall.
Differential Revision: https://reviews.llvm.org/D86751
This is motivated by tooling (clangd, libclang etc) - headers without
declarations are legitimate even if they're not valid TUs.
The other use -x c-header cases (PCH/modules) are nonstandard anyway and this
warning doesn't seem necessary there either.
Differential Revision: https://reviews.llvm.org/D85789
No other compiler accepts this as an extension, not even in permissive
mode. We're not doing anyone any favors by allowing this, and it's
unlikely to be at all common, even in Clang-only code, in the wild.
Currently a capture-default which is not the first element in the lambda-capture
is diagnosed with a generic expected variable name or 'this' in lambda capture
list, which is true but not very helpful.
If we don't have already parsed a capture-default then a lone "&" or "=" is
likely to be a misplaced capture-default, so diagnose it as such.
Differential Revision: https://reviews.llvm.org/D83681
Reviewed By: aaron.ballman
- add more tests (the test added in 2f448467e4 is weak);
- improve the `MyTemplate<type_typo, int>();` case, with this patch, typo correction
suggests the type decl, and no regressions found.
Differential Revision: https://reviews.llvm.org/D83025
The DependentNameType must have a non-null NSS. This property could be
violated during typo correction.
Differential Revision: https://reviews.llvm.org/D82738
instead of postfix-expressions, and improve error recovery for postfix
operators after unary-expressions.
This covers nullptr, __null, and some calls to type traits with special
parsing rules. We would previously not parse a postfix-expression suffix
for these expressions, so would reject expressions such as
__is_trivial(int)["foo"].
For the case where a postfix-expression suffix is *not* permitted after
a unary-expression (for example, after a new-expression or sizeof
expression), produce a diagnostic if one appears there anyway. That's
always ill-formed, but previously produced very bad diagnostics.
Reland https://reviews.llvm.org/D76696
All known crashes have been fixed, another attemption.
We have rolled out this to all internal users for a while, didn't see
big issues, we consider it is stable enough.
Reviewed By: sammccall
Subscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78350
DiagnosticErrorTrap is usually inappropriate because it indicates
whether an error message was rendered in a given region (and is
therefore affected by -ferror-limit and by suppression of errors if we
see an invalid declaration).
hasErrorOccurred() is usually inappropriate because it indicates
whethere an "error:" message was displayed, regardless of whether the
message was a warning promoted to an error, and therefore depends on
things like -Werror that are usually irrelevant.
Where applicable, CodeSynthesisContexts are used to attach notes to
the first diagnostic produced in a region of code, isnstead of using an
error trap and then attaching a note to whichever diagnostic happened to
be produced last (or suppressing the note if the final diagnostic is a
disabled warning!).
This is mostly NFC.
Summary:
Asm goto is not supported by SLH. Warn if an instance of asm goto is detected
while SLH is enabled.
Test included.
Reviewed By: jyu2
Differential Revision: https://reviews.llvm.org/D79743
On the one hand, one might interpret the use of the max-token pragmas or
-fmax-tokens flag as an opt-in to the warning. However, in Chromium
we've found it useful to only opt in selected build configurations, even
though we have the pragmas in the code. For that reason, we think it
makes sense to turn it off by default.
Differential revision: https://reviews.llvm.org/D80014
Summary: Erroneous error diagnostic observed in VS2017 <numeric> header
Also correction to propagate usesFPIntrin from template func to instantiation.
Reviewers: rjmccall, erichkeane (no feedback received)
Differential Revision: https://reviews.llvm.org/D79631
This patch adds a matrix type to Clang as described in the draft
specification in clang/docs/MatrixSupport.rst. It introduces a new option
-fenable-matrix, which can be used to enable the matrix support.
The patch adds new MatrixType and DependentSizedMatrixType types along
with the plumbing required. Loads of and stores to pointers to matrix
values are lowered to memory operations on 1-D IR arrays. After loading,
the loaded values are cast to a vector. This ensures matrix values use
the alignment of the element type, instead of LLVM's large vector
alignment.
The operators and builtins described in the draft spec will will be added in
follow-up patches.
Reviewers: martong, rsmith, Bigcheese, anemet, dexonsmith, rjmccall, aaron.ballman
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D72281
Objective-C++11 and under MS extensions.
This matches the MSVC behavior, and means that Objective-C behaves as a
set of extensions to the base language, rather than replacing the base
language rule with a different one.
The 'class' or 'struct' keyword is only permitted as part of either an
enum definition or a standalone opaque-enum-declaration, not as part of
an elaborated type specifier. We previously failed to diagnose this, and
generally didn't properly implement the restrictions on elaborated type
specifiers for enumeration types.
In passing, also fixed incorrect parsing for enum-bases, which we
previously parsed as a type-name, but are actually a type-specifier-seq.
This matters for cases like 'enum E : int *p;', which is valid as a
Microsoft extension.
Plus some minor parse diagnostic improvements.
Bumped the recently-added ExtWarn for 'enum E : int x;' to be
DefaultError; this is not an intentional extension, so producing an
error by default seems appropriate, but the warning flag to disable it
may still be useful for code written against old Clang. The same
treatment is given here to the diagnostic for 'enum class E x;', which
we similarly have incorrectly accepted for many years. These diagnostics
continue to be suppressed under -fms-extensions and when compiling
Objective-C code. We will need to decide separately whether Objective-C
should follow the C++ rules or the (older) MSVC rules.
Previously we implemented non-standard disambiguation rules to
distinguish an enum-base from a bit-field but otherwise treated a :
after an elaborated-enum-specifier as introducing an enum-base. That
misparses various examples (anywhere an elaborated-type-specifier can
appear followed by a colon, such as within a ternary operator or
_Generic).
We now implement the C++11 rules, with the old cases accepted as
extensions where that seemed reasonable. These amount to:
* an enum-base must always be accompanied by an enum definition (except
in a standalone declaration of the form 'enum E : T;')
* in a member-declaration, 'enum E :' always introduces an enum-base,
never a bit-field
* in a type-specifier (or similar context), 'enum E :' is not
permitted; the colon means whatever else it would mean in that
context.
Fixed underlying types for enums are also permitted in Objective-C and
under MS extensions, plus as a language extension in all other modes.
The behavior in ObjC and MS extensions modes is unchanged (but the
bit-field disambiguation is a bit better); remaining language modes
follow the C++11 rules.
Fixes PR45726, PR39979, PR19810, PR44941, and most of PR24297, plus C++
core issues 1514 and 1966.
