Adding invalid implementation for a function creates error messages in other parts of the code about roc

[jwoudenberg]

If I try with this simple code sample:

interface Foo
    exposes [foo]
    imports []

foo : U8 -> U8
foo = \_ -> {}

bar : U8
bar = foo 4

Then I just get a compile error for foo. The compiler doesn't give an additional compiler error in bar, which uses foo correctly according to its type signature, but not according to its implementation.

This behavior is matches my expectations too. I often add type signatures to contain type errors in a bit of code, making sure that if I make an error in one place it doesn't result in a type error in a completely different bit of code. That does appear to be happening here.

Going to reopen in that light, but please let me know if you disagree!

[Anton-4]

Thanks for this minimal reproduction @jwoudenberg! This is an interesting one :)

The error message is saying Roc is expecting an a and getting an a, so what's the problem?

The a is scoped to one definition, not to the entire function or file, so those are not inherently the same a. That being said, I don't know why that mismatch occurs 😄 I'll open a new issue for that.

It's weird that adding an implementation for one function creates a compiler error in an entirely different function.

Note that you did not just add an implementation here. The type does not match the implementation, so I can see how this changes things when the compiler tries to make the implementation work.

In my original case I got 34 extra errors in various seemingly unrelated parts of the code instead of just the one here, and those 34 burried the useful error

I also think these were caused by the compiler trying to make the implementation work with a different type then before.

[Anton-4]

Can we close this in favor of #6595 @jwoudenberg?

[jwoudenberg]

Sure, thank you!

[jwoudenberg]

Hey @Anton-4 , quick follow up question to your comments:

Note that you did not just add an implementation here. The type does not match the implementation, so I can see how this changes things when the compiler tries to make the implementation work.

I also think these were caused by the compiler trying to make the implementation work with a different type then before.

Do you mean to say that the compiler will infer the correct type for invalidFn which is different from the one I specified, and that inferred type then causes a type-error in validFn?

[Anton-4]

Do you mean to say that the compiler will infer the correct type for invalidFn which is different from the one I specified, and that inferred type then causes a type-error in validFn?

I believe that is the case, I'd have to do some investigating to confirm that.

[Anton-4]

Interesting! Yeah, this warrants further investigation.