search

google / xls

XLS: Accelerated HW Synthesis
http://google.github.io/xls/
Apache License 2.0
1.21k stars 178 forks source link

DSL should add "did you mean" on name resolution error #322

Open cdleary opened 3 years ago

cdleary commented 3 years ago

Simple edit distance heuristic would be fine, maybe highlight what chars are different in the closest match. I think this qualifies as a good first bug, hook into where uses are resolved-but-found-undefined.

cdleary commented 3 years ago

My triggering example was:

* 0027:   u32X4:[x, ...]                                                                                                                                      
  ~~~~~~~~^---^ ParseError: Cannot find a definition for name: 'u32X4'

When the type name was actually U32X4 (note leading capital).

taktoa commented 3 years ago

A somewhat more advanced version of this (for terms, not types) is to use a term index to search for all terms (including polymorphic ones) in scope that have the right type to fit into that spot in the code. Actually implementing a term index is pretty simple (it's not much more complicated than a trie), but maybe we don't yet have information on "the type that is needed for this spot". And of course, you can sort the term index output by edit distance from the invalid term.

cdleary commented 3 years ago

Cool, nice ref! Currently we emit def/use errors inline in the parsing process, if we did a more raw form of AST formation and then validation as a post-pass it'd allow us to take a more global view of what was likely needed given the surrounding context.

Brings up the point that, even without a post-pass, could try to do some simple matching based on lookahead (say at the token level) to say "hey looked like you were trying to form an array given the :[ lookahead so probably should be a type desired".