Hi all,
So I tried to replace the "cnd.antlr" runtime with "antlr" runtime as
promised. This required removing some stuff in the grammars that is not
recognized with the plain antlr compiler.
The result of this exercise is that there're indeed differences with the
antlr runtime (see [1] for an excerpt) that will require us to fork
antlr. Inheritance alone is not enough to have the job done, internal
antlr classes have to be modified.
For example, the aptBitIntegerExpr.g grammar in cnd.apt builds a Parser
object
(https://github.com/apache/netbeans/blob/e6d890a5f0bfff8ccee7c3bb49a821fb5e875900/cnd/cnd.apt/src/org/netbeans/modules/cnd/apt/impl/support/aptBigIntegerExpr.g#L50)
and then uses a constructor that doesn't exist in antlr.LLkParser
(https://github.com/apache/netbeans/blob/e6d890a5f0bfff8ccee7c3bb49a821fb5e875900/cnd/cnd.apt/src/org/netbeans/modules/cnd/apt/impl/support/aptBigIntegerExpr.g#L69).
So forking antlr is inevitable (if anyone has another idea please speak
up).
The steps to fork antlr in the ASF would be, I think:
1. Forking antlr
As far as I understand it's possible to fork Antlr 2.7.7 even though
it's not an Apache License based project. The problem could be that
license is somewhat blurry, and we may bump into requests with ASF-Legal
to acknowledge the licese as category A.
(see
https://www.apache.org/foundation/license-faq.html#code-developed-elsewhere-received-under-a-category-a-license-incorporated-into-apache-projects-distributed-by-apache-and-licensed-to-downstream-users-under-its-original-license
)
2. Hosting the fork in ASF infra
In order to host a fork of antlr we should open a JIRA ticket (to legal?).
(see https://www.apache.org/foundation/license-faq.html#licenses )
3. Building the fork
Once the fork is under ASF Infra the idea would be to enhance
antlr.LLKParser and friends to try to reproduce the cnd.antlr runtime
behaviour. All of this without seeing what cnd.antlr runtime does (i.e.,
we won't copy and paste CDDL code). This, of course, would require
research and testing other modules.
4. Asking for permissions for the C++ grammar etc.
Once alternative runtime is compiling and running, it may be difficult
to incorporate the "public license" C++ parser grammar that was long ago
incorporated in NetBeans 8.2 code.
See
https://apache.org/legal/resolved.html#handling-public-domain-licensed-works
for details on incorporating public domains work in ASF projects.
5. Summary
After following all the steps above (correct me if I'm wrong) we'll end
up with a running alternative CND antlr runtime, and grammars that are
difficult to maintain and evolve, as we've discussed in other emails in
this thread.
After all this research I think we should start thinking of a new CND,
possibly based on the current CPPLITE branch, taking advantage of
whatever the donated CND offers us.
So, what say? Shall we open a vote to decide what to do? Any questions,
anyone? Any other ideas you may come up with?
Thanks,
Antonio
[1]
Some of the errors found when replacing the "cnd.antlr" runtime with the
"antlr" runtime, and then trying to compile the "cnd.apt" module.
Note that the generated parser "APTBigIntegerExprParser extends
antlr.LLKParser" behaves differently:
netbeans/cnd/cnd.apt/src/org/netbeans/modules/cnd/apt/impl/support/generated/APTBigIntegerExprParser.java:752:
error: cannot find symbol
r=r.mod(b);
^
symbol: variable b
location: class APTBigIntegerExprParser
netbeans/cnd/cnd.apt/src/org/netbeans/modules/cnd/apt/impl/support/generated/APTExprParser.java:48:
error: no suitable constructor found for LLkParser(TokenStream,int,int)
super(lexer, 1, 16);
constructor LLkParser.LLkParser(int) is not applicable
(actual and formal argument lists differ in length)
constructor LLkParser.LLkParser(ParserSharedInputState,int) is not
applicable
(actual and formal argument lists differ in length)
constructor LLkParser.LLkParser(TokenBuffer,int) is not applicable
(actual and formal argument lists differ in length)
constructor LLkParser.LLkParser(TokenStream,int) is not applicable
(actual and formal argument lists differ in length)
El 12/4/21 a las 22:51, antonio escribió:
[...]
So, to summarize: it may be possible to replace cnd.antlr with antlr, so
I think I'll explore this possibility. Will report here afterwards.
Kind regards,
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
