| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
DeclContext rather than injecting it wherever we happen to be.
This avoids creating functions whose DeclContext is a struct or similar.
llvm-svn: 323998
|
| |
|
|
|
|
|
|
| |
Silence the -Wbitfield-constant-conversion warning for when -1 or other
negative values are assigned to unsigned bitfields, provided that the bitfield
is wider than the minimum number of bits needed to encode the negative value.
llvm-svn: 277796
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
consider the following:
enum E *p;
enum E { e };
The above snippet is not ANSI C because 'enum E' has not bee defined
when we are processing the declaration of 'p'; however, it is a popular
extension to make the above work. This would fail using the Microsoft
enum semantics because the definition of 'E' would implicitly have a
fixed underlying type of 'int' which would trigger diagnostic messages
about a mismatch between the declaration and the definition.
Instead, treat fixed underlying types as not fixed for the purposes of
the diagnostic.
llvm-svn: 249674
|
| |
|
|
|
|
|
|
|
| |
These test updates almost exclusively around the change in behavior
around enum: enums without a definition are considered incomplete except
when targeting MSVC ABIs. Since these tests are interested in the
'incomplete-enum' behavior, restrict them to %itanium_abi_triple.
llvm-svn: 249660
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Implement DR262 (for C). This patch will mainly affect bitfields of type _Bool
Reviewers: fraggamuffin, rsmith
Subscribers: hubert.reinterpretcast, cfe-commits
Differential Revision: http://reviews.llvm.org/D10018
llvm-svn: 247618
|
| |
|
|
|
|
|
|
| |
VerifyBitField must be called if we are to form a bitfield FieldDecl.
We will not verify the bitfield if the decl is known to be malformed in
other ways; pretend that we don't have a bitfield if this happens.
llvm-svn: 235816
|
| |
|
|
|
|
| |
unevaluated expression context, such as sizeof(), or decltype(). Also adds a similar warning when the expression passed to typeid() *is* evaluated, since it is equally likely that the user would expect the expression operand to be unevaluated in that case.
llvm-svn: 224465
|
| |
|
|
|
|
|
|
|
|
|
| |
we were failing to find that bit-field when performing integer promotions. This
brings us closer to following the standard, and closer to GCC.
In C, this change is technically a regression: we get bit-field promotions
completely wrong in C, promoting cases that are categorically not bit-field
designators. This change makes us do so slightly more consistently, though.
llvm-svn: 218428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
llvm-svn: 181252
|
| |
|
|
|
|
| |
As it turns out, this is my fault for not noticing this was an issue when I was looking at this a long time ago. :(
llvm-svn: 135026
|
| |
|
|
|
|
| |
Wieczorek! Fixes PR8025.
llvm-svn: 118481
|
| |
|
|
| |
llvm-svn: 101384
|
| |
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
| |
|
|
| |
llvm-svn: 81802
|
| |
|
|
|
|
|
|
|
| |
into the left-hand side of an assignment expression. This completes
most of PR3500; the only remaining part is to deal with the
GCC-specific implementation-defined behavior for "unsigned long" (and
other) bit-fields.
llvm-svn: 70623
|
| |
|
|
|
|
| |
enough at determining whether an expression is a bitfield or not, yet.
llvm-svn: 70613
|
| |
|
|
| |
llvm-svn: 70571
|
| |
|
|
| |
llvm-svn: 69608
|
| |
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
| |
|
|
| |
llvm-svn: 67045
|
| |
|
|
|
|
|
|
|
|
|
| |
definitions. We were rejecting tentative definitions of incomplete
(which is bad), and now we don't.
This fix is partial because we don't do the end-of-translation-unit
initialization for tentative definitions that don't ever have any
initializers specified.
llvm-svn: 66584
|
| |
|
|
|
|
| |
more consistently.
llvm-svn: 66210
|
| |
|
|
| |
llvm-svn: 60920
|
| |
|
|
| |
llvm-svn: 60907
|
|
|
llvm-svn: 60628
|
