search

plasma-umass / cwhy

"See why!" Explains and suggests fixes for compile-time errors for C, C++, C#, Go, Java, LaTeX, PHP, Python, Ruby, Rust, and TypeScript
Apache License 2.0
273 stars 6 forks source link

Extend wrapper for all the other supported target languages #23

Closed emeryberger closed 7 months ago

emeryberger commented 1 year ago

I am also wondering whether we shouldn't just switch to a mode where we precede any compiler command with cwhy and it does the right thing (that is, wrapper-mode would be the default).

nicovank commented 1 year ago

I agree that wrapper mode should be default.

Having it precede the compiler command is a good idea but with some caveats when working with build systems: they typically expect a single file/executable for the compiler, hence options cannot be passed then (example: CXX, CMAKE_CXX_COMPILER typically expect a single file). This is why the current --wrapper option generates a dummy Python file that 1. keeps all arguments that were passed to CWhy when creating the wrapper (including the compiler) 2. acts exactly as the original compiler would.

I do think we can make it nicer, but we need to make sure we can still invoke CWhy with build tools.

# Given a compile command.
% [COMPILER] [COMPILER_OPTIONS]
# Current way.
% `cwhy --wrapper --wrapper-compiler=[COMPILER] [CWHY_OPTIONS]` [COMPILER_OPTIONS]
# This is nicer for example.
% cwhy [CWHY_OPTIONS] --- [COMPILER] [COMPILER_OPTIONS]

I'll think about this and try to come up with something.

If we support more languages, I think that sooner or later we will have to select a specific mode for CWhy,with some auto-detection and a --mode option. I feel like we are bound to have conflicts in regexes, or we might decide to parse output for a certain language / compiler a smarter way.

nicovank commented 7 months ago

Wrapper mode has now been default for a bit, closing this.

Custom mode would still be good if we ever decide to be smarter about diagnostic parsing (or if compilers can emit SARIF / JSON).