SUPER STRICT for LUA

[pgimeno]

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]

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.

Also, this should work in main thread and worker threads:

Code: Select all

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

[ivan]

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)
4.loadstring support

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]

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.

[ivan]

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

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]

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]

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

[ivan]

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]

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]

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.