[clang] Reject non-declaration C++11 attributes on declarations

For backwards compatiblity, we emit only a warning instead of an error if the
attribute is one of the existing type attributes that we

[clang] Reject non-declaration C++11 attributes on declarations

For backwards compatiblity, we emit only a warning instead of an error if the
attribute is one of the existing type attributes that we have historically
allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU
syntax. (We will call these "legacy type attributes" below.)

The high-level changes that achieve this are:

- We introduce a new field `Declarator::DeclarationAttrs` (with appropriate
accessors) to store C++11 attributes occurring in the attribute-specifier-seq
at the beginning of a simple-declaration (and other similar declarations).
Previously, these attributes were placed on the `DeclSpec`, which made it
impossible to reconstruct later on whether the attributes had in fact been
placed on the decl-specifier-seq or ahead of the declaration.

- In the parser, we propgate declaration attributes and decl-specifier-seq
attributes separately until we can place them in
`Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively.

- In `ProcessDeclAttributes()`, in addition to processing declarator attributes,
we now also process the attributes from `Declarator::DeclarationAttrs` (except
if they are legacy type attributes).

- In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes,
we also process any legacy type attributes that occur in
`Declarator::DeclarationAttrs` (and emit a warning).

- We make `ProcessDeclAttribute` emit an error if it sees any non-declaration
attributes in C++11 syntax, except in the following cases:
- If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk`
- If the attribute is a legacy type attribute (in which case we only emit
a warning)

The standard justifies treating attributes at the beginning of a
simple-declaration and attributes after a declarator-id the same. Here are some
relevant parts of the standard:

- The attribute-specifier-seq at the beginning of a simple-declaration
"appertains to each of the entities declared by the declarators of the
init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3)

- "In the declaration for an entity, attributes appertaining to that entity can
appear at the start of the declaration and after the declarator-id for that
declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2)

- "The optional attribute-specifier-seq following a declarator-id appertains to
the entity that is declared."
(https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1)

The standard contains similar wording to that for a simple-declaration in other
similar types of declarations, for example:

- "The optional attribute-specifier-seq in a parameter-declaration appertains to
the parameter." (https://eel.is/c++draft/dcl.fct#3)

- "The optional attribute-specifier-seq in an exception-declaration appertains
to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1)

The new behavior is tested both on the newly added type attribute
`annotate_type`, for which we emit errors, and for the legacy type attribute
`address_space` (chosen somewhat randomly from the various legacy type
attributes), for which we emit warnings.

Depends On D111548

Reviewed By: aaron.ballman, rsmith

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

show more ...

[clang] Fix for "Bug 27113 - MSVC-compat __identifier implementation incomplete"

this patch fixes Bug 27113 by adding support for string literals to the
implementation of the MS extension __identifi

[clang] Fix for "Bug 27113 - MSVC-compat __identifier implementation incomplete"

this patch fixes Bug 27113 by adding support for string literals to the
implementation of the MS extension __identifier.

Differential revision: https://reviews.llvm.org/D100252

show more ...

Better diagnostics for anonymous bit-fields with attributes or an initializer.

The current C++ grammar allows an anonymous bit-field with an attribute,
but this is ambiguous (the attribute in that c

Better diagnostics for anonymous bit-fields with attributes or an initializer.

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.

show more ...

Use "default member initializer" instead of "in-class initializer" for diagnostics.

This changes some diagnostics to use terminology from the standard
rather than invented terminology, which improve

Use "default member initializer" instead of "in-class initializer" for diagnostics.

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.

show more ...

Enforce the C++11 anonymous enum bitfields check even for
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 ba

Enforce the C++11 anonymous enum bitfields check even for
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.

show more ...

Properly implement 'enum class' parsing.

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

Properly implement 'enum class' parsing.

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.

show more ...

Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and constants are represented.

Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expressi

Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and constants are represented.

Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expression that could be a canonical template argument, it
could be a constant lvalue base object, and so on. In addition, we
represented the UUID value as a string, whose source form we did not
preserve faithfully, and that we partially parsed in multiple different
places.

With this patch, we create an MSGuidDecl object to represent the
implicit object of type 'struct _GUID' created by a UuidAttr. Each
UuidAttr holds a pointer to its 'struct _GUID' and its original
(as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves
like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue
representation of the GUID on the MSGuidDecl and use it from constant
evaluation where needed.

This allows removing a lot of the special-case logic to handle these
expressions. Unfortunately, many parts of Clang assume there are only
a couple of interesting kinds of ValueDecl, so the total amount of
special-case logic is not really reduced very much.

This fixes a few bugs and issues:
* PR38490: we now support reading from GUID objects returned from
__uuidof during constant evaluation.
* Our Itanium mangling for a non-instantiation-dependent template
argument involving __uuidof no longer depends on which CXXUuidofExpr
template argument we happened to see first.
* We now predeclare ::_GUID, and permit use of __uuidof without
any header inclusion, better matching MSVC's behavior. We do not
predefine ::__s_GUID, though; that seems like a step too far.
* Our IR representation for GUID constants now uses the correct IR type
wherever possible. We will still fall back to using the
{i32, i16, i16, [8 x i8]}
layout if a definition of struct _GUID is not available. This is not
ideal: in principle the two layouts could have different padding.

Reviewers: rnk, jdoerfert

Subscribers: arphaman, cfe-commits, aeubanks

Tags: #clang

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

show more ...

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Not

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

This reinstates r360974, reverted in r360988, with a fix for a
static_assert failure on 32-bit builds: force Type base class to have
8-byte alignment like the rest of Clang's AST nodes.

llvm-svn: 360995

show more ...

Revert Refactor constant evaluation of typeid(T) to track a symbolic type_info object rather than tracking the originating expression.

This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40c

Revert Refactor constant evaluation of typeid(T) to track a symbolic type_info object rather than tracking the originating expression.

This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009)

llvm-svn: 360988

show more ...

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Not

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

llvm-svn: 360974

show more ...

[Sema][MSVC] Fix bogus microsoft-pure-definition warning on member function of class template

Clang emits a warning when using a pure specifier =0 in a function definition
at class scope (a MS-speci

[Sema][MSVC] Fix bogus microsoft-pure-definition warning on member function of class template

Clang emits a warning when using a pure specifier =0 in a function definition
at class scope (a MS-specific construct), when using -fms-extensions.
However, to detect this, it was using FD->isCanonicalDecl() on function
declaration, which was also detecting out-of-class definition of member
functions of class templates. Fix this by using !FD->isOutOfLine() instead.

Fixes PR21334.

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

Reviewed By: riccibruno

Reviewers: rnk, riccibruno

Patch By: Rudy Pons

llvm-svn: 358849

show more ...

[MS] Accept __unaligned as a qualifier on member function pointers

We need to treat __unaligned like the other 'cvr' qualifiers when it
appears at the end of a function prototype. We weren't doing t

[MS] Accept __unaligned as a qualifier on member function pointers

We need to treat __unaligned like the other 'cvr' qualifiers when it
appears at the end of a function prototype. We weren't doing that in
some tentative parsing.

Fixes PR36638.

llvm-svn: 326962

show more ...

Determine the attribute subject for diagnostics based on declarative information in DeclNodes.td. This greatly reduces the number of enumerated values used for more complex diagnostics; these are now

Determine the attribute subject for diagnostics based on declarative information in DeclNodes.td. This greatly reduces the number of enumerated values used for more complex diagnostics; these are now only required when the "attribute only applies to" diagnostic needs to be generated manually as part of semantic processing.

This also clarifies some terminology used by the diagnostic (methods -> Objective-C methods, fields -> non-static data members, etc).

Many of the tests needed to be updated in multiple places for the diagnostic wording tweaks. The first instance of the diagnostic for that attribute is fully specified and subsequent instances cut off the complete list (to make it easier if additional subjects are added in the future for the attribute).

llvm-svn: 319002

show more ...

Keep the IdentifierInfo in the Token for alternative operator keyword

The goal of this commit is to fix clang-format so it does not merge tokens when
using the alternative spelling keywords. (eg: "n

Keep the IdentifierInfo in the Token for alternative operator keyword

The goal of this commit is to fix clang-format so it does not merge tokens when
using the alternative spelling keywords. (eg: "not foo" should not become "notfoo")

The problem is that Preprocessor::HandleIdentifier used to drop the identifier info
from the token for these keyword. This means the first condition of
TokenAnnotator::spaceRequiredBefore is not met. We could add explicit check for
the spelling in that condition, but I think it is better to keep the IdentifierInfo
and handle the operator keyword explicitly when needed. That actually leads to simpler
code, and probably slightly more efficient as well.

Another side effect of this change is that __identifier(and) will now work as
one would expect, removing a FIXME from the MicrosoftExtensions.cpp test

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

llvm-svn: 308008

show more ...

Revert MSVC CXXOperatorNames patch due to issues with Chromium

llvm-svn: 303882

For Microsoft compatibility, set fno_operator_names

There's a Microsoft header in the Windows SDK which won't
compile with clang because it uses an operator name (and)
as a field name. This patch

For Microsoft compatibility, set fno_operator_names

There's a Microsoft header in the Windows SDK which won't
compile with clang because it uses an operator name (and)
as a field name. This patch allows that file to compile by
setting the option which disables operator names.
The header which doesn't compile <Query.h> C:/Program Files (x86)/
Windows Kits/10/include/10.0.14393.0/um\Query.h:259:40:
error: expected member name or ';' after declaration specifiers

/* [case()] */ NODERESTRICTION or;
~~~~~~~~~~~~~~~ ^

1 error generated.

Contributed for Melanie Blower

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

llvm-svn: 303798

show more ...

Warn that the [] spelling of uuid(...) is deprecated.

https://reviews.llvm.org/D32879

llvm-svn: 302255

__uuidof() and declspec(uuid("...")) should be allowed on enumeration types

Although not specifically mentioned in the documentation, MSVC accepts
__uuidof(…) and declspec(uuid("…")) attributes on e

__uuidof() and declspec(uuid("...")) should be allowed on enumeration types

Although not specifically mentioned in the documentation, MSVC accepts
__uuidof(…) and declspec(uuid("…")) attributes on enumeration types in
addition to structs/classes. This is meaningful, as such types *do* have
associated UUIDs in ActiveX typelibs, and such attributes are included
by default in the wrappers generated by their #import construct, so they
are not particularly unusual.

clang currently rejects the declspec with a –Wignored-attributes
warning, and errors on __uuidof() with “cannot call operator __uuidof on
a type with no GUID” (because it rejected the uuid attribute, and
therefore finds no value). This is causing problems for us while trying
to use clang-tidy on a codebase that makes heavy use of ActiveX.

I believe I have found the relevant places to add this functionality,
this patch adds this case to clang’s implementation of these MS
extensions. patch is against r285994 (or actually the git mirror
80464680ce).

Both include an update to test/Parser/MicrosoftExtensions.cpp to
exercise the new functionality.

This is my first time contributing to LLVM, so if I’ve missed anything
else needed to prepare this for review just let me know!

__uuidof: https://msdn.microsoft.com/en-us/library/zaah6a61.aspx
declspec(uuid("…")): https://msdn.microsoft.com/en-us/library/3b6wkewa.aspx
#import: https://msdn.microsoft.com/en-us/library/8etzzkb6.aspx

Reviewers: aaron.ballman, majnemer, rnk

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

llvm-svn: 289567

show more ...

[ms] Add support for parsing uuid as a Microsoft attribute.

Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:

[uuid("....

[ms] Add support for parsing uuid as a Microsoft attribute.

Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:

[uuid("....")] class IBufferByteAccess {};

To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it. Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.

Final part of https://reviews.llvm.org/D23895

llvm-svn: 280578

show more ...

Ignore the "novtable" declspec when not using the Microsoft C++ ABI.

Clang used to silently ignore __declspec(novtable). It is implemented
now, but leaving the vtable uninitialized does not work whe

Ignore the "novtable" declspec when not using the Microsoft C++ ABI.

Clang used to silently ignore __declspec(novtable). It is implemented
now, but leaving the vtable uninitialized does not work when using the
Itanium ABI, where the class layout for complex class hierarchies is
stored in the vtable. It might be possible to honor the novtable
attribute in some simple cases and either report an error or ignore
it in more complex situations, but it’s not clear if that would be
worthwhile. There is also value in having a simple and predictable
behavior, so this changes clang to simply ignore novtable when not using
the Microsoft C++ ABI.

llvm-svn: 242730

show more ...

Revert "parser: wordsmith diagnostic message" and "parser: diagnose empty attribute blocks"

This reverts commit r239846 and r239879. They caused clang's
-fms-extensions behavior to incorrectly pars

Revert "parser: wordsmith diagnostic message" and "parser: diagnose empty attribute blocks"

This reverts commit r239846 and r239879. They caused clang's
-fms-extensions behavior to incorrectly parse lambdas and includes a
testcase to ensure we don't regress again.

This issue was found in PR24027.

llvm-svn: 241668

show more ...

[MS ABI] Correctly associate align attrs before the class-key

__declspec(align(...)) is unlike all other attributes in that it is not
applied to a variable if it appears before the class-key. If th

[MS ABI] Correctly associate align attrs before the class-key

__declspec(align(...)) is unlike all other attributes in that it is not
applied to a variable if it appears before the class-key. If the
tag in question isn't part of a variable declaration, it is not ignored.

Instead, the alignment attribute is applied to the tag.

This fixes PR18024.

llvm-svn: 235272

show more ...

Sema: __assume with side effects shouldn't result in invalid AST nodes

We'd diagnose an __assume expression which contained a function call.
This would result in us wrongly returning ExprError, caus

Sema: __assume with side effects shouldn't result in invalid AST nodes

We'd diagnose an __assume expression which contained a function call.
This would result in us wrongly returning ExprError, causing mysterious
failures later on.

llvm-svn: 230597

show more ...

MS ABI: Implement support for 'novtable'

It is common for COM interface classes to be marked as 'novtable' to
tell the compiler that constructors and destructors should not reference
virtual functio

MS ABI: Implement support for 'novtable'

It is common for COM interface classes to be marked as 'novtable' to
tell the compiler that constructors and destructors should not reference
virtual function tables.

This commit implements this feature in clang.

llvm-svn: 227796

show more ...

[Objective-C]. Modern property getters have side-effects.
So, place warning about property getter should not be used for side-effect
under its own group so warning can be turned off.
rdar://19137815

[Objective-C]. Modern property getters have side-effects.
So, place warning about property getter should not be used for side-effect
under its own group so warning can be turned off.
rdar://19137815

llvm-svn: 224479

show more ...