16 Commits

Author SHA1 Message Date
River Riddle
305d718539 [mlir][NFC] Move the headers for lsp-server-support to include/
This makes it a bit easier to share the functionality for building
language servers, and makes the API public. No real functional
change, as the API was already intended for this anyways.

Differential Revision: https://reviews.llvm.org/D142790
2023-01-27 17:36:06 -08:00
Kazu Hirata
0a81ace004 [mlir] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<.  I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 01:25:58 -08:00
Kazu Hirata
a1fe1f5f77 [mlir] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-13 21:05:06 -08:00
Fangrui Song
1da3a795fc JSON: llvm::Optional => std::optional
Many files are from language servers.

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-16 07:56:52 +00:00
Kazu Hirata
192d9dd731 [mlir] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-04 19:58:32 -08:00
Kazu Hirata
1a36588ec6 [mlir] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 18:50:27 -08:00
River Riddle
e00dc16dbe [tblgen-lsp-server] Fix various ASAN issues
* Properly use virtual destructors for index symbols
* Clear the index before initializing it
2022-10-20 10:49:09 -07:00
River Riddle
99e24123e9 [TableGen:LSP] Resolve "go-to-def" on a let field to the base definition
This allows for go-to-def on the a `let` field to resolve to the definition
of the base class. This is kind of like how C++ works with go-to-def
from use->def->decl, with the decl in this case being the base definition
of the field.

Differential Revision: https://reviews.llvm.org/D134264
2022-09-27 23:48:16 -07:00
River Riddle
3e2ad37679 [TableGen:LSP] Add hover support for records and recordvals
This provides hover information for classes, defs, fields, and template
arguments. Like PDLL, this pulls documentation from the source code
when hovering over fields and records.

Differential Revision: https://reviews.llvm.org/D134259
2022-09-27 23:48:16 -07:00
River Riddle
50d96f59d0 [TableGen] Track reference locations of Records/RecordVals
This is extremely useful for language tooling as it allows
for providing go-to-def/find-references/etc. for many
more situations than what is currently possible.

Differential Revision: https://reviews.llvm.org/D134087
2022-09-27 23:48:16 -07:00
River Riddle
6187178e83 [mlir:LSP] Switch document sync mode to Incremental
This is much more efficient over the full mode, as it only requires sending
smalls chunks of files. It also works around a weird command ordering
issue (full document updates are being sent after other commands like
code completion) in newer versions of vscode.

Differential Revision: https://reviews.llvm.org/D126032
2022-06-06 20:20:19 -07:00
River Riddle
8d021670c3 [mlir][Tablegen-LSP] Add support for a tracking definitions and references
This essentially builds an index for the parsed records and record values (fields).
This covers quite a few cases, but is limited by the currently lackluster location
tracking in tablegen. A followup will work on plumbing more locations through
tablegen, which should greatly improve what we can do here.

Differential Revision: https://reviews.llvm.org/D125443
2022-05-27 02:39:49 -07:00
River Riddle
682ca00e21 [mlir][Tablegen-LSP] Add support for include file link and hover
This allows for following links to include files. This support is effectively
identical to the logic in the PDLL language server, and code is shared as
much as possible.

Differential Revision: https://reviews.llvm.org/D125442
2022-05-27 02:39:49 -07:00
River Riddle
dc9fb65c4f [mlir][Tablegen-LSP] Add support for a compilation database
This provides a format for externally specifying the include directories
for a source file. The format of the tablegen database is exactly the
same as that for PDLL, namely it includes the absolute source file name and
the set of include directories. The database format is shared to simplify
the infra, and also because the format itself is general enough to share. Even
if we desire to expand in the future to contain the actual compilation command,
nothing there is specific enough that we would need two different formats.

As with PDLL, support for generating the database is added to our mlir_tablegen
cmake command.

Differential Revision: https://reviews.llvm.org/D125441
2022-05-27 02:39:49 -07:00
David Spickett
9e469ced42 [mlir][Tablegen-LSP] Don't link with llvm dylib
This updates 5de12bb703c5104b3fd64ee51c6900d6171d826a
to not link with the dylib since that does not include
the tablegen library.

Should fix flang dylib build failures:
https://lab.llvm.org/buildbot/#/builders/177/builds/5120
2022-05-17 11:03:01 +00:00
River Riddle
5de12bb703 [mlir][Tablegen-LSP] Add support for a basic TableGen language server
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

Differential Revision: https://reviews.llvm.org/D125440
2022-05-16 16:03:51 -07:00