Compilation errors report do not point to the location

[abailly-iohk]

Summary

When one gets a PlutusTx compilation error like

 GHC Core to PLC plugin: Error: Reference to a name which is not a local, a builtin, or an external INLINABLE function: Variable GHC.Num.Integer.integerGt#

there is no indication of the origin of the error in the original source code, and one gets a 3000+ lines long error report which is pretty much useless.

Steps to reproduce the behavior

An example contract that's failing to build can be found here but it's easy to reproduce with simpler code.

Actual Result

An example output from Plutus compilation.

out.md

Expected Result

As a PlutusTx developer, I would like the compiler to tell me where the problem is in my source code. In this particular case, I expect something like:

Plutus compiler error in line 167, column 22:  GHC.Num.Integer.integerGt# is not a local, a builtin, or an external INLINABLE function
Possible fix: You are trying to use a literal number inside a multiway-if expression which is not supported by the Plutus compiler, please check https://plutus.readthedocs.io/en/latest/troubleshooting.html#non-inlinable-functions

Describe the approach you would take to fix this

I am not a compiler engineer and I am not aware of the details of the internals of the PlutusTx plugin, so it's very hard for me suggest an approach.

System info

OS: Mac OS X Ventura 13.6 arm64 GHC: 9.2.8 Plutus: 1.7.0.0

[effectfully]

I've tried adding GHC.ppr (GHC.getSrcSpan n) to the error message, but all it gave me was <no location info>, since if GHC attempted to print the location of the binding site of a variable that it doesn't recognize. I've tried to persuade GHC to do something with the Tickish thing, but to no avail.

I guess we'll have to wait for @michaelpj to come from his vacation for this one, since he's probably the only person who's intimately familiar with GHC internals in our team. @zliu41 or do you happen to know how to reliably get source locations out of GHC?

[kwxm]

I think that the particular error message that's reproduced above may be caused by the use of ranges like [1..9], which aren't supported in PlutusTx. I happen to be working on a PR at the moment (see https://github.com/input-output-hk/plutus/issues/3395) that will improve the error message to something like

Error: Unsupported feature: Literal ranges are not supported: please use PlutusTx.enumFromTo or PlutusTx.enumFromThenTo
Context: Compiling expr: GHC.Enum.$fEnumInteger_$cenumFromTo
Context: Compiling expr: GHC.Enum.$fEnumInteger_$cenumFromTo 1
Context: Compiling expr: GHC.Enum.$fEnumInteger_$cenumFromTo 1 5
Context: Compiling expr at "main:Main:(36,15)-(36,50)"

That's specific to the use of ranges though, and won't help in the general case .

[michaelpj]

We should print the src spans in the context wherever we have them. But we often don't have them. Adding -g can help (it seems to add more src spans), but in general I think we can't go from an arbitrary GHC Core expression to its src span, which sucks :(

[effectfully]

but in general I think we can't go from an arbitrary GHC Core expression to its src span, which sucks :(

So there's no way we can resolve this ticket by implementing the desired functionality? In that case, I have to close the issue as "won't do". If I interpreted your message incorrectly or if somebody disagrees, please reopen the issue.