| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 215927
|
|
|
|
| |
llvm-svn: 215900
|
|
|
|
|
|
| |
silent coverity warning CID 1231654
llvm-svn: 215897
|
|
|
|
|
|
| |
needing to mention the size.
llvm-svn: 215869
|
|
|
|
| |
llvm-svn: 215853
|
|
|
|
|
|
| |
auroraux.org is not resolving.
llvm-svn: 215644
|
|
|
|
|
|
|
|
| |
std::unique_ptr is null initialized and reset default to null.
Thanks to David Blaikie for noticing.
llvm-svn: 215560
|
|
|
|
| |
llvm-svn: 215559
|
|
|
|
|
|
|
| |
This code doesn't care where the data it is processing comes from, so a
StringRef is probably the most natural interface.
llvm-svn: 215448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the gcc docs, -include uses the current working directory
for the lookup instead of the main source file.
This patch gets rid of NormalizeIncludePath (which relied on an
implementation detail of FileManager / FileEntry for the include path
logic to work), and instead hands the correct lookup information down to
LookupFile.
This will allow us to change the FileEntry's behavior regarding its Name
caching.
llvm-svn: 215433
|
|
|
|
|
|
|
|
| |
anyway. If -ast-dump *is* also provided, then dump the AST declarations as well
as the lookup results. This is invaluable for cross-correlating the lookup
information with the declarations actually found.
llvm-svn: 215393
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(dropping const from the reference as MemoryBuffer is immutable already,
so const is just redundant - and while I'd personally put const
everywhere, that's not the LLVM Way (see llvm::Type for another example
of an immutable type where "const" is omitted for brevity))
Changing the pointer argument to a reference parameter makes call sites
identical between callers with unique_ptrs or raw pointers, minimizing
the churn in a pending unique_ptr migrations.
llvm-svn: 215391
|
|
|
|
|
|
|
|
|
|
| |
And in the process, discover that FileManager::removeStatCache had a
double-delete when removing an element from the middle of the list (at
the beginning or the end of the list, there was no problem) and add a
unit test to exercise the code path (which successfully crashed when run
(with modifications to match the old API) without this patch applied)
llvm-svn: 215388
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unique_ptr around a non-owning raw_ostream in CodeGenAction::CreateASTConsumer"
It cannot be compiled on Visual Studio 2012.
clang\include\clang/Frontend/CompilerInstance.h(153):
error C2248: 'std::unique_ptr<_Ty>::unique_ptr' : cannot access private member declared in class 'std::unique_ptr<_Ty>'
with
[
_Ty=llvm::raw_ostream
]
D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\memory(1447) : see declaration of 'std::unique_ptr<_Ty>::unique_ptr'
with
[
_Ty=llvm::raw_ostream
]
This diagnostic occurred in the compiler generated function 'clang::CompilerInstance::OutputFile::OutputFile(const clang::CompilerInstance::OutputFile &)'
llvm-svn: 215346
|
|
|
|
|
|
| |
a non-owning raw_ostream in CodeGenAction::CreateASTConsumer
llvm-svn: 215331
|
|
|
|
|
|
|
|
|
| |
CompilerInstance.h on Sema.h
Hopefully this fixes the libstdc++ build on some of the buildbots after
r215321.
llvm-svn: 215325
|
|
|
|
|
|
|
|
| |
After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.
llvm-svn: 215323
|
|
|
|
| |
llvm-svn: 215321
|
|
|
|
| |
llvm-svn: 215320
|
|
|
|
| |
llvm-svn: 215319
|
|
|
|
| |
llvm-svn: 215317
|
|
|
|
|
|
|
|
|
| |
class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
the remaining cases. This lets us do less bookkeeping to keep the
ModuleMap fields up to date.
llvm-svn: 215268
|
|
|
|
|
|
|
|
|
| |
These macros are used as markers for Interface Builder and need to be defined
to empty strings since they have no impact on the code.
Patch by Ted Kremenek.
llvm-svn: 215259
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4799
llvm-svn: 215258
|
|
|
|
|
|
|
|
|
|
|
| |
of a file.
This allows using EndOfMainFile from a PPCallback to access data from the
action. The pattern of PPCallback referencing an action is common in clang-tidy.
Differential Revision: http://reviews.llvm.org/D4773
llvm-svn: 215145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intent when we added remark support, but was never implemented in the general
case, because the first -R flags didn't need it. (-Rpass= had special handling
to accomodate its argument.)
-Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark,
or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything
does not affect remarks, and -Reverything does not affect warnings or errors.
The only "real" -R flag we have right now is -Rmodule-build; that flag is
effectively renamed from -Wmodule-build to -Rmodule-build by this change.
-Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and
-Rno-pass by this change; it's not completely clear whether we intended to have
a -Rpass (with no =pattern), but that is unchanged by this commit, other than
the flag name. The default pattern is effectively one which matches no passes.
In future, we may want to make the default pattern be .*, so that -Reverything
works for -Rpass properly.
llvm-svn: 215046
|
|
|
|
|
|
|
|
|
| |
to instruct the code generator to not enforce a higher alignment
than the given number (of bytes) when accessing memory via an opaque
pointer or reference. Patch reviewed by John McCall (with post-commit
review pending). rdar://16254558
llvm-svn: 214911
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis using
the execution counts obtained from the instrumentation
based profiling (-fprofile-instr-generate).
llvm-svn: 214752
|
|
|
|
|
|
|
| |
This isn't a real diagnostic kind, only a location note, and this form isn't even
used if the SourceManager can provide a valid presumed location. But still.
llvm-svn: 214002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
|
|
|
|
|
|
| |
... just to find out that it didn't build.
llvm-svn: 213454
|
|
|
|
|
|
|
|
|
|
|
| |
".reset()"
It's also possible to just write "= nullptr", but there's some question
of whether that's as readable, so I leave it up to authors to pick which
they prefer for now. If we want to discuss standardizing on one or the
other, we can do that at some point in the future.
llvm-svn: 213439
|
|
|
|
|
|
|
|
|
| |
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
llvm-svn: 213325
|
|
|
|
|
|
|
|
|
| |
(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)
llvm-svn: 213307
|
|
|
|
|
|
|
|
| |
constants. Comparing int against a constant of the given type like
UINT8_MAX will otherwise force a promotion to unsigned int, which is
typically not expected.
llvm-svn: 213301
|
|
|
|
| |
llvm-svn: 213299
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before this patch, you could get lines in the output such as:
Note: including file: ../../dist/include/js/Tc:/path/to/foo.cpp(1,1) : error(clang): static_assert failed...
This patch ensures that the stdout output from showIncludes won't be garbled
in the terminal like this, and it also helps applications that use the output
to generate dependency information if they happen to capture both stdout and
stderr.
Test Plan:
Tested locally, it's hard to write an automated test for this as
the behavior depends on the buffering of the ostreams.
Reviewers: nico
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4559
llvm-svn: 213297
|
|
|
|
| |
llvm-svn: 213289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to fix debug info emission in the presence of plugins.
When plugins are used the Multiplex(AST)Consumer is employed to dispatch
to both the plugin ASTConsumers and the IRGen ASTConsumer. It wasn't
dispatching a critical call for debug info, resulting in plugin users
having a negative debugging experience.
While I'm here, forward a bunch of other missing calls through the
consumer that seem like they should be there.
To test this, use the example plugin (requires plugins and examples) and
split the test case up so that the plugin testing can be done under that
requirement while the non-plugin testing will execute even in builds
that don't include plugin support or examples.
llvm-svn: 213213
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
llvm-svn: 213171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This restores the original behaviour of -fmsc-version. The older option
remains as a mechanism for specifying the basic version information. A
secondary option, -fms-compatibility-version permits the user to specify an
extended version to the driver.
The new version takes the value as a dot-separated value rather than the
major * 100 + minor format that -fmsc-version format. This makes it easier to
specify the value as well as a more flexible manner for specifying the value.
Specifying both values is considered an error.
The older parameter is left solely as a driver option, which is normalised into
the newer parameter. This allows us to retain a single code path in the
compiler itself whilst preserving the semantics of the old parameter as well as
avoid having to determine which of two formats are being used by the invocation.
The test changes are due to the fact that the compiler no longer supports the
old option, and is a direct conversion to the new option.
llvm-svn: 213119
|
|
|
|
| |
llvm-svn: 213097
|
|
|
|
| |
llvm-svn: 213066
|
|
|
|
| |
llvm-svn: 213065
|
|
|
|
|
|
| |
underlaying types.
llvm-svn: 213063
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add __ILP32__ and _ILP32 macro for corresponding platforms.
Cover x86_64-*-*-gnux32 with test.
Test Plan: test added
Reviewers: chandlerc, atanasyan
Subscribers: cfe-commits, dschuff, zinovy.nis
Differential Revision: http://reviews.llvm.org/D4473
llvm-svn: 212931
|
|
|
|
|
|
|
| |
- Plugins don't need to export _ZN4llvm8Registry*.
- Win32.DLL cannot merge common symbols among DLLs. Static members in llvm::Registry should be instantiated in a parent.
llvm-svn: 212821
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hansw, rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4419
llvm-svn: 212753
|
|
|
|
|
|
|
|
| |
Allow diagnostic checks that originate in included files to be matched without necessarily determining the line number that the diagnostic occurs on. The new syntax replaces the line number with '*'. This extension is limited to diagnostics in included files and may be used where the include file is not part of the test-suite itself.
Expected uses are for diagnostics originating in system headers, or for users who use -verify in testing 3rd-party library code where the location of diagnostics in header files may change from revision to revision and their precise location is not important to the success of the test-case.
llvm-svn: 212735
|