| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.
Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.
llvm-svn: 147467
|
|
|
|
|
|
| |
@import identifier [. identifier]* ;
llvm-svn: 147452
|
|
|
|
|
|
| |
ObjCProtocolDecl modules forward declarations properly.
llvm-svn: 147415
|
|
|
|
|
|
|
| |
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
|
|
|
|
|
|
|
|
| |
good parser error recovery and for not crashing.
We still have a accepts-invalid-code bug.
llvm-svn: 147216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stopping at '@' was originally intended to avoid skipping an '@' at the @interface context
when doing parser recovery, but we should not stop at all '@' tokens because they may be part
of expressions (e.g. in @"string", @selector(), etc.), so in most cases we will want to skip them.
This commit caused 'test/Parser/method-def-in-class.m' to fail for the cases where we tried to
recover from unmatched angle bracket but IMO it is not a big deal to not have good recovery
from such broken code and the way we did recovery would not always work anyway (e.g. if there was '@'
in an expression).
The case that rdar://7029784 is about still passes.
llvm-svn: 146815
|
|
|
|
| |
llvm-svn: 146145
|
|
|
|
| |
llvm-svn: 145785
|
|
|
|
|
|
| |
<rdar://problem/10465079>.
llvm-svn: 145656
|
|
|
|
|
|
|
| |
top-level module name to a module path (e.g., std.vector). We're still
missing a number of pieces for this actually to do something.
llvm-svn: 145462
|
|
|
|
|
|
|
|
| |
definitions tokens
for late parsing.
llvm-svn: 145394
|
|
|
|
|
|
|
|
|
|
|
|
| |
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
|
|
|
|
|
|
|
| |
entering the context of a nested-name-specifier. Fixes
<rdar://problem/10397846>.
llvm-svn: 143967
|
|
|
|
|
|
|
|
|
| |
Microsoft __if_exists/__if_not_exists statement. Also note that we
weren't traversing DeclarationNameInfo *at all* within the
RecursiveASTVisitor, which would be rather fatal for variadic
templates.
llvm-svn: 142906
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
analysis to separate dependent names from non-dependent names. For
dependent names, we'll behave differently from Visual C++:
- For __if_exists/__if_not_exists at class scope, we'll just warn
and then ignore them.
- For __if_exists/__if_not_exists in statements, we'll treat the
inner statement as a compound statement, which we only instantiate
in templates where the dependent name (after instantiation)
exists. This behavior is different from VC++, but it's as close as
we can get without encroaching ridiculousness.
The latter part (dependent statements) is not yet implemented.
llvm-svn: 142864
|
|
|
|
|
|
|
| |
keyword, because both libstdc++ and libc++ use "__except" as an
identifier. Fixes <rdar://problem/10322555>.
llvm-svn: 142636
|
|
|
|
|
|
| |
gcc's behaviour), and a -Wc++98-compat-pedantic warning for C++11.
llvm-svn: 142597
|
|
|
|
| |
llvm-svn: 142056
|
|
|
|
|
|
|
| |
delimiter pairs and detect when we exceed the implementation limit for
nesting depth, from Aaron Ballman!
llvm-svn: 141782
|
|
|
|
|
|
|
|
| |
The main motivation was to do typo correction in C++ "new" statements,
though picking it up in other places where type names are expected was
pretty much a freebie.
llvm-svn: 141621
|
|
|
|
| |
llvm-svn: 141610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm[1]: Compiling CommandLine.cpp for Debug+Asserts build
if /Users/void/llvm/llvm-opt.obj/Release+Asserts/bin/clang++ -I/Users/void/llvm/llvm.obj/include -I/Users/void/llvm/llvm.obj/lib/Support -I/Users/void/llvm/llvm.src/include -I/Users/void/llvm/llvm.src/lib/Support -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fno-exceptions -fno-common -Woverloaded-virtual -Wcast-qual -m64 -Wall -W -Wno-unused-parameter -Wwrite-strings -c -MMD -MP -MF "/Users/void/llvm/llvm.obj/lib/Support/Debug+Asserts/CommandLine.d.tmp" -MT "/Users/void/llvm/llvm.obj/lib/Support/Debug+Asserts/CommandLine.o" -MT "/Users/void/llvm/llvm.obj/lib/Support/Debug+Asserts/CommandLine.d" /Users/void/llvm/llvm.src/lib/Support/CommandLine.cpp -o /Users/void/llvm/llvm.obj/lib/Support/Debug+Asserts/CommandLine.o ; \
then /bin/mv -f "/Users/void/llvm/llvm.obj/lib/Support/Debug+Asserts/CommandLine.d.tmp" "/Users/void/llvm/llvm.obj/lib/Support/Debug+Asserts/CommandLine.d"; else /bin/rm "/Users/void/llvm/llvm.obj/lib/Support/Debug+Asserts/CommandLine.d.tmp"; exit 1; fi
In file included from /Users/void/llvm/llvm.src/lib/Support/CommandLine.cpp:25:
/Users/void/llvm/llvm.src/include/llvm/Support/system_error.h:690:14: error: unknown type name 'make_error_condition'; did you mean 'error_condition'?
{*this = make_error_condition(_e);}
^~~~~~~~~~~~~~~~~~~~
error_condition
...
llvm-svn: 140599
|
|
|
|
| |
llvm-svn: 140589
|
|
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
|
|
|
|
|
|
|
|
|
| |
'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
llvm-svn: 139275
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
|
|
|
|
|
|
|
|
| |
existing practice with Python extension modules. Not that Python
extension modules should be using a double-underscored identifier
anyway, but...
llvm-svn: 138870
|
|
|
|
|
|
|
|
|
|
| |
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
llvm-svn: 138709
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
llvm-svn: 138679
|
|
|
|
| |
llvm-svn: 138584
|
|
|
|
|
|
| |
as in @class foo, bar. More cleanup to follow.
llvm-svn: 138567
|
|
|
|
|
|
| |
a context switching object.
llvm-svn: 138248
|
|
|
|
|
|
| |
failures are resolved.
llvm-svn: 138234
|
|
|
|
| |
llvm-svn: 138049
|
|
|
|
|
|
|
|
|
|
| |
to modernity. Instead of passing down individual
context objects from parser to sema, establish decl
context in parser and have sema access current context
as needed. I still need to take of Doug's comment for
minor cleanups.
llvm-svn: 138040
|
|
|
|
| |
llvm-svn: 136210
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
| |
llvm-svn: 134419
|
|
|
|
|
|
|
|
|
|
| |
resources that, while their
lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak.
Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138.
llvm-svn: 133610
|
|
|
|
| |
llvm-svn: 132878
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
typedef int TYPE;
class C {
__if_exists(TYPE) {
TYPE a;
}
__if_not_exists(TYPE) {
this will never be parsed.
}
};
llvm-svn: 132052
|
|
|
|
|
|
|
|
| |
The general out-of-line case (including explicit instantiation mostly
works except that the definition is being lost somewhere between the AST
and CodeGen, so the definition is never emitted.
llvm-svn: 131933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They are actually grammatically considered definitions and parsed
accordingly.
This fixes the outstanding bugs regarding defaulting functions after
their declarations.
We now really nicely diagnose the following construct (try it!)
int foo() = delete, bar;
Still todo: Defaulted functions other than default constructors
Test cases (including for the above construct)
llvm-svn: 131228
|
|
|
|
| |
llvm-svn: 131050
|
|
|
|
|
|
|
|
| |
Patch authored by Sohail Somani.
Provide parsing and AST support for Windows structured exception handling.
llvm-svn: 130366
|
|
|
|
|
|
|
|
|
| |
in the classification of template names and using declarations. We now
properly typo-correct the leading identifiers in statements to types,
templates, values, etc. As an added bonus, this reduces the number of
lookups required for disambiguation.
llvm-svn: 130288
|
|
|
|
|
|
| |
This is wip.
llvm-svn: 130138
|
|
|
|
|
|
|
|
| |
This fixes 1 error when parsing MSVC 2008 headers with clang.
Must "return true;" even if it is a warning because the rest of the code path assumes that SS is set to something. The parser will get back on its feet and continue parsing the rest of the declaration correctly so it is not a problem.
llvm-svn: 130088
|
|
|
|
|
|
| |
-flate-template-parsing mode.
llvm-svn: 130030
|
|
|
|
|
|
|
|
|
| |
function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup.
Using this flag is necessary for compatibility with Microsoft template code.
This also provides some parsing speed improvement.
llvm-svn: 130022
|