This commit adds support for interacting with a (valid) bytecode file in the same
way as .mlir. This allows editing, using all of the traditional LSP features, etc. but
still using bytecode as the on-disk serialization format. Loading a bytecode file this
way will fail if the bytecode is invalid, and saving will fail if the edited .mlir is invalid.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Nice! The typescript I peripherally followed only. I was expecting this to be worse. Is period in schema the preferred form? (I saw some with colons but wasn't sure what is the defacto reference)
mlir/lib/Tools/mlir-lsp-server/MLIRServer.cpp | ||
---|---|---|
320 | I thought ModuleOp was intended to not be required here? | |
612 | Was this just discovered with this change or why is changed here along with bytecode? | |
1279 | Could we avoid saving in this case to not make it accidentally lossy viewing? |
period/dash/etc are all fine, colon separates the scheme from the rest of the content.
mlir/lib/Tools/mlir-lsp-server/MLIRServer.cpp | ||
---|---|---|
320 | Thanks for the comment here. It was in my head that we need this, but the real constraint we have for bytecode right now is single op, restructured this to just block loading/saving on that (with TODOs that we can fix that if/when necessary). | |
612 | Unnecessary now. | |
1279 | We can't even detect this right now. I think we should have some mechanism for parsing in unknown external resources opaquely, which would allow for us to round trip. The producer case I'm not sure how we want to handle. If the user saves, technically the producer of the bytecode will be different. It will also be interesting in how the support here interacts with versioning and auto-upgrade whenever that happens. |
I thought ModuleOp was intended to not be required here?