silver icon indicating copy to clipboard operation
silver copied to clipboard

Improved Silver command-line interface

Open tedinski opened this issue 7 years ago • 3 comments

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.

tedinski avatar Jul 17 '17 17:07 tedinski

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.

tedinski avatar Aug 31 '17 19:08 tedinski

Another:

  • [x] --only-codegen or --dont-compile -- generate Java sources without compiling them or building the JAR

EDIT: Added as --dont-translate

remexre avatar Oct 17 '17 19:10 remexre

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.

tedinski avatar Jan 22 '18 19:01 tedinski