typo. This can happen with context-sensitive keywords like "super",
when typo correction didn't know that "super" wasn't permitted in this
context.
llvm-svn: 117372
There's probably still significant padding waste on x86-64 UNIXen, but
the difference in 32-bit compiles should be significant.
There are a lot of Expr nodes left that could lose a word this way.
llvm-svn: 117359
until after we've checked/promoted the argument. Hopefully fixes the
Emacs regression due to my recent change that expanded type-checking
in the presence of K&R function definitions.
llvm-svn: 117353
- tags with C linkage should ignore visibility=hidden
- functions and variables with explicit visibility attributes should
ignore the linkage of their types
Either of these should be sufficient to fix PR8457.
Also, FileCheck-ize a test case.
llvm-svn: 117351
covariant/contravariant overrides and implementations, but do so under
control of a new flag (-Wno-objc-covariant-overrides, which yes does cover
contravariance too).
*At least* the covariance cases will probably be enabled by default shortly,
but that's not totally uncontroversial.
llvm-svn: 117346
getCanonicalType() to make sure that the type we got back is actually
canonical. This is the case for most types, which always build a
canonical type when given canonical components. However, some types that
involve expressions in their canonicalization (e.g., array types with
dependent sizes) don't always build canonical types from canonical
components, because there is no such thing as a "canonical"
expression. Therefore, we do this extra mapping to ensure that the
canonical types we store are actually canonical.
llvm-svn: 117344
globals memory space gets assigned a symbolic value, but that value was not being used for lazy symbolication
of fields of globals. This could result in cases where bogus null dereferences were being reported.
Fixes PR 8440.
llvm-svn: 117336
function definition, we should still use a prototype to type-check and
convert the function arguments, if such a prototype exists. Fixes
PR8314.
llvm-svn: 117305
A common idiom in Objective-C is to provide a definition of a method in a subclass that returns a more-specified version of an object than the superclass. This does not violate the principle of substitutability, because you can always use the object returned by the subclass anywhere that you could use the type returned by the superclass. It was, however, generating warnings with clang, leading people to believe that semantically correct code was incorrect and requiring less accurate type specification and explicit down-casts (neither of which is a good thing to encourage).
This change ensures that any method definition has parameter and return types that make it accept anything that something conforming to the declaration may pass and return something that the caller will expect, but allows stricter definitions.
llvm-svn: 117271
This adds them where missing, and traces them through PCH. We fix at least one
bug in the extents found by the Index library, and make a lot of refactoring
tools which care about the exact formulation of a constructor call easier to
write. Also some minor cleanups to more consistently follow the friend pattern
instead of the setter pattern when rebuilding a serialized AST.
Patch originally by Samuel Benzaquen.
llvm-svn: 117254
In that case a chained PCH will record the updates to the DefinitionData pointer of forward references.
If a forward reference mutated into a definition re-write it into the chained PCH, this is too big of a change.
llvm-svn: 117239
- Pass around RecordDataImpl instead of the concrete RecordData so that any SmallVector can be used.
- Move ASTDeclWriter::WriteCXXDefinitionData to ASTWriter::AddCXXDefinitionData.
llvm-svn: 117236
its initial creation/deserialization and store the changes in a chained PCH.
The idea is that the AST entities call methods on the ASTMutationListener to give notifications
of changes; the PCHWriter implements the ASTMutationListener interface and stores the incremental changes
of the updated entity. WIP
llvm-svn: 117235
members in class subobjects of different types. So long as the
underlying declaration sets are the same, and the declaration sets
involve non-instance members, this is not an ambiguity.
llvm-svn: 117163
We shouldn't recurse into CompoundStmts since they are already inlined in the CFG. This could result in
bogus dead stores warnings (among other things).
llvm-svn: 117162
Douglas Gregor