Tatakinov / yayalint

a linter of YAYA
MIT License
5 stars 0 forks source link

bunch of error messages that might help #2

Closed steve02081504 closed 2 years ago

steve02081504 commented 2 years ago

Uh, this bunch of error messages is caused by me using yayalint like this:

C:\Users\steve02081504\Desktop\temp\yayalint\yayalint.bat E:\ssp\ghost\Taromati2\ghost\master\shiori\aya.txt

I'm not sure if I'm using it right, but I think these are too many errors in report.

lint_with_taro.log

Some obvious possible changes you can do:

I'm not sure how much this error log tells us(After all, I know almost nothing about lua), but I thought it might give you some help! If you don't like this, feel free to close the issue

For testing purposes, you might consider clone Taromati2/ghost.

Tatakinov commented 2 years ago

I think that v1.2.0 has supported it to some extent.

It seems that one of the reasons for the long log is that the reference* is undefined. I think the reason is that yayalint cannot detect variable definitions by LETTONAME or EVAL.

However, due to my lack of programming skills, it is difficult to detect them.

steve02081504 commented 2 years ago

I think it's a bit too difficult to detect EVAL How about adding a regular expression filter just like the function?

Tatakinov commented 2 years ago

I was able to implement it maybe in v1.3.1, please try it out.

steve02081504 commented 2 years ago

Sorry, I've just been to two exams I added ^reference%d+$ to the list of predefined variables, but it seems that the error log is not reduced as expected Here is my configuration file & the output

Tatakinov commented 2 years ago

I'm sorry. There was a mistake in the program. It is probably fixed in v1.3.2.

steve02081504 commented 2 years ago

Thank you for all your hard work! I'm wondering if the filtering of functions uses the same logic as variables though, and only the variable part was changed in this revision?

Tatakinov commented 2 years ago

Yes, the variable part only. Are there any problems remaining?

steve02081504 commented 2 years ago

Yes, I've noticed that some functions are reported as errors even in the predefine or used list, such as IARRAY and some others.

nikolat commented 2 years ago

slight modification for yayalint It must be because it was recognized as a variable, not a function. I think function calls with no arguments should be written as IARRAY(), not IARRAY. That way, syntax highlighting works and is easier for us to understand.

steve02081504 commented 2 years ago

Oh I just noticed that these hints are talking about variables, sorry for the misstatement But I think not having to write call signs after functions is a special feature of yaya, and one that can sometimes make code more concise - even if the syntax is sometimes misleading. Although somewhat cumbersome, I wonder if lint could force any variable that hits the func.predefined rule to be treated as a function, and reorganise the function list after reading the full dic file contents to circumvent any function misclassification as a variable?

Tatakinov commented 2 years ago

maybe fixed in v1.3.6.

steve02081504 commented 2 years ago
attempt to index a nil value
stack traceback:
        [C]: in for iterator 'for iterator'
        ...ers\steve02081504\Desktop\temp\yayalint\user_defined.lua:241: in function 'user_defined.isUserDefinedFunction'
        [string "yayalint"]:753: in upvalue 'recursive'
        [string "yayalint"]:543: in upvalue 'recursive'
        [string "yayalint"]:849: in upvalue 'interpret'
        [string "yayalint"]:985: in local 'main'
        [string "yayalint"]:990: in local 'func'
        [string "yayalint"]:41: in main chunk
Press any key to continue . . .

This appeared when I was using the latest version of yayalint Hope this helps

Tatakinov commented 2 years ago

That error should not occur, so the configuration may be wrong. Is func.predefined missing?

Please use v1.3.7 or later, as another bug was found in v1.3.6.

steve02081504 commented 2 years ago

Oh sorry my life has been a bit chaotic lately, I have just made a mistakeπŸ˜‚

I wonder if lint could force any variable that hits the func.predefined rule to be treated as a function, and reorganise the function list after reading the full dic file contents to circumvent any function misclassification as a variable?

I'm still looking forward to future updates that will make it possible to recognise functions without the call sign!πŸ±β€πŸ Thanks for all this XD

Tatakinov commented 2 years ago

It is supported in v1.3.7 or later.

I'm sorry to have taken your time.

steve02081504 commented 2 years ago

Oh sorry I got it wrong again BTW, There are two small problems here:

syntax error:   ../dic\games\Gobang\Gobang.dic  before  line    970     col     9       data            elseif fight-defense>-8
syntax error:   ../dic\games\linkwnd.dic        before  line    2270    col     62      data            for _buff = FREAD(_mapfile);_buff != -1&& _buff !='';;_buff = FREAD(_mapfile){
Tatakinov commented 2 years ago
syntax error:   ../dic\games\linkwnd.dic        before  line    2270    col     62      data            for _buff = FREAD(_mapfile);_buff != -1&& _buff !='';;_buff = FREAD(_mapfile){

This is fixed in v1.3.9. However, Gobang.dic line 969

        k1=0.5f
              ^

It's odd to have f (is variable?) right after a number.

steve02081504 commented 2 years ago

Thanks for the info, I fixed it! I think it was a minor error on the part of whoever wrote the function, although I'm not sure why such code wouldn't cause yaya to report error.πŸ˜‚

steve02081504 commented 2 years ago

I still have some suggestions for information purposes:

Tatakinov commented 2 years ago

Provide a function to ignore unused functions and global variables in a specific dic or dicdir lint configuration files placed in the ghost directory

Maybe implemented in v1.4.1.

Warn about similar variable names

If there are few typos, you will usually get an unused or undefined warning. It is possible to output the correct variable name at that time.

If the lint always checks to see if the variable name is correct, it will be difficult to determine if the variable name is correct, especially if the name is short.

steve02081504 commented 2 years ago
[string "yayalint"]:747: attempt to concatenate a nil value (field 'col')
stack traceback:
        [string "yayalint"]:747: in upvalue 'recursive'
        [string "yayalint"]:854: in upvalue 'interpret'
        [string "yayalint"]:991: in local 'main'
        [string "yayalint"]:996: in local 'func'
        [string "yayalint"]:41: in main chunk
Press any key to continue . . .

Sorry, I've been on my way home for the past 2 days so I haven't had time to touch the computer After I updated yayalint to the latest version, I got this error This time I checked carefully and there should be no config error

Tatakinov commented 2 years ago

Sorry, it's my mistake. fixed in v1.5.2.

steve02081504 commented 2 years ago
_l="%(_lunar[0])εΉ΄%(_lunar[1])月%(_lunar[2])ζ—₯γ€€%(_lunar[7])\n%(_lunar[4])(%(_lunar[3]))εΉ΄ %(_lunar[5])月%(_lunar[6])\n%(_jieqi)%(_lunar[12])(%(_lunar[13])月%(_lunar[14])ζ—₯)\n%(_lunar[9])\n%(_lunar[10])"
if _i+1==_d
    _w+="\_l[%(_x-5),%(_y)][\q[%(_i+1),OnCalendar,%(_l),%(_year),%(_m),%(_i+1),##]]"
elseif _i+1==day && _m==month && _year==year
    _w+="\_l[%(_x),%(_y)]\f[color,110,110,110]\f[underline,1]\q[%(_i+1),OnCalendar,%(_l),%(_year),%(_m),%(_i+1),##]\f[default]\f[sup,1]β—€\f[default]"
elseif _lunar[17]==0 || _lunar[17]==6
    _w+="\f[color,255,0,0]\_l[%(_x),%(_y)]\q[%(_i+1),OnCalendar,%(_l),%(_year),%(_m),%(_i+1),##]\f[color,default]"
elseif _lunar[9] || _lunar[10]
    _w+="\f[color,110,110,110]\_l[%(_x),%(_y)]\q[%(_i+1),OnCalendar,%(_l),%(_year),%(_m),%(_i+1),##]\f[default]"
else
    _w+="\_l[%(_x),%(_y)]\q[%(_i+1),OnCalendar,%(_l),%(_year),%(_m),%(_i+1),##]"

I have this code where _l is only used in the %() formatting character in the string But it looks like lint doesn't detect this use and marks _l as an unused variable Could you please provide a fix for this problem?

Tatakinov commented 2 years ago

maybe fixed in v1.5.3.

steve02081504 commented 2 years ago

Thanks for your efforts! Basically there are ok now, if I find any new ones later I will open another issue