<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">Am Mo., 26. Nov. 2018, 12:14 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 5:16 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>
> Am Mo., 26. Nov. 2018, 10:46 hat Ryan Joseph <<a href="mailto:ryan@thealchemistguild.com" target="_blank" rel="noreferrer">ryan@thealchemistguild.com</a>> geschrieben:<br>
> <br>
> <br>
> > On Nov 26, 2018, at 12:09 AM, 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>
> > - your pretty name is wrong; the pretty name for a specialization with constants should be "TSomeGeneric<TSomeType, 42>", not "TSomeGeneric<SomeUnit.TSomeType, System.LongInt#42>" as it would be now<br>
> <br>
> I’ll change the # prefix for const params but the unit prefix was not added by me. See the line:<br>
> <br>
> prettynamepart:=typeparam.resultdef.fullownerhierarchyname(true);<br>
> <br>
> in pgenutil.pas.<br>
> <br>
> Yes, but that is only because the code currently only handles types. For constants the addition of the type is not required, only the constant value. <br>
<br>
Then is it ok if type params have the unit prefix? Right now I’m doing TGeneric<Unit.Type,40> because the first param is a type so it uses the original code.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes. Type parameters have their full name so that one can differentiate between Unit1.TType and Unit2.TType or Unit1.TSomeClass.TType and Unit2.TSomeClass.TType in error messages.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Like you mention below if the const type was restricted in the definition then it would make sense to change these to tconstsym. I guess I need to try and see how much code this change blows up.<br>
> <br>
> Those assumptions will "simply" have to be checked/fixed. In the end we'll have cleaner code and thus it will be worth it. And with the help of the testsuite you can avoid regressions. :) <br>
<br>
Ok, I’ll make it happen if it’s important.<br>
<br>
> <br>
> <br>
> > - get rid of tscannerfile.parsing_generic_type; it's not only at the wrong location (the name "parsing_generic_type" should already tell you that it has no place inside the *scanner*), but it's also used to solve something in a completely wrong way: you must *not* use current_structdef for the generic parameters as the only valid parameter list inside parse_generic_specialization_types_internal *is* paradeflist and genericdef.genericparas. If there is still a problem then you need to handle that differently (Note: also don't Exit from parse_generic_specialization_type_internal, because the idea is that all incompatibilities are shown at once, so use Continue to check the next parameter)<br>
> <br>
> Yes, that was a hack to access current_structdef safely but I guess that’s not what I should be doing. Let me see if I can get that same information from the 2 params you mentioned.<br>
> <br>
> Maybe you can show a test case that is failing? <br>
<br>
This is why I wanted to access current_structdef. When "specialize IMyInterface<T, U>” was being parsed I need a way to refer back to the generic so I know what “U” is.<br>
<br>
type<br>
        generic TMyClass<T, const U> = class (specialize IMyInterface<T, U>)<br>
                type<br>
                        THelperType = specialize THelper<T, U>;<br>
                public<br>
                        helper: THelperType;<br>
                        procedure DoThis (value: T);<br>
        end;<br>
        TListClass = specialize TMyClass<integer,10>;<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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 <span style="font-family:sans-serif">parse_generic_specialization_t</span><span style="font-family:sans-serif">ype_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). </span></div><div dir="auto"><span style="font-family:sans-serif">I currently favor the first one, which will mean a few more adjustments inside pgenutil when parsing specialization parameters.</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">Regards, </span></div><div dir="auto"><span style="font-family:sans-serif">Sven </span></div></div>