zigtools / sus Goto Github PK

See new code in https://github.com/zigtools/zig-lsp-codegen

it's borked

• Fuzzing invalid syntax Zig code
• Fuzzing valid syntax, invalid typing Zig code
• Fuzzing valid syntax, valid typing Zig code

oops todo fix this tmrw

• initialized
• initialize
• shutdown
• exit
• $/cancelRequest
• textDocument/didOpen
• textDocument/didChange
• textDocument/didSave
• textDocument/didClose
• textDocument/willSaveWaitUntil
• textDocument/semanticTokens/full
• textDocument/inlayHint
• textDocument/completion
• textDocument/signatureHelp
• textDocument/definition
• textDocument/typeDefinition
• textDocument/implementation
• textDocument/declaration
• textDocument/hover
• textDocument/documentSymbol
• textDocument/formatting
• textDocument/rename
• textDocument/references
• textDocument/documentHighlight
• textDocument/codeAction
• workspace/didChangeConfiguration
• textDocument/foldingRange
• textDocument/selectionRange

Using a seed allows us to reproduce issues that take a large amount of requests rather than one message.

i would like it if the project were more configurable by supporting additional cli args. i think this could be done without introducing a bunch of complexity or dependencies.

motivation - i think we are likely to discover more bugs in zls/zig if this project is easily configurable. as an example, i found an adversarial input the other day - enum(u32) - after manually changing maxlen and 'cycles per gen' values to smaller numbers. this happened quickly after changing the parameters while the previous configuration ran for ~15 minutes without discovering any adversarial inputs.

i would be glad to implement this if you agree that its a good idea. i think it could be done fairly simply with a state-machine (state = mode) and an args iterator.

my idea for these args would be:

• zls path - positional first arg - full path to the zls executable
• mode - positional second arg - one of [markov, ...]
  • mode == markov
    • --training-dir - directory to be used for training the markov model. searched for .zig files recursively.
    • --maxlen - maximum length of each file generated by the markov model.
    • --cycles-per-gen - how many times to call fuzzer.fuzzFeatureRandom() before regenerating a new file
  • mode == ...
    • process other args specific to this mode

let me know if you think this is a good idea and/or have anything to add or change. no worries if its just too early for these type of changes. just wanted to share my thoughts and maybe get some feedback.