<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr">Am Mo., 26. Nov. 2018, 15:47 hat Ryan Joseph <<a href="mailto:ryan@thealchemistguild.com">ryan@thealchemistguild.com</a>> geschrieben:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Nov 26, 2018, at 8:18 PM, Sven Barth via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank" rel="noreferrer">fpc-pascal@lists.freepascal.org</a>> wrote:<br>
> <br>
> You don't need to manually check for U. The parser will find U in the symbol table of the TMyClass generic and then a list containing the parameters will be generated and passed to parse_generic_specialization_type_internal. Though we'll probably either have to adjust the type of the paradeflist to carry the type/constant sym instead of the Def or an additional list that contains the constant symbols (plus NILs for the type ones). <br>
> I currently favor the first one, which will mean a few more adjustments inside pgenutil when parsing specialization parameters.<br>
<br>
I get a "class type expected, but got "<erroneous type>”” on the “U” in the nested specialization so I assumed this was because the hidden constant “U” was getting parsed instead of the generic param type “U”. I need to look at this more closely tomorrow because I don’t really understand what’s happening to be honest.<br></blockquote></div><div dir="auto"><br></div><div dir="auto">Best check again once you've done the switch to tconstsym for constants. :) </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>