silver
silver copied to clipboard
Improved Silver command-line interface
Another thing I found in my head and thought I should write down.
Presently, we have just one mode that Silver operates in: get a grammar name, build it. Maybe generate some other stuff along the way, given flags.
We should have multiple modes. Probably something git-like silver command --options
. Here are a few reasons why:
- [ ] We need a "build all grammars under this root" build mode, especially for testing (and for things like IDE support where why wouldn't we want everything in the project built?)
- [ ] Possibly a "watch" mode that detects changed files and auto-rebuilds.
- We want a lot of simple, easy to write utilities that could be implemented as part of the compiler. e.g.:
- [ ]
silver aspects silver:definition:core:Expr
: print aspects of all non-forwarding productions of that nonterminal for me. - [ ]
silver ctags grammars/
: generate a ctags (or other index) allowing easy "go to definition" in emacs/vim and friends. - [ ] Simple refactorings like
silver rename
without needing regex hacks. :)
- [ ]
- [x]
silver doc
for generating documentation for a set of grammars - [ ]
silver test
might be a later option, if we want to build a better testing extension that lets us write tests in-line with the code, and let the compiler find and execute them all.
Another command line invokable function: turning inferred things into explicit things.
- [ ] See https://github.com/melt-umn/ableC/pull/60 for an example of turning implied flowtypes into explicitly declared flowtypes.
Another:
- [x]
--only-codegen
or--dont-compile
-- generate Java sources without compiling them or building the JAR
EDIT: Added as --dont-translate
Another idea:
- [ ]
--log-msgs <file>
Also write errors/warnings to<file>
in addition to printing them.
This would be useful in that we could have deep-rebuild
's final step do --warn-all --log-msgs known-warnings.txt
, and then we could commit that file and thus track any changes in issued warnings when other changes are made to the compiler.
We might want to consider canonicalizing them somehow though. Like, sorting grammars alphabetically or something to reduce noise. Or removing full file paths. And line numbers... Might not be as trivial of a feature as it initially sounds, now that I think about it.