"__attribute((pascal))" or "__pascal" (and "_pascal" under
-fborland-extensions). Support still needs to be added to llvm.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112939 91177308-0d34-0410-b5e6-96231b3b80d8
#pragma once wasn't working on win32 if the header file was included
using a different case.
I tracked down the problem to the fact that clang::FileManager was
caching files using case sensitive string (UniqueFiles) on Windows.
I changed FileManager to cache filename in lower case only.
Doesn't affect UNIX because UNIX uses Inode to uniquely identify files.
unix doesn't use this codepath.
Analysis and patch by Francois Pichet!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111866 91177308-0d34-0410-b5e6-96231b3b80d8
it deserves its own enumerator. Obviously the implementations should
closely follow the Itanium ABI except in cases of divergence.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111749 91177308-0d34-0410-b5e6-96231b3b80d8
-There are 2 instances that change the TokenID for GNU libstdc++ 4.2 compatibility.
To handler those cases introduce a RevertedTokenID bitfield, RevertTokenIDToIdentifier() and hasRevertedTokenIDToIdentifier() methods.
Store the bitfield in PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110868 91177308-0d34-0410-b5e6-96231b3b80d8
- We don't recognize double or NEON register names yet -- we don't have the
infrastructure to generate the right clobbers for them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110775 91177308-0d34-0410-b5e6-96231b3b80d8
randomly. This makes us consistently show "-pedantic" as the warning option
for a warning where appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109987 91177308-0d34-0410-b5e6-96231b3b80d8
the files in the precompiled preamble have changed since it was build,
force the preamble to be rebuilt.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109937 91177308-0d34-0410-b5e6-96231b3b80d8
its absolute path on disk. Also, introduce a fun test for the
precompiled preamble, which almost works...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109470 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
reparses an already-parsed translation unit. At the moment it's just a
convenience function, but we hope to use it for performance
optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108756 91177308-0d34-0410-b5e6-96231b3b80d8
represent builtins that have the "scanf" attribution (via the format attribute) just
like we do with printf functions. Follow-up work is needed to add similar support
for fscanf et al.
This is to support format-string checking for scanf functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108499 91177308-0d34-0410-b5e6-96231b3b80d8
whether to use objc_msgSend_fpret; the choice is target dependent, not Obj-C ABI
dependent.
- <rdar://problem/8139758> arm objc _objc_msgSend_fpret bug
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108379 91177308-0d34-0410-b5e6-96231b3b80d8