Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?
Ryan Joseph via fpc-devel schrieb am Fr., 23. Apr. 2021, 00:53: > > > > On Apr 21, 2021, at 11:21 PM, Sven Barth > wrote: > > > > You need to use named types, though for operators this is less useful, > because the compiler will implicitly convert different ShortString types to > find a suitable operator overload: > > Then the compiler must do this for all strings types by default right? > For the compiler it's more often than not simply a stringdef with the string type set to st_shortstring. The length of that stringdef comes into play much less often. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?
> On Apr 21, 2021, at 11:21 PM, Sven Barth wrote: > > You need to use named types, though for operators this is less useful, > because the compiler will implicitly convert different ShortString types to > find a suitable operator overload: Then the compiler must do this for all strings types by default right? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit function specialization precedence
> On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote: > > Got this all integrated and put up the changes to > https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another > final review. :) The next thing to do now is to handle a memory leak. From the bug tracker: > You essentially need to make sure the symbols become part of the > specialization that is picked in the end (cause you create the symbols in > make_param_list only once, but you might use them for multiple generic > overloads of which at most one will be picked). > What you might be able to do is the following (have not looked at it in > detail yet): > - those symbols you directly add to genericparams you ensure that their owner > is the specialization right away (after generate_specialization_phase1) > - those symbols you add to callerparams you'll probably have to bubble up to > htypechk and have that somehow add these syms to the final specialization if > it is picked and free them otherwise My response: > I looked at this again and it looks like there is just one place where we can > leak memory now and that's those lines from create_unamed_typesym. > > newtype:=ctypesym.create(def.typename,def); > newtype.owner:=def.owner; > > I set the owner of the new typesym to the target def but what does that even > do? I think you're saying I need to set the owner of that symbol to be a > procdef but I don't see how the helps the memory get freed. I would think > when the specialization is freed we could check some flag in the generic > params and if they are not owned then we free them then. And with that I'm stuck. :) I don't know how the symbols in the compiler are memory managed but I don't see setting their owner is helping them get freed. I've tried setting their owner to the procdef.owner being specialized but that does't do anything either. I guess I don't understand what adding them to "the final specialization" means so please clarify. My naive assumption would be to add them to a list in tspecializationcontext and free them when the content is freed because I don't think the symbols are used after the implicit specialization is finished and a proc def is produced, but I may be wrong about that. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
