Ignore type-checking

[Nv7-GitHub]

I don't know what type my function's return type will be until I have made all of the code up to the return statement. Most of the time this works, however, when I try to do recursion, I get errors due to mismatching types. In addition, these errors are panics, so I can't ignore them. Is there any way to ignore these types, and have it figure out the types when converting a module to a string (because, by then, the types will all be figured out)?

[mewmew]

Hi @Nv7-GitHub,

Do you have a minimal reproducible example? That would help us get a better insight into the use case, and try to help in a more time efficient manner. Right now, and for the next few weeks, I'll be quite busy at work and in life, so I won't be able to help out too much. Hope you manage to figure out a good approach to solve this.

Just for reference, this seem related to #65.

Cheers, Robin

[Nv7-GitHub]

I want the opposite - I want to be able to disable the type-checking, and have it assume that I did it correctly in certain parts. Is this possible?

[mewmew]

I want the opposite - I want to be able to disable the type-checking, and have it assume that I did it correctly in certain parts. Is this possible?

I think we should revisit the early type-checking. Either move parts to a later semantic evaluation step (e.g. #77), and/or convert panic to non-fatal logging, at least where possible.

[mewmew]

@Nv7-GitHub would you be able to provide a minimal proof of concept example (e.g. 30-50 or so lines of Go code which generates a recursive function, but fails with panic)?

[dannypsnl]

Seems like postpone type checking would be nice.

[mewmew]

cc: @pwaller

If memory serves me right, you wanted to add early type-checking panics to facilitate debugging when implementing a compiler using llir/llvm.

Would replacing early type-checking panics with optional logging still support your use case, and then postpone type-checking to the semantic analysis stage?

[Nv7-GitHub]

So basically, I have a bunch of statements in a function. I don't know the return type of the function, but by going through the statements, I can figure out the return type. However, previous statements might affect the current statement, and so on, because a variable definition will affect the type of the variable. In the end, after all the variables are defined, I can convert the return statement to an LLVM object, and know the return type of the function. However, when I call the function before the return type has been evaluated, I get errors about types not matching. Is there a way to ignore these and only have it do the type-checking once I try to convert the module to a string (by then, the return type will be defined).

[mewmew]

What function panics (file + line nr)? As you don't need early type-checking, just try to comment out the line that panics and see if it works ;)

P.S. when using Go modules, you can use the replace directive to specify a local file path to the llir/llvm module, so that you can run with your local changes after commenting out the line that panics.

replace github.com/llir/llvm => /path/to/llir/llvm // directory local git clone with panic line commented out.

[pwaller]

cc: @pwaller

If memory serves me right, you wanted to add early type-checking panics to facilitate debugging when implementing a compiler using llir/llvm.

Would replacing early type-checking panics with optional logging still support your use case, and then postpone type-checking to the semantic analysis stage?

My memory of this is quite old/worn. I don't hold strong opinions here, I am not currently deeply invested in this project, so my 2¢ should be downweighted appropriately. It would be useful to see a specific case (code + crash) for the ticket.

Remembering from the past, the goal in my mind of the early typechecking is to prevent you from constructing something broken, in my experience if you explode early it can be easy to figure out where the brokenness came from. Logging could potentially help, so long as it indicated the next-frame-up.

[Nv7-GitHub]

Right now the function panicking is Store, but it could be any, store is just the first one called

I like that it tells me when something is wrong, most of the time it's extremely helpful, which is why I want it to be something optional - maybe store a flag in the Module object?

This is also pretty specific for my needs, I can probably just update my code to figure out variable types

[Nv7-GitHub]

I was able to find a workaround for this issue by just calculating the type before, so I have resolved my side of the issue.