Functions with an immediate return value shouldn't have an extra argument

[catamorphism]

as per comment in trans::type_of::type_of_fn

[thomaslee]

@catamorphism I'm going to try to figure this one out. Any advice on where I should be looking outside of type_of::type_of_fn? I'm guessing I need to update call sites (so maybe middle::trans::callee.rs?), & I'm guessing there may be some sort of issue wrt argument indices being shifted around or something like that -- beyond that I think I'm flying blind :)

[catamorphism]

Yup, you'll need to update Various Code In Trans (tm). If I were going to do this, I would just change it in one place and see what breaks -- lots of tests should fail catastrophically in that case :-) But that may not be the best way. I suspect one thing that would be just as helpful as fixing the bug is adding documentation as you go along to the code that deals with args.

[thomaslee]

If I were going to do this, I would just change it in one place and see what breaks -- lots of tests should fail catastrophically in that case

I totally would if I could get the build to do anything but segfault with this change :) All good, I think I'm just going to have to do a bit of whack-a-mole.

[catamorphism]

Yes, unfortunately the way the build works is not the best thing for testing -- there are easier test cases you could be running than the entire compiler itself, but make check will build the stage2 compiler before any test cases! :-) What I like to do instead is just try compiling run-pass test cases individually, by hand, with the stage1 compiler, until I find one that's simple enough and that exhibits the crash. Let me know if you'd like me to expand on that or if it's clear...

[thomaslee]

Not sure I follow -- doesn't that leave me in the position of needing to build the stage1 compiler? This seems to be falling over in stage0: https://gist.github.com/thomaslee/5617386

(Must say I've not spent a whole lot of time trying to understand the bootstrapping thing -- my laziness may be my undoing here :P)

That said, I think I'm making a little progress -- just stumbled across rustc::middle::trans::common::first_real_arg, which I believe is going to be at the root of a lot of the hurtiness associated with this issue. That aside, would love clarification wrt using the stage1 compiler to test this if you still think it's relevant!

[catamorphism]

Ah, I see what's confusing. If you build rustc-stage1, that will build the stage1 compiler and also build libcore and libstd with the stage1 compiler. But libcore is, like the compiler itself, a pretty challenging test case! So for a "break the whole compiler and put it together again" (I'm exaggerating somewhat) change like this, you want to find test cases that don't depend on any libraries, not even core -- or just write one, all you need is a function that returns an immediate value like an int -- and compile them with the stage1 compiler (which exists, even though the step after it, building libcore with the stage1 compiler, failed) and see what happens.

Hopefully that's a little clearer...

[thomaslee]

Awesome, that helps a whole lot. Thanks very much!

[thomaslee]

I've managed to get the whole toolchain through stage 1 with a few hacks with this WIP:

thomaslee@7c27273

Still seems to need some work: it's crashing hard building libcore at stage 2 & there's some nasty hacks in there to work around the fact dtors somehow get either one or both of the implicit parameters.

stage 2 borkage looks like this:

https://gist.github.com/thomaslee/5625937

Slow going, but there's some definite progress here.

[pnkfelix]

Fixed by commit e3d0c1e