CPPLite and Assembler

[Chris2011]

I know that it is up to me for what we will implement into NetBeans etc. etc. but still people who are already implementing stuff may have some ideas and "roadmap" in their mind. So my question, more or less to @vieiro is, is it planned to implement assembler support to cpplite or not? Afaik in the old CPP I could add a lot of exdcutables, also an assembler for this. Just a question whether antonio or anyone else have this in their ideas or not. Thx

[Chris2011]

Or maybe should this be a whole new project type? Independent from the CPPLite project?

[vieiro]

Hi @Chris2011 ,

AFAIK cpplite major use cases are for OpenJDK and GraalVM developers (internal Oracle Teams?) that use it for native debugging. I think @MartinBalin can shed some light on these use cases / future enhancements to cpplite.

[vieiro]

if I remember correctly, the CND branch was close to a useable state, it was just in conflict with CCPLite which was developed independently for a while. It is probably not easy to have them both available at the same time due to overlaps. most recent thread is here: https://lists.apache.org/thread/jkht80llstl3rndg1n8jtssyfhhz2myo

Yep, the CND branch works fine if:

• one disables the "cpplite" cluster.
• the ide/lsp.client needs some refactoring (uses different threads, should just use one per LSP server, has nothing to do with CND).

The CND branch does not support assembler, though (as clangd does not support it).

[Chris2011]

So not everything from cnd was donated? Because the old CND of course could handle assembler.

[vieiro]

So not everything from cnd was donated? Because the old CND of course could handle assembler.

Most of it was indeed donated (some parts weren't), but could not be integrated due to licensing issues/code provenance.

The lexer/parser/AST stuff in CND (for C, C++ and assembler) was not donated to the ASF. Possibly because it was based in a fork of Antlrv2, and Antlrv2 licensing is problematic (even for being used in Eclipse).

The plan was then to use a C/C++ LSP Server for Apache NetBeans instead of rebuilding all those lexers/parsers (C++ parsing is undecidable, after all ).

The NetBeans dev mailing list archive can be of help to clarify donation history.

[jlahoda]

if I remember correctly, the CND branch was close to a useable state, it was just in conflict with CCPLite which was developed independently for a while. It is probably not easy to have them both available at the same time due to overlaps. most recent thread is here: https://lists.apache.org/thread/jkht80llstl3rndg1n8jtssyfhhz2myo

Yep, the CND branch works fine if:

* one disables the "cpplite" cluster.

So, I wonder what is the clash with the cpplite cluster. When cpplite was added, it was specifically intended to do nearly nothing when (old) CND was installed. In particular:

• the MIME types are supposed to different (note the capital 'X'):
  

  netbeans/cpplite/cpplite.editor/src/org/netbeans/modules/cpplite/editor/file/MIMETypes.java

  Line 27 in 69fbded

  public static final String C = "text/X-c";

• the MIME resolvers should have positions after the CND resolvers:
  

  netbeans/cpplite/cpplite.editor/src/org/netbeans/modules/cpplite/editor/file/CDataObject.java

  Line 46 in 69fbded

  position = 1000000

hence CND should resolve files according to its MIME types, and MIME type-related functionality of cpplite should not be triggered for them. cpplite uses LSP to provide language features anyway, and I believe the new CND is doing the same. Once new CND is ready, I don't personally see a strong need to keep this part of cpplite. (At least as long as CND supports the ccls LSP server - I have much better experience with that compared to clangd.)

The cpplite project may not work well with CND editor, but that's not a big issue, and CND has its own. We could decide to keep or remove the project - it might be useful even outside of C/C++, because it provides a way to open "anything" as a project, althought that would require some tweaking. Just having a project type that is not used should not clash with anything? (For Java, we have many project types, and they tend to work together fairly well?)

For the cpplite debugger, I am not a really expert there, but not sure why debugger implementations should clash - if the CND project won't start the cpplite debugger, but will start its own, there should be no clash(?).

For the OpenJDK relation - it mostly uses cpplite as an C/C++ editor. If/when new CND provides that, it should be possible to simply use that, at least as long as the OpenJDK project can provide the configuration for the LSP server.

For assembler - a language support consists of at least three parts:
-the project, for which the existing CND and/or cpplite project should work (or could be adjusted to work), I think
-the debugger, for which the existing debuggers could and should be adjusted
-the editing support, for which an LSP server could presumably be used (with some minimal IDE bindings, like MIME resolver(s), DataObject(s), templates, etc.)

* the ide/lsp.client needs some refactoring (uses different threads, should just use one per LSP server, has nothing to do with CND).

The CND branch does not support assembler, though (as clangd does not support it).

[vieiro]

[...]
hence CND should resolve files according to its MIME types, and MIME type-related functionality of cpplite should not be triggered for them. cpplite uses LSP to provide language features anyway, and I believe the new CND is doing the same. Once new CND is ready, I don't personally see a strong need to keep this part of cpplite. (At least as long as CND supports the ccls LSP server - I have much better experience with that compared to clangd.)

When CND and cpplite coexist then CND does indeed take ownership of mime type related functionality.

The CND branch uses clangd (ccls could be added). I have the opposite experience with clangd (and clangd is supported by the LLVM team). Also clangd seems to permit UTF-8 offsets (LSP spec seems to mandate UTF-16 offsets, don't know how strict LSP servers are about that).

The cpplite project may not work well with CND editor, but that's not a big issue, and CND has its own. We could decide to keep or remove the project - it might be useful even outside of C/C++, because it provides a way to open "anything" as a project, althought that would require some tweaking. Just having a project type that is not used should not clash with anything? (For Java, we have many project types, and they tend to work together fairly well?)

It seems the cpplite project is being used by OpenJDK/GraalVM teams. Can't tell how exactly, though.

For the cpplite debugger, I am not a really expert there, but not sure why debugger implementations should clash - if the CND project won't start the cpplite debugger, but will start its own, there should be no clash(?).

Since CND takes ownership of mime-type related functionality you can only add CND breakpoints in the editor, and not cpplite breakpoints. As a consequence cpplite debugger doesn't work properly, because it knows nothing about CND breakpoints.

For the OpenJDK relation - it mostly uses cpplite as an C/C++ editor. If/when new CND provides that, it should be possible to simply use that, at least as long as the OpenJDK project can provide the configuration for the LSP server.

I don't know if CND can open the OpenJDK project. Currently CND generates compile_commands.json automatically from a NetBeans Makefile-based project structure. Can't tell what build system OpenJDK uses (ninja? cmake?). Maybe cpplite project support is required in these cases, after all.

For assembler - a language support consists of at least three parts: -the project, for which the existing CND and/or cpplite project should work (or could be adjusted to work), I think -the debugger, for which the existing debuggers could and should be adjusted -the editing support, for which an LSP server could presumably be used (with some minimal IDE bindings, like MIME resolver(s), DataObject(s), templates, etc.)

IIRC the donation included assembler grammars (in AntlrV2 format). Something similar to DisScanner.g and ATTScanner.g. If these were indeed donated then somebody could migrate them to AntlrV4 to add support for assembler.

AFAIK there's only an IBM LSP server for IBM assembler.

--

For the record, one of the modules that was not donated was cnd.antlr that included grammars for C/C++/assembler and a C preprocessor (including macro expansion). If the assembler support requires the C preprocessor (for macros, IFDEFs or whatever) then that's something to take into account too when adding support for assembler language.