Filter out "name" and "unresolved" nodes

[larkinscott]

This is in response to issue https://github.com/codeclimate/app/issues/6609.

@toddmazierski and I paired on this Go duplication bug yesterday afternoon and came up with this fix. It's patchwork and we agree that the real fix should be at the parser level, since it's essentially returning a lot of information we don't need (see: https://github.com/codeclimate/app/issues/6609).

My inclination would be to merge this in now since the bug is currently live in production, but ultimately fix the parser.

Thoughts @wfleming @katwchen ?

[wfleming]

• name is useful to keep on parser side: it identifies the package of the file. So I'd stick with deleting that here.
• I agree the unresolved key can probably go entirely, and should be removed on the parser side. It's not even directly part of the source code itself since it's identifying types elsewhere in the file that couldn't be resolved, not representing syntax in the file anywhere.

Is what was happening here that these nodes don't have real line information, so it's the old issue of when they match it looks like the whole file even though it isn't, since missing line information is (incorrectly) filled in as the whole file by the parser client? If that's what we're talking about, I'd suggest we discuss a new card next week to improve, if not entirely fix, that situation: this is probably the third or fourth time that behavior has been super confusing & eaten a couple days of person time.

As a general rule, if we think it's appropriate to make a change in the parser I think we should do that immediately and not kick that can down the road: the parser is an equally important part of our infrastructure as the engine that we're responsible for, so as a team we shouldn't be skirting around it. If making changes to the parser is something people feel unsure about taking on, I think that's an issue to tackle, not side-step.

Well done getting to the bottom of this, @larkinscott & @toddmazierski!

[larkinscott]

Is what was happening here that these nodes don't have real line information, so it's the old issue of when they match it looks like the whole file even though it isn't, since missing line information is (incorrectly) filled in as the whole file by the parser client?

I'm pretty sure that was the issue here.

And yeah, that makes sense! I'm happy to take a look at the Go parser and see if I can get a fix working today.

[larkinscott]

Updated this PR to reflect only filtering at "name" at the s-exp level. Made a tweak to the parser which excludes "unresolved" from the AST: https://github.com/codeclimate/codeclimate-parser/pull/138.