This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
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
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
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
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
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
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
