Basic Linting

[woollybah]

It would be nice if we had some basic linting functionality... somewhere. Not necessarily in bcc itself.

Here's an example where such a thing might be useful:

SuperStrict
Framework brl.standardio

Local variable:TMyType New TMyType

Type TMyType
End Type

The assignment operator is missing from the statement. This is obviously a coding error, but is valid in both legacy and NG.

Rather than me spending a stupid amount of time looking for a non-existant bug elsewhere, a warning about my potentially stupid code would be preferred.

Perhaps we need a suite of utilities - like libdparse - that can be applied to such tasks...

[HurryStarfish]

For this and similar things (I'm thinking autocomplete, proper syntax highlighting, autorefactoring tools, ...), I'd imagine it would be useful if bcc could work but in some sort of "realtime mode", allowing it to run in parallel with an IDE or other tools and exchange information. I'm thinking an IDE could send it messages whenever the user makes a change to the code, then bcc would recompile the affected piece of code and respond with an updated syntax tree, scope/identifier dictionary, error list etc. This would probably require very major changes to bcc though...

[GWRon]

@HurryStarfish BCC functionality should then be transformed into a kind of library. The new BCC would wrap around that functionality. So some kind of "API". Every third party library would mean to update the tools each time you update language features - but you have to write two different implementations (bcc + 3rd party tool) compared to just recompile the tools.

Of course we could do as you suggested too - making bcc act as API too - so you can request information about a sourcecode you "compile".

On the other hand using a 3rd party lib allows to shape of a lot of work which else needs to be done. Syntax checks could be offloaded to the IDE (language plugin to intellij or so).

[HurryStarfish]

I'd imagine that, ideally, the compilation process would be divided into cleanly separated steps (lexing -> parsing -> resolving imports -> semantic analysis -> generation), each with its own API for other programs to hook into. Possibly even as separate programs. To compile a full program, they would then be chained together, instead of feeding the files into a single program that does everything like it currently does. This is just me throwing around ideas though, to actually implement something like this, it would be a good idea to study existing software that does this kind of thing (like Roslyn?) Either way, it would require a major rewrite of bcc...

[woollybah]

The lexer could then also be used to generate the documentation - assuming it also collected bbdoc comments.

And on the assumption we had an AST with docs, it wouldn't be a giant step to use that data directly in context - from whatever tools wanted it.

[HurryStarfish]

It would also pave the way for various very useful IDE functionality: autocomplete, find references, jump to definition, show errors "in realtime" as you type, auto-refactoring (renaming identifiers, formatting etc.)

[woollybah]

Here's another one

If Not classDecl.attrs & CLASS_INTERFACE Then

which should be

If Not (classDecl.attrs & CLASS_INTERFACE) Then

One day the compiler will ask me if I really know what I'm doing...

[GWRon]

Next is

Bmk createapp "weather forecast"

:-)

[DivineDominion]

The proposition by @HurryStarfish reminds me of Apple's SourceKit. You can use it to parse (Swift) source code and get an AST and remote-control code from the IDE. This is also used by SwiftLint to get information about the code's structure. Xcode has a parallel SourceKit process running to perform syntax highlighting. So that'd be one example where this approach is used :)

[dmaz]

am I missing something... blide ran bcc in the background to give this I thought...