It got disconnected during the cmake conversion. For Miscompilation.cpp,
it was purely advisory for the user and the ToolRunner.cpp version was
trying to compensate for libs and bins in the same directory, which
hasn't been the case for a very long time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283022 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places here that actually emit any errors right now, but threading the
APIs through will allow us to replace a bunch of exit(1)'s that are
scattered through this code with proper error handling.
This is more or less NFC, but does move around where a couple of error
messages are printed out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280720 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't the right thing to do - it turns out a number of the APIs
that "never fail" just exit(1) if something bad happens. We can and
should thread Error through this instead.
That diff will make more sense with this reverted. Sorry for the
noise.
This reverts r280690
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280691 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies ListReducer and most of its subclasses by removing the
std::string &Error that was threaded through all of them but almost
never used. If we end up needing error handling in more places here we
can reinstate it using llvm::Error instead of these unwieldy strings.
The 2 cases (out of 12) that actually can hit the error cases are a
little bit awkward now, but those will clean up as I refactor this API
further.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280690 91177308-0d34-0410-b5e6-96231b3b80d8
Passing in a std::unique_ptr should help find errors when the module
is used after being linked into another module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255842 91177308-0d34-0410-b5e6-96231b3b80d8
This patch converts code that has access to a LLVMContext to not take a
diagnostic handler.
This has a few advantages
* It is easier to use a consistent diagnostic handler in a single program.
* Less clutter since we are not passing a handler around.
It does make it a bit awkward to implement some C APIs that return a
diagnostic string. I will propose new versions of these APIs and
deprecate the current ones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255571 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch the diagnostic handler was optional. If it was not
passed, the one in the LLVMContext was used.
That is probably not a pattern we want to follow. If each area has an
optional callback, there is a sea of callbacks and it is hard to follow
which one is called.
Doing this also found cases where the callback is a nice addition, like
testing that no errors or warnings are reported.
The other option is to always use the diagnostic handler in the
LLVMContext. That has a few problems
* To implement the C API we would have to set the diag handler and then
set it back to the original value.
* Code that creates the context might be far away from code that wants
the diagnostics.
I do have a patch that implements the second option and will send that as
an RFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254777 91177308-0d34-0410-b5e6-96231b3b80d8
The linker never takes ownership of a module or changes which module it
is refering to, making it natural to use references.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254449 91177308-0d34-0410-b5e6-96231b3b80d8
We now use clang by default and fallback to gcc when requested.
With this commit, names reflect reality. No functional change
intended.
Discussed with: Rafael Espindola.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@250321 91177308-0d34-0410-b5e6-96231b3b80d8
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238602 91177308-0d34-0410-b5e6-96231b3b80d8
Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233938 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed that it was untested, and forcing it on caused some tests to fail:
LLVM :: Linker/metadata-a.ll
LLVM :: Linker/prefixdata.ll
LLVM :: Linker/type-unique-odr-a.ll
LLVM :: Linker/type-unique-simple-a.ll
LLVM :: Linker/type-unique-simple2-a.ll
LLVM :: Linker/type-unique-simple2.ll
LLVM :: Linker/type-unique-type-array-a.ll
LLVM :: Linker/unnamed-addr1-a.ll
LLVM :: Linker/visibility1.ll
If it is to be resurrected, it has to be fixed and we should probably have a
-preserve-source command line option in llvm-mc and run tests with and without
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220741 91177308-0d34-0410-b5e6-96231b3b80d8
The memory management in BugPoint is fairly convoluted, so this just unwraps
one layer by changing the return type of functions that always return
owned Modules.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216464 91177308-0d34-0410-b5e6-96231b3b80d8