Simon Sobisch

@brunopacheco1 if I understand correctly this issue is more about clang support (in this case you could also reproduce the issue on GNU/Linux and possibly wsl2 when self-building GnuCOBOL and...

That are no comment lines but instructions (ending up in the final binary) about the positions. I suggest to take the benefit of these (ideally the plugin never has to...

I'd but I've not dived into extension writing or even compiling yet, so you'd have to upload your vsix, possibly here. Theoretically we should be able to create a CI...

@cribetti I guess your issue is too about clang support, not about MacOS in general. Correct? In this case I still argue that @brunopacheco1 or @OlegKunitsyn may should change the...

Note: if you take the NIST-test sample given in the issue's start post and check that it works with containerized 3.1.1 then that's fine and I'd consider it worthy for...

We do see that all environments that are mentioned in this issue share the following; * Mac OS * used brew packages (I *think* those are binary packages, please correct...

What do you mean by "the GnuCOBOL part"?

ping @OlegKunitsyn

> Well, compiling gnucobol with gcc and running the debugger gives me exactly the same error message. You did recognize that it is just the gcc-frontend of clang, didn't you?...

> Note: 3.1+ has a quite different codegen, and if not explicit asked for also generated COBOL line comments (so GDB already does know which COBOL line it operates on)...