You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we find a {-# OPTIONS -fplugin=SomePlugin #-} pragma atop a source file, we should bail out (or take some other appropriate action), as GHC source plugins can run arbitrary transformations on source code. An example of source-plugin-modified code that we can’t parse (without pulling in the plugin architecture, which is of course out of scope for a plain parser) can be found here.
The text was updated successfully, but these errors were encountered:
The code in that post still looks like valid syntax to me. Are you sure using plugins allows you to write syntactically invalid code?
In any case, since you a) can use a plugin by putting it in the cabal config and b) some plugins only do type inference support (e.g. polysemy-plugin), I think this isn't feasible.
@tek Yeah, that’s a good point. I suppose when I said ‘parse’ in this case I meant ‘parse to what is meant by the user’, rather than ‘yield a parse tree’—kind of an unhelpful formulation. And yeah, regardless of whether a plugin allows you to write syntactically invalid code, this is still a WONTFIX situation.
If we find a
{-# OPTIONS -fplugin=SomePlugin #-}
pragma atop a source file, we should bail out (or take some other appropriate action), as GHC source plugins can run arbitrary transformations on source code. An example of source-plugin-modified code that we can’t parse (without pulling in the plugin architecture, which is of course out of scope for a plain parser) can be found here.The text was updated successfully, but these errors were encountered: