LÖVE

Posted: **Mon Jan 11, 2021 9:27 pm**

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.

Posted: **Mon Jan 11, 2021 10:15 pm**

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.

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

Code: Select all

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

Posted: **Tue Jan 12, 2021 8:07 am**

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

Posted: **Tue Jan 12, 2021 11:57 am**

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.

Posted: **Tue Jan 12, 2021 12:33 pm**

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

Posted: **Tue Jan 12, 2021 4:00 pm**

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

Posted: **Wed Jan 13, 2021 4:26 am**

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

Posted: **Wed Jan 13, 2021 7:49 am**

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.

Posted: **Wed Jan 13, 2021 11:44 am**

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.

Posted: **Wed Jan 13, 2021 2:37 pm**

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.

LÖVE

SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA

Re: SUPER STRICT for LUA