Abstract with haxe.ds.Either breaks the compiler

[filt3rek]

Hej,

Sorry again, I know you're tired of me 🙃, and here, I even don't really know how to title that issue ...
A lot of time spent to isolate this issue : https://try.haxe.org/#f581b82f

abstract Outcome(Int) from Int to Int{		// Just comment this abstract and compiler "wake-up" lol
	@:from static inline function fromEither(ei:haxe.ds.Either<String, Err>): Outcome
		return switch ei {
			case Right(e): 1;
                        case _ : 2;
		}
}

abstract Err(Bool) from Bool to Bool {
	//inline function new() return true; // You can also omit the constructor...

	@:from inline static function fromInt(n:Int) {
		return new Err(here, you, can, write, what, you, want, lol);
	}
}

class Test {
	static function main() {
            var err : Err = 5;
            trace( err );
	}
}

It fails on all targets on try.haxe.
Just remove or comment the Outcome abstract and all works fine (I mean compiler throws the right errors and so on...)
The JS output is also "funny"...

Thanks for your help

[Simn]

This looks pretty wtf... Reduced a bit:

class Outcome {
	static function fromEither(ei:haxe.ds.Option<Err>) {
		switch ei {
			case Some(o):
			case _:
		}
	}
}

abstract Err(Bool) {
	@:from static public function fromInt(n:Int) {
		return new Err(here);
	}
}

class Main {
	static function main() {
		var err:Err = 5;
		trace(err);
	}
}

No idea yet what's happening here.

[Apprentice-Alchemist]

Bisected to 5f8cc79 ([typer] make display_error typer-independent)

[Simn]

Explanation: the pattern matcher mutates com.error_ext in order to ignore errors when attempting to type a pattern. This was already not reliable before 5f8cc79 because depending on how exactly a typer context is created, its on_error may or may not point to the right function. My original change made this worse in the sense that now all contexts definitely had the new (ignoring) error function.

I've applied the same position check that we have in callUnification.ml. I don't love this kind of handling and would prefer if error_ext wasn't mutable at all, but this should be good enough at least.

[filt3rek]

Thanks @Simn for explanation and your work.
Have a nice day.