For this source:
const int &ref = someStruct.bitfield;
We used to generate this AST:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'const int' lvalue <NoOp>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Notice the lvalue inside the MaterializeTemporaryExpr, which is very
confusing (and caused an assertion to fire in the analyzer - PR15694).
We now generate this:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'int' <LValueToRValue>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Which makes a lot more sense. This allows us to remove code in both
CodeGen and AST that hacked around this special case.
The commit also makes Clang accept this (legal) C++11 code:
int &&ref = std::move(someStruct).bitfield
PR15694 / <rdar://problem/13600396>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179250 91177308-0d34-0410-b5e6-96231b3b80d8
constructor. This isn't quite perfect (as usual, we don't handle default
arguments correctly yet, and we don't deal with copy/move constructors for
arguments correctly either, but this will be fixed when we implement core issue
1351.
This completes our support for inheriting constructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179154 91177308-0d34-0410-b5e6-96231b3b80d8
of a property just in case the property's getter happens to be +1.
We won't synthesize a getter for such a property, but we will allow
the user to define a +1 method for it.
rdar://13115896
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178731 91177308-0d34-0410-b5e6-96231b3b80d8
smarts so that it doesn't approve of keywords and/or type names when it
knows (based on its flags) that those kinds of corrections are not
wanted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178668 91177308-0d34-0410-b5e6-96231b3b80d8
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178663 91177308-0d34-0410-b5e6-96231b3b80d8
variable in a C99 inline (but not static-inline or extern-inline)
function definition.
The standard doesn't actually say that this doesn't apply to
"extern inline" definitions, but that seems like a useful extension,
and it at least doesn't have the obvious flaw that a static
mutable variable in an externally-available definition does.
rdar://13535367
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178520 91177308-0d34-0410-b5e6-96231b3b80d8
visible. There's a lot of potential badness in how we're modelling
these things, but getting this much correct is reasonably easy.
rdar://13535367
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178488 91177308-0d34-0410-b5e6-96231b3b80d8
* Give the right diagnostic for 'restrict' applied to a non-pointer, non-reference type.
* Don't reject 'restrict' applied indirectly to an Objective-C object pointer type (eg, through template instantiation).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178200 91177308-0d34-0410-b5e6-96231b3b80d8
for self.GetterName where GetterName is the getter method
for a property with name different from the property name
(declared via a property getter attribute) // rdar://12791315
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177744 91177308-0d34-0410-b5e6-96231b3b80d8
picking up cleanups from earlier in the statement. Also fix a
crash-on-invalid where a reference to an invalid decl from an
enclosing scope was causing an expression to fail to build, but
only *after* a cleanup was registered from that statement,
causing an assertion downstream.
The crash-on-valid is rdar://13459289.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177692 91177308-0d34-0410-b5e6-96231b3b80d8
This created 2 issues:
1) Performance issue, since typo-correction with PCH/modules is rather expensive.
2) Correctness issue, since if it managed to "correct" 'super' then bogus compiler errors would
be emitted, like this:
3.m:8:3: error: unknown type name 'super'; did you mean 'super1'?
super.x = 0;
^~~~~
super1
t3.m:5:13: note: 'super1' declared here
typedef int super1;
^
t3.m:8:8: error: expected identifier or '('
super.x = 0;
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177126 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.
That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.
We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.
This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176999 91177308-0d34-0410-b5e6-96231b3b80d8
This was causing correctness issues for ARC and the static analyzer when a
function template has "consumed" Objective-C object parameters (i.e.
parameters that will be released by the function before returning).
The fix is threefold:
(1) Actually copy over the attributes from old ParmVarDecls to new ones.
(2) Have Sema::BuildFunctionType only work for building FunctionProtoTypes,
which it was doing anyway. This allows us to pass an ExtProtoInfo
instead of a plain ExtInfo and several flags.
(3) Drop param attributes as part of StripImplicitInstantiation, which is
used when an implicit instantiation is followed by an explicit one.
<rdar://problem/12685622>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176728 91177308-0d34-0410-b5e6-96231b3b80d8
can't have default arguments even though it's a parameter-declaration-clause in
a function declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176542 91177308-0d34-0410-b5e6-96231b3b80d8
of block declarators. Document the rule we use.
Also document the rule that Doug implemented a few weeks ago
which drops ownership qualifiers on function result types.
rdar://10127067
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176336 91177308-0d34-0410-b5e6-96231b3b80d8
Testing shows that it's empty in >99% of the cases and I couldn't find a case
where it contained more than 2 elements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175967 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain
to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these
attributes can be sema checked just as attributes attached to "normal" declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175900 91177308-0d34-0410-b5e6-96231b3b80d8
the normal attribute-merging path, because we can't merge alignment attributes
without knowing the complete set of alignment attributes which apply to a
particular declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175861 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175587 91177308-0d34-0410-b5e6-96231b3b80d8
attributes yet, so just issue the appropriate diagnostics. Also generalize the
fixit for attributes-in-the-wrong-place code and reuse it here, if attributes
are placed after the access-specifier or 'virtual' in a base specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175575 91177308-0d34-0410-b5e6-96231b3b80d8
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175281 91177308-0d34-0410-b5e6-96231b3b80d8
a property, the -Wdirect-ivar-access should not warn when
accessing the property's synthesized instance variable.
// rdar://13142820
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175195 91177308-0d34-0410-b5e6-96231b3b80d8
if it found any decls, rather than returning a list of found decls. This
removes a returning-ArrayRef-to-deleted-storage bug from
MultiplexExternalSemaSource (in code not exercised by any of the clang
binaries), reduces the work required in the found-no-decls case with PCH, and
importantly removes the need for DeclContext::lookup to be reentrant.
No functionality change intended!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174576 91177308-0d34-0410-b5e6-96231b3b80d8
says, but that's a defect (to be filed). "Cls::purevfn()" is still an odr use.
Also fixes a bug that caused us to not mark the function referenced just
because we didn't want to mark it odr used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174242 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith
Benjamin Kramer
Jordan Rose
John McCall
Rafael Espindola
Kaelyn Uhrain
Matt Beaumont-Gay
Fariborz Jahanian
Daniel Jasper
Alexey Bataev
Eric Christopher
Argyrios Kyrtzidis
Joey Gouly
Michael Han
David Blaikie
Dmitri Gribenko
Guy Benyei
Nick Lewycky