| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapply a variant commit r247179 after post-commit review from
D.Blaikie.
Hopefully I got it right this time: lifetime of initializer list ends
as with any expression, which make invalid the pattern:
ArrayRef<int> Arr = { 1, 2, 3, 4};
Just like StringRef, ArrayRef shouldn't be used to initialize local
variable but only as function argument.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247233
|
|
|
|
|
|
|
|
|
| |
SmallVector (NFC)"
This reverts commit r247179.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247183
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247179
|
|
|
|
|
|
|
|
| |
them directly to the control block. These are fairly large, and in a build with
lots of modules / chained PCH, we don't need to read most of them. No
functionality change intended.
llvm-svn: 247055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r246546, with a workaround for an MSVC 2013 miscompile and an MSVC 2015
rejects-valid.
Original commit message:
[modules] Rework serialized DeclContext lookup table management. Instead of
walking the loaded ModuleFiles looking for lookup tables for the context, store
them all in one place, and merge them together if we find we have too many
(currently, more than 4). If we do merge, include the merged form in our
serialized lookup table, so that downstream readers never need to look at our
imports' tables.
This gives a huge performance improvement to builds with very large numbers of
modules (in some cases, more than a 2x speedup was observed).
llvm-svn: 246582
|
|
|
|
|
|
|
|
|
|
|
| |
avoid merge conflicts). It broke the build on MSVC 2015. It also broke an MSVC 2013 bot with testing issues.
llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(117):
error C2065: 'Files': undeclared identifier
http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/2917
llvm-svn: 246546
|
|
|
|
|
|
| |
referenced by the entries that we emit.
llvm-svn: 246534
|
|
|
|
| |
llvm-svn: 246526
|
|
|
|
| |
llvm-svn: 246504
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
walking the loaded ModuleFiles looking for lookup tables for the context, store
them all in one place, and merge them together if we find we have too many
(currently, more than 4). If we do merge, include the merged form in our
serialized lookup table, so that downstream readers never need to look at our
imports' tables.
This gives a huge performance improvement to builds with very large numbers of
modules (in some cases, more than a 2x speedup was observed).
llvm-svn: 246497
|
|
|
|
|
|
|
|
| |
DeclarationName (because all ctor names are considered the same, and so on).
Reflect this in the type used as the lookup table key. As a side-effect, remove
one copy of the duplicated code used to compute the hash of the key.
llvm-svn: 246124
|
|
|
|
|
|
|
|
|
|
| |
CompilerInstance::getFileSystemOpts
and CompilerInvocation::getFileSystemOpts by renaming it to getFileSystemOpts,
marking the const-returning access method const and adding a non-const version,
making the function prototypes identical to CompilerInstance::getFileSystemOpts.
llvm-svn: 246026
|
|
|
|
|
|
| |
HeaderFileInfos for all files we've seen in this compilation.
llvm-svn: 245881
|
|
|
|
|
|
|
| |
unnecessary in C++ modules (where we don't need the identifiers for their
Decls) and expensive.
llvm-svn: 245821
|
|
|
|
|
|
|
|
| |
Instead of eagerly deserializing a list of DeclIDs when we load a module file
and doing a binary search to find the redeclarations of a decl, store a list of
redeclarations of each chain before the first declaration and load it directly.
llvm-svn: 245789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all modules and reduce the number of declarations we load when loading a
redeclaration chain.
The new approach is:
* when loading the first declaration of an entity within a module file, we
first load all declarations of the entity that were imported into that
module file, and then load all the other declarations of that entity from
that module file and build a suitable decl chain from them
* when loading any other declaration of an entity, we first load the first
declaration from the same module file
As before, we complete redecl chains through name lookup where necessary.
To make this work, I also had to change the way that template specializations
are stored -- it no longer suffices to track only canonical specializations; we
now emit all "first local" declarations when emitting a list of specializations
for a template.
On one testcase with several thousand imported module files, this reduces the
total runtime by 72%.
llvm-svn: 245779
|
|
|
|
|
|
| |
modules for a header, not just the current favourite.
llvm-svn: 245390
|
|
|
|
|
|
| |
intended.
llvm-svn: 245361
|
|
|
|
|
|
|
| |
the produced pcm file for stable file creation across distributed build
systems.
llvm-svn: 245199
|
|
|
|
|
|
|
|
| |
via a module map found by -fmodule-map-file=, the home directory of the module
is the current working directory, even if that's a different directory on
reload.
llvm-svn: 244988
|
|
|
|
|
|
| |
-fmodule-file=.
llvm-svn: 244417
|
|
|
|
|
|
| |
DeclContext. These only ever come from the owning module file for the Decl.
llvm-svn: 244285
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
determine the primary context, rather than sometimes registering the lookup
table on the wrong context.
This exposed a couple of bugs:
* the odr violation check didn't deal properly with mergeable declarations
if the declaration retained by name lookup wasn't in the canonical
definition of the class
* the (broken) RewriteDecl mechanism would emit two name lookup tables for
the same DeclContext into the same module file (one as part of the
rewritten declaration and one as a visible update for the old declaration)
These are both fixed too.
llvm-svn: 244192
|
|
|
|
| |
llvm-svn: 243727
|
|
|
|
|
|
|
|
|
| |
-working-directory option is set, results in error.
The error was "module '<name>' was built in directory '<path>' but now resides in directory '<path>'
rdar://21330027
llvm-svn: 243718
|
|
|
|
|
|
| |
tables. We don't need to store the data length twice.
llvm-svn: 243612
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
chain and fix the cases where it fires.
* Handle the __va_list_tag as a predefined decl. Previously we failed to merge
sometimes it because it's not visible to name lookup. (In passing, remove
redundant __va_list_tag typedefs that we were creating for some ABIs. These
didn't affect the mangling or representation of the type.)
* For Decls derived from Redeclarable that are not in fact redeclarable
(implicit params, function params, ObjC type parameters), remove them from
the list of expected redeclarable decls.
llvm-svn: 243259
|
|
|
|
|
|
| |
C++ modules. Instead, serialize a list of interesting identifiers and mark those ones out of date on module import. Avoiding the identifier lookups here gives a 20-30% speedup in builds with large numbers of modules. No functionality change intended.
llvm-svn: 242868
|
|
|
|
|
|
|
|
|
| |
the identifier table. This is redundant, since the TU-scope lookups are also
serialized as part of the TU DeclContext, and wasteful in a number of ways. We
still emit the decls for PCH / preamble builds, since for those we want
identical results, not merely semantically equivalent ones.
llvm-svn: 242855
|
|
|
|
|
|
|
| |
to be interesting just because they are the name of a builtin. Reduces the size
of an empty module by over 80% (~100KB).
llvm-svn: 242650
|
|
|
|
|
|
|
| |
flag to change between serialization and deserialization, so it does not
require the identifier to be serialized.
llvm-svn: 242567
|
|
|
|
|
|
| |
computing redeclaration chains.
llvm-svn: 242253
|
|
|
|
|
|
|
|
| |
before the first imported declaration.
We don't need to track all formerly-canonical declarations of an entity; it's sufficient to track those ones for which no other formerly-canonical declaration was imported into the same module. We call those ones "key declarations", and use them as our starting points for collecting redeclarations and performing namespace lookups.
llvm-svn: 241999
|
|
|
|
|
|
|
|
|
|
| |
The __kindof type qualifier can be applied to Objective-C object
(pointer) types to indicate id-like behavior, which includes implicit
"downcasting" of __kindof types to subclasses and id-like message-send
behavior. __kindof types provide better type bounds for substitutions
into unspecified generic types, which preserves more type information.
llvm-svn: 241548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When messaging a method that was defined in an Objective-C class (or
category or extension thereof) that has type parameters, substitute
the type arguments for those type parameters. Similarly, substitute
into property accesses, instance variables, and other references.
This includes general infrastructure for substituting the type
arguments associated with an ObjCObject(Pointer)Type into a type
referenced within a particular context, handling all of the
substitutions required to deal with (e.g.) inheritance involving
parameterized classes. In cases where no type arguments are available
(e.g., because we're messaging via some unspecialized type, id, etc.),
we substitute in the type bounds for the type parameters instead.
Example:
@interface NSSet<T : id<NSCopying>> : NSObject <NSCopying>
- (T)firstObject;
@end
void f(NSSet<NSString *> *stringSet, NSSet *anySet) {
[stringSet firstObject]; // produces NSString*
[anySet firstObject]; // produces id<NSCopying> (the bound)
}
When substituting for the type parameters given an unspecialized
context (i.e., no specific type arguments were given), substituting
the type bounds unconditionally produces type signatures that are too
strong compared to the pre-generics signatures. Instead, use the
following rule:
- In covariant positions, such as method return types, replace type
parameters with “id” or “Class” (the latter only when the type
parameter bound is “Class” or qualified class, e.g,
“Class<NSCopying>”)
- In other positions (e.g., parameter types), replace type
parameters with their type bounds.
- When a specialized Objective-C object or object pointer type
contains a type parameter in its type arguments (e.g.,
NSArray<T>*, but not NSArray<NSString *> *), replace the entire
object/object pointer type with its unspecialized version (e.g.,
NSArray *).
llvm-svn: 241543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Objective-C type arguments can be provided in angle brackets following
an Objective-C interface type. Syntactically, this is the same
position as one would provide protocol qualifiers (e.g.,
id<NSCopying>), so parse both together and let Sema sort out the
ambiguous cases. This applies both when parsing types and when parsing
the superclass of an Objective-C class, which can now be a specialized
type (e.g., NSMutableArray<T> inherits from NSArray<T>).
Check Objective-C type arguments against the type parameters of the
corresponding class. Verify the length of the type argument list and
that each type argument satisfies the corresponding bound.
Specializations of parameterized Objective-C classes are represented
in the type system as distinct types. Both specialized types (e.g.,
NSArray<NSString *> *) and unspecialized types (NSArray *) are
represented, separately.
llvm-svn: 241542
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch extends ObjCBoxedExpr to accept records (structs and unions):
typedef struct __attribute__((objc_boxable)) _Color {
int r, g, b;
} Color;
Color color;
NSValue *boxedColor = @(color); // [NSValue valueWithBytes:&color objCType:@encode(Color)];
llvm-svn: 240761
|
|
|
|
| |
llvm-svn: 240434
|
|
|
|
|
|
|
| |
Any extra features from -fmodule-feature are part of the module hash and
need to get validated on load. Also print them with -module-file-info.
llvm-svn: 240433
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
|
| |
Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.
llvm-svn: 239750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
This patch attempts to fix this problem.
Given the following code snippet,
struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Differential Review: http://reviews.llvm.org/D5789
llvm-svn: 239446
|
|
|
|
|
|
|
|
|
|
| |
loops.
No functional change intended.
Patch by Sebastian Edman!
llvm-svn: 238547
|
|
|
|
|
|
|
|
|
| |
MSVC 2015 includes the std::data() template function added to C++17. ADL
causes both cl.exe and clang-cl to prefer std::data over our static
helper here, and we get errors about converting int64_t* to StringRef.
Renaming it to bytes avoids the ambiguity.
llvm-svn: 237863
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
rev 2 update:
`getNewExprFromInitListOrExpr` should return `dyn_cast_or_null`
instead of `dyn_cast`, since `E` might be null.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237608
|
|
|
|
|
|
| |
rather than converting to an absolute path. No observable change expected, but this allows us to correctly compute the module for an umbrella header, which later changes will require.
llvm-svn: 237508
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
llvm-svn: 237473
|
|
|
|
|
|
| |
module rather than requiring them to work it out themselves.
llvm-svn: 237416
|
|
|
|
|
|
|
|
|
| |
This reverts commit 742dc9b6c9686ab52860b7da39c3a126d8a97fbc.
This is generating multiple segfaults in our internal builds.
Test case coming up shortly.
llvm-svn: 237391
|