[Feature Request] Support valac compiler for Vala language.

[vdualb]

vala-language-server currently requires compile_commands.json to work. Please add support for valac compiler, so vls could work with autotools projects. That's an example of compile commands generated for vala-language-server itself by meson:

Details

{
    "directory": "/home/user/Projects/Vala projects/vala-language-server/build",
    "command": "valac --depfile src/vala-language-server.depfile -C --debug --define=WITH_JSONRPC_GLIB_3_30 --target-glib=auto --enable-gobject-tracing --fatal-warnings --pkg gio-unix-2.0 --pkg posix --pkg libvala-0.58 --pkg jsonrpc-glib-1.0 --pkg json-glib-1.0 --pkg gee-0.8 --pkg gio-2.0 --pkg gobject-2.0 --pkg glib-2.0 --color=always --directory src/vala-language-server.p --basedir ../src ../src/analysis/codeanalyzer.vala ../src/analysis/codelensanalyzer.vala ../src/analysis/codestyleanalyzer.vala ../src/analysis/inlayhintnodes.vala ../src/analysis/symbolenumerator.vala ../src/codeaction/addotherconstantstoswitchaction.vala ../src/codeaction/adddefaulttoswitchaction.vala ../src/codeaction/baseconverteraction.vala ../src/codeaction/implementmissingprereqsaction.vala ../src/codehelp/callhierarchy.vala ../src/codehelp/codeaction.vala ../src/codehelp/codehelp.vala ../src/codehelp/codelensengine.vala ../src/codehelp/completionengine.vala ../src/codehelp/find_scope.vala ../src/codehelp/formatter.vala ../src/codehelp/nodesearch.vala ../src/codehelp/signaturehelpengine.vala ../src/codehelp/symbolextractor.vala ../src/codehelp/symbolreferences.vala ../src/codehelp/symbolvisitor.vala ../src/codehelp/typehierarchy.vala ../src/documentation/cnamemapper.vala ../src/documentation/doccomment.vala ../src/documentation/girdocumentation.vala ../src/projects/buildtarget.vala ../src/projects/buildtask.vala ../src/projects/ccproject.vala ../src/projects/compilation.vala ../src/projects/defaultproject.vala ../src/projects/filecache.vala ../src/projects/mesonproject.vala ../src/projects/project.vala ../src/projects/textdocument.vala ../src/projects/types.vala ../src/protocol.vala ../src/reporter.vala ../src/request.vala ../src/server.vala config.vala ../src/util.vala version.vala",
    "file": "../src/analysis/codeanalyzer.vala",
    "output": "src/vala-language-server.p/analysis/codeanalyzer.c"
  },
  {
    "directory": "/home/user/Projects/Vala projects/vala-language-server/build",
    "command": "valac --depfile test/vls-testclient.depfile -C --debug --define=WITH_JSONRPC_GLIB_3_30 --target-glib=auto --enable-gobject-tracing --fatal-warnings --pkg gio-unix-2.0 --pkg posix --pkg libvala-0.58 --pkg jsonrpc-glib-1.0 --pkg json-glib-1.0 --pkg gee-0.8 --pkg gio-2.0 --pkg gobject-2.0 --pkg glib-2.0 --color=always --directory test/vls-testclient.p --basedir ../test ../test/testclient.vala ../src/util.vala",
    "file": "../test/testclient.vala",
    "output": "test/vls-testclient.p/testclient.c"
  },

[rizsotto]

Hi @vdualb, thanks for the suggestion - it was a good one, and well-scoped. valac support is now implemented on the 4.1.5-rc branch (4d47cebc).

What it does: Bear now recognizes valac invocations and emits one compilation entry per .vala (or .gs Genie) source, so vala-language-server can consume a Bear-generated compile_commands.json on non-meson builds.

One limitation worth knowing about up front: vala-language-server reads only the command string form of each entry and ignores the arguments array (which is Bear's default). So for VLS to see anything, you need to build the database with the array format disabled:

format:
  entries:
    use_array_format: false

This is a documented config knob rather than an automatic per-compiler switch - the reasoning (we keep every entry in the database the same shape) is written up in docs/rationale/vala-transpiler-database.md, and the man page's "Vala Projects" section covers the setup.

A related note for mixed C/Vala projects: valac transpiles to C and then runs a C compiler on the generated C, so the database also contains entries for that generated C. If you point clangd at the same database it will emit unknown-argument noise on the valac entries; you can suppress that on the clangd side with a .clangd PathMatch (also in the man page).

Could you give it a try? Build from the 4.1.5-rc branch and point VLS at the resulting database (with use_array_format: false). I'd love to hear whether it works for your project before it ships in 4.1.5.

[vdualb]

Hello, thanks for working on it. I couldn't get myself to work on testing it. I looked into vls code and compared compile_commands.json generated by meson and bear.

emits one compilation entry per .vala (or .gs Genie) source

This is wrong. When I tested vls with compile_commands.json generated by bear for vala compiler project (https://gitlab.gnome.org/GNOME/vala), vls processed these commands and marked many commands as producers for the same .vapi (vala/libvaladoc/valadoc-0.58.vapi for instance), which vls then detects and fails to create a cc project. Here is an example of command from wip/meson branch of vala that produces vala/libvaladoc/valadoc-0.58.vapi:

{
    "directory": "/home/dell/Projects/vala/build",
    "command": "valac --depfile libvaladoc/valadoc-0.58.depfile -C --debug --disable-version-header --vapidir /home/dell/Projects/vala/vapi --pkg config --hide-internal --abi-stability -D WITH_CGRAPH -D LIBGVC_13_0_0 --pkg libgvc --pkg gmodule-2.0 --color=always --directory libvaladoc/libvaladoc-0.58.so.0.0.0.p --basedir ../libvaladoc --library valadoc-0.58 --header libvaladoc/valadoc.h --vapi ../valadoc-0.58.vapi ../libvaladoc/ctyperesolver.vala ../libvaladoc/devhelp-markupwriter.vala ../libvaladoc/doclet.vala ../libvaladoc/errorreporter.vala ../libvaladoc/filehelper.vala ../libvaladoc/gtkdocmarkupwriter.vala ../libvaladoc/gtkdocrenderer.vala ../libvaladoc/markupwriter.vala ../libvaladoc/moduleloader.vala ../libvaladoc/settings.vala ../libvaladoc/api/array.vala ../libvaladoc/api/attribute.vala ../libvaladoc/api/callable.vala ../libvaladoc/api/childsymbolregistrar.vala ../libvaladoc/api/class.vala ../libvaladoc/api/constant.vala ../libvaladoc/api/delegate.vala ../libvaladoc/api/enum.vala ../libvaladoc/api/enumvalue.vala ../libvaladoc/api/errorcode.vala ../libvaladoc/api/errordomain.vala ../libvaladoc/api/field.vala ../libvaladoc/api/girsourcecomment.vala ../libvaladoc/api/interface.vala ../libvaladoc/api/item.vala ../libvaladoc/api/method.vala ../libvaladoc/api/namespace.vala ../libvaladoc/api/node.vala ../libvaladoc/api/nodetype.vala ../libvaladoc/api/ownership.vala ../libvaladoc/api/package.vala ../libvaladoc/api/parameter.vala ../libvaladoc/api/pointer.vala ../libvaladoc/api/property.vala ../libvaladoc/api/propertyaccessor.vala ../libvaladoc/api/signal.vala ../libvaladoc/api/signaturebuilder.vala ../libvaladoc/api/sourcecomment.vala ../libvaladoc/api/sourcefile.vala ../libvaladoc/api/struct.vala ../libvaladoc/api/symbol.vala ../libvaladoc/api/tree.vala ../libvaladoc/api/typeparameter.vala ../libvaladoc/api/typereference.vala ../libvaladoc/api/typesymbol.vala ../libvaladoc/api/visitor.vala ../libvaladoc/charts/chart.vala ../libvaladoc/charts/chartfactory.vala ../libvaladoc/charts/hierarchychart.vala ../libvaladoc/charts/simplechartfactory.vala ../libvaladoc/content/block.vala ../libvaladoc/content/blockcontent.vala ../libvaladoc/content/comment.vala ../libvaladoc/content/contentelement.vala ../libvaladoc/content/contentfactory.vala ../libvaladoc/content/contentrenderer.vala ../libvaladoc/content/contentvisitor.vala ../libvaladoc/content/embedded.vala ../libvaladoc/content/headline.vala ../libvaladoc/content/inline.vala ../libvaladoc/content/inlinecontent.vala ../libvaladoc/content/inlinetaglet.vala ../libvaladoc/content/link.vala ../libvaladoc/content/list.vala ../libvaladoc/content/listitem.vala ../libvaladoc/content/note.vala ../libvaladoc/content/page.vala ../libvaladoc/content/paragraph.vala ../libvaladoc/content/resourcelocator.vala ../libvaladoc/content/run.vala ../libvaladoc/content/sourcecode.vala ../libvaladoc/content/styleattributes.vala ../libvaladoc/content/symbollink.vala ../libvaladoc/content/table.vala ../libvaladoc/content/tablecell.vala ../libvaladoc/content/tablerow.vala ../libvaladoc/content/taglet.vala ../libvaladoc/content/text.vala ../libvaladoc/content/warning.vala ../libvaladoc/content/wikilink.vala ../libvaladoc/documentation/commentscanner.vala ../libvaladoc/documentation/documentationparser.vala ../libvaladoc/documentation/documentation.vala ../libvaladoc/documentation/girmetadata.vala ../libvaladoc/documentation/gtkdoccommentparser.vala ../libvaladoc/documentation/gtkdoccommentscanner.vala ../libvaladoc/documentation/gtkdocmarkdownparser.vala ../libvaladoc/documentation/gtkdocmarkdownscanner.vala ../libvaladoc/documentation/importerhelper.vala ../libvaladoc/documentation/wikiscanner.vala ../libvaladoc/documentation/wiki.vala ../libvaladoc/highlighter/codescanner.vala ../libvaladoc/highlighter/codetoken.vala ../libvaladoc/highlighter/highlighter.vala ../libvaladoc/highlighter/scanner.vala ../libvaladoc/highlighter/xmlscanner.vala ../libvaladoc/html/basicdoclet.vala ../libvaladoc/html/cssclassresolver.vala ../libvaladoc/html/htmlchartfactory.vala ../libvaladoc/html/htmlmarkupwriter.vala ../libvaladoc/html/htmlrenderer.vala ../libvaladoc/html/linkhelper.vala ../libvaladoc/importer/documentationimporter.vala ../libvaladoc/importer/girdocumentationimporter.vala ../libvaladoc/importer/internalidregistrar.vala ../libvaladoc/importer/valadocdocumentationimporterscanner.vala ../libvaladoc/importer/valadocdocumentationimporter.vala ../libvaladoc/parser/manyrule.vala ../libvaladoc/parser/oneofrule.vala ../libvaladoc/parser/optionalrule.vala ../libvaladoc/parser/parser.vala ../libvaladoc/parser/parsercallback.vala ../libvaladoc/parser/rule.vala ../libvaladoc/parser/scanner.vala ../libvaladoc/parser/sequencerule.vala ../libvaladoc/parser/stubrule.vala ../libvaladoc/parser/token.vala ../libvaladoc/parser/tokentype.vala ../libvaladoc/taglets/tagletdeprecated.vala ../libvaladoc/taglets/tagletinheritdoc.vala ../libvaladoc/taglets/tagletinit.vala ../libvaladoc/taglets/tagletlink.vala ../libvaladoc/taglets/tagletparam.vala ../libvaladoc/taglets/tagletreturn.vala ../libvaladoc/taglets/tagletsee.vala ../libvaladoc/taglets/tagletsince.vala ../libvaladoc/taglets/tagletthrows.vala vala/vala.vapi gee/gee.vapi codegen/valacodegen.vapi ccode/valaccode.vapi",
    "file": "../libvaladoc/ctyperesolver.vala",
    "output": "libvaladoc/libvaladoc-0.58.so.0.0.0.p/ctyperesolver.c"
  },

I patched vls to accept arguments so I didn't change bear configs.

[rizsotto]

Thanks - that diagnosis was exactly right, and very helpful.

You nailed the root cause: Bear was emitting one entry per .vala source, and because each of those entries still carried the target's --library/--vapi/--header flags, VLS saw N commands all claiming to produce the same binding (e.g. valadoc-0.58.vapi). Since VLS keys a build target on its produced .vapi, N duplicate producers made it bail before building the cc project. That's a design mismatch on our side, not something to work around in VLS: valac compiles all of a target's sources as a single translation unit, so fanning the invocation into per-source entries was simply wrong for it.

The fix is on the 4.1.5-rc branch (commit 7174d7fc): Bear now emits one entry per valac invocation, matching what Meson produces - file is the first source, and every source is kept in the command. So you get exactly one producer per .vapi, and the cc project should construct. Per-source compilers (gcc/clang/...) are unaffected.

If you can give 4.1.5-rc another run against GNOME/vala, I'd love to confirm it works for you before 4.1.5 ships.

On the arguments vs command point: good that patching VLS to read arguments worked for you. An unpatched VLS still reads only the command string, so building with format.entries.use_array_format: false remains the way to feed stock VLS - though if your patch lands upstream, even that step goes away.