Commit Graph

12 Commits

Author SHA1 Message Date
Michael Kruse dc5ce72afa Append new attributes to the end of an AttributeList.
Recommit of r335084 after revert in r335516.

... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.

The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse order, and therefore printed in the wrong order in
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.

The change unfortunately has some secondary effect, especially on
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attributes' order was changed instead.

This unfortunately causes some 'previous occurrence here' hints to be
textually after the main marker. This typically happens when attributes
are merged, but are incompatible to each other. Interchanging the role
of the the main and note SourceLocation will also cause the case where
two different declaration's attributes (in contrast to multiple
attributes of the same declaration) are merged to be reverse. There is
no easy fix because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway.

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

llvm-svn: 338800
2018-08-03 01:21:16 +00:00
Michael Kruse 41dd6ced2c Revert "Append new attributes to the end of an AttributeList."
This reverts commit r335084 as requested by David Jones and
Eric Christopher because of differences of emitted warnings.

llvm-svn: 335516
2018-06-25 20:06:13 +00:00
Michael Kruse ea31f0e4b8 Append new attributes to the end of an AttributeList.
... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.

The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse, and therefore printed in the wrong order by
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.

The change unfortunately has some secondary effects, especially for
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attribute's order was changed instead.

It also causes some 'previous occurrence here' hints to be textually
after the main marker. This typically happens when attributes are
merged, but are incompatible. Interchanging the role of the the main
and note SourceLocation will also cause the case where two different
declaration's attributes (in contrast to multiple attributes of the
same declaration) are merged to be reversed. There is no easy fix
because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway, which often is on the same line.

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

llvm-svn: 335084
2018-06-19 23:46:52 +00:00
Benjamin Kramer 7037021e78 Sema: Don't crash on visibility attributes with an identifier argument.
PR17105.

llvm-svn: 190312
2013-09-09 15:08:57 +00:00
John McCall d041a9bf2d Add a new 'type_visibility' attribute to allow users to
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.

Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.

The type_visibility work is rdar://11880378

llvm-svn: 175587
2013-02-20 01:54:26 +00:00
Rafael Espindola a6b3cd493c Warn about visibility attributes in typedefs.
llvm-svn: 156534
2012-05-10 03:01:34 +00:00
Rafael Espindola c67f223c9e Fix an old (2009) FIXME:
// FIXME: This needs to happen before we merge declarations. Then,
// let attribute merging cope with attribute conflicts.

This was already being done for variables, but for functions we were merging
then first and then applying the attributes. To avoid duplicating merging
logic, some of the helpers in SemaDeclAttr.cpp become methods that can
handle merging two attributes in one decl or inheriting attributes from one
decl to another.

With this change we are now able to produce errors for variables with
incompatible visibility attributes or warn about unused dllimports in
variables.

This changes the attribute list iteration back to being in reverse source
code order, as that matches what decl merging does and avoids differentiating
the two cases is the merge*Attr methods.

llvm-svn: 156531
2012-05-10 02:50:16 +00:00
Rafael Espindola 3c9d9479b0 Process attributes in the order they appear in the source code. This make clang
match gcc behavior for two conflicting visibilities in the same decl. It also
makes handling of dllimport/dllexport more natural.

As a bonus we now warn on the dllimport in

void __attribute__((dllimport)) foo13();
void __attribute__((dllexport)) foo13();

as does gcc.

llvm-svn: 156343
2012-05-07 23:58:18 +00:00
Rafael Espindola cd997e02b2 Walk the decls looking for the last one that has an attribute. We do have to walk
them, otherwise we cannot produce an error for both

struct HIDDEN test4; // canonical
struct test4;
struct DEFAULT test4;

and

struct test5; // canonical
struct HIDDEN test5;
struct DEFAULT test5;

llvm-svn: 156016
2012-05-02 20:36:57 +00:00
Rafael Espindola a01ff786ed Extend the error about incompatible visibility attributes in different
decls to work on function templates specializations.

llvm-svn: 155943
2012-05-01 20:58:29 +00:00
Rafael Espindola 4c3db23d1c Reject cases like
struct __attribute__((visibility("hidden"))) a;
struct __attribute__((visibility("default"))) b;

which gcc already rejects.

llvm-svn: 155603
2012-04-26 01:26:03 +00:00
John McCall eed64c77d2 Complain about attempts to use 'protected' visibility on targets
like Darwin that don't support it.  We should also complain about
invalid -fvisibility=protected, but that information doesn't seem
to exist at the most appropriate time, so I've left a FIXME behind.

llvm-svn: 149186
2012-01-29 01:20:30 +00:00