Age | Commit message (Collapse) | Author |
|
Serve Pavlov!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179603 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
references thereto.
Patch by Tong Shen!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179585 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179573 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Mostly refactoring + handle the nested fields by printing the innermost field only.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179572 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r179436.
Due to caching, it was possible that we could miss overridden methods that
were introduced by categories later on.
Along with reverting the commit I also included a test case that would have caught this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179547 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179525 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It was being used correctly, but it is a very dangerous API to have around.
Instead, move the logic from the filtering to when we are deciding if we should
link two decls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179523 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179501 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
or non-trivial destructor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179491 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179489 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
two new options –msingle-float and –mdouble-float. These options can be
used simultaneously with float ABI selection options (-mfloat-abi,
-mhard-float, -msoft-float). They mark whether a floating-point
coprocessor supports double-precision operations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179481 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the AST.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Use an newly introduce ASTContext::getBaseObjCCategoriesAfterInterface() which caches its
results instead of re-calculating the categories multiple times.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179436 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"included/expanded in" decomposed location of the given FileID.
The main benefit is to speed-up SourceManager::isBeforeInTranslationUnit which is common to query
the included/expanded location of the same FileID multiple times.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179435 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
semantics as __thread for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179424 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
least one of the macro definitions comes from a non-system header.
This slightly weakens the heuristic introduced in r178109.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179411 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179395 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
resides in a system header.
This is a modified patch provided from Mikołaj Siedlarek!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also reflow code a bit, no change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179382 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This new option is the default, but it is useful to have a flag to override
-mno-implicit-float by putting -mimplicit-float later on the command line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179309 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Handles all inheritance models for both data and function member
pointers.
Also implements isZeroInitializable() and refactors some of the null
member pointer code.
MSVC supports converting member pointers through virtual bases, which
clang does not (yet?) support. Implementing that extension is covered
by http://llvm.org/15713
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D613
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179305 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179300 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of a C++ declaration within its parent scope.
Suggested by Stefan Seefeld.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
clang_Type_getAlignOf
clang_Type_getSizeOf
clang_Type_getOffsetOf
clang_Cursor_isBitField
Patch by Loïc Jaquemet!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179251 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
// rdar://12379053
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-fstrict-aliasing.
rdar://13622687
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179216 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179204 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Amin Shali.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179180 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
|
|
The GNU line marker directive was sharing code with the #line directive, but some of the warnings/errors were reporting as #line directive diagnostics in both cases.
Previously:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "#line directive requires a simple digit sequence"
Now, we get:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "GNU line marker directive requires a simple digit sequence"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179139 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
isVirtual - matches CXXMethodDecl nodes for virtual methods
isOverride - matches CXXMethodDecl nodes for methods that override virtual methods from a base class.
Author: Philip Dunstan <phil@philipdunstan.com>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179126 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when appropriate.
Differential Revision: http://llvm-reviews.chandlerc.com/D502
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179082 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, the analyzer used isIntegerType() everywhere, which uses the C
definition of "integer". The C++ predicate with the same behavior is
isIntegerOrUnscopedEnumerationType().
However, the analyzer is /really/ using this to ask if it's some sort of
"integrally representable" type, i.e. it should include C++11 scoped
enumerations as well. hasIntegerRepresentation() sounds like the right
predicate, but that includes vectors, which the analyzer represents by its
elements.
This commit audits all uses of isIntegerType() and replaces them with the
general isIntegerOrEnumerationType(), except in some specific cases where
it makes sense to exclude scoped enumerations, or any enumerations. These
cases now use isIntegerOrUnscopedEnumerationType() and getAs<BuiltinType>()
plus BuiltinType::isInteger().
isIntegerType() is hereby banned in the analyzer - lib/StaticAnalysis and
include/clang/StaticAnalysis. :-)
Fixes real assertion failures. PR15703 / <rdar://problem/12350701>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179081 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to 256, since we're blowing the stack for a trivial "factorial" class template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When two template decls with the same name are used in this diagnostic,
force them to print their qualified names. This changes the bad message of:
candidate template ignored: could not match 'array' against 'array'
to the better message of:
candidate template ignored: could not match 'NS2::array' against 'NS1::array'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179056 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a non-variable iteration declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
order.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://12379114
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://12379114
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179039 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functions to the conversion function set eagerly.
This slightly propagates an existing hack that delays when we provide
access specifiers for the visible conversion functions of a class by
copying the available access specifier early. The only client this
affects is LLDB, which tends to discover and add conversion functions
after the class is technically "complete". As such, the only
observable difference is in LLDB, so the testing will go there.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179029 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179027 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
more information to the notes. This information is already present on other
diagnostic messages that involves overloads.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178923 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
address space in OpenCL.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178906 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://12379114
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178903 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also had to modify the PostInitializer ProgramLocation to contain the field region.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178826 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178813 91177308-0d34-0410-b5e6-96231b3b80d8
|