Ann: Deinline: a de-inline-var-alyzer

[LeP]

That requires a rename in the body too. Since I have depth and scope, that would be possible without large changes to the parser.

I think it's better to left an "error" (like double declaration), renaming a variable can interfere with others declared globally (only for visibility not in substance) or locally too.

[JuhaManninen]

That's a great idea. I think that once it can recognize variable types, it would be worth adding it to the "convert projects/packages from Delphi to Lazarus" tool.

Incidentally there is a new bug report for the Delphi converter caused by inline variables.
 https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/42225
Indeed this de-inline-var-alyzer would be a useful addition in the converter. Codetools only parses the code, does not change it, and it stops with the first error.
Ideally there would be an initial round for analyzing and maybe fixing inline vars in all units. The "normal" conversion would follow that if no manual changes are required.

[Thaddy]

I am making good progress by also parsing the presented code types inside the code presented. What I need to do now for being acceptable for codetools is also parsing used units AND include files recursively. That is a bit much, although I have already code for that.
What I have in practise is attached, but that is no release, although it performs much better. What I am working on in parsing code like this:

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

1. for var i = 0..9 do
2.   for var i := 'A' to 'Z' do
3.     for var i in Objectlist do

Which is something that delphi seems not to accept  but I need to de-duplicate / change the names to make it compilable without human intervention.
It should be:

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

1. for var i = 0..9 do
2.   for var i1 := 'A' to 'Z' do
3.     for var i2 in Objectlist do

Because that would solve the duplicate naming it now does, which needs intervention:

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

1. var i:integer;
2. i:char;
3. i:Tobjectlist

Into:

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

1. var i:integer;
2. i1:char;
3. i2:Tobjectlist;

That involves parsing and renaming, because that is how it looks now.
The code is very close, but not ready for codetools yet.

See attachment, please review:

[Thaddy]

Well, that is partially false alarm since Delphi won't accept this at all, so I am almost there:

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

1. //block scope
2. program Project16;
3. {$APPTYPE CONSOLE}
4. uses
5.   SysUtils, classes;
6.  
7. begin
8. for var i := 0 to 9 do // block 1
9. begin
10.   for var i := 'A' to 'Z' do // block 2
11.   begin
12.     for var i in Objectlist do; // block 3
13.   end;
14. end;
15. end.

Phiueeeew... That makes it way easier. Just a false alarm....

Code: Text  [Select][+][-]

1. [dcc32 Error] Project16.dpr(10): E2004 Identifier redeclared: 'i'
2. [dcc32 Error] Project16.dpr(12): E2004 Identifier redeclared: 'i'

I hate it when people put me on the wrong track and have untested expectations Thanks for that, but no thanks.
This also explains why the embarcadero public examples parsed correctly.

Unless there are real bugs, I just leave it alone.

@JuhaManninen
I would be pleased to turn it into a IDE plugin. This is near finished.

[440bx]

Well, that is partially false alarm since Delphi won't accept this at all, so I am almost there:

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

1. //block scope
2. program Project16;
3. {$APPTYPE CONSOLE}
4. uses
5.   SysUtils, classes;
6.  
7. begin
8.   for var i := 0 to 9 do // block 1
9.   begin
10.     for var i := 'A' to 'Z' do // block 2
11.     begin
12.       for var i in Objectlist do; // block 3
13.     end;
14.   end;
15. end.

Phiueeeew... That makes it way easier. Just a false alarm....

Code: Text  [Select][+][-]

1. [dcc32 Error] Project16.dpr(10): E2004 Identifier redeclared: 'i'
2. [dcc32 Error] Project16.dpr(12): E2004 Identifier redeclared: 'i'

Actually, it shouldn't complain about a redeclared identifier because if the "for" defines a scope then every instance of the inline variable "i" occurs in a different scope which means they mask/shadow the instances above them.

IOW, it's rather unclear what the defined scopes and their domains are in that example and, that is not good.  The boundaries of a scope should always be crystal clear.

[Thaddy]

@440bx

Again you did not test. (which worries me a bit, opinions are not facts)

I test against what Delphi does, because that is the guideline.
What you wish is not practise.
I am writing (actually wrote, it is finished apart from bug fixes) a practical solution to disinfect the code and make it FPC 3.2.2 and a current trunk (20260416) compatible.

For better or worse.

[LeP]

The logic of inline vars is simple: they cannot coesist in the sampe scope.
Local vars have full procedure / function / etc ... scope visibility. So none inline vars can have the same name as local vars.

The inline vars have visibility in a scoped block (I mean between "begin" and "end"), also if begin / end can be omited (like in a for with one line statement).
So every other inline vars inside that block (nested too) cannot have the same name.

It's so simple.

BTW: any begin / end block (unnecessary too) are a block scope and any var declared inside is ONLY valid inside that. And like local vars, inline vars can have the same name of global vars.

The "life" of those vars are different argument.

[440bx]

@440bx

I test against what Delphi does, because that is the guideline.
What you wish is not practise.

I did not test, I commented on what you posted, which I hope you copy/pasted correctly.

Here are some facts:

1. that you use Delphi as the guideline doesn't mean Delphi is doing it correctly.  Those are two unrelated facts.
2. As I stated in the previous post, Delphi shouldn't be complaining and, that's not opinion, that's a fact supported by theory.  Delphi is not making the index be in the scope of the "for", it is in some unknown scope, maybe function global ? no matter what, it's wrong!.  That's it.

Have you ever heard of variables masking/shadowing other variables ? ... apparently not.

[LeP]

Delphi is not making the index be in the scope of the "for", it is in some unknown scope, maybe function global ? no matter what, it's wrong!.  That's it.

????  The var inline defined as index in a for cycle has a "for block scope and nested too". That is the true. You can tell or doubt what you want about this but this is the rule (KNOWN, not an UNKNOWN).
You don't like it ? Simply don't use it.
And is good that @Thaddy made such utility, so everyone that doesn't want to use var inline is free to choose.

BTW: this is usefull also for Delphi users that don't like var inline.

[440bx]

The var inline defined as index in a for cycle has a "for block scope and nested too".

let's see ... draw the "for block scope", IOW, show its start and its end (NOTE: just in case, do NOT use begin/end statements as those are not part of a "for" statement.)

[LeP]

The var inline defined as index in a for cycle has a "for block scope and nested too".

let's see ... draw the "for block scope", IOW, show its start and its end (NOTE: just in case, do NOT use begin/end statements as those are not part of a "for" statement.)

You are serious ?
Do you think that a "for" without a begin / end extend its "influence" in the next one milion lines of code ? Or one milions row ?
Be serious, we all know a little bit of Pascal ... only a little bit but enough to understand what we are speaking.

But anyway, this is a reference for ... a for ...  : https://wiki.freepascal.org/For

[Thaddy]

I simply parse what Delphi does, empirically and by documentation and that is NOT what 440bx expected.

There are three caveats left:
- multiline strings, parses to char in multi-tick syntax, to todo with backtick syntax. But parses.
- reading used units in the type collector
- reading includes in the type collector
Frankly that is already a bit overkill except for triple/multi tick syntax.
Although it is possible and not difficult, only tedious.
Few tools support it.

[Thaddy]

I think it's better to left an "error" (like double declaration), renaming a variable can interfere with others declared globally (only for visibility not in substance) or locally too.

The Delphi compiler already throws an error since it is illegal syntax anyway.
But yes, I will throw a duplicate error in a future version.
That's three lines for the exception and a change from dupIgnore to dupError.
Delphi does not even allow duplicate names in nested blocks, it does not keep state. Names need to be unique on function/method/procedure/mainbody level. Whatever nesting takes place.

Side note: that is actually a bit disappointing from the Delphi developers, since that is not difficult: as you can see from my code where state is kept.
Anyway it makes the job easier.

[440bx]

The var inline defined as index in a for cycle has a "for block scope and nested too".

let's see ... draw the "for block scope", IOW, show its start and its end (NOTE: just in case, do NOT use begin/end statements as those are not part of a "for" statement.)

You are serious ?
Do you think that a "for" without a begin / end extend its "influence" in the next one milion lines of code ? Or one milions row ?
Be serious, we all know a little bit of Pascal ... only a little bit but enough to understand what we are speaking.

But anyway, this is a reference for ... a for ...  : https://wiki.freepascal.org/For

Yes, I'm very serious.  I asked you to draw the scope of the "for" statement because you've made it obvious you don't have a clue of what it is which is clearly demonstrated in your statements.

Let's try again... _draw_ the scope of a "for" statement... the beginning and end of its scope, can you do that ?

[LeP]

Side note: that is actually a bit disappointing from the Delphi developers, since that is not difficult: as you can see from my code where state is kept.

May be the var inline is what Delphi developers want.
Embarcadero's implementation may have been strongly requested by a good portion of the developers.
So it's likely that none of the Delphi developers are trying to "erase" the use of inline vars.
And besides, given their use in new projects or in revisiting old ones, I think this "innovation" has been well received.