| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit doesn't actually migrate to LLVM 9, but it brings our own
C++ bindings in line with LLVM 9 and able to compile against tip of
tree. The changes made were:
* The `MainSubprogram` flag for debuginfo moved between flag types.
* Iteration of archive members was tweaked slightly and we have to
construct the two iterators before constructing the returned
`RustArchiveIterator` value.
* The `getOrInsertFunction` binding now returns a wrapper which we use
`getCallee()` on to get the value we're interested in.
|
|
|
|
|
|
With emscripten removed in #55626, we no longer need to support
building against LLVM 4.
|
|
While we still have to support LLVM 4.0 for Emscripten, we can
drop checks for LLVM >= 4.0 and < 4.0.
|
|
|
|
Updated in llvm-mirror/llvm@203c90ba this function now just returns an `Error`,
so this updates the C++ bindings accordingly
|
|
It looks like LLVM also removed it in llvm-mirror/llvm@f45adc29d in favor of the
name "GNU64". This was added in the thought that we'd need such a variant when
adding mips64 support but we ended up not needing it! For now let's just
removing the various support on the Rust side of things.
|
|
We bumped the minimum LLVM to 3.9 in #45326. This just cleans up the
conditional code in the rustllvm C++ wrappers to assume at least 3.9.
|
|
This makes it more robust when assertions are disabled,
crashing instead of causing UB.
Also introduces a tidy check to enforce this rule,
which in turn necessitated making tidy run on src/rustllvm.
Fixes #44020
|
|
|
|
As per the LLVM style guide, use CamelCase for all locals and classes,
and camelCase for all non-FFI functions.
Also, make names of variables of commonly used types more consistent.
Fixes #38688.
|
|
|
|
|
|
Incrementing the `Archive::child_iterator` fetches and validates the next child.
This can trigger an error, which we previously checked on the *next* call to `LLVMRustArchiveIteratorNext()`.
This means we ignore the last error if we stop iterating halfway through.
This is harmless (we don't access the child, after all) but LLVM 4.0 calls `abort()` if *any* error goes unchecked, even a success value.
This means that basically any rustc invocation that opens an archive and searches through it would die.
The solution implemented here is to change the order of operations, such that
advancing the iterator and fetching the newly-validated iterator happens in the same `Next()` call.
This keeps the error handling behavior as before but ensures all `Error`s get checked.
|
|
The implicit constructor has been deleted. We should use
Error::success() instead.
The constructor in the LLVM headers mentions that "success" should be
used instead of the deleted constructor for clarity.
|
|
Error handling is being transitioned from ErrorOr<T> to Expected<T> which has a different API and requires explicitly handling all errors
|
|
This doesn't actually do anything for LLVM 4.x yet, but sets the stage.
|
|
|
|
|
|
The passed error needs to be checked.
Otherwise it will force an abort when it is deconstructed, but a
success value.
|
|
|
|
|
|
This was changed back in
https://github.com/rust-lang/llvm/commit/aacf2fbf
|
|
|
|
Changed in
https://github.com/rust-lang/llvm/commit/0b21d88fd31b4bfb6fdb7e2f1ed5f93639d5bd1c
|
|
The new NewArchiveMember is simpler and requires less context,
according to upstream.
This was changed in http://reviews.llvm.org/D21721
|
|
|
|
|
|
This brings some routine upgrades to the bundled LLVM that we're using, the most
notable of which is a bug fix to the way we handle range asserts when loading
the discriminant of an enum. This fix ended up being very similar to f9d4149c
where we basically can't have a range assert when loading a discriminant due to
filling drop, and appropriate flags were added to communicate this to
`trans::adt`.
|
|
|
|
Currently, `rustc` generates nondeterministic archives, which contain system timestamps. These don't really serve any useful purpose, and enabling deterministic archives moves us a little closer to completely deterministic builds. For a small toy library using `std::ops::{Deref,DerefMut}`, this change actually results in a bit-for-bit identical build every time.
|
|
Updates our LLVM bindings to be able to write out multiple kinds of archives.
This commit also enables using LLVM instead of the system ar on all current
targets.
|
|
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
|
