Target Language Validation in IDEs/Text Editors

[petervdonovan]

It has been suggested that we use this area to discuss efficient ways to do target language validation.

I assume that real-time validation (red and yellow squiggles that appear as the user types) will be desired if possible, and that such validation must finish within (say) 10^-1 or maybe 10⁰ seconds in order to be useful.

To get started, here are some rough notes on the linters that are available for analyzing target language code. They seem to suggest that for small LF files, the linter itself will generally be fast enough. Furthermore, (unless I am mistaken) the time required to start the process that runs the linter is on the order of 10^-3s, so I do not think it is a performance consideration. This means that my early impression is that (at least at first) we might need to look elsewhere if we are concerned about performance.

I will try to report on how long it takes to do the naive approach of simply generating the code and then using a coarse (basically wrong) heuristic to update the code blocks.

[lhstrh]

I agree that the linter isn't the bottleneck here. As far as the update strategy (i.e., bypassing the code generator) is concerned, we should determine clear criteria for kinds of edits that can be done through updates and the kinds of edits that create structural changes and thus require code generation to be redone. My guess is that most changes to LF code cannot be done with updates, while most target code edits (anything delimited {= and =}) probably could be.

[cmnrd]

The summary table looks good. Thanks for putting this together! Based on my experience in working with various C++ tools, IDEs, and linters, I can confirm that the linter shouldn't be a bottleneck. Usually it is quite fast, even though often the linter is run as an external process. However, setting the linters up isn't always straight forward (they also need include locations, external libraries, preprocessor defines, etc...) and we might need additional information from users on each program to make things work.

Reading this table, I realized that it would be a mistake to limit ourselves to only one specific linter per target language. Users will have very different setups. Due to the usage of cmake, both the C++ and the C target support a wide range of compilers, and depending on the host system, we might have a situation where only one of the compilers is installed. So either we need to one specific linter and ship it with our products, or be flexible and support whatever the user has installed.