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?