| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
to destroy one of these.
llvm-svn: 213837
|
|
|
|
|
|
|
|
| |
Remove pointless MICache: it only ever contained up to 1 object, and was only
non-empty when recovering from an error. There's no performance or memory win
from maintaining this cache.
llvm-svn: 213825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This flag specifies that we are building an implementation file of the
module <name>, preventing importing <name> as a module. This does not
consider this to be the 'current module' for the purposes of doing
modular checks like decluse or non-modular-include warnings, unlike
-fmodule-name.
This is needed as a stopgap until:
1) we can resolve relative includes to a VFS-mapped module (or can
safely import a header textually and as part of a module)
and ideally
2) we can safely do incremental rebuilding when implementation files
import submodules.
llvm-svn: 213767
|
|
|
|
|
|
| |
This will be used to improve other diagnostics.
llvm-svn: 213657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thorough tests.
Original commit message:
[modules] Fix macro hiding bug exposed if:
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
llvm-svn: 213416
|
|
|
|
| |
llvm-svn: 213349
|
|
|
|
|
|
|
| |
Just because we can open a directory named "COcoa.framework" doesn't
mean we should provide a "COcoa" module on a case-insensitive filesystem.
llvm-svn: 212975
|
|
|
|
|
|
|
|
|
| |
std::unique_ptr
Spotted after a memory leak (due to the complexities of manual memory
management) was fixed in 212466.
llvm-svn: 212541
|
|
|
|
|
|
| |
Cleanup only.
llvm-svn: 212457
|
|
|
|
| |
llvm-svn: 212408
|
|
|
|
| |
llvm-svn: 212047
|
|
|
|
|
|
| |
and count.
llvm-svn: 211763
|
|
|
|
|
|
|
| |
By using vfs::recursive_directory_iterator, this warning will now fire
when some or all of a module's headers are from VFS mappings.
llvm-svn: 211746
|
|
|
|
| |
llvm-svn: 211479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
|
|
|
|
|
|
|
|
|
| |
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
|
|
|
|
|
|
|
|
|
|
|
|
| |
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
|
|
|
|
| |
llvm-svn: 211295
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
llvm-svn: 211005
|
|
|
|
| |
llvm-svn: 210802
|
|
|
|
| |
llvm-svn: 210780
|
|
|
|
| |
llvm-svn: 210764
|
|
|
|
|
|
|
|
|
| |
This begins to address cognitive dissonance caused by treating the Note
diagnostic level as a severity in the diagnostic engine.
No change in functionality.
llvm-svn: 210758
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diagnostic mappings are used to calculate the final severity of diagnostic
instances.
Detangle the implementation to reflect the terminology used in documentation
and bindings.
No change in functionality.
llvm-svn: 210518
|
|
|
|
|
|
|
| |
This GCC warning is useful for validating reproducible builds
and might help when tracking down issues with modules too.
llvm-svn: 210511
|
|
|
|
| |
llvm-svn: 210448
|
|
|
|
|
|
|
|
|
|
|
| |
extension
With recent changes, this is now a compatible language extension and can be
safely enabled with -ms-extensions instead of requiring the full
-ms-compatibility MSVC drop-in mode. As such we can now also emit an extension
warning under -Wmicrosoft to help users port their code.
llvm-svn: 209978
|
|
|
|
|
|
|
|
|
|
| |
identifiers
This failure mode shows up occasionally when users try to include C headers in
C++ projects or when porting from Windows. We might as well recover in the way
the user expected, thus avoiding confusing diagnostic messages at point of use.
llvm-svn: 209963
|
|
|
|
|
|
|
|
|
|
| |
The checks below can hypothetically apply to converted operator name
identifiers.
In practice there are no builtin macros etc. with those names so there's no
behavioural change to test.
llvm-svn: 209962
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3963
llvm-svn: 209859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The limits on the number of fix-it hints and ranges attached to a
diagnostic are arbitrary and don't apply universally to all users of the
DiagnosticsEngine. The way the limits are enforced may lead to diagnostics
generating invalid sets of fixes. I suggest removing the limits, which will also
simplify the implementation.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3879
llvm-svn: 209468
|
|
|
|
| |
llvm-svn: 209322
|
|
|
|
|
|
|
|
|
| |
Also flesh out missing tests, improve diagnostic QOI and fix a couple of corner
cases found in the process.
Fixes PR10606.
llvm-svn: 209276
|
|
|
|
|
|
| |
There's no immediate demand or plan to work on these.
llvm-svn: 209090
|
|
|
|
| |
llvm-svn: 209083
|
|
|
|
| |
llvm-svn: 209061
|
|
|
|
|
|
|
|
| |
It makes more sense to just overload createFileID().
Gardening only.
llvm-svn: 209002
|
|
|
|
|
|
|
|
|
|
| |
When using the VFS, we want the virtual header location when searching
for a framework module, since that will be the one in the correct
directory structure for the module.
I'll add a regression test once I finish reducing the larger one I have.
llvm-svn: 208901
|
|
|
|
|
|
|
| |
cxx_decltype_auto, and fix documentation of cxx_generic_lambdas and
cxx_init_captures to specify the right feature-check name.
llvm-svn: 208445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroArgs are owned by TokenLexer, and when a TokenLexer is destroyed, it'll
call its MacroArgs's destroy() method. destroy() only appends the MacroArg to
Preprocessor's MacroArgCache list, and Preprocessor's destructor then calls
deallocate() on all MacroArgs in that list. This method then ends up freeing
the MacroArgs's memory.
In a code completion context, Parser::cutOffParsing() gets called when a code
completion token is hit, which changes the type of the current token to
tok::eof. eof tokens aren't always ConsumeToken()ed, so
Preprocessor::HandleEndOfFile() isn't always called, and that function is
responsible for popping the macro stack.
Due to this, Preprocessor::CurTokenLexer can be non-NULL when
~Preprocessor runs. It's a unique_ptr, so it ended up being destructed after
~Preprocessor completed, and its MacroArgs thus got added to the freelist after
the code freeing things on the freelist had already completed. The fix is to
explicitly call reset() before the freelist processing happens. (See the bug
for more notes.)
llvm-svn: 208438
|
|
|
|
| |
llvm-svn: 208386
|
|
|
|
| |
llvm-svn: 208381
|
|
|
|
| |
llvm-svn: 208380
|
|
|
|
|
|
|
|
|
|
| |
But keep -Wnon-modular-include-in-[framework-]module
This warning is too noisy and doesn't really indicate a problem for most
people. Even though it would only really affect people using
-Weverything, that seems bad so remove it.
llvm-svn: 208345
|
|
|
|
|
|
|
|
|
|
|
|
| |
Warn on non-modular includes in various contexts.
-Wnon-modular-include
-Wnon-modular-include-in-module
-Wnon-modular-include-in-framework-module
Where each group is a subgroup of those above it.
llvm-svn: 208004
|
|
|
|
|
|
|
|
|
| |
whole code would be better with std::unique_ptr managing the lifetimes
of the handlers, but I wanted to make a targeted fix to the leaks first.
With this change, all of the Clang preprocessor tests are leak free with
LSan.
llvm-svn: 207872
|
|
|
|
|
|
| |
Landing this separately to make the previous commits easy to follow at home.
llvm-svn: 207826
|
|
|
|
|
|
|
|
| |
The Preprocessor::Initialize() function already offers a clear interface to
achieve this, further reducing the confusing number of states a newly
constructed preprocessor can have.
llvm-svn: 207825
|
|
|
|
|
|
|
| |
Preprocessor::enableIncrementalProcessing() provides a consistent interface to
enable the feature.
llvm-svn: 207824
|
|
|
|
|
|
|
| |
And refactor to have just one place in code that sets up the empty
pragma handlers.
llvm-svn: 207758
|