[fpc-pascal] Constants in generics

[Sven Barth]

Am Mo., 26. Nov. 2018, 12:14 hat Ryan Joseph <ryan at thealchemistguild.com>
geschrieben:

>
>
> > On Nov 26, 2018, at 5:16 PM, Sven Barth via fpc-pascal <
> fpc-pascal at lists.freepascal.org> wrote:
> >
> > Am Mo., 26. Nov. 2018, 10:46 hat Ryan Joseph <ryan at thealchemistguild.com>
> geschrieben:
> >
> >
> > > On Nov 26, 2018, at 12:09 AM, Sven Barth via fpc-pascal <
> fpc-pascal at lists.freepascal.org> wrote:
> > >
> > > - 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
> >
> > I’ll change the # prefix for const params but the unit prefix was not
> added by me. See the line:
> >
> > prettynamepart:=typeparam.resultdef.fullownerhierarchyname(true);
> >
> > in pgenutil.pas.
> >
> > 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.
>
> 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.
>

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.


> > 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.
> >
> > 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. :)
>
> Ok, I’ll make it happen if it’s important.
>
> >
> >
> > > - 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)
> >
> > 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.
> >
> > Maybe you can show a test case that is failing?
>
> 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.
>
> type
>         generic TMyClass<T, const U> = class (specialize IMyInterface<T,
> U>)
>                 type
>                         THelperType = specialize THelper<T, U>;
>                 public
>                         helper: THelperType;
>                         procedure DoThis (value: T);
>         end;
>         TListClass = specialize TMyClass<integer,10>;
>

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).
I currently favor the first one, which will mean a few more adjustments
inside pgenutil when parsing specialization parameters.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20181126/096a9967/attachment.html>