Remove unwrap() from cabi_x86_64.rs

[topecongiro]

This PR is a follow-up of #47014. I am not certain whether simply removing unwrap() suffices, but at least no test failed.

Closes#38763. Closes#45662.

[rust-highfive]

r? @estebank

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

[topecongiro]

Added a test for #38763.

[estebank]

Are the tests now passing because of the if let Ok(cls) or the if let Some(target)? I feel like instead of silently passing this should fail with a diagnostic error, but I'm not knowledgeable enough about this part fo the language. Otherwise the code seems ready to merge.

@eddyb could you take a look?

[eddyb]

See #38763 (comment) - I think this needs further investigation.

[eddyb]

These don't seem right - if the unwrap can fail that means there's a logic error somewhere within this file, which this seems to hide.

[topecongiro]

Updated to call bug!() when this failed.

[topecongiro]

@eddyb@estebank Thank you for your reviews!

I updated this PR so that registers are 'allocated' to paddings or i128 args. Do you think this is a better approach?

[eddyb]

@topecongiro I'm still not happy - I haven't seen any explanation for what's happening.
I really don't want to paper over whatever bug this may be, which is what using Result does.

[topecongiro]

I am sorry for being lazy about explaining what I was working on. Let me clarify a bit.

I first tried to compile the following file using 83ba46f:

// test.rs#![feature(repr_align)]#![feature(attr_literals)]#[repr(align(16))]pubstructFoo(i32);#[no_mangle]pubextern"C"fnfoo(x:Foo){}fnmain(){}

and got the following error (an irrelevant part is omitted):

error: internal compiler error: librustc_trans/cabi_x86_64.rs:236: cast_target() failed: cls [Int, None, None, None, None, None, None, None] size Size { raw: 16 }

Here, the content of cls should be [Int, Int, None, None, None, None, None, None], but it is [Int, None, None, None, None, None, None, None]. c1a08a5 fixes this. e48d452 fixes the similar error when using i128.

I really don't want to paper over whatever bug this may be, which is what using Result does.

The new commits do not paper over errors, they will call bug!() when there is an error. Or do you mean using Result inside classify_arg() is a bad idea?

[eddyb]

Or do you mean using Result inside classify_arg() is a bad idea?

Yes, because it should never fail. I think I see what's wrong here, we assumed primitives would fit into u64s - let me try to come up with a very targetted fix for that.

EDIIT: I mean, specifically when u128 is involved. Increased alignment should be ignored.

[eddyb]

I've opened #47437 and #47439 which solve the two issues separately.

[topecongiro]

Cool, I will close this PR in favor of those two.

@eddyb Thank you very much for your help!

[estebank]

@topecongiro thank you for taking the time to dig into this in the first place!