David Heffernan

Doesn't look like there is any code in this repo. I'm confused.

EnsureRange in the RTL, Math unit IIRC

Er, yes, I see it now!!

Obviously that cast is a bit pointless but it hardly matters

You can use the Delete function directly if you have a dynamic array. It may be easier to use TList<T> though. However you will need to handle the nested class instances. Probably the design of your record type is a bad choice because it makes the lifetime very hard to manage.

It's a bug and surely it's already reported. Have you searched QP yet? Obviously, if it is a bug, then you have to make that choice. I just did the search: https://quality.embarcadero.com/browse/RSP-21719 although I bet there are plenty of dupes

Well, you'll have to make a choice. Have the squiggles, and accept that they are wrong, or remove the squiggles. Your call.

Disable the IDE feature and rely on the compiler?

That's inevitable in a forum. If you want rigid enforcement of on topic discussion, this is definitely the wrong place. Did you submit a feature request? Without that I see little hope for this feature being implemented.

If you named your forms well, you'd be able to see from the name which one was the main form.

I'm curious though, why aren't you naming forms? Unit4 doesn't convey very much.

In English we use "you" and "one" interchangeably. I didn't mean you personally I meant that it could be done by someone. So it would have been clearer if I had said "one could do this".

"this" is the IDE enhancement you propose

Who ever works on a program without knowing what the main form is? I mean, you could do this but would it bring significant benefit? Would it make developers more productive? I can't see it.

Without knowing what types you are using we can only guess what you are doing.

More details please. What is the error? What is TArray? I expect that it is your own type because the type defined in the RTL of that name is not an array, it's just a collection of static methods.

Actually, I am probably misleading you here. OTL needs a message loop which isn't there. I'm sure you can run one but it doesn't come for free in a blank console app. Sorry!

FWIW, the repro could quite readily be expressed as a console app. It's worth learning how to do that because those apps are much simpler to share, being just a single file.

{$POINTERMATH ON} would be preferable, so avoiding the static array type

Calls to ExitProcess or TerminateProcess. My experience however is that guesswork is not much of a basic for solving problems. My experience is that debugging is way more effective. My advice is that you debug your problem. Cutting down to a minimal reproduction is one way to start doing that.

Those are reported as leaks for me. As I said, we need a minimal reproduction.

Leak reporting works fine. I guess your code doesn't have a leak. Throw in a call to GetMem and see how that goes.

Leak reporting works. If you want help, make a minimal reproduction, and post it here.

Nothing has gone wrong with FastMM and memory leak reporting works fine.

Works fine in any context. If you notice though, I supplied a complete program. You only supplied snippets, the latest of which does not compile. Perhaps if you want help finding the bug in your code you could supply a complete but minimal reproduction, just as I did. Then it would be simple for us to find the mistake.