Macros that define variables (often used in Symbolics.jl and ModelingToolkit.jl and derivatives) confuse the parser.

[Qfl3x]

(cut from LanguageServer as it seems that this is where this belongs)

In this code:

using ModelingToolkit

@parameters param1,param2

param1 and param2 are undefined. In fact, at that line it returns a "Missing Reference".

I thought there could be a few options, first a better "macro walk" where macros should be evaluated by source, or a hard definition (mark @parameters...etc as "definers").

[mrufsvold]

The reason I've been given previously that macros are hard is because expanding a macro to see what expression(s) it evaluates to can execute arbitrary--potentially effectful and or expensive-- computation.

I've wondered if it would be possible to use package extensions in packages that define macros like this which, when StaticLint.jl is loaded, methods for StaticLint.should_expand(::Type{MyMacro}) = True are defined. That way SumTypes.jl, Symbolics.jl, etc. could tell StaticLint.jl -- this macro is pure and reasonably cheap to compute, you should try to expand it when building the list of symbols.

[johannesnauta]

Is there any update/progress on this? Working with macro-heavy packages, like ModelingToolkit, DifferentialEquations, and Catalyst, my screen is slowly turning into a red-wavy mess. Some fonts specifically suffer quite a lot (see picture), making development using them quite distracting to be fair.

[mrufsvold]

FWIW -- if you add

if false
    local r1, r2, A11 #, ... rest of your parameters
end

to the top of your file, it tricks the linter into thinking these symbols are defined. It doesn't help with intellisense or anything, but at least the errors go away.

[iago-lito]

Would extra annotations, either provided by macro callers like:

macro define_struct(id)
    quote
        struct $id end
    end |> esc
end

@define_struct(A) #! JuliaLS: def: A

A()

or by macro authors like:

macro define_struct(id)
    JuliaLS.define_identifiers(id)
    quote
        struct $id end
    end |> esc
end

@define_struct(A)

A()

Be options here?

[mrufsvold]

For the second option, no, unfortunately!

LS cannot expand macros to do its analysis because macros can execute arbitrary (potentially effectful) code.

Adding comments to annotate the code would work theoretically. But it's definitely not ideal to require users to clutter their code with comments to make it readable to LS.

I think that one way to do this would be to provide users the ability to opt certain macros into expansion by the Language Server, and by doing so, take responsibility for any side effects of rerunning the macro.

But the architecture to do something like that would be a major undertaking that I certainly don't have the bandwidth or capability to take on.

[iago-lito]

I see. If JuliaLS cannot expand macros then what about:

macro define_struct(id, more...)
    quote
        struct $id end
        println($more)
    end |> esc
end
JuliaLS.@definedby(define_struct, (id, more...) -> id)

@define_struct(A)

A()

.. is this what you meant with this third option?

[mrufsvold]

So, my personal hope is that the user's source code would have no awareness of LS. I don't want to have to install it in my Project.toml or commit code that doesn't do anything in production just so I can get linting.

Instead, I'm drawing inspiration from the Debugger part of the VSCode extension, where there is a UI for opting certain modules in and out of compilation depending on where you want speed vs debuggability. Likewise, there could be a panel in the UI that allows you to opt into certain macros getting expanded. I could click the [ ] expand @parameters box, and that would give permission to LS to expand anywhere it sees that macro.

But then there is an additional issue: LS is running in a separate, clean process that doesn't have your project dependencies installed, so it doesn't have access to the macro code it would need to do the expansion. That means we would either need to:

1. Clutter the LS process with all project dependencies and hope that there are no conflicts with the packages LS requires OR
2. Set up some system where LS can call the live REPL session, ask it to run @macroexpand @some_macro user_expression... and get the result returned back.

The second one seems like it could work, but it would be extremely difficult.

[non-Jedi]

2. Set up some system where LS can call the live REPL session, ask it to run @macroexpand @some_macro user_expression... and get the result returned back.

The second one seems like it could work, but it would be extremely difficult.

Is there a reason the language server couldn't just launch a new separate "dirty" julia process that it could use for trying @macroexpand on a best effort basis? Then if the macroexpand fails it's not taking down the language server process, and it's also not polluting the user's REPL.

This also would have the advantage of being available to all users of LanguageServer.jl--not just vscode.

[mrufsvold]

Until recently, I think the big issue would have been redefinition of structs requiring the "dirty" process to potentially have to restart and do expensive reload work over and over, but v1.12 will get rid of that issue.

edit: Actually, I think there is another issue: how does the "dirty" process know what to load? Consider the following script:

# dirty process needs to actually import SumTypes
using SumTypes

# Dirty process needs to expand this and then send the AST
# to the main LS server. We would have to capture the green
# tree produced by JuliaSyntax.jl as an identifier and then send
# it via a RemoteChannel to the LS process. The LS process would
# then need to stich the output of the macro into its representation
# of the same file.
@sum_type Fruit begin
    apple
    banana
    orange
end

# To expand @create_x later on, dirty process needs to
# run this code to define the macro
macro create_x(ex)
    return :($(esc(x)) = $ex)
end

# This would also need to get expanded so that LS could know that
# `x` is actually defined in this context. So it isn't as simple as just
# doing top level macros.
function some_very_expensive_function()
    @my_macro "hello"
    return x * ", world"
end

# The script runs this function at the top level. How does dirty
# process know not to run it?
some_very_expensive_function()

# This will cause dirty execution to fail because Vegetable is not
# defined. But it would be good if we could still identify errors
# later in the file, so we need to handle errors gracefully.
function undef_type(::Vegetable) end

In the end, the dirty process would essentially have to

1. run the file (within the correct context if the file is included elsewhere)
2. Figure out which expressions to skip -- i.e. function calls.
3. collect the location information for each expression and the Expr it produces
4. Pass that information to LS
5. Hopefully, not fail out completely if there is an invalid expression at the top of the file?

Edit:

For running on your own computer with packages you installed, the above stands, but I think you would also want to be able to lint other code. Like pull down an arbitrary repo for inspection. In this case, the dirty process could execute arbitrary malicious code via macros, so you would need very tight isolation to do that safely. I'm really not sure if it is feasible at all to isolate a Julia process securely without some very heavy dependencies.

[purepani]

@mrufsvold Is there a reason not to expand macros by default besides security?

The rust language server currently executes all macros by default, allowing for language server features to work, assuming all code is trusted. This is obviously not ideal, but if this language server were to do so, it certainly wouldn't be the only one.

[mrufsvold]

@purepani I don't think it's just security. Since Julia is a dynamic language that allows arbitrary compilation at runtime, we don't benefit from the clear delineation of compilation and runtime that rust has. You have to run Julia code to really know what the code means.

Now, I don't think perfect needs to be the enemy of the good, so there is probably a lot more meta programming expansion that could be done. But I have no doubt that the edge cases would be plenty and very annoying 😅

Tangent: I'm peripherally aware of a ORM rust package that tests the validity of your SQL models at comp against a live db connection... I wonder how their ls would manage that.

[purepani]

how does the "dirty" process know what to load?

This is perhaps a big hammer to a small question, but in general it might be good to look at how ty for python works.

They use the same incremental framework that rust is using(I think?) called salsa and, for how it would apply here, you would effectively define a chain of dependencies in the code, and then figure out exactly what you would need to rerun based on what's changed.

[pfitzseb]

The answer here is https://github.com/aviatesk/JETLS.jl.

For this language server implementation we've made the choice to never load user code into the LS process and that is very unlikely to ever change.