## SUPER STRICT for LUA

pgimeno
Party member
Posts: 2575
Joined: Sun Oct 18, 2015 2:58 pm

### Re: SUPER STRICT for LUA

ivan wrote: Mon Jan 11, 2021 6:32 pm I have changed the following patterns:

Code: Select all

hexp = "0x%x+[Pp][%-%+]?%x"
float = "%d*%.%d+[Ii]?"
The x can also be upper and lower case (same as in integers, by the way). The exponent can only be decimal digits. The pattern does not support decimal point in the mantissa, or more than one digit in the exponent.

You can use this pattern:

Code: Select all

hexp = "0[Xx]%x-%.?%x-[Pp][%-%+]?%d+"

It will accept invalid numbers like 0xp3 or 0x.p3, but it's not up to this kind of library to report syntax errors, so I guess it's OK. If you still want it to err for invalid cases, it can be properly processed with two patterns:

Code: Select all

hexp1 = "0[Xx]%x+%.?[Pp][%-%+]?%d+"  -- mantissa without decimals, point optional
hexp2 = "0[Xx]%x-%.%x+[Pp][%-%+]?%d+"  -- mantissa with decimals, point mandatory

All patterns untested.
grump
Party member
Posts: 710
Joined: Sat Jul 22, 2017 7:43 pm

### Re: SUPER STRICT for LUA

ivan wrote: Mon Jan 11, 2021 9:01 pm
I tried using it with a larger project, but it really doesn't like C modules. And C modules exporting globals is probably double the trouble.
I'll make if work if you show me a concrete example.
I recall you being a Windows guy, so I hope this will suffice because I couldn't test it in Windows. Don't run the zip, extract it first. It will fail when sstrict.lua is used, but work fine without it.

The "globals exported by C module" issue is not demonstrated by this, I don't have a lib ready that actually does that.

Code: Select all

require('sstrict')
require('love.image')
local bit = require('bit')

Attachments
sstrictcmod.zip
ivan
Party member
Posts: 1719
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

### Re: SUPER STRICT for LUA

Thanks so much for the feedback everybody, I have pushed an update featuring the following changes:
1.added the new patterns by pgimeno (thanks!)
2.binary files are skipped (as requested by grump)
3.dofile support (this will need testing)
Note that [[double brackets]] can have any number of [===]equal signs[===] inside them
This turns out to be a difficult issue. I don't know if we can catch these cases using pattern matching.
The parser can now handle up to 3 equal signs but we will need a better solution in the long term.

PS. SUPERSTRICT now detects empty code blocks such as:

Code: Select all

local function oops()
-- empty
end
local list = {1,2,3}
for _ in ipairs(list) do
-- empty
end
pgimeno
Party member
Posts: 2575
Joined: Sun Oct 18, 2015 2:58 pm

### Re: SUPER STRICT for LUA

ivan wrote: Tue Jan 12, 2021 8:07 am This turns out to be a difficult issue. I don't know if we can catch these cases using pattern matching.
The parser can now handle up to 3 equal signs but we will need a better solution in the long term.
They need special separate treatment. For example:

Code: Select all

  local startstring, laststart = script:find("^%[=*%[")
if startstring then
local nequals = laststart - startstring - 1
local endstring = script:find("%]" .. ("="):rep(nequals) .. "%]")
if endstring then
return script:sub(1, endstring + nequals + 1)
else
error("String or comment not properly closed")
end
end

(untested)

I abuse that Lua feature sometimes, and I'm probably not alone, e.g. https://love2d.org/forums/viewtopic.php ... 61#p234861

By the way, it still does not accept integer hex numbers with an uppercase X, like this: VAR = 0X2 or VAR = 0X2ULL

Edit: This isn't correctly processed:

Code: Select all

print("a\"b")


Code: Select all

luajit: ./sstrict.lua:179:
./test.lua:2: undefined variable 'a'

And Lua patterns aren't powerful enough to properly parse it, so quoted strings also need special treatment.

I think in the end grump is right, it's a can of worms.
Last edited by pgimeno on Wed Jan 13, 2021 1:22 pm, edited 1 time in total.
ivan
Party member
Posts: 1719
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

### Re: SUPER STRICT for LUA

Hey, I have just pushed a fix for the uppercase issue.

Also I have made SUPERSTRICT less verbose now.
Certain empty blocks are reported:

Code: Select all

local function boo(a, b)
-- empty code block error
end
for i = 1, 100 do
-- empty code block error
end
Others are allowed:

Code: Select all

local obj = {}
function obj:baz()
-- allowed because it's inside an object
end
while myFunc() do
-- allowed because of the call to myFunc()
end
When dealing with lists of variables, an error is reported ONLY if the entire list of variables is unused:

Code: Select all

local function getHeight()
local w, h = love.graphics.getDimensions()
return -- error because both w and h are unused
end
No error because one of the variables in the list (h) is used:

Code: Select all

local function getHeight()
local w, h = love.graphics.getDimensions()
return h -- w is unused but it's ok
end
ivan
Party member
Posts: 1719
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

### Re: SUPER STRICT for LUA

SUPERSRTICT now finds too many values on the right-hand side during assignment.

Code: Select all

local a = 1, 2 -- too many values in assignment
zorg
Party member
Posts: 3077
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: SUPER STRICT for LUA

ivan wrote: Tue Jan 12, 2021 12:33 pm Others are allowed:

Code: Select all

local obj = {}
function obj:baz()
-- allowed because it's inside an object
end
while myFunc() do
-- allowed because of the call to myFunc()
end
since : is just syntax sugar, are empty functions of this form allowed or not? i'd assume they are since they're in a table as well, due to the .

Code: Select all

function obj.baz(self_but_not_necessarily_called_self_specifically, other_params_or_maybe_not)
-- ?
end

Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
ivan
Party member
Posts: 1719
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

### Re: SUPER STRICT for LUA

Hey zorg. Thank you for taking a look!
Looking at the code I see that function() obj.baz end would raise an error.
The reason why I allowed function() obj:baz() end was because of inheritance where somebody could override the empty function.
After some additional thought, I realize that maybe this should be disallowed too.
It's not good design to have empty functions I think.
I'm not 100% sure so this question is open to debate.
grump
Party member
Posts: 710
Joined: Sat Jul 22, 2017 7:43 pm

### Re: SUPER STRICT for LUA

ivan wrote: Wed Jan 13, 2021 7:49 am It's not good design to have empty functions I think.
I'm not 100% sure so this question is open to debate.
I think you're getting a tiny bit overzealous there. An empty function doesn't happen by accident, and treating it like a bug is going one step too far.
ivan
Party member
Posts: 1719
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

### Re: SUPER STRICT for LUA

grump wrote: Wed Jan 13, 2021 11:44 am I think you're getting a tiny bit overzealous there. An empty function doesn't happen by accident, and treating it like a bug is going one step too far.
Hehe, yea you're probably right.

### Who is online

Users browsing this forum: No registered users and 9 guests