| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir:LSP] Add a quickfix code action for inserting expected-* diagnostic checks This allows for automatically inserting expected checks for parser and verifier diagnostics, which simplifies the workflow when building new dialect constructs or extending existing ones. Differential Revision: https://reviews.llvm.org/D130152 | 3 年前 | |
Recommit "[Support] change StringMap hash function from djbHash to xxHash" This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0. Test failures have been fixed: - ubsan failure fixed by 72eac42f21c0f45a27f3eaaff9364cbb5189b9e4 - warn-unsafe-buffer-usage-fixits-local-var-span.cpp fixed by 03cc52dfd1dbb4a59b479da55e87838fb93d2067 (wasn't related) - test-output-format.ll failure was spurious, build failed at https://lab.llvm.org/buildbot/#/builders/54/builds/3545 (b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93) but passed at https://lab.llvm.org/buildbot/#/builders/54/builds/3546 (5ae99be0377248c74346096dc475af254a3fc799) which is before my revert https://github.com/llvm/llvm-project/compare/b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93...5ae99be0377248c74346096dc475af254a3fc799 Original commit message: Depends on https://reviews.llvm.org/D142861. Alternative to https://reviews.llvm.org/D137601. xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile. Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order. No additional tests fail with this patch compared to main when running check-all with -DLLVM_ENABLE_PROJECTS="all" (on a Linux host), so I hope I found everything that needs to be changed. Differential Revision: https://reviews.llvm.org/D142862 | 3 年前 | |
[mlir][NFC] Update remaining textual references of un-namespaced func operations The special case parsing of operations in the func dialect is being removed, and operations will require the dialect namespace prefix. | 4 年前 | |
[mlir][lsp] Add LSP support for attribute and type aliases This wires in attribute and type aliases into the MLIR LSP server. This will allow goto definition and find references on attribute and type references, which should make debugging locations and other metadata easier. Depends on D158781 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D158782 | 2 年前 | |
[mlir:LSP] Improve conversion between SourceMgr and LSP locations SourceMgr generally uses 1-based locations, whereas the LSP is zero based. This commit corrects this conversion and also enhances the conversion from SMLoc to SMRange to support string tokens. Differential Revision: https://reviews.llvm.org/D124584 | 4 年前 | |
[mlir][NFC] Update remaining textual references of un-namespaced func operations The special case parsing of operations in the func dialect is being removed, and operations will require the dialect namespace prefix. | 4 年前 | |
[mlir][mlir-lsp] Add a new C++ LSP server for MLIR named mlir-lsp-server This commits adds a basic LSP server for MLIR that supports resolving references and definitions. Several components of the setup are simplified to keep the size of this commit down, and will be built out in later commits. A followup commit will add a vscode language client that communicates with this server, paving the way for better IDE experience when interfacing with MLIR files. The structure of this tool is similar to mlir-opt and mlir-translate, i.e. the implementation is structured as a library that users can call into to implement entry points that contain the dialects/passes that they are interested in. Note: This commit contains several files, namely those in mlir-lsp-server/lsp, that have been copied from the LSP code in clangd and adapted for use in MLIR. This copying was decided as the best initial path forward (discussed offline by several stake holders in MLIR and clangd) given the different needs of our MLIR server, and the one for clangd. If a strong desire/need for unification arises in the future, the existence of these files in mlir-lsp-server can be reconsidered. Differential Revision: https://reviews.llvm.org/D100439 | 5 年前 | |
[mlir][mlir-lsp] Add a new C++ LSP server for MLIR named mlir-lsp-server This commits adds a basic LSP server for MLIR that supports resolving references and definitions. Several components of the setup are simplified to keep the size of this commit down, and will be built out in later commits. A followup commit will add a vscode language client that communicates with this server, paving the way for better IDE experience when interfacing with MLIR files. The structure of this tool is similar to mlir-opt and mlir-translate, i.e. the implementation is structured as a library that users can call into to implement entry points that contain the dialects/passes that they are interested in. Note: This commit contains several files, namely those in mlir-lsp-server/lsp, that have been copied from the LSP code in clangd and adapted for use in MLIR. This copying was decided as the best initial path forward (discussed offline by several stake holders in MLIR and clangd) given the different needs of our MLIR server, and the one for clangd. If a strong desire/need for unification arises in the future, the existence of these files in mlir-lsp-server can be reconsidered. Differential Revision: https://reviews.llvm.org/D100439 | 5 年前 | |
[mlir][mlir-lsp] Add a new C++ LSP server for MLIR named mlir-lsp-server This commits adds a basic LSP server for MLIR that supports resolving references and definitions. Several components of the setup are simplified to keep the size of this commit down, and will be built out in later commits. A followup commit will add a vscode language client that communicates with this server, paving the way for better IDE experience when interfacing with MLIR files. The structure of this tool is similar to mlir-opt and mlir-translate, i.e. the implementation is structured as a library that users can call into to implement entry points that contain the dialects/passes that they are interested in. Note: This commit contains several files, namely those in mlir-lsp-server/lsp, that have been copied from the LSP code in clangd and adapted for use in MLIR. This copying was decided as the best initial path forward (discussed offline by several stake holders in MLIR and clangd) given the different needs of our MLIR server, and the one for clangd. If a strong desire/need for unification arises in the future, the existence of these files in mlir-lsp-server can be reconsidered. Differential Revision: https://reviews.llvm.org/D100439 | 5 年前 | |
Adopt Properties to store operations inherent Attributes in the Arith dialect This is part of an on-going migration to adopt Properties inside MLIR. Differential Revision: https://reviews.llvm.org/D148298 | 3 年前 | |
[mlir-lsp] Add client information to the InitializationParams This is specified in the spec, but we just never really needed it. This allows for users of the LSP libraries to inspect information about the client that is connected to the server. Differential Revision: https://reviews.llvm.org/D155566 | 2 年前 | |
[mlir-lsp] Add client information to the InitializationParams This is specified in the spec, but we just never really needed it. This allows for users of the LSP libraries to inspect information about the client that is connected to the server. Differential Revision: https://reviews.llvm.org/D155566 | 2 年前 | |
[mlir][lsp] Add LSP support for attribute and type aliases This wires in attribute and type aliases into the MLIR LSP server. This will allow goto definition and find references on attribute and type references, which should make debugging locations and other metadata easier. Depends on D158781 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D158782 | 2 年前 | |
[mlir][lsp] Enable registering dialects based on URI. (#141331) Previously the dialects registered were fixed per LSP binary. This works as long as all the dialects of interest from the different projects across which one uses the LSP, are disjoint. This expands this to support cases where there are dialects that overlap in dialect name but usage of these are separate wrt projects. The alternative is multiple binaries and switching LSP used in editor per project (there is some extra complexity in hosted instances). This handles a simple (I believe common case) where one can determine based on path and have single binary - the cost of dynamically doing so based on path would be either keeping different registries to return or repopulating dialect & extension maps. | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 |