issue #8495 Java: members entirely missing if generic parameter extends another generic #8534

Stewori · 2021-05-04T12:35:13Z

Proposed fix for #8495. See discussion therein.

The information of a class being static was not being processed as it was not stored with a class (contrary to e.g. abstract, but this is done through another mechanism).

Updating the xml xsd file was omitted

…r extends another generic

albert-github · 2021-05-04T12:44:18Z

src/doxygen.cpp

+    if ((root->lang==SrcLangExt_CSharp || root->lang==SrcLangExt_Java) && (i=fullName.find('<'))!=-1)
    {


Is this fix also valid for C# or are apply there different rules?

Honestly, I hoped you would know. I guess the findRev was there for a reason and this might require to be guarded as Java-only. What I am rather confident about is that this is the proper way to do it for Java. I can guard it if you think that's required.

Probably safest is to guard it (I'm not a C# expert either)

Unfortunately I am not much familiar with C#. I am aware that it has somewhat similar generics like Java but probably with some differences. I already suspected the issue might apply to C# as well but do not know for sure. The opinion of someone familiar with C# would be helpful. After a quick search it appears to me that it is not totally trivial to comprehend the full set of rules from C# documentation. (Edit: posted before I saw your answer.)

The latest standard,is to the best of my knowledge, ECMA-334, 5th Edition / December 2017. After this there are changes to the standard as Specification Proposals but they have not bee officially standardized (see e.g. https://en.wikipedia.org/wiki/C_Sharp_(programming_language)).

albert-github · 2021-05-04T12:45:52Z

src/defargs.l

+                                       }
+<ReadTypeConstraint>">"                {
+                                          if (yyextra->argSharpCount > 0)
+                                          {
+                                            yyextra->curTypeConstraint+=yytext;
+                                            --yyextra->argSharpCount;
+                                          }
+                                          else
+                                          {
+                                            unput(*yytext);
+                                            BEGIN(yyextra->lastExtendsContext);
+                                          }
+                                        }
+<ReadTypeConstraint>"<"                 {
+                                          yyextra->curTypeConstraint+=yytext;
+                                          ++yyextra->argSharpCount;


What happens when the user has an error in the number of < > pairs e.g. more > than < (not a valid program but still ...)?

What behavior would you recommend in this case? Note that the status quo is rather random behavior for examples described in the issue. I guess the behavior of doxygen on invalid programs is in general undefined. However I admit that we may come up with a friendly behavior for this particular type of syntax issue. E.g. raise a warning if a premature [(){}] is encountered (notice that the entrance to <ReadTypeConstraint> is already guarded as Java-only)?

Actually I'm a bit confused as I see that ReadTypeConstraint is entered as soon as the rule <ReadFuncArgType,ReadFuncArgPtr>"extends" is satisfied (for Java) and the count is increased as soon as < is seen and decreased when > is seen, but the count is at that moment still > 0 and when no , or ) is found the user remains in the ReadTypeConstraint and will leave it as soon as it sees a , or ) but what will happen when the user is in a < ..> part and sees a , or ) or is this not possible?

(for reference: discussion on this continued in #8495)

albert-github · 2021-05-04T12:47:09Z

src/defargs.l

@@ -471,6 +471,7 @@ CPPC  "/\/"
                                           {
                                             yyextra->curTypeConstraint.resize(0);
                                             yyextra->lastExtendsContext=YY_START;
+                                             assert(yyextra->argSharpCount == 0);


Not sure why an assert is necessary here? or does this have to do with my remark around the lines 503.? Wouldn't it be better to give a real doxygen warning?

I believe argSharpCount != 0 can never happen here. Just placed the assert to see whether it would go through the ci. The line can be removed.

…ng of nested commas in declarations of Java generics.

src/defargs.l

albert-github · 2021-05-06T09:36:34Z

src/defargs.l

+<ReadStringLiteral>"\\"                {
+                                          BEGIN(ReadEscape);
+                                       }


Why not combine this with the rule <ReadEscape>. to <ReadStringLiteral>"\\." (like it is also done for <CopyArgString> )?

Okay. Good idea.

I found the "\." slightly misleading for escape sequences because they can be longer than one character, e.g. for unicode \uXXXX. So I went with <ReadStringLiteral>"\\\"" which I think is more on spot for the purpose of that rule. Anyway, just a matter of taste I guess.

Probably yes, but I don't really see the problem with the \uXXXX as here the \\. rule would eat the \u and the normal . rule Xs. I think both solutions would be valid in this case.

Yes, sure both would work. That's why I wrote it's a matter of taste. I just found the \\\" rule more explicit for it's purpose.

albert-github · 2021-05-06T09:37:33Z

src/defargs.l

+<ReadAnnotation>"\""                   {
+                                          BEGIN(ReadStringLiteral);
+                                       }


Does for annotations also the single quote possibility exist?

No. The string literals in annotations are just usual Java string literals. Java only uses double quotes as string boundaries, much like C and friends do (and unlike Python does).

Oh sorry, I forgot there can also be character literals, which indeed use a single quote. However, there can only be one single character in between (or an escape sequence), so it should be sufficient to handle the rules <ReadAnnotation>"'('" and <ReadAnnotation>"')'", <ReadAnnotation>"'\"'" and probably also <ReadAnnotation>"'\\\"'". It should be possible to combine the first three into <ReadAnnotation>"'"[()\"]"'". I will add them soon.

Not sure but don't forget about the '\'' i.e. "the escaped single quote character literal".

I thought about that, but it should be covered by the general <ReadAnnotation>. rule. Since we do not enter a new state on ' (unlike we do for "), no extra care should be required to avoid premature return from such a state. The " must be considered to avoid entering <ReadStringLiteral> falsely, which cannot happen for '.

But couldn't in that case '"' be problematic?

That's covered by <ReadAnnotation>"'\"'". The overall rule I added just now is

<ReadAnnotation>"'"[()\"]"'"|"'\\\"'". It should catch the Java literals '(', ')', '"', '\"' and I confirmed this with some simple tests.

…gs.l.

…nd state ReadEscape in defargs.l.

…ate ReadAnnotation to defargs.l.

Feature/issue 8434

Issue 8434

asteele0 · 2022-03-11T00:13:04Z

@albert-github what ended up happening here? It looks like the PR was completed?
I'm also running into this issue, so it would be nice to have fixed.

albert-github and others added 4 commits March 17, 2021 13:12

issue doxygen#8434 Java: static classes not recognized as static

5eb5fce

The information of a class being static was not being processed as it was not stored with a class (contrary to e.g. abstract, but this is done through another mechanism).

issue doxygen#8434 Java: static classes not recognized as static

616e77a

Updating the xml xsd file was omitted

Merge branch 'master' into feature/issue_8434

d242d0b

issue doxygen#8495 Java: members entirely missing if generic paramete…

348bd84

…r extends another generic

albert-github added bug Java labels May 4, 2021

Stewori mentioned this pull request May 4, 2021

Java: members entirely missing if generic parameter extends another generic #8495

Open

albert-github reviewed May 4, 2021

View reviewed changes

Stewori marked this pull request as draft May 4, 2021 13:34

issue doxygen#8495: Implemented proper annotation handling and handli…

996b5e6

…ng of nested commas in declarations of Java generics.

Stewori marked this pull request as ready for review May 5, 2021 19:16

Stewori commented May 5, 2021

View reviewed changes

src/defargs.l Outdated Show resolved Hide resolved

albert-github reviewed May 6, 2021

View reviewed changes

Stewori added 2 commits May 6, 2021 12:20

issue doxygen#8495: Fixed alignment of lex declaration block in defar…

6d6df54

…gs.l.

issue doxygen#8495: Simplified annotation parsing and removed rules a…

1f54071

…nd state ReadEscape in defargs.l.

Stewori marked this pull request as draft May 8, 2021 10:27

issue doxygen#8495: Added proper handling of character literals in st…

60a3e7a

…ate ReadAnnotation to defargs.l.

Stewori marked this pull request as ready for review May 8, 2021 12:54

Stewori added 5 commits June 1, 2021 14:02

Merge branch 'doxygen:master' into issue_8495

16c3d91

Merge pull request #3 from albert-github/feature/issue_8434

affc57e

Feature/issue 8434

Restored compatibility of the changes with current master.

df3654f

Merge pull request #5 from Stewori/issue_8434

8613652

Issue 8434

Merge branch 'all_features_2021-11-02' into issue_8495

ccade5a

BramVerb mentioned this pull request Mar 8, 2023

Make all methods show in java API Z3Prover/z3#6626

Merged

		if ((root->lang==SrcLangExt_CSharp \|\| root->lang==SrcLangExt_Java) && (i=fullName.find('<'))!=-1)
		{

issue #8495 Java: members entirely missing if generic parameter extends another generic #8534

Are you sure you want to change the base?

issue #8495 Java: members entirely missing if generic parameter extends another generic #8534

Uh oh!

Conversation

Stewori commented May 4, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Stewori May 4, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

albert-github May 4, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Stewori May 4, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

albert-github May 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asteele0 commented Mar 11, 2022

Uh oh!

Uh oh!

Stewori May 4, 2021 •

edited

Loading

albert-github May 4, 2021 •

edited

Loading

Stewori May 4, 2021 •

edited

Loading

albert-github May 8, 2021 •

edited

Loading