| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 149868
|
|
|
|
| |
llvm-svn: 149864
|
|
|
|
|
|
| |
before inserting into the vector. Fixes PR11930.
llvm-svn: 149855
|
|
|
|
| |
llvm-svn: 149854
|
|
|
|
| |
llvm-svn: 149852
|
|
|
|
|
|
| |
type doesn't seem to work on MSVC.
llvm-svn: 149819
|
|
|
|
|
|
|
| |
can't produce a constant expression is not ill-formed (so long as some
instantiation of that function can produce a constant expression).
llvm-svn: 149802
|
|
|
|
| |
llvm-svn: 149801
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
| |
llvm-svn: 149798
|
|
|
|
|
|
|
| |
lvalue-to-rvalue conversions on the source type of the conversion, not the
target type (which has them removed for non-class types).
llvm-svn: 149796
|
|
|
|
|
|
|
|
| |
We had been generating load/store instructions with the default alignment
for the vector element type, even when the pointer argument had less alignment.
<rdar://problem/10538555>
llvm-svn: 149794
|
|
|
|
| |
llvm-svn: 149792
|
|
|
|
|
|
| |
since it needs to be used again for list constructor resolution.
llvm-svn: 149791
|
|
|
|
|
|
| |
instead doing a little more work inside. This should make finding initializer list constructors easier, as well as fix one place where the ({}) vs {} issue was probably poorly handled.
llvm-svn: 149790
|
|
|
|
|
|
|
|
| |
include.
Fix all the transitive include users.
llvm-svn: 149783
|
|
|
|
|
|
|
| |
- Move the offending methods out of line and fix transitive includers.
- This required changing an enum in the PPCallback API into an unsigned.
llvm-svn: 149782
|
|
|
|
|
|
|
|
|
| |
of Diagnostic.h.
Fix all the files that depended on transitive includes of Diagnostic.h.
With this patch in place changing a diagnostic no longer requires a full rebuild of the StaticAnalyzer.
llvm-svn: 149781
|
|
|
|
|
|
|
|
|
| |
can forward declare them.
Let ASTContext allocate the storage in its BumpPtrAllocator.
This will help us remove ASTContext's depedency on PartialDiagnostic.h soon.
llvm-svn: 149780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
|
|
|
|
|
|
|
| |
array new expression. This lays some groundwork for the implicit conversion to
integral or unscoped enumeration which C++11 ICEs undergo.
llvm-svn: 149772
|
|
|
|
|
|
| |
undefined arguments, when CF functions are called with wrong number of arguments.
llvm-svn: 149771
|
|
|
|
| |
llvm-svn: 149770
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new, is well-formed with defined semantics of throwing (a type which can be
caught by a handler for) std::bad_array_new_length, unlike in C++98 where it is
somewhere nebulous between undefined behavior and ill-formed.
If the array size is an integral constant expression and satisfies one of these
criteria, we would previous the array new expression, but now in C++11 mode, we
merely issue a warning (the code is still rejected in C++98 mode, naturally).
We don't yet implement new C++11 semantics correctly (see PR11644), but we do
implement the overflow checking, and (for the default operator new) convert such
expressions to an exception, so accepting such code now does not seem especially
unsafe.
llvm-svn: 149767
|
|
|
|
| |
llvm-svn: 149764
|
|
|
|
|
|
| |
allocator is given the pointer to allocate into.
llvm-svn: 149760
|
|
|
|
| |
llvm-svn: 149759
|
|
|
|
|
|
|
| |
- osx.coreFoundation.containers.IndexOutOfBounds
- osx.cocoa.SelfInit
llvm-svn: 149747
|
|
|
|
|
|
| |
(Also renames in other ObjC checkers to create one category of checks.)
llvm-svn: 149745
|
|
|
|
| |
llvm-svn: 149742
|
|
|
|
|
|
| |
of ArrayRef goodness. No functionality change.
llvm-svn: 149739
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
want to provide "po"-like functionality which
treats the result of an expression implicitly as
"id" (if it is not otherwise known) and prints
it as an Objective-C object.
This has in the past been gated by the
"DebuggerSupport" language option, but that is
too general. Debuggers also provide other commands
like "print" that do not make any assumptions
about whether the object is an Objective-C object.
This patch makes the assumption conditional on a
new language option: DebuggerCastResultToId. I
have also made corresponding modifications to the
testsuite.
llvm-svn: 149735
|
|
|
|
| |
llvm-svn: 149734
|
|
|
|
|
|
| |
look into a rather nasty bug in the new odr-use marking code.
llvm-svn: 149731
|
|
|
|
|
|
|
|
|
|
| |
The recent support for potential constant expressions exposed a bug in the
implementation of libstdc++4.6, where numeric_limits<int>::min() is defined
as (int)1 << 31, which isn't a constant expression. Disable the 'constexpr
function never produces a constant expression' error inside system headers
to compensate.
llvm-svn: 149729
|
|
|
|
| |
llvm-svn: 149725
|
|
|
|
| |
llvm-svn: 149719
|
|
|
|
|
|
| |
Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases.
llvm-svn: 149718
|
|
|
|
|
|
| |
size. Otherwise, we can end up with bogus layouts.
llvm-svn: 149703
|
|
|
|
|
|
|
|
| |
template without a corresponding parameter pack, don't immediately
substitute the alias template. This is under discussion in the C++
committee, and may become ill-formed, but for now we match GCC.
llvm-svn: 149697
|
|
|
|
|
|
| |
Also, in C, call this a C11 extension rather than a GNU extension.
llvm-svn: 149695
|
|
|
|
|
|
|
|
|
| |
template. Such pack expansions can easily fail at template
instantiation time, if the expanded parameter packs are of the wrong
length. Fixes <rdar://problem/10040867>, PR9021, and the example that
came up today at Going Native.
llvm-svn: 149685
|
|
|
|
|
|
|
|
|
| |
That llvm change removed the -trap-func backend option, so that using
-ftrap-function with clang would cause the backend to complain. Fix it
by adding the trap function name to the CodeGenOptions and passing it through
to the TargetOptions.
llvm-svn: 149679
|
|
|
|
|
|
|
| |
instead of a SourceRange, and handle the case where the range is
a char (not token) range.
llvm-svn: 149677
|
|
|
|
|
|
| |
the limit on the number of fixits.
llvm-svn: 149676
|
|
|
|
|
|
| |
available.
llvm-svn: 149675
|
|
|
|
|
|
|
|
|
|
|
|
| |
* When we detect that a CFG block has inconsistent lock sets, point the
diagnostic at the location where we found the inconsistency, and point a note
at somewhere the inconsistently-locked mutex was locked.
* Fix the wording of the normal (non-loop, non-end-of-function) case of this
diagnostic to not suggest that the mutex is going out of scope.
* Fix the diagnostic emission code to keep a warning and its note together when
sorting the diagnostics into source location order.
llvm-svn: 149669
|
|
|
|
|
|
|
| |
'continue' and another block, prefer the lockset from the other block, and
diagnose the 'continue' block as being the end of a loop.
llvm-svn: 149666
|
|
|
|
|
|
|
|
| |
a cast to the same type is allowed so long as it does not cast away constness.
Fix for PR11747. Patch by Aaron Ballman. Reviewed by Eli.
llvm-svn: 149664
|
|
|
|
|
|
| |
bit of the code for lambdas. The only visible changes are that we use the C++11 odr-used rules to figure out when a variable is captured, and type-checking in lambdas is slightly more accurate.
llvm-svn: 149663
|