feat : field completions

[Sypher845]

This PR adds field completion support to JETLS. When a user types x. and triggers completions (e.g., via Ctrl+Space), the server now suggests available fields for the inferred type of x.

[aviatesk]

This PR implements .-completion as "field completion", but in Julia, x.y is actually not a field access but it's a property access. That means x.-completion needs to be implemented in a way that emulates the behavior of getproperty(::typeof(x), ::Symbol). The current implementation calls fieldnames on the inferred type, which is the most reliable but incomplete way to statically emulate getproperty. Do you have any ideas on this?

Also, there should be additional points to discuss:

• ASTTypeAnnotator probably expects a complete AST in most cases. However, code like xxx.| might produce an incomplete AST. I'd like you to investigate what happens in which cases, and check whether the current approach still works fine.
• Please improve the completion trigger logic so that .| automatically triggers completion.

Lastly, please rebase this PR and set #620 as the merge target.

[Sypher845]

@aviatesk i have addressed the main review points,

• . now triggers completion automatically.
• dot completion now handles properties, not only fields.
• typed local dot completion still works, including incomplete cases like p. .
• displayed type details are postprocessed before showing them.

Current limitation:
for inferred non-constant values, custom property completion currently works for simple static propertynames(::T) cases, but not for all dynamic getproperty cases.

Please take a look when you have time

[codecov]

Codecov Report

❌ Patch coverage is 72.81553% with 84 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.23%. Comparing base (16ca32f) to head (3fc3361).
⚠️ Report is 28 commits behind head on avi/ASTTypeAnnotator.

Files with missing lines	Patch %	Lines
src/completions.jl	64.88%	46 Missing ⚠️
src/analysis/ASTTypeAnnotator.jl	84.10%	24 Missing ⚠️
src/utils/inference.jl	45.45%	12 Missing ⚠️
src/utils/binding.jl	60.00%	2 Missing ⚠️

Additional details and impacted files

@@                   Coverage Diff                    @@
##           avi/ASTTypeAnnotator     #615      +/-   ##
========================================================
+ Coverage                 69.14%   69.23%   +0.09%     
========================================================
  Files                        51       53       +2     
  Lines                      8734     9034     +300     
========================================================
+ Hits                       6039     6255     +216     
- Misses                     2695     2779      +84     

Flag	Coverage Δ
JETLS.jl	69.23% <72.81%> (+0.09%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aviatesk]

@Sypher845 consolidated feedback before we iterate further — the concrete items from the first review are addressed (. trigger, propertynames framing, post-processing, tests), thanks for that.

The remaining concern is approach-level. The current PR layers three parallel paths — add_dot_property_completions!, add_static_dot_property_completions!, add_dot_field_completions! — that are each a partial, ad-hoc emulation of propertynames over a different slice of inputs. What I'd have liked you to notice on your own is that building several incomplete emulations in parallel isn't a good way to approach a problem like this; it's a sign that the single underlying question, "what does propertynames(x) return in this context?", should be answered once by the right tool rather than approximated three times.

The unified formulation is: obtain the inferred type (or Core.Const value) of the dot prefix — ASTTypeAnnotator gives you this for local bindings — then abstract-call propertynames(::T) through an AbstractInterpreter (LSAnalyzer is sufficient for this part). If the result is a Core.Const(::Tuple{Vararg{Symbol}}), use those names directly. The type detail for each name can come from similarly abstract-calling getproperty(::T, Core.Const(:name)). Three paths collapse into one, and the "is propertynames overridden?" question disappears — inference resolves both cases uniformly.

One way to have caught this earlier is to try to break an approach like the current one on a non-trivial example, e.g. Regex:

julia> code_typed((Regex,); optimize=false) do r
           propertynames(r)
       end
1-element Vector{Any}:
 CodeInfo(
1 ─ %1 = Main.propertynames::Core.Const(propertynames)
│   %2 =   dynamic (%1)(r)::Core.Const((:pattern, :compile_options, :match_options, :regex))
└──      return %2
) => NTuple{4, Symbol}

The current collect_static_property_names cannot reach this case — the length(stmts) == 2 assumption rejects branching bodies — whereas the abstract-call approach handles it uniformly, and as a side benefit avoids deserializing IR on each completion.

If you'd like to take this forward, the path is to rework the implementation around this abstract-call design.

[Sypher845]

Thanks for the detailed breakdown. I understand the issue now. I'll look into this and try to rework the implementation around that design. Will update once I have something concrete.