michaelficarra / CoffeeScriptRedux

:sweat: rewrite of the CoffeeScript compiler with proper compiler design principles and a focus on robustness and extensibility

Home Page:https://michaelficarra.github.com/CoffeeScriptRedux/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Strange issue with overzealous helper inclusion during compilation

samuelhorwitz opened this issue · comments

First of all, I am unsure of whether or not this is expected behavior. If it is expected behavior, then the bug is on Ibrik coverage tool's end https://github.com/Constellation/ibrik

I noticed, when running my coverage tests with Ibrik, that after adding a CS class with the extends syntax that my coverage reports got all weird. Line by line, every path appeared to be covered, but the percentages at the top of the screen for branches/functions/etc. all were displaying non-100% values (however my code is 100% covered and properly reports that way when the extends syntax was removed).

After digging, it appears that enabledHelpers in compiler.coffee (https://github.com/michaelficarra/CoffeeScriptRedux/blob/master/src/compiler.coffee#L372) never gets reinitialized to an empty array after each program block. This means that all of my files processed by a CSR instance after the one that includes extends will have the extends$ and isOwn$ helper functions in the compiled JS. Although these helpers don't show up in the Coffeescript coverage map (which maps all the paths back to the original CS file which doesn't include any of the helpers that come with compilation), I obviously haven't actually covered these extend helpers since the files in question don't necessarily use the extend syntax but simply were processed after a file that did.

Regardless of my coverage reporting issues, is this expected behavior? Should new program/file blocks not compile with a fresh enabledHelpers empty array? Or is this working exactly as expected, and I should report to Ibrik that they need to somehow clean up their CSR instance between files?

No, this is not expected behavior. I also ran into this problem recently, and opened #323, which is a duplicate of this issue I realize now. Even though this issue was reported first, I’m closing this one in favor of #323, since that one is more straight to the point.