Weirdest Error resolution ever! lazarus / 9-Editor ---------------------------------------------------------------------- EganSolo · 2025-07-30 00:01 I must not understand unit references properly. Take a look at Unit1 and Unit2 below: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unit Unit1;uses Unit2;Type  TMyDM = class(TDataModule)  //published stuff as usual  private     fWidget : TWidget;     procedure SetWidget(const Value: TWidget); public    property ActiveWidget : TWidget read fWidget write SetWidget; end;Implementationuses UnitB;//implementation code here.end.var dm : TMyDM;  Then Unit2 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unit Unit2;Type  TWidget = class  //class declarations  public    Procedure SetAsActiveWidget;  end;Implementationuses Unit1; procedure TWidget.SetAsActiveWidget;begin  dm.ActiveWidget := Self;end; end.  It's the classic cyclical dependency mediated by use clauses in the declarative and implementation sections of each unit. Recently, I've introduced some changes and was stumped when the compiler returned the following error while compiling unit 2: Identifier idents no member: "ActiveWidget" Suddenly, the compiler could no longer see ActiveWidget in the scope of its compilation. I found this odd, as I had assumed the compiler would compile the definition sections of all units before moving on to the implementation side, but I may be mistaken. Anyway, here's what blew me away: I moved the declaration of ActiveWidget in Unit1 to the top of TMyDM as follows: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unit Unit1;uses Unit2;Type  TMyDM = class(TDataModule)  private     fWidget : TWidget;     procedure SetWidget(const Value: TWidget); public    property ActiveWidget : TWidget read fWidget write SetWidget; published  //published stuff as usual end;Implementationuses UnitB;//implementation code here.end.var dm : TMyDM;  The program compiled without a hitch ... Thought? ---------------------------------------------------------------------- cdbc · 2025-07-30 03:47 Hi Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Implementationuses UnitB;//implementation code here.end. //<-- END OF UNITvar dm : TMyDM; //<-- WHAT THE H***?!? What's that 'var' declaration doing AFTER unit-end?!?!?!? /bc ---------------------------------------------------------------------- Thaddy · 2025-07-30 03:54 Indeed. var dm : TMyDM;  Is should be or is ignored and will give a warning? Any code after the end dot should not be compiled at all. Otherwise is see no strange things. (Apart from dm not being created in these units.) ---------------------------------------------------------------------- WooBean · 2025-07-30 05:40 It would be much productive to present a real project. Now we are invited to guess which changes were introduced during publishing a code essay rather than a code. ---------------------------------------------------------------------- Thaddy · 2025-07-30 07:32 Good observation. The uses clauses are also incomplete, so even if you write an example program unit it will not compile in any case. ---------------------------------------------------------------------- n7800 · 2025-07-30 12:11 I've stepped on the "end." error a couple of times. And recently fixed the same one in Lazarus. The projects had a whole copy of the program block! I don't think the developers will agree to throw an error, since it may affect compatibility (though personally I don't mind). For example, here is an interesting exploitation of this "hack". But I'm sure they will agree to add a warning message. I'll create an issue in FPC today, using this topic as another argument. I'll also create another bug report in Lazarus, since syntax highlighting shouldn't colorize code after "end." as if it were valid. ---------------------------------------------------------------------- Thaddy · 2025-07-30 14:09 There should be a warning and there is AFAIK: "code after end. is ignored." If it isn't, it is a regression. That is - if that's the case - not a lazarus bug, but a compiler bug. ---------------------------------------------------------------------- n7800 · 2025-07-30 15:08 Quote from: Thaddy on July 30, 2025, 04:09:05 pmThere should be a warning and there is AFAIK: "code after end. is ignored." If it isn't, it is a regression. Compiling the test project does not show any messages (I copied the original messages from the IDE, not filtered). I searched for keywords ("ignor", "after") in the FPC (3.2.2 and trunk) message file, and did not find anything there. Maybe this warning exists in Delphi? Quote from: Thaddy on July 30, 2025, 04:09:05 pmThat is - if that's the case - not a lazarus bug, but a compiler bug. I know, about Lazarus, I was talking about the syntax highlighting issue, which should not highlight the code after "end.", since it is ignored by the compiler. This is a separate issue. ---------------------------------------------------------------------- EganSolo · 2025-07-31 03:15 My bad, the actual program is far more involved, and I tried to replicate it and failed. I should have compiled that example before posting it. Lesson learned. The issue was as I stated. It popped up in a program that I've compiled a few hundred times without a hitch. What's really weird, though, is that after the program compiled, I moved the property declaration back to its initial location and the program compiled without a hitch. I'll close this issue and hope not to have to open it again. It was weird ---------------------------------------------------------------------- n7800 · 2025-08-01 00:29 Quote from: EganSolo on July 31, 2025, 05:15:00 amI should have compiled that example before posting it. Lesson learned. Got it. We're all too lazy to test code before posting a comment, but it needs to be done )) But of course I still created bug reports if anyone is interested (#41352, #41783). Quote from: EganSolo on July 31, 2025, 05:15:00 amThe issue was as I stated. It popped up in a program that I've compiled a few hundred times without a hitch. What's really weird, though, is that after the program compiled, I moved the property declaration back to its initial location and the program compiled without a hitch. In fact, creating circular dependencies is always a dead end. And creating mutual dependencies is especially bad. As far as I know, rebuilding can have problems in such cases, so try a clean build. To do this, call "Menu > Run > Clean up and Build". Mark the project files, packages are optional (although it wouldn't hurt).