issue #77: make types.Check ignore errors

[dgnorton]

• Skip function bodies
• Print errors but don't stop

[clipperhouse]

Thanks. This is a start in the right direction, but we need to go a bit further.

I plan to make this behavior opt-in by the user. There are classes of type check errors where this will succeed, and others where it will fail. As a design goal, I want the behavior to be strict by default, and if the user wants to choose the non-deterministic approach, let them.

I've got a bit more architecture in the works on my end, will share with you.

[dgnorton]

I think it's important to be able to start with just a copy of the handwritten code (no generated files present) and generate from there.

I'd be interested to see what you have in the works.

[clipperhouse]

@dgnorton Agree, that’s the idea – you’re saying that even if the handwritten code has dependencies on the yet-to-be-generated code, it should work? That’s what I am going for here, if I understand the use case you are describing.

[dgnorton]

Yes, exactly. As it is, it's kind of a chicken & egg problem and I would be reluctant to use it on a big project for fear of getting into a state that required manual intervention to build.

[clipperhouse]

Yup. Am scratching my own itch here too, I’ve gotten into that state a lot.

[dgnorton]

I haven't played with Go's scanner / parser. Is it possible to feed it small chunks of code instead of files? I.e., could you read out just the package name and type declarations with some hand written scanning and feed those chunks into the parser? Dunno...maybe that's too hokey.

[clipperhouse]

To answer your question, yes you can do that but not sure what it buys us in this scenario. I get the instinct, maybe we can only evaluate the specific bits we need. Not impossible but sounds like a tough road.

typewriter first parses your whole package as an AST. That part is not changing – the code needs to be syntactically valid to proceed. If it’s syntactically busted, we really have no reliable information about the code.

It is possible for a program to be syntactically valid but incorrect. A class of error here is a variable of an unknown (undeclared) type. I think this is the state I think we are talking about above – handwritten code using yet-to-be-generated code.

typewriter then passes the AST to the types checker. The change we are discussing here is to have the types checker ignore that class of error.