Vincent Parrett

ok I'm blaming @Dalija Prasnikar for logging bugs on such esoteric code that no sane person would ever use

Logged as https://quality.embarcadero.com/browse/RSP-30073

Ok, so they are not managed records, the compiler is just broken.

My thoughts exactly.

No, that was the first thing I tried, get this error instead [dcc32 Error] MsgDemoMainForm.pas(62): E2512 Type parameter 'T' must be a non-nullable value type Which makes me suspect that record constraints are broken. My records have constructors, I'm guessing that now makes them managed records (I really haven't paid too much attention to how managed records work).

More on my issue, removing the record constraint does allow it compile, but removes some compile time type safety

10.4 Update 2 breaks code that compiled fine with update 1 and earlier This is the library that shows the problem https://github.com/VSoftTechnologies/VSoft.Messaging TChannelHelper = record public procedure PostMessage<T : record>(const message : T); end This is my message record type TGoodByeMessage = record MsgID : TMessageID; Filler : TMessageFiller; Name : string; public constructor Create(const theName : string); end; It failed here with [dcc32 Error] MsgDemoMainForm.pas(62): E2010 Incompatible types: 'T' and 'TGoodByeMessage' procedure TForm2.goodbyeButtonClick(Sender: TObject); var msg : TGoodByeMessage; begin msg := TGoodByeMessage.Create('world'); FChannel.Queue.PostMessage(msg); //<============ end; This looks like records are broken with this updates, why? I'm guessing this has something to do with managed records?

@pyscripter I didn't, I leveraged the work done by Jan Goyvaerts in TPerlRegex (System.RegularExpressionCore) which leveraged the work of others on PCRE imports (System.RegularExpressionsAPI)

This all seems like an over complication for little gain. Perhaps the OP could explain better what he is trying to achieve by this? As @David Heffernan said, this is worse than method overloading, and the need for that could be removed in many cases by allowing named parameter passing. IMHO, most uses of GetTypeKind in generic code is just making up for the lack of constraint types on delphi's generics.

Yes, that's what I'm doing, not before each form.. just before the first form (splash screen) is shown. I just don't do it in the dpr, since I need to check the user's config to see which theme is selected first. My dpr literally had 1 line (apart from uses etc) begin TIDEStartup.Run(); end. That does mean however that the Appearance node in the project options doesn't show - so I have to manually add the styles to a resource file - not a big deal though.

I do that (well not in the dpr, but before any forms are shown).

Styles cause all sorts of flicker problems - I'm pulling my hair out dealing with flicker that was introduced somewhere between XE7 and 10.4 (I'm upgrading from XE7) - really wishing I had never bothered with styles! FWIW, the IDE also has many flicker issues - the whole VCL/styles thing is a mess, but they can't be bothered to fix it because marketing can't put that "on the box"!

Is the source available somewhere?

I have GExperts (built from latest svn) and fix insight, seeing shutdown issues since installing fixinsight yesterday. Also seeing the occasional issue with GExperts.. but I'm going to blame the IDE because even without these two plugins, it's buggy as hell!

Unfortunately Resharper is a resource hog, and really slows down the IDE. I have not used Rider, but have used some of their other IDE's and found them quite strange to work in. We live in hope!

There's no doubt about that. I use VS a lot, and with CodeRush installed and navigating code is leaps and bounds ahead of delphi.

It works most of the time inside a single unit or even a single project. I wouldn't call a project group a special case though, anyone who works on a non trivial project would be using them.

Yes it could, but it would need to parse all the code.. which would reintroduce the overhead that the LSP is supposed to remove (high memory usage). Writing a complete, fast, memory efficient parser for the purposes of navigation is no trivial task.

I've already been over this with embarcadero people privately (look at the date, here's a clue, it's before the release date) and provided lsp logs etc. Ctrl+enter opens the file open dialog. So does right clicking and selecting Open file at cursor. So for me, 10.4 has completely broken code navigation... which makes it painfully slow to work in. To reproduce, create a project group with a package project, and an exe (that uses runtime packages) and references the package project. In a unit in the exe, add a unit from the package in your uses clause, then try ctr+click. My project as 100+ packages and a few exe projects.. it's not easy to work on with broken navigation.

https://quality.embarcadero.com/browse/RSP-28457 - opened on the 8th May.. read into that what you will.

Nope, not true. It completely fails when the identifier or type in is in another (referenced) project in the same project group. Makes working on a large project quite painful.

A quick look tells me there are other issues with TDirectory.GetFiles - no support for paths longer than MAX_PATH - which windows 10 1607 or later does support. You do have to enable it both on the system (reg key) and per process (manifest option) https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#enable-long-paths-in-windows-10-version-1607-and-later

Thanks for that info! I have been using TDirectory lately, but this thread spiked my interest in looking at how it's implemented.. creating a freeing a TMask for every file/directory is not very efficient.

We see a spike in traffic visiting this post on our site after every delphi release - how-to-fix-your-system-path-after-installing-delphi It's rather sad that it's the second most popular post on our blogs (after the DUnitX introduction post).

No memory leak, FTask is an interface reference. FreeAndNil should never have been called on it.