Both operands to ICmp instruction are not of the same type!

iface monad<A> {
    fn bind<B>(fn(A) -> self<B>);
}
impl monad<A> of monad<A> for [A] {
    fn bind<B>(f: fn(A) -> [B]) {
        let mut r = fail;
        for self.each {|elt| r += f(elt); }
    }
}
fn main() {
    ["hi"].bind {|x| [x] };
}

rustc fails with:

Assertion failed: (getOperand(0)->getType() == getOperand(1)->getType() && "Both operands to ICmp instruction are not of the same type!"), function ICmpInst, file /Users/jruderman/code/rust/src/llvm/include/llvm/Instructions.h, line 958.

I suspect that this, #2150, and #2151 are all a result of a (perhaps poor) decision I made to resolve unconstrained types to bottom. I think I will revert that choice. It means that some nonsensical programs (like these) will not compile but also that something like "let x = none;" where there is no further constraint on the type of x will fail, because it will not know what sort of "none" x is (e.g., option<int> etc). The latter is how things used to be and is tolerable in practice...I only put in the "unresolved types become bot" rule because some programs that used to work (which contained unconstrained types) now failed, but they were all nonsensical (generated by the fuzzer) to begin with.

Could allow let x = none; to compile as if x were option<()> while still rejecting let x = fail;?

Hmm, I could be wrong in my theory, actually. I'm not 100% sure why r += f(elt) compiles. I would expect that to error out right now, since the type of r is completely unknown at that point.

@jruderman

@jruderman well one possible fix along those lines, which I just implemented, is to refuse to consider the "bottom" type as "resolved"---this causes this test (and the others) to result in a compile error, because a resolved type is required in order to process a binary operator. (resolved types are required wherever the resulting type of an expression is overloaded based on an input type; this occurs for binary operators because of overloaded operators and because not all types are addable and so forth) I am not sure if this is the best fix---it may leave other weird paths through the compiler---but I guess I will institute it for now.

Auto merge of rust-lang#2149 - RalfJung:tests, r=RalfJung

Upgrade toolchain to `nightly-2023-01-23` (rust-lang#2149)

Update `//@ proc-macro` aux build directive docs (rust-lang#2149)

Merge pull request rust-lang#2149 from ruyrocha/hotfix/bump-rand-version

Merge rust-lang#2149

Navigation Menu

Repository navigation

Both operands to ICmp instruction are not of the same type! #2149

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Both operands to ICmp instruction are not of the same type! #2149

Description

Activity

nikomatsakis commented on Apr 7, 2012

jruderman commented on Apr 7, 2012

nikomatsakis commented on Apr 7, 2012

nikomatsakis commented on Apr 7, 2012

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions