rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods #54012

denismerigoux · 2018-09-06T22:11:00Z

This PR is the continuation of #52461 in the grand plan of #45274 to allow for multiple codegen backends. A first attempt at this was #52987 but since @irinagpopa is no longer working on it I'm taking ownership of the PR.

State of the code before the refactoring

All the code related to the compilation of MIR into LLVM IR was contained inside the rustc_codegen_llvm crate. Here is the breakdown of the most important elements:

the back folder (7,800 LOC) implements the mechanisms for creating the different object files and archive through LLVM, but also the communication mechanisms for parallel code generation;
the debuginfo (3,200 LOC) folder contains all code that passes debug information down to LLVM;
the llvm (2,200 LOC) folder defines the FFI necessary to communicate with LLVM using the C++ API;
the mir (4,300 LOC) folder implements the actual lowering from MIR to LLVM IR;
the base.rs (1,300 LOC) file contains some helper functions but also the high-level code that launches the code generation and distributes the work.
the builder.rs (1,200 LOC) file contains all the functions generating individual LLVM IR instructions inside a basic block;
the common.rs (450 LOC) contains various helper functions and all the functions generating LLVM static values;
the type_.rs (300 LOC) defines most of the type translations to LLVM IR.

The goal of this refactoring is to separate inside this crate code that is specific to the LLVM from code that can be reused for other rustc backends. For instance, the mir folder is almost entirely backend-specific but it relies heavily on other parts of the crate. The separation of the code must not affect the logic of the code nor its performance.

For these reasons, the separation process involves two transformations that have to be done at the same time for the resulting code to compile :

replace all the LLVM-specific types by generics inside function signatures and structure definitions;
encapsulate all functions calling the LLVM FFI inside a set of traits that will define the interface between backend-agnostic code and the backend.

While the LLVM-specific code will be left in rustc_codegen_llvm, all the new interfaces and backend-agnostic code will be moved in rustc_codegen_ssa (name suggestion by @eddyb).

Generic types and structures

@irinagpopa started to parametrize the types of rustc_codegen_llvm by a generic Value type, implemented in LLVM by a reference &'ll Value. This work has been extended to all structures inside the mir folder and elsewhere, as well as for LLVM's BasicBlock and Type types.

The two most important structures for the LLVM codegen are CodegenCx and Builder. They are parametrized by multiple liftime parameters and the type for Value.

struct CodegenCx<'ll, 'tcx: 'll, V : 'll> {
  /* ... */
}

struct Builder<'a, 'll: 'a, 'tcx: 'll, V: 'll> {
  cx: &'a CodegenCx<'ll, 'tcx, V>,
  /* ... */
}

CodegenCx is used to compile one codegen-unit that can contain multiple functions, whereas Builder is created to compile one basic block.

The code in rustc_codegen_llvm has to deal with multiple explicit lifetime parameters, that correspond to the following:

'tcx is the longest lifetime, that corresponds to the original TyCtxt containing the program's information;
'a is a short-lived reference of a CodegenCx or another object inside a struct;
'll is the lifetime of references to LLVM objects such as Value or Type.

Although there are already many lifetime parameters in the code, making it generic uncovered situations where the borrow-checker was passing only due to the special nature of the LLVM objects manipulated (they are extern pointers). For instance, a additional lifetime parameter had to be added to LocalAnalyser in analyse.rs, leading to the definition:

struct LocalAnalyzer<'mir, 'a: 'mir, 'f: 'mir, 'll: 'a + 'f, 'tcx: 'll> {
  /* ... */
}

However, the two most important structures CodegenCx and Builder are not defined in the backend-agnostic code. Indeed, their content is highly specific of the backend and it makes more sense to leave their definition to the backend implementor than to allow just a narrow spot via a generic field for the backend's context.

Traits and interface

Because they have to be defined by the backend, CodegenCx and Builder will be the structures implementing all the traits defining the backend's interface. These traits are defined in the folder rustc_codegen_ssa/interfaces and all the backend-agnostic code is parametrized by them. For instance, let us explain how a function in base.rs is parametrized:

pub fn codegen_instance<'a, 'll: 'a, 'tcx: 'll, Bx: BuilderMethods<'a, 'll, 'tcx>>(
    cx: &'a Bx::CodegenCx,
    instance: Instance<'tcx>
) where &'a Bx::CodegenCx :
  LayoutOf<Ty = Ty<'tcx>, TyLayout=TyLayout<'tcx>> + HasTyCtxt<'tcx> {
    /* ... */
}

In this signature, we have the three lifetime parameters explained earlier and the master type Bx which satisfies the trait BuilderMethods corresponding to the interface satisfied by the Builder struct. The BuilderMethods defines an associated type Bx::CodegenCx that itself satisfies the CodegenMethods traits implemented by the struct CodegenCx. This prototype contains a where clause because the LayoutOf trait is satisfied by a reference (&'a Bx::CodegenCx) of the associated type and that we can't specify that in the trait definition of BuilderMethods. Finally, we have to specify that the associated types inside LayoutOf are the actual types of Rust, using the Ty = Ty<'tcx> syntax.

On the trait side, here is an example with part of the definition of BuilderMethods in interfaces/builder.rs:

pub trait BuilderMethods<'a, 'll :'a, 'tcx: 'll> : HasCodegen<'a, 'll, 'tcx> +
    DebugInfoBuilderMethods<'a, 'll, 'tcx> + ArgTypeMethods<'a, 'll, 'tcx> +
    AbiBuilderMethods<'a, 'll, 'tcx> + IntrinsicCallMethods<'a, 'll, 'tcx> +
    AsmBuilderMethods<'a, 'll, 'tcx>
    where &'a Self::CodegenCx :
        LayoutOf<Ty = Ty<'tcx>, TyLayout = TyLayout<'tcx>> + HasTyCtxt<'tcx>
{
    fn new_block<'b>(
        cx: &'a Self::CodegenCx,
        llfn: <Self::CodegenCx as Backend<'ll>>::Value,
        name: &'b str
    ) -> Self;
    /* ... */
    fn cond_br(
        &mut self,
        cond: <Self::CodegenCx as Backend<'ll>>::Value,
        then_llbb: <Self::CodegenCx as Backend<'ll>>::BasicBlock,
        else_llbb: <Self::CodegenCx as Backend<'ll>>::BasicBlock,
    );
    /* ... */
}

Finally, a master structure implementing the ExtraBackendMethods trait is used for high-level codegen-driving functions like codegen_crate in base.rs. For LLVM, it is the empty LlvmCodegenBackend. ExtraBackendMethods should be implemented by the same structure that implements the CodegenBackend defined in rustc_codegen_utils/codegen_backend.rs.

During the traitification process, certain functions have been converted from methods of a local structure to methods of CodegenCx or Builder and a corresponding self parameter has been added. Indeed, LLVM stores information internally that it can access when called through its API. This information does not show up in a Rust data structure carried around when these methods are called. However, when implementing a Rust backend for rustc, these methods will need information from CodegenCx, hence the additional parameter (unused in the LLVM implementation of the trait).

State of the code after the refactoring

The traits offer an API which is very similar to the API of LLVM. This is not the best solution since LLVM has a very special way of doing things: when addding another backend, the traits definition might be changed in order to offer more flexibility.

However, the current separation between backend-agnostic and LLVM-specific code has allows the reuse of a significant part of the old rustc_codegen_llvm. Here is the new LOC breakdown between backend-agnostic (BA) and LLVM for the most important elements:

back folder: 3,800 (BA) vs 4,100 (LLVM);
mir folder: 4,400 (BA) vs 0 (LLVM);
base.rs: 1,100 (BA) vs 250 (LLVM);
builder.rs: 1,400 (BA) vs 0 (LLVM);
common.rs: 350 (BA) vs 350 (LLVM);

The debuginfo folder has been left almost untouched by the splitting and is specific to LLVM. Only its high-level features have been traitified.

The new interfaces folder has 1500 LOC only for trait definitions. Overall, the 27,000 LOC-sized old rustc_codegen_llvm code has been split into the new 18,500 LOC-sized new rustc_codegen_llvm and the 12,000 LOC-sized rustc_codegen_ssa. We can say that this refactoring allowed the reuse of approximately 10,000 LOC that would otherwise have had to be duplicated between the multiple backends of rustc.

The refactored version of rustc's backend introduced no regression over the test suite nor in performance benchmark, which is in coherence with the nature of the refactoring that used only compile-time parametricity (no trait objects).

One test is failing after the refactoring : src/test/run-pass/thinlto/thin-lto-inlines.rs. It tests whether ThinLTO inlining is working via the indirect property that two raw function pointers are equal. This regression happens after the splitting of the back folder introduced by the commit "Separating the back folder between backend-agnostic and LLVM-specifc code". I double-checked that I did not alter the logic of the code when doing the splitting and it seems not, so maybe this is a more subtle LLVM ThinLTO bug like #53912.

rust-highfive · 2018-09-06T22:11:03Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matthewjasper (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

eddyb · 2018-09-06T22:34:28Z

r? @eddyb cc @rust-lang/compiler @sunfishcode

sunfishcode · 2018-09-06T23:16:02Z

src/librustc_codegen_llvm/interfaces/type_.rs

+    fn type_i32(&self) -> Self::Type;
+    fn type_i64(&self) -> Self::Type;
+    fn type_i128(&self) -> Self::Type;
+    fn type_ix(&self, num_bites: u64) -> Self::Type;


Typo: s/bites/bits/

Mark-Simulacrum · 2018-09-07T00:59:16Z

@bors try

I agree that this shouldn't affect performance, but let's check

bors · 2018-09-07T00:59:29Z

⌛ Trying commit 5a880b7 with merge 12c6a75...

@irinagpopa

rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods This PR is the continuation of #52461 in the grand plan of #45274 to allow for multiple codegen backends. A first attempt at this was #52987 but since @irinagpopa is no longer working on it I'm taking ownership of the PR. The changes are refactoring only and do not affect the logic of the code. Performance should not be impacted since all parametrization is done with generics (no trait objects). The `librustc_codegen_llvm` crate now contains a new folder `interfaces` that describes with traits part of how the compiler interfaces with LLVM during codegen. `CodegenCx` and `Builder` implement those traits. Many things are still missing. All the calls to LLVM are not yet under a trait, and later LLVM-agnostic code should be parametrized.

TimNN · 2018-10-09T17:16:30Z

Let's try this again:

@bors try

bors · 2018-10-09T17:17:44Z

⌛ Trying commit cf510ad919ecc89f176781932794a94e5d989ebd with merge 63cfaffef84632fc355bfdc48ffc8a3d2f3c46fe...

bors · 2018-10-09T21:17:44Z

💥 Test timed out

denismerigoux · 2018-10-10T08:07:46Z

I don't know why bors says that the tests timed out while the Travis log reports everything green.

…piles

…BaseTypeMethods

rust-highfive · 2018-10-23T14:55:51Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:17:38]    Compiling rustc_lint v0.0.0 (/checkout/src/librustc_lint)
[00:17:38]    Compiling rustc_plugin v0.0.0 (/checkout/src/librustc_plugin)
[00:17:38]    Compiling rustc_resolve v0.0.0 (/checkout/src/librustc_resolve)
[00:18:07]    Compiling rustc_save_analysis v0.0.0 (/checkout/src/librustc_save_analysis)
[00:18:07]    Compiling rustc_codegen_ssa v0.0.0 (/checkout/src/librustc_codegen_ssa)
[00:19:35]     Finished release [optimized] target(s) in 14m 35s
[00:19:35] Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
[00:19:35] travis_fold:end:stage0-rustc

---
[00:32:23]    Compiling rustc_codegen_utils v0.0.0 (/checkout/src/librustc_codegen_utils)
[00:32:35]    Compiling rustc_lint v0.0.0 (/checkout/src/librustc_lint)
[00:32:35]    Compiling rustc_passes v0.0.0 (/checkout/src/librustc_passes)
[00:33:01]    Compiling rustc_borrowck v0.0.0 (/checkout/src/librustc_borrowck)
[00:33:01]    Compiling rustc_codegen_ssa v0.0.0 (/checkout/src/librustc_codegen_ssa)
[00:34:00]    Compiling rustc-main v0.0.0 (/checkout/src/rustc)
[00:34:00]     Finished release [optimized] target(s) in 12m 07s
[00:34:00] Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
[00:34:00] travis_fold:end:stage1-rustc
---
[00:50:11] .................................................................................................... 2200/4940
[00:50:18] .................................i.................................................................. 2300/4940
[00:50:24] .................................................................................................... 2400/4940
[00:50:32] .................................................................................................... 2500/4940
[00:50:37] ................................................iiiiiiiii........................................... 2600/4940
[00:50:43] ..................................................................................................ii 2700/4940
[00:50:52] .................................................................................................... 2900/4940
[00:50:57] ........................................................................................i........... 3000/4940
[00:51:01] .................................................................................................... 3100/4940
[00:51:06] ...............................................i.i..ii.............................................. 3200/4940
---
[00:58:13] .................................................................................................... 2100/2868
[00:58:24] ..................................................................................................ii 2200/2868
[00:58:49] .....................................................................i....i......................... 2300/2868
[00:59:08] ............i....................................................................................... 2400/2868
[00:59:29] ..........................................................................................F......... 2500/2868
[01:00:09] .................................................................................................... 2700/2868
[01:00:22] .................................................................................................... 2800/2868
[01:00:35] ....................................................................
[01:00:35] failures:
---
[01:00:35] 
[01:00:35] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:503:22
[01:00:35] 
[01:00:35] 
[01:00:35] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-5.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:00:35] 
[01:00:35] 
[01:00:35] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:00:35] Build completed unsuccessfully in 0:17:25
[01:00:35] Build completed unsuccessfully in 0:17:25
[01:00:35] make: *** [check] Error 1
[01:00:35] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0579d59a
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:09cc08a4:start=1540306545989055614,finish=1540306545992791409,duration=3735795
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:03e21c07
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:21aff3c1
travis_time:start:21aff3c1
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:272c7fa8
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

… code

denismerigoux · 2018-10-23T16:00:17Z

I included in this PR the work I've done over the past month and that completes the refactoring. A new weird LLVM ThinLTO bug causes one test to fail (see description of the PR).

rust-highfive · 2018-10-23T16:15:40Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:17:58]    Compiling rustc_passes v0.0.0 (/checkout/src/librustc_passes)
[00:17:58]    Compiling rustc_lint v0.0.0 (/checkout/src/librustc_lint)
[00:17:58]    Compiling rustc_borrowck v0.0.0 (/checkout/src/librustc_borrowck)
[00:18:17]    Compiling rustc_save_analysis v0.0.0 (/checkout/src/librustc_save_analysis)
[00:18:38]    Compiling rustc_codegen_ssa v0.0.0 (/checkout/src/librustc_codegen_ssa)
[00:19:36]     Finished release [optimized] target(s) in 14m 20s
[00:19:36] Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
[00:19:36] travis_fold:end:stage0-rustc

---
[00:32:39]    Compiling rustc_codegen_utils v0.0.0 (/checkout/src/librustc_codegen_utils)
[00:32:39]    Compiling rustc_lint v0.0.0 (/checkout/src/librustc_lint)
[00:32:39]    Compiling rustc_borrowck v0.0.0 (/checkout/src/librustc_borrowck)
[00:32:41]    Compiling rustc_passes v0.0.0 (/checkout/src/librustc_passes)
[00:32:56]    Compiling rustc_codegen_ssa v0.0.0 (/checkout/src/librustc_codegen_ssa)
[00:33:51]    Compiling rustc-main v0.0.0 (/checkout/src/rustc)
[00:33:51]     Finished release [optimized] target(s) in 11m 58s
[00:33:51] Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
[00:33:51] travis_fold:end:stage1-rustc
---
[00:50:02] .................................................................................................... 2200/4940
[00:50:09] .................................i.................................................................. 2300/4940
[00:50:15] .................................................................................................... 2400/4940
[00:50:23] .................................................................................................... 2500/4940
[00:50:28] ................................................iiiiiiiii........................................... 2600/4940
[00:50:34] ..................................................................................................ii 2700/4940
[00:50:44] .................................................................................................... 2900/4940
[00:50:49] ........................................................................................i........... 3000/4940
[00:50:53] .................................................................................................... 3100/4940
[00:50:58] ...............................................i.i..ii.............................................. 3200/4940
---
[00:58:14] .................................................................................................... 2100/2868
[00:58:24] ..................................................................................................ii 2200/2868
[00:58:48] .....................................................................i....i......................... 2300/2868
[00:59:08] ............i....................................................................................... 2400/2868
[00:59:28] ..........................................................................................F......... 2500/2868
[01:00:08] .................................................................................................... 2700/2868
[01:00:21] .................................................................................................... 2800/2868
[01:00:34] ....................................................................
[01:00:34] failures:
---
[01:00:34] 
[01:00:34] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:503:22
[01:00:34] 
[01:00:34] 
[01:00:34] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-5.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:00:34] 
[01:00:34] 
[01:00:34] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:00:34] Build completed unsuccessfully in 0:17:48
[01:00:34] Build completed unsuccessfully in 0:17:48
[01:00:34] Makefile:58: recipe for target 'check' failed
[01:00:34] make: *** [check] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1f26860c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:1c8a6bfc:start=1540311333247625399,finish=1540311333253343887,duration=5718488
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1190dcc4
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:100ba89c
travis_time:start:100ba89c
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0f2afa02
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

sunfishcode · 2018-11-02T19:43:03Z

I've now fixed the thin-lto test failure here, rebased on master, and opened #55627 to carry this forward.

denismerigoux · 2018-11-04T17:36:31Z

Closing in favor of #55627.

@nikomatsakis

rustc_target: pass contexts by reference, not value. `LayoutOf` now takes `&self` instead of `self`, and so does every method generic over a context that implements `LayoutOf` and/or other traits, like `HasDataLayout`, `HasTyCtxt`, etc. Originally using by-value `Copy` types was relevant because `TyCtxt` was one of those types, but now `TyCtxt::layout_of` is separate from `LayoutOf`, and `TyCtxt` is not an often used layout context. Passing these context by reference is a lot nicer for miri, which has `self: &mut EvalContext`, and needed `f(&self)` (that is, creating `&&mut EvalContext` references) for layout purposes. Now, the `&mut EvalContext` can be passed to a function expecting `&C`, directly. This should help with #54012 / #55627 (to not need `where &'a T::Cx: LayoutOf` bounds). r? @nikomatsakis or @oli-obk or @nagisa cc @sunfishcode

rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods This PR is the continuation of #54012 and earlier PRs, in the grand plan of #45274 to allow for multiple codegen backends. High-level summary: interpose a set of traits between Rust's codegen logic and the LLVM APIs, allowing another backend to implement the traits and share most of the codegen logic. These traits are currently somewhat LLVM-specific, but once this refactoring is in place, they can evolve to be more general. See [this README](https://github.com/rust-lang/rust/blob/756f84d7cef90b7364ae88ca707e59670dde4c92/src/librustc_codegen_ssa/README.md) for a writeup on the current trait organization.

rust-highfive assigned matthewjasper Sep 6, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 6, 2018

rust-highfive assigned eddyb and unassigned matthewjasper Sep 6, 2018

sunfishcode reviewed Sep 6, 2018

View reviewed changes

sunfishcode mentioned this pull request Sep 10, 2018

Question: How close is CraneLift to being a usable rustc backend? bytecodealliance/cranelift#508

Closed