Lazarus Release Candidate 2 of 3.0

[n7800]

I don´t know why, but RC2 when I choose events onclick, onbefore[it],... sometimes (not all time) in uses interfaces section add units like DB, Grids, Forms... again! Not a probleam, just remove duplicates and will be OK for some time.
I think that is a parse problem, because I like to my 'use' like that (one per line):
uses
  Classes,
  SysUtils,
  Forms,
  Controls,
  Graphics,
  Dialogs,
  ExtCtrls,
  Buttons,
  ComCtrls,
  StdCtrls,
  DBGrids,
  DBCtrls,
  DBExtCtrls,
  ActnList,
  Variants,
  DB,
  ZDataset,
  ZAbstractRODataset,
  ZAbstractConnection,
  Grids,
  classe.nfe;

I build my lazarus from git.

It´s happens only with me, anyone?

Regarding re-adding units to the usage section, there are two issues that have already been closed:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40522
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40572

I just checked fixes_3_0 and there are no problems, even if I put the unit names on separate lines.

[Martin_fr]

I don´t know why, but RC2 when I choose events onclick, onbefore[it],... sometimes (not all time) in uses interfaces section add units like DB, Grids, Forms... again! Not a probleam, just remove duplicates and will be OK for some time.
I think that is a parse problem, because I like to my 'use' like that (one per line):
uses
  classe.nfe;

I build my lazarus from git.

Not my area of expertise, but I don't think line breaks are the issue.

Dotted unit names "casse.nfe" are a relatively new feature.... So could be (but don't know).

If it happens, please bug report and include the following info in your report:
1) Install the package "Cody" / it needs to be installed when the issue happens
2) When the issue happens, while the unit that has gotten the duplicates is the active tab, go to menu:
    View > Ide Internals > Show code tool node info
   And copy the info from all tabs in the window that opens.
 

If you are using 3.0RC2 with a version of FPC other than 3.2.2 then make sure to mention this.

Please note that the above collected info includes your sources.
You may therefore either want to supply it in a "private comment" to the bug report, if you do not want it to go public.

[d7_2_laz]

Martin, i'd noticed such frequently with the 3.0RC2 (and never before), but from some issue entries i thought that's already fixed. Wrong understood? I could provide a recent test project. Interested?

It has:

Code: Pascal  [Select][+][-]

1. uses
2.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ShellCtrls, ExtCtrls,
3.   StdCtrls,
4.   ComCtrls;  // TTreeNode

After adding an event "OnSelectItem" for a ShellListView i get:

Code: Pascal  [Select][+][-]

1. uses
2.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ShellCtrls, ExtCtrls,
3.   StdCtrls,
4.   ComCtrls, ComCtrls;  // TTreeNode

Easy to solve, but nevertheless it should be fixed with the final 3.0 imo.

Don't know nothing about "Cody". but i could provide the test project / test steps.
Happens with Win 10 64bit, Laz 3.0 RC2 with FPC 3.2.2.

I'm hesitant to open again an issue due to already existing and closed:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40572

[Bart]

@d7_2_laz: it doesn't do that with Lazarus main (Lazarus 3.99 (rev main_3_99-538-g7c055798ef) FPC 3.2.2 i386-win32-win32/win64).
Would you be able to bisect the guilty revision?

Bart

[d7_2_laz]

@Bart (thanks), of course; that's from the About box (if the info should be sufficient):
Lazarus 3.0RC2 (rev lazarus_3_0_RC2) FPC 3.2.2 x86_64-win64-win32/win64

(Have the 3.0 RC2 installed without having done any Lazarus source modifications.
My understanding so far had been that it is fixed within the fixes_3.0 branch, so foreseen (right??) for the final 3.0).

[Bart]

Better checkout the fixes branch then, to see if it really got fixed 

Bart

[Martin_fr]

Martin, i'd noticed such frequently with the 3.0RC2 (and never before), but from some issue entries i thought that's already fixed. Wrong understood?

I can confirm it can be reproduced in 3.0RC2 (or fixes branch) / but not main branch
- new app
- Add TShellListView on form
- add to end of uses
  StdCtrls,
  ComCtrls
- in OI double click the OnSelectItem to create the event

I don't know if/when I will be able to look deeper into it.

Even if there is investigation here on the forum, best is to create a new issue on it.  (Unless the old one was fixed recently and not merged => then merging it would likely fix it)


Above test had the 3.0rc  build with different settings than the trunk IDE => so the "not happen in trunk" may be due to build method, packages installed or fixes in codetools.

Noticeable the 3.0rc build is without Cody, while the trunk is with Cody.

[d7_2_laz]

Ok then, here:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40591

Q. about fixes_3.0 branch: will that be merged within the final 3.0 (then i would wait), or does it run in parallel for a subsequent release?
Sorry for ignorance - it's self-evident for you, but i simply don't know that  ...

[Martin_fr]

Q. about fixes_3.0 branch: will that be merged within the final 3.0 (then i would wait), or does it run in parallel for a subsequent release?

The 3.0 release will be a point on the fixes-3_0 branch.

Fixes for the 3.0 release will be merged to the fixes-3_0 branch, then the release will be made from that branch.
After that, more fixes will be merged to the fixes-3_0 branch, and eventually a fixes release 3.2 will be made (and maybe a 3.4 and so on).

Eventually 4.0 will be released, and that will be a new branch fixes-4_0 wich will be branched of the main branch in the future.


Versions 3.1 and 3.3 and so on will be used to mark the unreleased commits on the fixes-3_0 branch. E.g after 3.0 the branch will have 3.1. Then after 3.2 the branch will have 3.3.
The odd numbers on the 2nd place are non-releases, and span many commits.

[d7_2_laz]

Thank you Martin for taking you the time to clarify!   

[n7800]

Even if there is investigation here on the forum, best is to create a new issue on it.  (Unless the old one was fixed recently and not merged => then merging it would likely fix it)

Ok then, here:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40591

There is no need to create a new issue if one already exists. You can simply reopen it, or even write a message to closed ones. Currently there are 3 identical issues on the bug tracker.

[n7800]

I can confirm it can be reproduced in 3.0RC2 (or fixes branch) / but not main branch
- new app
- Add TShellListView on form
- add to end of uses
  StdCtrls,
  ComCtrls
- in OI double click the OnSelectItem to create the event

Sorry, but are you sure you checked the fixes branch? I checked the branch again (d0513b23) by repeating the steps you provided and everything is fine. I used "make clean all" and even tried installing the "cody" package - no errors.

I also don’t see the revision (commit) in the d7_2_laz version information:

@Bart (thanks), of course; that's from the About box (if the info should be sufficient):
Lazarus 3.0RC2 (rev lazarus_3_0_RC2) FPC 3.2.2 x86_64-win64-win32/win64

My version of the fixed branch, compiled from git, looks like this:
Lazarus 3.0RC2 (rev lazarus_3_0_RC2-56-gd0513b237e) FPC 3.2.2 i386-win32-win32/win64

It looks very likely that this is just RC2 (without fixes) obtained through the installer.

[Martin_fr]

Yes, using the fixes branch. And I thought I had rebuild it, too (the file date shows that I did rebuild, and the git is regularly updated by script).

However I made a "clean build" now, and it no longer happens.

The weird thing is, that now even yesterdays exe works fine.

[xinjl93]

(*) The only thing i saw at one of my apps:
When doing "Start" (green arrow icon), after compile & link, there is no error message, but the project's executable won't start.
- When i now start the executable from outside the IDE (via double click in win explorer), i will be thrown within the IDE again
- When having closed the IDE and start the generated exe, it will start regularly and correctly
Compile mode is "Default". Install is a secondary install. Config dir is within the RC2 folder.
Where does this might point to? Never saw such.

Retried with RC1: behaves as expected.

Also I met this problem yesterday. But after I copy all file to a new dir, it works right. I think maybe it is someting about "access right" from windows system. Some action changed the original dir access right. I guess.

[AlexTP]

I found major regression in 3.0 (it is even in fixes_3_0).
Please don't release Lazarus yet.
https://github.com/Alexey-T/CudaText/issues/5265

I will try to make the small demo.

EDITED
bug was reported, solved and merged to fixes_3_0.