[Suggestion:] 某库文件被任意文件n引用后，不存在的变量n的警告消失

[PythonYunfei]

某库文件被任意文件n引用后，不存在的变量n的警告消失。

一个库文件是可以被无数文件引用的。 理论上，只要Library.ahk被引用的次数足够多，那么这个Library.ahk文件中，所有不存在的变量名的警告都将全部消失。 这样一来，任何变量名在Library.ahk中写错了，都不再显示警告。因为有足够多的引用这个“库”的文件，定义了正好重名的全局变量。
显然，这不符合本意。

所以希望：所有变量未定义的警告都在当前文件中正常显示。文件A的警告不该因为 “被谁引用了” 而消失；警告只会因为文件A “引用了谁” 而消失。

[PythonYunfei]

Translate:

When "some library file" is referenced by "any file n", the warning of non-existent "variable n" disappears.

A "library file" can be referenced by countless files. Theoretically, as long as "Library.ahk" is referenced enough times, all warnings about non-existent variable names in this "Library.ahk" file will completely disappear. As a result, any incorrectly written variable names in "Library.ahk" no longer show warnings. This is because there are enough files referencing this "library" that define global variables with exactly the same names.
Obviously, this is not what was intended.

Therefore, it is hoped that: all undefined variable warnings should display normally in the current file. The warnings in "File A" should not disappear because it was referenced by others; warnings should only disappear because "File A" referenced others.

[RaptorX]

The warnings in "File A" should not disappear because it was referenced by others; warnings should only disappear because "File A" referenced others.

Totally agree. The fact that the error is repeated many times doesn't mean it is right.

[thqby]

In this case, more #includes are needed to suppress warnings. Warning errors like #643 will also be eliminated.

What about features such as parameter prompting and completion? Is that the same?

[RaptorX]

What about features such as parameter prompting and completion? Is that the same?

I think thats a different thing.

Autohotkey will execute lines in Library.ahk first, and then will perform the assignment in line 335 of test11.ahk.
For that reason we need the warning in Library.ahk because it WILL be a warning/error when we execute the script.

Parameter prompting and completion are unrelated to the order in which the files are read I guess.

I think the issue here is this, the parser should start on the root folder and go in the same order as the script is loading the files and marking warning/errors in that same order. At least it should try and mimic what the autohotkey parser is doing and mark the errors in that same order.

[thqby]

Autohotkey will execute lines in Library.ahk first, and then will perform the assignment in line 335 of test11.ahk.
For that reason we need the warning in Library.ahk because it WILL be a warning/error when we execute the script.

Executing this file first does not mean that these unassigned variables are accessed first. It is also unreliable to mark warnings in order.

At least it should try and mimic what the autohotkey parser is doing and mark the errors in that same order.

This only affects where the warning appears, not whether the warning appears. When ahk is loaded, you will not get different warnings in different order.

[RaptorX]

This only affects where the warning appears, not whether the warning appears.

Sorry then my comments are not helpful, I thought he said:

All warnings about non-existent variable names in this "Library.ahk" file will completely disappear.
Note: Emphasis added.

I took that to meant that they were gone completely. Are you saying the warning is still present but on a different spot?
Because if thats the case the Problems view is the one that will show the warning then.

[thqby]

Under normal circumstances, the warning of the extension tag should be consistent with ahk, because the recognition order of the extension and the loading order of ahk may be different, resulting in different tag positions.

[thqby]

After realizing module parsing, using module grammar can solve this issue.

[PythonYunfei]

This only affects where the warning appears, not whether the warning appears.

Sorry then my comments are not helpful, I thought he said:

All warnings about non-existent variable names in this "Library.ahk" file will completely disappear.
Note: Emphasis added.

I took that to meant that they were gone completely. Are you saying the warning is still present but on a different spot? Because if thats the case the Problems view is the one that will show the warning then.

You don't mistake. What I am speaking of, is surely whether to show warnings. I had initially expected it to show warnings, but nothing at all if the file has been included by another file.

[PythonYunfei]

另外建议：
如果一个变量未定义，则希望它后面所有出现的位置（在它后续被赋值的位置之前），都显示警告。