Stefan Glienke

What memory leak? That assert is telling you that CRYPTO_set_mem_functions returned 0

If with "you" you mean @Der schöne Günther then yes.

The compiler is responsible for writing typeInfo into the binary.

It seems indeed as if the TIntfFlag enum was never extended since Delphi6 (I think that was when interface RTTI was introduced) - I can confirm that at least since XE an interface type with $M+ gets a fourth flag (lets call it ifHasMethodInfo) set. If the type is an anonymous method type (see https://stackoverflow.com/q/49950534/587106) then there is a 7th enum value in the set. The situations where bit 5 and 6 are set are unknown to me. You might want to file an issue in QP about this. @Remy Lebeau Your diagnosis is still wrong - if the debugger shows then that means it has the 4th bit set. I can confirm my findings with this code: uses SysUtils, Rtti; type TIntfFlagEx = (ifHasGuid, ifDispInterface, ifDispatch, ifMethodInfo, ifUnknown, ifUnknown2, ifAnonymousMethod); TIntfFlagsEx = set of TIntfFlagEx; {$M+} IFoo = interface ['{35CFB4E2-4A13-48E9-8026-C1558001F4B7}'] procedure Main; end; {$M-} {$M+} IBar = interface(TProc) ['{AB2FEC1A-339F-4E58-B3DB-EC7B734F461B}'] end; {$M-} {$M+} TMyProc = reference to procedure; {$M-} procedure PrintIntf(typeInfo: Pointer); var context: TRttiContext; rttiInterface: TRttiInterfaceType; flags: TIntfFlagsEx; begin rttiInterface := context.GetType(typeInfo) as TRttiInterfaceType; flags := TIntfFlagsEx(rttiInterface.IntfFlags); Writeln(rttiInterface.Name, ' ', TValue.From(flags).ToString); end; begin PrintIntf(TypeInfo(IInterface)); PrintIntf(TypeInfo(IInvokable)); PrintIntf(TypeInfo(IFoo)); PrintIntf(TypeInfo(TProc)); PrintIntf(TypeInfo(TFunc<Integer>)); PrintIntf(TypeInfo(TMyProc)); PrintIntf(TypeInfo(IBar)); Readln; end. prints this: IInterface [ifHasGuid] IInvokable [ifMethodInfo] IFoo [ifHasGuid,ifMethodInfo] TProc [ifAnonymousMethod] TFunc<System.Integer> [ifAnonymousMethod] TMyProc [ifMethodInfo,ifAnonymousMethod] IBar [ifHasGuid,ifMethodInfo,ifAnonymousMethod]

The block will happen less than two months from now - read for yourself: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

Ah, I see now, they are all hidden in that innocently looking TestParse and TestEmit methods - was expecting to see them more fine grained :) I have some suggestions for some possible low level optimizations (for example eliminating some unnecessary code from function prologues and epilogues caused by usually not raised exceptions but the fact the exception creation code is directly coded into the methods (and in fact is repeated multiple times) - will file a PR.

Does it pass https://github.com/yaml/yaml-test-suite ?

function _GetMem(Size: NativeInt): Pointer; begin if Size <= 0 then Exit(nil); Result := MemoryManager.GetMem(Size); if Result = nil then Error(reOutOfMemory); end; function GetMemory(Size: NativeInt): Pointer; cdecl; begin Result := MemoryManager.GetMem(Size); end; Do you see the difference? Also GetMem is an intrinsic that maps to System._GetMem

DCC_MapFile=3 See BDS\bin\CodeGear.Delphi.Targets starting at around line 400

Writing entire words in uppercase (even more so if colored red) is considered shouting on the internet

That was my point - no need to shout.

What should it show? scnr 😉

uses Spring.VirtualClass; procedure NotifyFree(const Self: TObject); var freeInstance: TFreeInstance; begin freeInstance := GetClassData(Self.ClassParent).FreeInstance; Writeln('Object of class ', Self.ClassName, ' destroyed'); freeInstance(Self); end; var vc: TVirtualClasses; o: TObject; begin vc := TVirtualClasses.Create; try o := TObject.Create; try vc.Proxify(o); GetClassData(o.ClassType).FreeInstance := NotifyFree; finally o.Free; end; finally vc.Free; end; end.

I know the repositories get maintenance and update for new Delphi releases but I wonder if there is actually a release planned. Last JCL release is 2.7 from september 2015 which probably does not support any Delphi version after that - last JVCL release is 3.49 also from september 2015. Since then we are in limbo state working with some master state - this is kinda far from optimal.

Anonymous methods normally don't appear in the procedure list (which I don't mind - so even if you decide to list them in the future, please make that optional). However when you have a function/procedure does not have any arguments and you don't write () they appear in the list: procedure Main; var f: TFunc<Integer>; p: TProc; f2: TFunc<Integer,Integer>; p2: TProc<Integer>; begin f := function: Integer begin end; // appears as empty entry in procedure list f := function(): Integer begin end; // does not appear p := procedure begin end; // appears as "begin end" in procedure list p := procedure() begin end; // does not appear p2 := procedure(x: Integer) begin end; // does not appear f2 := function(x: Integer): Integer begin end; // does not appear end;

What does QP have to do with a GExperts bug?

Yes - all major versions can coexist

Well if you are working with ignoramuses you have to get the bigger guns out and install some commit hooks to prevent them from committing unresolved conflicts. Google will help you finding out how that works.

Slap your coworker because he obviously did not resolve a conflict and just commited this (this is git 101). This is how git annotates the code when there is a conflict and usually you then call git mergetool (or similar) or just use the resolve conflict button in whatever git ui client you are using. Remove lines 2, 4 and 6 and decide if you want to keep 3 or 5

There are no false positives to this - if FastMM reports this it's true. These errors are usually very subtle and the reference to that freed instance might only live a few cycles more and unless there does not happen another memory allocation that might reuse this particular piece of memory there will never be a defect (in terms of an AV happening or something) which is why this usually goes unnoticed by most until you enable this option which is not part of the build-in FastMM version (which is a shame!). It's unbelievable how ignorant some vendors can be...

Wrong: TypeInfo(SchemaTemplate) Right: TypeInfo(T); Also fwiw making the entire method generic although you only need the typeinfo of T supports code bloat - it would be better to make it non generic and a small generic overload that just passes down the typeinfo to the non generic one.

When you call that procedure while objects are allocated it will list them!

Make procedure FastMM4.CheckBlocksOnShutdown(ACheckForLeakedBlocks: Boolean); accessible in the interface section and simply call it.

Measure again with optimization on and stackframe off (release config) - I guess the overhead for the getter/setter calls will shrink.

When the method/routine being jumped to via procedure list is inside a collapsed region this region is not being expanded causing weird behavior. Same is the case for using "Previous/Next Identifier Reference" (Ctrl+Alt+Up/Down)