| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a comma occurs in a default argument or default initializer within a
class, disambiguate whether it is part of the initializer or whether it ends
the initializer.
The way this works (which I will be proposing for standardization) is to treat
the comma as ending the default argument or default initializer if the
following token sequence matches the syntactic constraints of a
parameter-declaration-clause or init-declarator-list (respectively).
This is both consistent with the disambiguation rules elsewhere (where entities
are treated as declarations if they can be), and should have no regressions
over our old behavior. I think it might also disambiguate all cases correctly,
but I don't have a proof of that.
There is an annoyance here: because we're performing a tentative parse in a
situation where we may not have seen declarations of all relevant entities (if
the comma is part of the initializer, lookup may find entites declared later in
the class), we need to turn off typo-correction and diagnostics during the
tentative parse, and in the rare case that we decide the comma is part of the
initializer, we need to revert all token annotations we performed while
disambiguating.
Any diagnostics that occur outside of the immediate context of the tentative
parse (for instance, if we trigger the implicit instantiation of a class
template) are *not* suppressed, mirroring the usual rules for a SFINAE context.
llvm-svn: 190639
|
| |
|
|
|
|
| |
<rdar://problem/14970968>
llvm-svn: 190635
|
| |
|
|
|
|
|
|
|
|
|
| |
variable uninitialized every time we reach its (reachable) declaration, or
every time we call the surrounding function, promote the warning from
-Wmaybe-uninitialized to -Wsometimes-uninitialized.
This is still slightly weaker than desired: we should, in general, warn
if a use is uninitialized the first time it is evaluated.
llvm-svn: 190623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it makes sense that a Command knows how to execute itself.
There's no functionality change but i rewrote the code to avoid the manual
memory management of Argv.
My motivation for this is that I plan to subclass Command to build fall-back
functionality into clang-cl.
Differential Revision: http://llvm-reviews.chandlerc.com/D1654
llvm-svn: 190621
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the code to Job.cpp, which seems like a more natural fit,
and replaces the "is this a JobList? is this a Command?" logic with
a virtual function call.
It also removes the code duplication between PrintJob and
PrintDiagnosticJob and simplifies the code a little.
There's no functionality change here, except that the Executable is
now always printed within quotes, whereas it would previously not be
quoted in crash reports, which I think was a bug.
Differential Revision: http://llvm-reviews.chandlerc.com/D1653
llvm-svn: 190620
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CMake does not have the ability to perform actions before calculating
dependencies, so it can't know whether it needs to rebuild clangBasic
to update for a new revision number. CLANG_ALWAYS_CHECK_VC_REV (off by
default) will cause clangBasic to always be dirty by deleting the
generated SVNVersion.inc after use; otherwise, SVNVersion.inc will
always be updated, but only included in the final binary when clangBasic
is rebuilt.
It'd be great to find a better way to do this, but hopefully this is
still an improvement over the complete lack of version information before.
llvm-svn: 190613
|
| |
|
|
| |
llvm-svn: 190601
|
| |
|
|
|
|
|
|
| |
initializer_list.
rdar://14887351
llvm-svn: 190561
|
| |
|
|
|
|
| |
Just always regenerate SVNVersion.inc. Don't worry about it not changing.
llvm-svn: 190560
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now that LLVM's helper script GetSVN.cmake actually works consistently,
there's no reason not to use it. This does mean that the clangBasic target
is potentially always dirty, because CMake-generated projects do not
necessarily recalculate dependencies after running each target.
This should end the issues of the AST format changing and breaking old
module files; CMake-Clang should now detect that the version changed just
like Autoconf-Clang has.
llvm-svn: 190557
|
| |
|
|
|
|
|
| |
unknown methods which return Cocoa objects. No need to annotate
such methods.
llvm-svn: 190555
|
| |
|
|
|
|
|
|
|
| |
Before:
for (int i = 0; i* 2 < z; i *= 2) {}
After:
for (int i = 0; i * 2 < z; i *= 2) {}
llvm-svn: 190546
|
| |
|
|
|
|
| |
arguments to map strings to the proper enumeration value. This makes error checking more consistent and reduces the amount of hand-written code required.
llvm-svn: 190545
|
| |
|
|
|
|
|
|
| |
such that it does not lower case the staring property
name if getter name (after "get" prefix) starts with
two upper case letters.
llvm-svn: 190539
|
| |
|
|
|
|
| |
start with "get" are inferreed as a readonly properties.
llvm-svn: 190532
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RegionStore tries to protect against accidentally initializing the same
region twice, but it doesn't take subregions into account very well. If
the outer region being initialized is a struct with an empty base class,
the offset of the first field in the struct will be 0. When we initialize
the base class, we may invalidate the contents of the struct by providing
a default value of Unknown (or some new symbol). We then go to initialize
the member with a zeroing constructor, only to find that the region at
that offset in the struct already has a value. The best we can do here is
to invalidate that value and continue; neither the old default value nor
the new 0 is correct for the entire struct after the member constructor call.
The correct solution for this is to track region extents in the store.
<rdar://problem/14914316>
llvm-svn: 190530
|
| |
|
|
|
|
|
| |
This also bakes the /M options into a separate option group to make
them easier to refer to from the code.
llvm-svn: 190529
|
| |
|
|
|
|
|
|
|
| |
The code in CGExpr was added back in 2012 (r165536) but not exercised in tests
until recently.
Detected on the MemorySanitizer bootstrap bot.
llvm-svn: 190521
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
reformat() tries to determine the newline style used in the input
(either LF or CR LF), and uses it for the output. Maybe not every single case is
supported, but at least the bug described in http://llvm.org/PR17182 should be
resolved.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1643
llvm-svn: 190519
|
| |
|
|
| |
llvm-svn: 190516
|
| |
|
|
| |
llvm-svn: 190515
|
| |
|
|
|
|
|
|
|
|
|
| |
With r190382, -Wunused-variable warns about unused const variables when
appropriate. For codebases that use -Werror, this poses a problem as
existing unused const variables need to be cleaned up first. To make the
transistion easier, this patch splits -Wunused-variable by pulling out
an additional -Wunused-const-variable (by default activated along with
-Wunused-variable).
llvm-svn: 190508
|
| |
|
|
|
|
| |
NumCallArguments in Sema::getMostSpecialized(). They were removed since r190444. [-Wdocumentation]
llvm-svn: 190501
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the first step to make module-map-files modular (instead
of requiring a single "module.map"-file per include directory). This
step adds a new "extern module" declaration that enables
module-map-files to reference one another along with a very basic
implementation.
The next steps are:
* Combine this with the use-declaration (from
http://llvm-reviews.chandlerc.com/D1546) in order to only load module
map files required for a specific compilation.
* Add an additional flag to start with a specific module-map-file (instead
of requiring there to be at least one "module.map").
Review: http://llvm-reviews.chandlerc.com/D1637
llvm-svn: 190497
|
| |
|
|
| |
llvm-svn: 190496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
More accurately characterize the nature of array parameters. Doing this
removes false back-reference opportunities. Remove some hacks now that
we characterize these better.
Reviewers: rnk, timurrrr, whunt, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1626
llvm-svn: 190488
|
| |
|
|
|
|
| |
PR17123.
llvm-svn: 190484
|
| |
|
|
|
|
|
|
|
| |
Fixes a crash in cases where the first argument was an incomplete type
or an uninstantiated template type.
<rdar://problem/14938471>
llvm-svn: 190482
|
| |
|
|
|
|
| |
constructor, copy assignment operator and move assignment operator.
llvm-svn: 190481
|
| |
|
|
|
|
| |
argument. Instead, it takes an expression that is fully resolved.
llvm-svn: 190476
|
| |
|
|
|
|
|
|
|
|
|
| |
non-member function, the number of arguments in the two candidate calls
will be different (the non-member call will have one extra argument).
We used to get confused by this, and fail to compare the last argument
when testing whether the member is better, resulting in us always
thinking it is, even if the non-member is more specialized in the last
argument.
llvm-svn: 190470
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some build systems use pipes for stdin/stderr. On nix-ish platforms colored
output can be forced by -fcolor-diagnostics. On Windows this option has
no effect in these cases because LLVM uses the console API (which only
operates on the console buffer) even if a console wrapper capable of
interpreting ANSI escape codes is used.
The -fansi-escape-codes option allows switching from the console API to
ANSI escape codes. It has no effect on other platforms.
llvm-svn: 190464
|
| |
|
|
| |
llvm-svn: 190463
|
| |
|
|
| |
llvm-svn: 190462
|
| |
|
|
| |
llvm-svn: 190447
|
| |
|
|
| |
llvm-svn: 190445
|
| |
|
|
|
|
|
| |
call; remove its 'number of explicit arguments' and 'what kind of call'
parameters.
llvm-svn: 190444
|
| |
|
|
|
|
|
|
|
|
| |
trunk clang is a bit more aggressive about emitting unused-declaration
warnings, so adjust some AST code to match. Specifically, use
LLVM_ATTRIBUTE_UNUSED for declarations which are never supposed to be
referenced, and turn references to declarations which are supposed to be
referenced into odr-uses.
llvm-svn: 190443
|
| |
|
|
|
|
|
|
|
|
| |
As requested when applying the same logic to calling conventions.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1634
llvm-svn: 190441
|
| |
|
|
|
|
|
| |
treat such subtractions as being non-constant. Patch by Serge Pavlov! With a
few tweaks by me.
llvm-svn: 190439
|
| |
|
|
|
|
|
|
|
| |
Make sure we perform the correct "referenced-but-not-used" check for
static member constants.
Fixes bug reported on cfe-commits by Alexey Samsonov.
llvm-svn: 190437
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Dynamic initializers are mangled as ??__E <name> YAXXZ.
Reviewers: timurrrr
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1477
llvm-svn: 190434
|
| |
|
|
|
|
|
|
| |
This adds driver support for building DLLs (the /LD and /LDd flags).
It basically does two things: runtime selection and passing -dll and
-implib to the linker.
llvm-svn: 190428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Static locals requiring initialization are not thread safe on Windows.
Unfortunately, it's possible to create static locals that are actually
externally visible with inline functions and templates. As a result, we
have to implement an initialization guard scheme that is compatible with
TUs built by MSVC, which makes thread safety prohibitively difficult.
MSVC's scheme is that every function that requires a guard gets an i32
bitfield. Each static local is assigned a bit that indicates if it has
been initialized, up to 32 bits, at which point a new bitfield is
created. MSVC rejects inline functions with more than 32 static locals,
and the externally visible mangling (?_B) only allows for one guard
variable per function.
On Eli's recommendation, I used MangleNumberingContext to track which
bit each static corresponds to.
Implements PR16888.
Reviewers: rjmccall, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1416
llvm-svn: 190427
|
| |
|
|
|
|
| |
with a suitable 'getter' attribute.
llvm-svn: 190420
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1639
llvm-svn: 190408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This also unifies the handling of escaped newlines for all tokens.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1638
llvm-svn: 190405
|
| |
|
|
|
|
|
|
|
|
|
| |
Before:
typedef typeof(int(int, int)) * MyFunc;
After:
typedef typeof(int(int, int)) *MyFunc;
This fixes llvm.org/PR17178.
llvm-svn: 190401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes various issues with mixed tabs and spaces handling, e.g.
when realigning block comments.
Reviewers: klimek, djasper
Reviewed By: djasper
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1608
llvm-svn: 190395
|
| |
|
|
| |
llvm-svn: 190394
|