Am Mo., 26. Nov. 2018, 12:14 hat Ryan Joseph <r...@thealchemistguild.com> geschrieben:
> > > > On Nov 26, 2018, at 5:16 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Am Mo., 26. Nov. 2018, 10:46 hat Ryan Joseph <r...@thealchemistguild.com> > geschrieben: > > > > > > > On Nov 26, 2018, at 12:09 AM, Sven Barth via fpc-pascal < > fpc-pascal@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
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
