StaticLint.jl icon indicating copy to clipboard operation
StaticLint.jl copied to clipboard

A few issues

Open EricForgy opened this issue 5 years ago • 6 comments

Hi,

Over the last couple of days I noticed a few issues and thought I'd share them here.

Exporting abstract types

I exported an abstract type, but it still shows up with squiggly lines in the module they get exported to.

Callable types

I had a callable typed defined with

(mt::Type{MyType})(x) = dostuff(mt,x)

and mt is showing up with squiggly lines when I use it, e.g. mt(x), the mt has squiggly lines.

Macro defined variables

I have some variables defined by a macro that creates custom types (not instances) like

@construct T

That constructs a variable T referring to a custom parametric type.

When I use T later in my code, it has squiggly lines, e.g. T(x), the T has squiggly lines.

In all cases above, the code actually runs and is valid Julia code, but the linting isn't picking it up for some reason.

I hope this helps 🙏

EricForgy avatar Jul 04 '20 17:07 EricForgy

Note that the macro case is something we can't really support in full generality since macros are allowed to to everything.

pfitzseb avatar Jul 06 '20 07:07 pfitzseb

Hiya, going through these in order

  1. Is the reference to the exported type in another package or in a not directly related file (other than some using/import statement)? If so then this is something we're currently unable to handle (without the restarting of vscode). Packages are re-cached each time an editor session starts but we don't update for in-session changes to that imported code. I'll be exploring ways to change this in the near future (this way). If not, then its a bug and a MWE would be appreciated!
  2. This seems odd - are the squigglies just under mt, and so marking a missing reference or does the hint message indicate something else?
  3. As @pfitzseb we can't currently support full interpreting of macros in a safe way. An attempt to do so would require the running of code contained within the macro definition (and any functions it calls), and so could have any arbitrary effect contrary to the users intentions. As an extreme - and highly unrealistic - example, writing the following code in the editor, without asking for it to be executed, could be bad...
macro add_one(arg)
    rm("/home/zac/important_files")
    :($(esc(arg)) + 1)
end
@add_one 1

It's not clear to me, at this point, how you would isolate code that is manipulating expressions from code doing something arbitrary.

ZacLN avatar Jul 06 '20 13:07 ZacLN

Hi @pfitzseb and @ZacLN 👋

Thanks for following up on this 👍

Exporting abstract types

Yes, this is coming from using a local file where the module is defined. Restarting VS Code worked and that is good to know and is good enough for me for now. Thanks 👍

Callable types

I don't see this anymore because I changed my code 😅 I believe it was a "Missing reference" error, which is the usual case. If it was something else, I probably would have noticed.

Macro defined variables

Understood 👍😊

EricForgy avatar Jul 06 '20 19:07 EricForgy

Re the callable types point: I just tried that locally on master with a minimal definition and didn't see any lint errors, so that case seems fixed.

pfitzseb avatar Jul 06 '20 19:07 pfitzseb

Thanks for the help. I hadn't thought of restarting VS Code, so that helps a lot.

Should I close this or leave it open until Item 1 works as expected. I imagine I'm not the only one who will bump into this and restarting VS Code wasn't an obvious solution to me (I usually always just leave it open).

EricForgy avatar Jul 06 '20 20:07 EricForgy

Let's leave this open for now, I think. We can improve our docs in the short term and the behaviour in the long term.

pfitzseb avatar Jul 06 '20 20:07 pfitzseb