Compiler panic while compiling

Compiler paniced when "cargo test" was executed

git snap shot of file https://github.com/valarauca/Fact/tree/1cfcdbb41e2099abefcea7994bd03b48aa2be882

[steveklabnik]

Can you give some more information please? This builds and runs just fine for me. I'm on Linux, using both 1.3 stable and the nightly from 9-17.

I just filed a bug because the compiler told me too.

If you can't re-produce then I really have no clue. I wasn't driving deep into debugging it.

[steveklabnik]

I just mean like, platform and compiler version? Maybe it only happens in OSX and not Linux, or in a different version than I tried.

Sorry shouldn't post online before morning coffee

I used the default x64 binaries v1.3 for Linux

My kernel is v3.9.3

Laptop is at home, so I can answer additional questions in ~8-9 hours

On 9/21/15, Steve Klabnik notifications@github.com wrote:

I just mean like, platform and compiler version? Maybe it only happens in
OSX and not Linux, or in a different version than I tried.

---

Reply to this email directly or view it on GitHub:
#28540 (comment)

[steveklabnik]

Ah ha! I also noticed just now that you linked to a specific commit, which wasn't HEAD, so I bet that was why I missed it before :( using that commit, both 1.3 and 1.5-nightly case an ICE.

It's likely worth filing as a separate bug (I'm honestly not sure). But if you get brave enough to read that 100LOC match statement that's returning a Boxed lambda. There is a statement like

        SearchOp::RsQiFn( r, q, f )
            => Box::new( move | var :&LLFact | -> bool
            {
                true
                &&
                match var.forward
                {
                    DataPoint::None => true,
                    _ => false
                }
                &&
                match var.reverse
                {
                    DataPoint::Key( k ) => k == r,
                    _ => false
                }
            }),

Where part of the evaluation is

       true && match stuff /* yadayada*/

This is because simply preforming this operation:

  match item0 { something => true, _ => false } && match item1{ something => true, _ => false }

Won't preform the proper type inference within the lambda. Instead it'll throw an error concerning my attempting to passing a &&match to a bool result.

[arielb1]

@valarauca

The second problem is that your code is parsed as a match statement followed by twice taking the address of a match expression - as if a semicolon was inserted between them:

        SearchOp::RsQiFn( r, q, f )
            => Box::new( move | var :&LLFact | -> bool
            {
                match var.forward
                {
                    DataPoint::None => true,
                    _ => false
                }; // <- note implicit semicolon
                & & match var.reverse
                {
                    DataPoint::Key( k ) => k == r,
                    _ => false
                }
            }),

You can put both expressions within parentheses to prevent this. Not a bug, anyway.

Could you post the ICE backtrace?

[steveklabnik]

Giving this a close, as the author has gone, and we don't have enough info.