This revision adds assembly state tracking for uses of symbols, allowing for go-to-definition and references support for SymbolRefAttrs.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks good thanks
mlir/include/mlir/Parser/AsmParserState.h | ||
---|---|---|
69 | What is the range of a symbol use? E.g., just the name of it so that hover would report it is the op? | |
mlir/lib/Parser/AsmParserState.cpp | ||
41 | When would this one be needed? | |
42 | Do we need this to be implicitly convertable? | |
71 | Would all these all be nested? | |
mlir/lib/Parser/Parser.cpp | ||
1996 | Nit: move this to line 1992 (it feels closer linked to the conditional there and then also clearer why you just consume vs consumeIf before) | |
2001 | Nice lint warning :) I can't see it off hand though, is this due to parseBlock ? | |
mlir/test/mlir-lsp-server/hover.test | ||
8 | Could we have this as a comment with line & column markers? Would make it easier to check the tests manually: 0 5 a 0 func @foo(%arg: i1) { 0 9 1 %value = constant true 2 br ^bb2 |
mlir/include/mlir/Parser/AsmParserState.h | ||
---|---|---|
69 | The range is the full at_identifier: i.e. @foo. I haven't added hover behavior, because I'm not entirely sure what we would actually want to display in this case. | |
mlir/lib/Parser/AsmParserState.cpp | ||
71 | Whether they are or not isn't really that important, the expectation of nesting here is that the most recently started operation is stopped first. | |
mlir/lib/Parser/Parser.cpp | ||
2001 | Yeah, that is the only reasonable thing it could be caused by. (I don't plan on changing anything though, because well... parsing is generally a recursive play land). | |
mlir/test/mlir-lsp-server/hover.test | ||
8 | I can look at this in a followup, as this applies to all of the tests. |
What is the range of a symbol use? E.g., just the name of it so that hover would report it is the op?