This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Tablegen-LSP] Add support for a basic TableGen language server
ClosedPublic

Authored by rriddle on May 11 2022, 8:00 PM.

Details

Summary

This follows the same general structure of the MLIR and PDLL language
servers. This commits adds the basic functionality for setting up the server,
and initially only supports providing diagnostics. Followon commits will
build out more comprehensive behavior.

Realistically this should eventually live in llvm/, but building in MLIR is an easier
initial step given that:

  • All of the necessary LSP functionality is already here
  • It allows for proving out useful language features (e.g. compilation databases) without affecting wider scale tablegen users
  • MLIR has a vscode extension that can immediately take advantage of it

Diff Detail

Event Timeline

rriddle created this revision.May 11 2022, 8:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 11 2022, 8:00 PM
rriddle requested review of this revision.May 11 2022, 8:00 PM
jpienaar accepted this revision.May 15 2022, 6:30 PM

I'll let the argument about the location of this slide as I know you'll follow up ;-)

Looks good as mostly close to PDLL one, couple of places it seemed leftovers which need update/may not apply, but overall LGTM.

mlir/include/mlir/Tools/mlir-tblgen-lsp-server/TableGenLspServerMain.h
20 ↗(On Diff #428844)

Shall we just call this tblgen-lsp-server? Given this isn't mlir specific, should move eventually and doesn't cause confusion (there isn't another TableGen LSP to differentiate with)

mlir/lib/Tools/lsp-server-support/SourceMgrUtils.cpp
15

Could we skip lex? E.g., why not just "find end of string that starts at curptr"?

mlir/lib/Tools/lsp-server-support/SourceMgrUtils.h
24

Is there any useful expansion to what the heuristic is that could be added here?

mlir/lib/Tools/mlir-tblgen-lsp-server/CMakeLists.txt
16 ↗(On Diff #428844)

So this is the main reason for this being inside mlir/? So if it moves to like tools or what not, this could move to be adjacent to tblgen binary itself?

mlir/lib/Tools/mlir-tblgen-lsp-server/LSPServer.h
23 ↗(On Diff #428844)

Pdll -> Tablegen?

mlir/lib/Tools/mlir-tblgen-lsp-server/TableGenServer.cpp
57 ↗(On Diff #428844)

Is the syntax registered as tblgen or tablegen? (Doc side https://github.com/llvm/llvm-project/blob/main/mlir/docs/OpDefinitions.md we have been using Tablegen, the tool is tblgen)

60 ↗(On Diff #428844)

Is there any verifier errors in Tablegen?

mlir/lib/Tools/mlir-tblgen-lsp-server/TableGenServer.h
1 ↗(On Diff #428844)

TablegenLspGenServer?

This revision is now accepted and ready to land.May 15 2022, 6:30 PM
rriddle updated this revision to Diff 429625.May 16 2022, 12:40 AM
rriddle edited the summary of this revision. (Show Details)
rriddle marked 8 inline comments as done.

This is failing to build on one of our flang bots: https://lab.llvm.org/buildbot/#/builders/177/builds/5120

This bot is building llvm as (or with, I'm not 100% sure yet myself) shared libraries. I'll see if I can find the fix myself (it's a missing library include...somewhere) but if you get to it first let me know.

Turns out we specifically don't include tablegen in the llvm shared library https://github.com/llvm/llvm-project/blob/main/llvm/tools/llvm-shlib/CMakeLists.txt#L20.

If I do it will link but you get:

FAILED: tools/clang/include/clang/Sema/AttrParsedAttrList.inc
<...>
: CommandLine Error: Option 'o' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

Given that this is a language server would it make sense to disable building it if LLVM_LINK_LLVM_DYLIB is on?

Turns out we specifically don't include tablegen in the llvm shared library https://github.com/llvm/llvm-project/blob/main/llvm/tools/llvm-shlib/CMakeLists.txt#L20.

If I do it will link but you get:

FAILED: tools/clang/include/clang/Sema/AttrParsedAttrList.inc
<...>
: CommandLine Error: Option 'o' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

Given that this is a language server would it make sense to disable building it if LLVM_LINK_LLVM_DYLIB is on?

Dang, thanks for the report. I think we can just do what we do for the PDLL parser, maybe something like:

llvm_add_library(TableGenLspServerLib STATIC
  LSPServer.cpp
  TableGenServer.cpp
  TableGenLspServerMain.cpp

  ADDITIONAL_HEADER_DIRS
  ${MLIR_MAIN_INCLUDE_DIR}/mlir/Tools/tblgen-lsp-server

  DISABLE_LLVM_LINK_LLVM_DYLIB

  LINK_COMPONENTS
  Support
  TableGen

  LINK_LIBS PUBLIC
  MLIRLspServerSupportLib
  MLIRSupport
  )

Could you give that a try?

mlir/include/mlir/Tools/mlir-tblgen-lsp-server/TableGenLspServerMain.h
20 ↗(On Diff #428844)

Yeah, agreed there. Meant to rename this before, thanks for pointing this out!

mlir/lib/Tools/mlir-tblgen-lsp-server/CMakeLists.txt
16 ↗(On Diff #428844)

Yep, we rely heavily on the LSPServer support library. If we can move that to a more common place, we could move the tblgen server out of MLIR.

mlir/lib/Tools/mlir-tblgen-lsp-server/LSPServer.h
23 ↗(On Diff #428844)

Oops, thanks for the catch!

mlir/lib/Tools/mlir-tblgen-lsp-server/TableGenServer.cpp
57 ↗(On Diff #428844)

The syntax is registered as tablegen IIRC. Let me fix the references to tblgen here.

60 ↗(On Diff #428844)

Let me drop this for now, but I did initially have this comment purposefully. It's a little more nuanced than from MLIR/PDLL. Right now we only capture parser errors, but realistically a lot of warnings/errors/notes/etc. come during the execution of the tablegen backend. It may be interesting in the future to try and run backends on files we know they should run on, and try to capture errors. That would expose more problems to users that would otherwise only pop up during build time. I'm not sure right now how we should do that/if we should do that, so dropped the comment for now.

Could you give that a try?

I'll do that, in fact I was looking for an existing lib that did the same thing thanks for the pointer.

Thanks for the fix! Really appreciated.