language options. Use that .def file to declare the LangOptions class
and initialize all of its members, eliminating a source of annoying
initialization bugs.
AST serialization changes are next up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139605 91177308-0d34-0410-b5e6-96231b3b80d8
Only predefine the OBJC_ZEROCOST_EXCEPTIONS macro if Objective-C
exceptions are turned on. Fixes PR10910.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139496 91177308-0d34-0410-b5e6-96231b3b80d8
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134453 91177308-0d34-0410-b5e6-96231b3b80d8
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise statements like:
__int64 var = __int64(0);
would be expanded to:
long long var = long long(0);
and fail to compile.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130369 91177308-0d34-0410-b5e6-96231b3b80d8
matches GCC behavior which libstdc++ uses to limit #warning-based
messages about deprecation.
The machinery involves threading this through a new '-fdeprecated-macro'
flag for CC1. The flag defaults to "on", similarly to -Wdeprecated. We
turn the flag off in the driver when the warning is turned off (modulo
matching some GCC bugs). We record this as a language option, and key
the preprocessor on the option when introducing the define.
A separate flag rather than a '-D' flag allows us to properly represent
the difference between C and C++ builds (only C++ receives the define),
and it allows the specific behavior of following -Wdeprecated without
potentially impacting the set of user-provided macro flags.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130055 91177308-0d34-0410-b5e6-96231b3b80d8
should report the original file name for contents of files that were overriden by other files,
otherwise it should report the name of the new file. Default is true.
Also add similar field in PreprocessorOptions and pass similar parameter in ASTUnit::LoadFromCommandLine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127289 91177308-0d34-0410-b5e6-96231b3b80d8
FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120010 91177308-0d34-0410-b5e6-96231b3b80d8
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118203 91177308-0d34-0410-b5e6-96231b3b80d8
reparsing an ASTUnit. When saving a preamble, create a buffer larger
than the actual file we're working with but fill everything from the
end of the preamble to the end of the file with spaces (so the lexer
will quickly skip them). When we load the file, create a buffer of the
same size, filling it with the file and then spaces. Then, instruct
the lexer to start lexing after the preamble, therefore continuing the
parse from the spot where the preamble left off.
It's now possible to perform a simple preamble build + parse (+
reparse) with ASTUnit. However, one has to disable a bunch of checking
in the PCH reader to do so. That part isn't committed; it will likely
be handled with some other kind of flag (e.g., -fno-validate-pch).
As part of this, fix some issues with null termination of the memory
buffers created for the preamble; we were trying to explicitly
NULL-terminate them, even though they were also getting implicitly
NULL terminated, leading to excess warnings about NULL characters in
source files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109445 91177308-0d34-0410-b5e6-96231b3b80d8
'long'. The practical upshot is so that the uint64_t we define in our stdint.h
ends up being compatible with that defined by gcc (at least on Darwin), which
otherwise could lead to type incompatibilities with other system headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107255 91177308-0d34-0410-b5e6-96231b3b80d8
.S files. "# 123" is passed through as-is, not treated as a line
marker in this mode. No testcase, because it would be nasty and isn't
worth it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102391 91177308-0d34-0410-b5e6-96231b3b80d8
copy the source buffers provided rather than referencing them
directly, so that the caller can free those buffers immediately after
calling clang_createTranslationUnitFromSourceFile(). Otherwise, we
risk hitting those buffers later (when building source ranges, forming
diagnostics, etc.).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97296 91177308-0d34-0410-b5e6-96231b3b80d8
temporaries (this is one reason I'm nervous about propagating their use beyond
particularly performance critical places).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93981 91177308-0d34-0410-b5e6-96231b3b80d8
std::vectors.
- MacroBuilder wraps a raw_ostream so it can easily write to any buffer
supported by raw_ostream.
- MacroBuilder's method take Twines for easy string concatenation (this was done
with sprintf and temporary buffers before).
- Targets still use std::vector as they don't have access to the builder.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93051 91177308-0d34-0410-b5e6-96231b3b80d8
file. This is accomplished by introducing the notion of a "virtual"
file into the file manager, which provides a FileEntry* for a named
file whose size and modification time are known but which may not
exist on disk.
Added a cute little test that remaps both a .c file and a .h file it
includes to alternative files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90329 91177308-0d34-0410-b5e6-96231b3b80d8
__INTPTR_TYPE__ as the last is used in the test/CodeGen/const-init.c and all
could potentially be in use in the wild. My apologies.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89345 91177308-0d34-0410-b5e6-96231b3b80d8
__INTn_C_SUFFIX__ macros that are defined for types with corresponding
constant suffixes (i.e. long and long long).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@88914 91177308-0d34-0410-b5e6-96231b3b80d8
Ken Dyck!
"This adds definitions for types of 8-bit multiples
from 8 to 64 to stdint.h and rationalizes the selection of types
for the exact-width definitions in InitPreprocessor.cpp."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86977 91177308-0d34-0410-b5e6-96231b3b80d8
into TargetInfo, just derive this based on the underlying type.
This prevents them from getting out of synch, patch by Ken Dyck!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86976 91177308-0d34-0410-b5e6-96231b3b80d8
Note that I'm guessing that *BSD and Solaris do the same thing as Linux
here, but it's quite possible I'm wrong; if the following testcase
gives an error on x86-64 with gcc for any of those operating systems, please
tell me:
#include <stdint.h>
int64_t x; long x;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74583 91177308-0d34-0410-b5e6-96231b3b80d8
function attributes. There are predefined macros that are defined when stack
protectors are used: __SSP__=1 with -fstack-protector and __SSP_ALL__=2 with
-fstack-protector-all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74405 91177308-0d34-0410-b5e6-96231b3b80d8
unnecessary, this was causing issues for assembler-with-cpp mode, which
doesn't process the directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73382 91177308-0d34-0410-b5e6-96231b3b80d8
compiled with -fobjc-sender-dependent-dispatch. This is used in AOP, COP, implementing object
planes, and a few other things.
Patch by David Chisnall.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72275 91177308-0d34-0410-b5e6-96231b3b80d8
buffer. This caused exciting nonsense like this:
$ clang t.c -fsyntax-only -UMACRO
In file included from <built-in>:104:
<command line>:1:14: warning: extra tokens at end of #undef directive [-Wextra-tokens]
#undef MACRO 1
^
//
1 diagnostic generated.
rdar://6891800
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71860 91177308-0d34-0410-b5e6-96231b3b80d8
- If we don't find a file looking relative to the current working
directory, fall back to header search. This is closer to what would
happen if the lookup was starting from right directory in the first
place (except it will find files in the directory of the main
source file, which I *think* should not be found).
- PR3992.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69794 91177308-0d34-0410-b5e6-96231b3b80d8
by marking the predefines buffer as a system header. The problem
with stdint is that it was getting problems like this:
/Volumes/Projects/cvs/llvm/Debug/lib/clang/1.0/include/stdint.h:43:9: warning: 'long long' is an extension when C99 mode is not enabled
typedef __INT64_TYPE__ int64_t;
^
<built-in>:73:29: note: instantiated from:
#define __INT64_TYPE__ long long
^
We correctly silence warnings in system headers, but only if the
spelling location of the token came from the system header. This is
designed so that if you use a system macro in your code that you don't
get punished for its definition. This is all cool except that the
predefines buffer wasn't considered a system header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69770 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor