Unused Variable Warnings

[lmulcahy21]

The basic functionality of the warnings works correctly, printing "unused [var name]" or "used [var name]" to the console.

Would love review on these changes, as this does alter some of the core functionality of the backend, as well as the function definition for upat_to_info_map.

After review and revision, next step is to merge in the adt-defs-refutable branch and implement a warning for this, so that the variable is highlighted in place.

[disconcision]

Looks good! Some cleanup and case/lambda still need wiring up. Then prob good to proceed with bringing in warnings code

[lmulcahy21]

Just made a commit implementing most of these suggestions, but needs more time/work for debugging case statements. They currently aren't evaluating and the use of a variable in the case statement isn't counting as a "use" for the state of the variable, and im pretty sure it has something to do with an empty free/co-ctx instead of a properly created/propagated one

[lmulcahy21]

UVWs are working, with a basic warning interface outlined through the Info module. Would love to get feedback on it, as many things could use improvement, such as the names of warnings, info that each displays, how they are found, etc.

[cyrus-]

Nice work!

It isn't handling recursive functions correctly, so maybe look into that:

Another thing we should think about is how to handle variables where there is an empty expression hole in the scope. We think of holes as being potentially filled by anything, including that unused variable, so in such a case I would call the variable "possibly unused" rather than "definitely unused". I think we should hold off on displaying the warning marker in that situation.

[lmulcahy21]

Also not working correctly for case statements, will look into this

[cyrus-]

@lmulcahy21

• need to resolve some merge conflicts
• the message in the cursor inspector needs to be human-readable
• we need to have it so if there is a hole in the scope of a variable, we don't show unused variable warnings, otherwise we end up with stuff like this in exercises mode where odd is showing as unused because it isn't explicitly used in the "in" portion (but it will be referred to by the tests etc. downstream in exercises mode):

[lmulcahy21]

Had a boxing match with git and lost (had to force push) but warnings now (inelegantly) don't display if there is a hole in the co-context; done with a __hole__ variable in the co-context, as i didn't want to change the current co-ctx's interface

[disconcision]

looking pretty good but wondering about a couple details of the approach

Re-requesting