| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 61441
|
| |
|
|
| |
llvm-svn: 61440
|
| |
|
|
| |
llvm-svn: 61439
|
| |
|
|
| |
llvm-svn: 61438
|
| |
|
|
|
|
| |
Patch by Ilya Okonsky
llvm-svn: 61437
|
| |
|
|
|
|
| |
Patch by Ilya Okonsky!
llvm-svn: 61436
|
| |
|
|
| |
llvm-svn: 61435
|
| |
|
|
| |
llvm-svn: 61434
|
| |
|
|
| |
llvm-svn: 61433
|
| |
|
|
| |
llvm-svn: 61432
|
| |
|
|
| |
llvm-svn: 61431
|
| |
|
|
|
|
| |
Change preprocessor implementation of _cdecl to reference __cdecl.
llvm-svn: 61430
|
| |
|
|
| |
llvm-svn: 61429
|
| |
|
|
| |
llvm-svn: 61428
|
| |
|
|
|
|
| |
Remove previous __declspec macro that would effectively erase the construct prior to parsing.
llvm-svn: 61422
|
| |
|
|
| |
llvm-svn: 61421
|
| |
|
|
| |
llvm-svn: 61419
|
| |
|
|
|
|
| |
struct.
llvm-svn: 61418
|
| |
|
|
| |
llvm-svn: 61417
|
| |
|
|
| |
llvm-svn: 61416
|
| |
|
|
|
|
| |
actually do anything with the template arguments, but they'll be used to create template declarations
llvm-svn: 61413
|
| |
|
|
| |
llvm-svn: 61412
|
| |
|
|
| |
llvm-svn: 61411
|
| |
|
|
| |
llvm-svn: 61410
|
| |
|
|
|
|
| |
identify GDM entries.
llvm-svn: 61409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
semantics and improve our handling of default arguments. Specifically,
we follow this order:
- As soon as the see the '}' in the class definition, the class is
complete and we add any implicit declarations (default constructor,
copy constructor, etc.) to the class.
- If there are any default function arguments, parse them
- If there were any inline member function definitions, parse them
As part of this change, we now keep track of the the fact that we've
seen unparsed default function arguments within the AST. See the new
ParmVarDecl::hasUnparsedDefaultArg member. This allows us to properly
cope with calls inside default function arguments to other functions
where we're making use of the default arguments.
Made some C++ error messages regarding failed initializations more
specific.
llvm-svn: 61406
|
| |
|
|
|
|
| |
Patch by Ilya Okonsky!
llvm-svn: 61394
|
| |
|
|
| |
llvm-svn: 61393
|
| |
|
|
|
|
|
| |
sure to look at all of the results returned by name lookup. Fixes
<rdar://problem/6465262>
llvm-svn: 61388
|
| |
|
|
|
|
| |
We now pass all gcc's encoding compatibility tests.
llvm-svn: 61387
|
| |
|
|
|
|
|
|
| |
attached to an identifier. Instead, all overloaded functions will be
pushed into scope, and we'll synthesize an OverloadedFunctionDecl on
the fly when we need it.
llvm-svn: 61386
|
| |
|
|
| |
llvm-svn: 61384
|
| |
|
|
|
|
| |
gcc compatibilty in all aspects of encoding now.
llvm-svn: 61383
|
| |
|
|
| |
llvm-svn: 61382
|
| |
|
|
|
|
| |
No big functionality change.
llvm-svn: 61381
|
| |
|
|
|
|
|
| |
- This reduces the PTH size for Cocoa.h by 7%.
- The increases PTH -Eonly speed for Cocoa.h by 0.8%.
llvm-svn: 61377
|
| |
|
|
| |
llvm-svn: 61375
|
| |
|
|
| |
llvm-svn: 61370
|
| |
|
|
| |
llvm-svn: 61367
|
| |
|
|
|
|
|
|
| |
- Encode the token length with 2 bytes instead of 4.
- This reduces the size of the .pth file for Cocoa.h by 12%.
- This speeds up PTH time (-Eonly) on Cocoa.h by 1.6%.
llvm-svn: 61364
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- In PTHLexer::Lex read all of the token data from PTH file before
constructing the token. The idea is to enhance locality.
- Do not use Read8/Read32 in PTHLexer::Lex. Inline these operations manually.
- Change PTHManager::ReadIdentifierInfo() to PTHManager::GetIdentifierInfo().
They are functionally the same except that PTHLexer::Lex() reads the
persistent id.
These changes result in a 3.3% speedup for PTH on Cocoa.h (-Eonly).
llvm-svn: 61363
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Embed 'eom' tokens in PTH file.
- Use embedded 'eom' tokens to not lazily generate them in the PTHLexer.
This means that PTHLexer can always advance to the next token after
reading a token (instead of buffering tokens using a copy).
- Moved logic of 'ReadToken' into Lex. GetToken & ReadToken no longer exist.
- These changes result in a 3.3% speedup (-Eonly) on Cocoa.h.
- The code is a little gross. Many cleanups are possible and should be done.
llvm-svn: 61360
|
| |
|
|
| |
llvm-svn: 61359
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DeclContext. Instead, just keep the list of currently-active
declarations and only build the OverloadedFunctionDecl when we
absolutely need it.
This is a half-step toward eliminating the need to explicitly build
OverloadedFunctionDecls that store sets of overloaded
functions. This was suggested by Argiris a while back, and it's a good
thing for several reasons: first, it eliminates the messy logic that
currently tries to keep the OverloadedFunctionDecl in sync with the
declarations that are being added. Second, it will (eventually)
eliminate the need to allocate memory for overload sets, which could
help performance. Finally, it helps set us up for when name lookup can
return multiple (possibly ambiguous) results, as can happen with
lookup of class members in C++.
Next steps: make the IdentifierResolver store overloads as separate
entries in its list rather than replacing them with an
OverloadedFunctionDecl now, then see how far we can go toward
eliminating OverloadedFunctionDecl entirely.
llvm-svn: 61357
|
| |
|
|
|
|
| |
outer-most const of pointer types.
llvm-svn: 61355
|
| |
|
|
|
|
| |
rewriting @selector?.
llvm-svn: 61351
|
| |
|
|
| |
llvm-svn: 61348
|
| |
|
|
| |
llvm-svn: 61346
|
| |
|
|
|
|
| |
pointer type. Fixes rdar://problem/6463298
llvm-svn: 61340
|
| |
|
|
|
|
|
| |
instance methods by building print-class-info.m,
whose output is now identical to what gcc puts out.
llvm-svn: 61339
|