Use ty::layout for ABI computation instead of LLVM types. #40658

eddyb · 2017-03-19T23:44:11Z

This is the first step in creating a backend-agnostic library for computing call ABI details from signatures.
I wanted to open the PR before attempting to move cabi_* from trans to avoid rebase churn in #39999.
EDIT: As I suspected, #39999 needs this PR to fully work (see #39999 (comment)).

The first 3 commits add more APIs to ty::layout and replace non-ABI uses of sizing_type_of.
These APIs are probably usable by other backends, and miri too (cc @stoklund @solson).

The last commit rewrites rustc_trans::cabi_* to use ty::layout and new rustc_trans::abi APIs.
Also, during the process, a couple trivial bugs were identified and fixed:

msp430, nvptx, nvptx64: type sizes in bytes were compared with 32 and 64
x86 (fastcall): f64 was incorrectly not treated the same way as f32

Although not urgent, this PR also uses the more general "homogenous aggregate" logic to fix #32045.

rust-highfive · 2017-03-19T23:44:23Z

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

eddyb · 2017-03-19T23:44:32Z

cc @rust-lang/compiler

nagisa

Some nits gathered over the day.

nagisa · 2017-03-20T07:16:05Z

src/librustc/ty/layout.rs

@@ -1087,25 +1089,33 @@ impl<'a, 'gcx, 'tcx> Layout {
            // Arrays and slices.
            ty::TyArray(element, count) => {
                let element = element.layout(infcx)?;
+                let element_size = element.size(dl);
+                let count = count as u64;


The cast is not necessary and is possibly dangerous (e.g. after a type in the declaration changes)

It's currently usize (even if it shouldn't be).

if we care, maybe make fn usize_to_u64(x: usize) and then do usize_to_u64(count)?

or (count: usize) as u64.

LOL. I'll add a whole variable dealing with this fact and a comment on it.

nagisa · 2017-03-20T07:18:34Z

src/librustc/ty/layout.rs

+                        i: usize,
+                        variant_index: Option<usize>)
+                        -> Size {
+        match *self {


debug_assert i==0, perhaps?

nagisa · 2017-03-20T07:26:17Z

src/librustc/ty/layout.rs

+
+            ty::TyTuple(tys, _) => tys[i],
+
+            // SIMD vector types.


Assumes that all fields of a some vector must be the same (true for LLVM but not true for some architectures/proposals such as for RISC-V)

Not a big issue (also we discussed this on IRC already)

Oh, just to be super clear: ty::layout already assumes uniform vectors.
We'd have to overhaul it a bit when that assumption breaks down anyway.

nagisa · 2017-03-20T08:04:48Z

src/librustc_trans/cabi_x86_64.rs

-    }
-}
+// Currently supported vector size (AVX).
+const LARGEST_VECTOR_SIZE: usize = 256;


AVX-512 has 512 bits. (Also discussed on IRC)

Right, I meant AVX. AVX512 is different from AVX like SSE3 is different from SSE.

Also cc @BurntSushi on what stance we should have in terms of ABI compat.

eddyb · 2017-03-20T15:57:30Z

src/librustc/ty/layout.rs

+            Scalar { .. } |
+            CEnum { .. } |
+            UntaggedUnion { .. } |
+            RawNullablePointer { .. } => {


debug_assert i==0, perhaps?

You mean here? I might just take this out, except for UntaggedUnion. It was meant for something I abandoned.

bors · 2017-03-20T21:03:56Z

☔ The latest upstream changes (presumably #39628) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · 2017-03-23T19:46:21Z

r? @nikomatsakis

arielb1 · 2017-03-24T12:25:54Z

src/librustc/ty/layout.rs

@@ -1087,25 +1089,33 @@ impl<'a, 'gcx, 'tcx> Layout {
            // Arrays and slices.
            ty::TyArray(element, count) => {
                let element = element.layout(infcx)?;
+                let element_size = element.size(dl);
+                let count = count as u64;


or (count: usize) as u64.

arielb1 · 2017-03-24T12:31:44Z

src/librustc_trans/type_of.rs

+    pub fn size_of(&self, ty: Ty<'tcx>) -> machine::llsize {
+        let layout = self.layout_of(ty);
+        layout.size(&self.tcx().data_layout).bytes() as machine::llsize
+    }
 }

 fn llvm_type_name<'a, 'tcx>(cx: &CrateContext<'a, 'tcx>, ty: Ty<'tcx>) -> String {


Nice catch!

arielb1 · 2017-03-24T12:33:54Z

src/librustc/ty/layout.rs

@@ -202,6 +202,16 @@ impl TargetDataLayout {
    }
 }

+pub trait HasDataLayout: Copy {


Generic bloat? Not sure this is worth worrying about.

arielb1 · 2017-03-24T12:43:02Z

src/librustc/ty/layout.rs

+    }
+}
+
+pub trait LayoutTyper<'tcx>: HasTyCtxt<'tcx> {


This looks like a rather heavy abstraction - it is only used for .field, which is only called from trans::abi, which already defines LayoutExt. I'll move Layout::field to LayoutExt and remove this trait.

The abstraction exists so we can pull out the ABI computation into a separate crate, so the heaviness is intentional.

I'm fine with this if this is temporary code.

arielb1 · 2017-03-24T12:46:20Z

src/librustc/ty/layout.rs

-    pub fn of(infcx: &InferCtxt<'a, 'gcx, 'tcx>, ty: Ty<'gcx>)
-              -> Result<Self, LayoutError<'gcx>> {
-        let ty = normalize_associated_type(infcx, ty);
+pub trait HasTyCtxt<'tcx>: HasDataLayout {


If you are defining this trait, maybe move it to ty::fold and make TypeFolder a subtrait? Can you add a blanket impl<T: HasTyCtxt> HasDataLayout for T? Is there any place that needs data layout but does not have a tcx (aka do we need HasDataLayout)?

I tried that and it required weird inexpressible region bounds to work, sadly.

arielb1 · 2017-03-24T12:51:09Z

src/librustc_trans/abi.rs

@@ -133,32 +134,279 @@ impl ArgAttributes {
    }
 }

+pub trait CastTarget {


Any reason this is a trait rather than an enum (Reg | RegPair | Uniform)? That would make moving away from LLVM easier.

I wanted to make sure it works first, and the trait allows replacing with an enum later, but maybe I should do it now.

arielb1

Looks excellent. I should look at this last commit more but I have to go.

arielb1 · 2017-03-24T12:56:16Z

src/librustc/ty/layout.rs

+
+            // ADTs.
+            ty::TyAdt(def, _) => {
+                let v = if def.is_enum() {


I'll say "what about univariant enums" but you appear to have fixed this in the next commit.

I'll move it back (rebasing was painful when fixing that but now it should be fine.

arielb1 · 2017-03-24T12:56:52Z

src/librustc/ty/layout.rs

-            ty::TyNever |
-            ty::TyFnDef(..) |
-            ty::TyDynamic(..) => {
+            ty::TyFnPtr(_) => {
                bug!("TyLayout::field_type({:?}): not applicable", self)


bug and comment are wrong - function is called field_count, and TyDynamic is not a ZST. OTOH, non-ADT/arrays have 0 fields, so presumably you should always return 0 for them (+TyStr).

It mostly has to match the Layout variant (maybe I should match on that instead).

arielb1 · 2017-03-24T13:12:48Z

src/librustc_trans/abi.rs

+                }
+            }
+            RegKind::Vector => {
+                // Try to pick an integer at least twice as small.


What's the motivation for this? AFAICT this seems to be used only for SSE/AVX on amd64 SysV, so the if statement can never be hit. If LLVM really does not care about the type of the vector elements as long as it has the right length, why not use [u8; N] everywhere? Or [u64; N] because all SIMD is a multiple of 64 bits.

I'll switch to <n x i8>, it's the cleanest simple solution.

arielb1 · 2017-03-24T13:32:05Z

src/librustc_trans/cabi_x86_64.rs

+use rustc::ty::layout::{self, Layout, TyLayout, Size};
+
+#[derive(Clone, Copy, PartialEq, Debug)]
+enum Class {


Nice to see we can reduce this.

arielb1 · 2017-03-24T13:32:22Z

src/librustc_trans/cabi_x86_64.rs

-    SSEDv,
-    SSEInt(/* bitwidth */ u64),
+    LoneF32,
+    Sse,


Might be worth commenting that this also includes AVX (yes I know the spec calls this Sse).

Also, LoneF32 is also an Sse in the spec - the only difference is that we want to tell LLVM that only the lowest 32 bits matter. I'll make it a field of the enum.

There's a more elegant way to handle this (last Sse with only 4 bytes of data left, only way to get LoneF32 anyway, unless you have weird padding). I'll try to implement it.
Also, clang does somewhat complex type recovery - I don't think we care, as this is for FFI.

nikomatsakis · 2017-03-24T15:01:16Z

src/librustc/ty/layout.rs

@@ -1513,6 +1531,59 @@ impl<'a, 'gcx, 'tcx> Layout {
            }
        }
    }
+
+    pub fn field_offset(&self,


Seems like some comments, or better choice of names, would be good here. e.g. what is i -- the index of the field, I guess? variant_index is for structs/enums? (I'd also find the opposite order of those parameters more intuitive, but I can't say why -- I guess because the i is defined relative to variant_index)

We'll hopefully eventually remove variant_index by adding variant types, so I'm not sure how much I care about it.

nikomatsakis · 2017-03-24T15:09:15Z

OK, since @arielb1 and @nagisa are already giving this a detailed look, I gave it more of a cursory overview. Seems quite nice to me, but I didn't dig into the last commit, which is obviously where most of the subtle logic resides.

arielb1

Most changes should be fixed in a separate PR, but I don't like the "pirate" pair of floats feature in this PR.

arielb1 · 2017-03-24T19:40:52Z

src/librustc/ty/layout.rs

+    }
+}
+
+pub trait LayoutTyper<'tcx>: HasTyCtxt<'tcx> {


I'm fine with this if this is temporary code.

arielb1 · 2017-03-24T19:42:20Z

src/librustc/ty/layout.rs

+        self.layout.field_offset(cx, i, self.variant_index)
+    }
+
+    pub fn field_count<C: HasTyCtxt<'tcx>>(&self, cx: C) -> usize {


Can you match on the layout instead?

arielb1 · 2017-03-24T19:48:43Z

src/librustc_trans/abi.rs

@@ -133,32 +134,279 @@ impl ArgAttributes {
    }
 }

+pub trait CastTarget {


arielb1 · 2017-03-24T20:14:58Z

src/librustc_trans/abi.rs

+                        return;
+                    }
+
+                    // Pairs of floats.


This is not present in the original code. Random micro-optimization?

Oh I meant to find that issue and mention it in the description. This is a long-wanted feature and now it's easy to implement so I just did it when I rewrote that code.

arielb1 · 2017-03-24T20:20:22Z

src/librustc_trans/adt.rs

    let fields = variant.field_index_by_increasing_offset().map(|i| fields[i as usize]);
    if sizing {
-        fields.filter(|ty| !dst || cx.shared().type_is_sized(*ty))
-            .map(|ty| type_of::sizing_type_of(cx, ty)).collect()
+        bug!()


nit: remove the sizing and dst parameters? They don't seem to be used anywhere.

Have to keep to allow #39999 to rebase.

arielb1 · 2017-03-24T20:36:57Z

src/librustc_trans/cabi_aarch64.rs

+    let size = ret.layout.size(ccx);
+    let bits = size.bits();
+    if bits <= 128 {
+        let unit = if bits <= 8 {


can't this logic be lifted to abi? It appears to be used in several places, including the Rust ABI.

arielb1 · 2017-03-24T21:27:38Z

src/librustc_trans/cabi_x86_64.rs

-    SSEDv,
-    SSEInt(/* bitwidth */ u64),
+    LoneF32,
+    Sse,


Also, LoneF32 is also an Sse in the spec - the only difference is that we want to tell LLVM that only the lowest 32 bits matter. I'll make it a field of the enum.

arielb1 · 2017-03-24T21:28:38Z

src/librustc_trans/cabi_x86_64.rs

+
+#[derive(Clone, Copy, PartialEq, Debug)]
+enum Class {
+    None,


This is called NoClass in the spec. Why not stick to it?

Because Class::NoClass is unidiomatic.

arielb1 · 2017-03-24T21:42:56Z

src/test/codegen/function-arguments.rs

@@ -121,13 +121,13 @@ pub fn unsafe_slice(_: &[UnsafeInner]) {
 fn str(_: &[u8]) {
 }

-// CHECK: @trait_borrow(i8* nonnull, void (i8*)** noalias nonnull readonly)
+// CHECK: @trait_borrow({}* nonnull, {}* noalias nonnull readonly)


Are LLVM's problems with unit pointers gone?

Those problems were only around C FFI were LLVM was looking for a specific signature, IIRC.
i.e. Not unit pointers were the problem but any pointer thst wasn't i8*.

arielb1 · 2017-03-25T11:01:42Z

@bors r+

bors · 2017-03-25T11:01:43Z

📌 Commit 6ac00de has been approved by arielb1

bors · 2017-03-25T11:54:15Z

⌛ Testing commit 6ac00de with merge 0b20dbd...

bors · 2017-03-25T12:00:09Z

💔 Test failed - status-travis

arielb1 · 2017-03-25T12:30:15Z

try to fix the build on emscripten #40821
@bors retry

bors · 2017-03-25T14:00:17Z

⌛ Testing commit 6ac00de with merge 5f08d8d...

bors · 2017-03-25T14:04:07Z

💔 Test failed - status-travis

eddyb · 2017-04-08T20:55:28Z

@bors r=arielb1

bors · 2017-04-08T20:55:28Z

📌 Commit 1759358 has been approved by arielb1

bors · 2017-04-08T22:34:33Z

⌛ Testing commit 1759358 with merge fbe44d3...

eddyb · 2017-04-08T22:37:31Z

@bors r- retry

eddyb · 2017-04-08T22:44:33Z

@bors r=arielb1

bors · 2017-04-08T22:44:34Z

📌 Commit a8dd65a has been approved by arielb1

bors · 2017-04-09T01:02:49Z

⌛ Testing commit a8dd65a with merge c5404c5...

bors · 2017-04-09T02:08:08Z

💔 Test failed - status-travis

eddyb · 2017-04-09T06:11:16Z

@bors retry

unrelated (AFAICT) emscripten failure ("The end of the file was unexpectedly encountered")

nagisa · 2017-04-09T06:58:48Z

This is the log of the error (there are multiple like these:

[00:52:59] error: linking with `emcc` failed: exit code: 1
[00:52:59]   |
[00:52:59]   = note: "emcc" "-s" "DISABLE_EXCEPTION_CATCHING=0" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-fail/test-should-panic-no-message.0.o" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-fail/test-should-panic-no-message.stage2-asmjs-unknown-emscripten.js" "-s" "EXPORTED_FUNCTIONS=[\"_main\",\"_rust_eh_personality\"]" "-O2" "--memory-init-file" "0" "-g0" "-s" "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-fail" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-fail/test-should-panic-no-message.stage2-asmjs-unknown-emscripten.run-fail.libaux" "-L" "/checkout/obj/build/asmjs-unknown-emscripten/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libtest-6c35a477e7bec8d3.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libterm-fa872424129019f5.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libgetopts-a80f7c589731de53.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libstd-f4594d3e53dcb114.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libpanic_unwind-a0157c0ca919c364.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libunwind-488b4ab4bd53a138.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/librand-1efbcfd8938372b6.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libcollections-532a3dbf317eff86.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc-ca07b617414dd0fa.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libstd_unicode-cfbd6648f7db2ee5.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc_system-68e33a366943aef4.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/liblibc-88c194c15fdb6521.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libcore-687e6a964d22cbb4.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libcompiler_builtins-987729be881d4d32.rlib" "-l" "c" "-s" "ERROR_ON_UNDEFINED_SYMBOLS=1"
[00:52:59]   = note: /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libtest-6c35a477e7bec8d3.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libterm-fa872424129019f5.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libgetopts-a80f7c589731de53.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libstd-f4594d3e53dcb114.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libpanic_unwind-a0157c0ca919c364.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libunwind-488b4ab4bd53a138.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/librand-1efbcfd8938372b6.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libcollections-532a3dbf317eff86.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc-ca07b617414dd0fa.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libstd_unicode-cfbd6648f7db2ee5.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc_system-68e33a366943aef4.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/liblibc-88c194c15fdb6521.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libcore-687e6a964d22cbb4.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           /tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin/llvm-nm: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/asmjs-unknown-emscripten/lib/libcompiler_builtins-987729be881d4d32.rlib(rust.metadata.bin) The end of the file was unexpectedly encountered
[00:52:59]           
[00:52:59]           Value:   %.fca.1.insert109.i361.i = phi [2 x double] [ %.fca.1.insert109.i.i, %bb21.i.thread.i ], [ %.fca.1.insert109.i353.i, %bb3.i33.i.preheader.i ]
[00:52:59]           LLVM ERROR: Unrecognized struct value
[00:52:59]           Traceback (most recent call last):
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/emcc", line 13, in <module>
[00:52:59]               emcc.run()
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/emcc.py", line 1635, in run
[00:52:59]               final = shared.Building.emscripten(final, append_ext=False, extra_args=extra_args)
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/tools/shared.py", line 1745, in emscripten
[00:52:59]               call_emscripten(cmdline)
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/emscripten.py", line 1783, in _main
[00:52:59]               temp_files.run_and_clean(lambda: main(
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/tools/tempfiles.py", line 78, in run_and_clean
[00:52:59]               return func()
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/emscripten.py", line 1788, in <lambda>
[00:52:59]               DEBUG=DEBUG,
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/emscripten.py", line 1689, in main
[00:52:59]               temp_files=temp_files, DEBUG=DEBUG)
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/emscripten.py", line 91, in emscript
[00:52:59]               funcs, metadata, mem_init = get_and_parse_backend(infile, settings, temp_files, DEBUG)
[00:52:59]             File "/tmp/emsdk_portable/emscripten/tag-1.37.1/emscripten.py", line 157, in get_and_parse_backend
[00:52:59]               backend_output = open(temp_js).read()
[00:52:59]           IOError: [Errno 2] No such file or directory: '/tmp/tmpswNHZh.4.js'
[00:52:59]           
[00:52:59] 
[00:52:59] error: aborting due to previous error
[00:52:59] 
[00:52:59] 
[00:52:59] ------------------------------------------
[00:52:59] 
[00:52:59] thread '[run-fail] run-fail/test-should-panic-no-message.rs' panicked at 'explicit panic', /checkout/src/tools/compiletest/src/runtest.rs:2621

This is not related to the out-of-disk-space errors. There’s still plenty left.

cc @alexcrichton this one is new.

eddyb · 2017-04-09T07:37:38Z

@bors r- Aaaaah there's an LLVM error in there, thanks!

eddyb · 2017-04-09T13:03:42Z

This appears to be an emscripten bug, which I've filed as emscripten-core/emscripten-fastcomp#178.
I'll try to work around it by not using Uniform in the Rust ABI and I'll leave a FIXME in.

eddyb · 2017-04-09T13:08:07Z

@bors r=arielb1

bors · 2017-04-09T13:08:07Z

📌 Commit f0636b6 has been approved by arielb1

bors · 2017-04-09T13:08:16Z

⌛ Testing commit f0636b6 with merge 2c48ae6...

@stoklund

Use ty::layout for ABI computation instead of LLVM types. This is the first step in creating a backend-agnostic library for computing call ABI details from signatures. I wanted to open the PR *before* attempting to move `cabi_*` from trans to avoid rebase churn in #39999. **EDIT**: As I suspected, #39999 needs this PR to fully work (see #39999 (comment)). The first 3 commits add more APIs to `ty::layout` and replace non-ABI uses of `sizing_type_of`. These APIs are probably usable by other backends, and miri too (cc @stoklund @solson). The last commit rewrites `rustc_trans::cabi_*` to use `ty::layout` and new `rustc_trans::abi` APIs. Also, during the process, a couple trivial bugs were identified and fixed: * `msp430`, `nvptx`, `nvptx64`: type sizes *in bytes* were compared with `32` and `64` * `x86` (`fastcall`): `f64` was incorrectly not treated the same way as `f32` Although not urgent, this PR also uses the more general "homogenous aggregate" logic to fix #32045.

bors · 2017-04-09T15:30:11Z

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 2c48ae6 to master...

Fix pairs of doubles using an illegal <8 x i8> vector. Accidentally introduced in rust-lang#40658 and discovered in some Objective-C bindings (returning `NSPoint`). Turns out LLVM will widen element types of illegal vectors instead of increasing element count, i.e. it will zero-extend `<8 x i8>` to `<8 x i16>`, interleaving the bytes, instead of using the first 8 of `<16 x i8>`.

rust-highfive assigned pnkfelix Mar 19, 2017

eddyb mentioned this pull request Mar 19, 2017

Implementation of repr struct alignment RFC 1358. #39999

Merged

eddyb force-pushed the lay-more-out branch 2 times, most recently from f55fb66 to c91c10a Compare March 20, 2017 11:01

nagisa reviewed Mar 20, 2017

View reviewed changes

eddyb commented Mar 20, 2017

View reviewed changes

eddyb force-pushed the lay-more-out branch 2 times, most recently from b3001b2 to 6ac00de Compare March 21, 2017 20:25

This was referenced Mar 21, 2017

implement #[repr(align)] (tracking issue for RFC 1358) #33626

Closed

Refactor rustc_trans::abi not to use LLVM #39617

Closed

rust-highfive assigned nikomatsakis and unassigned pnkfelix Mar 23, 2017

arielb1 reviewed Mar 24, 2017

View reviewed changes

arielb1 suggested changes Mar 24, 2017

View reviewed changes

nikomatsakis reviewed Mar 24, 2017

View reviewed changes

arielb1 suggested changes Mar 24, 2017

View reviewed changes

eddyb force-pushed the lay-more-out branch from 1759358 to a8dd65a Compare April 8, 2017 22:44

eddyb mentioned this pull request Apr 9, 2017

Support splitting Phi and Select over arrays. emscripten-core/emscripten-fastcomp#178

Closed

rustc_trans: use ty::layout for ABI computation instead of LLVM types.

f0636b6

eddyb force-pushed the lay-more-out branch from a8dd65a to f0636b6 Compare April 9, 2017 13:07

bors merged commit f0636b6 into rust-lang:master Apr 9, 2017

eddyb deleted the lay-more-out branch April 9, 2017 15:31

eddyb mentioned this pull request Apr 10, 2017

Fix pairs of doubles using an illegal <8 x i8> vector. #41206

Merged

cuviper mentioned this pull request Jul 21, 2017

1.18.0 armv7 regression: extern-fn-struct-passing-abi assertion failed, passed in 1.17.0 #43329

Closed

Use ty::layout for ABI computation instead of LLVM types. #40658

Use ty::layout for ABI computation instead of LLVM types. #40658

Conversation

eddyb commented Mar 19, 2017 • edited Loading

rust-highfive commented Mar 19, 2017

eddyb commented Mar 19, 2017

nagisa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Mar 20, 2017

nikomatsakis commented Mar 23, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielb1 Mar 24, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielb1 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielb1 Mar 24, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Mar 24, 2017

arielb1 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eddyb Mar 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielb1 commented Mar 25, 2017

bors commented Mar 25, 2017

bors commented Mar 25, 2017

bors commented Mar 25, 2017

arielb1 commented Mar 25, 2017

bors commented Mar 25, 2017

bors commented Mar 25, 2017

eddyb commented Apr 8, 2017

bors commented Apr 8, 2017

bors commented Apr 8, 2017

eddyb commented Apr 8, 2017

eddyb commented Apr 8, 2017

bors commented Apr 8, 2017

bors commented Apr 9, 2017

eddyb commented Mar 19, 2017 •

edited

Loading

arielb1 Mar 24, 2017 •

edited

Loading

arielb1 Mar 24, 2017 •

edited

Loading

eddyb Mar 25, 2017 •

edited

Loading

nagisa commented Apr 9, 2017 •

edited

Loading