[ANN] Lua 5.5.0 (rc2) now available

[Luiz Henrique de Figueiredo]

Lua 5.5 is the next version of Lua.

Lua 5.5.0 (rc2) is now available for testing at
https://www.lua.org/work/lua-5.5.0-rc2.tar.gz

The SHA256 checksum is
50b24b8fce4644a4590af0f23c65945836161515b9e87c45ee1f0e62b0255a1d

The Git commit ID is
985ef32248f17ae4ca2d4e83e5e39e15393bb2f6

The main changes in Lua 5.5.0 are listed at
https://www.lua.org/work/doc/#changes

An updated reference manual is included and also available at
https://www.lua.org/work/doc

The complete diffs from rc1 to rc2 are available at
https://www.lua.org/work/diffs-lua-5.5.0-rc1-rc2.html
https://www.lua.org/work/diffu-lua-5.5.0-rc1-rc2.html

A test suite is available at
https://www.lua.org/work/lua-5.5.0-tests.tar.gz

All feedback welcome. Thanks.
--lhf

[Bas Groothedde]

Thank you,

The new flagging confuses me a bit, lobject.h:

/*

** Flags in Prototypes

*/

#define PF_VAHID  1  /* function has hidden vararg arguments */

#define PF_VATAB  2  /* function has vararg table */

#define PF_FIXED  4  /* prototype has parts in fixed memory */

In my testing I cannot quite figure out how to detect a named vararg argument that is not a vararg table.

Thanks,

~b

[Roberto Ierusalimschy]

> The new flagging confuses me a bit, lobject.h:
>
> /*
> ** Flags in Prototypes
> */
> #define PF_VAHID 1 /* function has hidden vararg arguments */
> #define PF_VATAB 2 /* function has vararg table */
> #define PF_FIXED 4 /* prototype has parts in fixed memory */
>
> In my testing I cannot quite figure out how to detect a named vararg
> argument that is not a vararg table.

function foo (n, ...t) return t[n] end

-- Roberto

[Rett Berg]

Can these two be elaborated on in the changes a bit more?

* declarations for global variables: does this mean I can say "global foo"? Is it just for documentation or does it affect anything?

* for-loop variables are read only: does this mean in "for k,v in pairs(t)" I can no longer do "k = 42"?

* major collections done incrementally: what does this mean?

Thanks,

Rett

[Rett Berg]

I see that "global" is documented in https://www.lua.org/work/doc/manual.html#8 "3.3.7 – Variable Declarations"

[sur-behoffski]

On 2025-12-02 00:43, Luiz Henrique de Figueiredo wrote:
> Lua 5.5 is the next version of Lua.
>
> Lua 5.5.0 (rc2) is now available for testing at
> https://www.lua.org/work/lua-5.5.0-rc2.tar.gz

> [...]

>
> An updated reference manual is included and also available at

> https://www.lua.org/work/doc [...]

Thanks for the new -rc.

While browsing the Lua 5.5 reference manual (triggered by the
previous query about 'global'), I was looking at Section 2.1 -
Values and Types. Some observations:

- Perhaps add "signed" to the definition of "integer";

- "two-complement arithmetic" is more traditionally called
"two's complement arithmetic", or maybe
"two's-complement arithmetic";

- IEEE 754 is quoted as the "usual" floating-point standard
in Section 3.4.1; also, 2.1 also prohibits IEEE 754 "NaN"
as a table index. Given these snippets, is it worth
promoting "usually IEEE 754" from 3.4.1 into the definition
of floating-point numbers in 2.1?

I accept that the manual is very carefully written, and so the
suggestions above may cause more harm than good. In any case,
thanks for your consideration.

s-b etc

[Bas Groothedde]

I understand, but the rc2 proto flags do no longer distinguish whether a vararg pack is named or not (unless it is a PF_VATAB)?

 

--@main = function id: 0, PF_VAHID: 1, PF_VATAB: 0, is_variadic: true, num_params: 0

--function id: 1, PF_VAHID: 1, PF_VATAB: 0, is_variadic: true, num_params: 1

function foo1(n, ...t)

    return t[n]

end

--function id: 2, PF_VAHID: 1, PF_VATAB: 0, is_variadic: true, num_params: 1

function foo2(n, ...)

    local v1 = ...;

end

--function id: 3, PF_VAHID: 0, PF_VATAB: 2, is_variadic: true, num_params: 1

function foo3(n, ...t)

    t[n] = true

end

 

foo2 has a local named '(vararg table)', but main does not and is vararg too. How to distinguish named and unnamed non-table varargs in bytecode as in foo1 and foo2 (and the main chunk)?

 

~b

[Andrey Dobrovolsky]

вт, 2 груд. 2025 р. о 20:12 'Bas Groothedde' via lua-l
<lu...@googlegroups.com> пише:

>
> How to distinguish named and unnamed non-table varargs in bytecode as in foo1 and foo2 (and the main chunk)?

I think they are indistinguishable from outside the function. What is
the purpose of such knowledge?


In manual.html line 2991:

for instance <code>a , b, c = e1, e2, e3</code>

looks like there is an extraneous space after the name "a"

-- Andrew

[Bas Groothedde]

> On 2 Dec 2025, at 21:25, Andrey Dobrovolsky <andrey.dobro...@gmail.com> wrote:
>
> вт, 2 груд. 2025 р. о 20:12 'Bas Groothedde' via lua-l

> <lu...@googlegroups.com> пише:
>>
>> How to distinguish named and unnamed non-table varargs in bytecode as in foo1 and foo2 (and the main chunk)?
>
> I think they are indistinguishable from outside the function. What is
> the purpose of such knowledge?

Static analysis of bytecode, parsing and reporting such as in luac.nl - it is not a necessity, I am merely wondering as in rc1 the flags were slightly different where this determination was made possible.

~b

[Roberto Ierusalimschy]

> > I think they are indistinguishable from outside the function. What is
> > the purpose of such knowledge?
>
> Static analysis of bytecode, parsing and reporting such as in luac.nl - it is not a necessity, I am merely wondering as in rc1 the flags were slightly different where this determination was made possible.

All internal data structures in Lua are there to support its official API.
You may want to propose some way to have this knowledge though the debug
API. But it makes little sense to keep an internal flag just because
some external tool wants to check it (violating the API).

-- Roberto

[Bas Groothedde]

> On 3 Dec 2025, at 14:16, Roberto Ierusalimschy <rob...@inf.puc-rio.br> wrote:
>
> 

I understand, I was mostly just curious. I’m always trying to work with what is there, hence why I became curious about the proto flag changes.

I didn’t expect a change, I was merely seeking confirmation and optionally tips about distinguishing these options from a bytecode perspective

Cheers,

~b

[Luiz Henrique de Figueiredo]

Bas Groothedde> I was merely seeking confirmation and optionally tips

about distinguishing these options from a bytecode perspective

BTW, thanks for your work and service on luac.nl.
It's a valuable tool for the Lua community.

--lhf

[Bas Groothedde]

> On 3 Dec 2025, at 16:40, Luiz Henrique de Figueiredo <l...@tecgraf.puc-rio.br> wrote:
>
> Bas Groothedde> I was merely seeking confirmation and optionally tips

It’s my pleasure, I love Lua and its internal structures and mechanics.

~b

[Bob Dellaca]

There has been an omission in the documentation for 5.5.0 since the beta release: the new LUA constants (LUA_GLIBK &c.) are not included in contents.html ("constants"), and there is no entry under "Incompatibilities" in manual.html. While we're on the doc folder, could not the logo file (logo.gif), a PNG file, stop masquerading as a GIF file :)

--rjd

[Roberto Ierusalimschy]

> I didn’t expect a change, I was merely seeking confirmation and optionally tips about distinguishing these options from a bytecode perspective

You can look at the debug information: If the number of active variables
on the first instruction of a prototype is one more than the number of
parameters (field numparams), then this extra variable is the vararg
parameter.

-- Roberto

[Bas Groothedde]

> On 3 Dec 2025, at 21:46, Roberto Ierusalimschy <rob...@inf.puc-rio.br> wrote:
>
> 

Super, that clears things up, thank you.

~b

[Roberto Ierusalimschy]

> > You can look at the debug information: If the number of active variables
> > on the first instruction of a prototype is one more than the number of
> > parameters (field numparams), then this extra variable is the vararg
> > parameter.
>

> Super, that clears things up, thank you.

Another trick would be to look for a OP_GETVARG instruction. If the
function uses this instruction, it must have a vararg parameter.

So, if a vararg function uses a vararg parameter, either it has a
vararg table or it has a OP_GETVARG instruction. However, if a
vararg function has a named vararg parameter but does not use it,
this trick would fail.

-- Roberto

[Bas Groothedde]

I think the first trick would give me all I need, I collect the locals that are alive
after the first instruction (when it is OP_VARARGPREP). If there is more than 
numparams, I still have to check if the varargs param name != (vararg table).

If those conditions pass, I have the vararg param name. 

Thank you for giving that info, I overlooked that detail. 

~b

[ppp vvv]

> could not the logo file (logo.gif), a PNG file, stop masquerading as a GIF file :)

if would help, also the same as 389 bytes svg

<svg xmlns='http://www.w3.org/2000/svg' width='256' height='256'><circle cx='128' cy='128' r='126' fill='none' stroke='#929292' stroke-width='3' stroke-dasharray='13.2'/><circle cx='128' cy='128' r='99' fill='#00007D'/><circle cx='168' cy='88' r='29' fill='white'/><circle cx='226' cy='30' r='29' fill='#00007D'/><text x='55' y='177' style='font:88px Helvetica;fill:white'>Lua</text></svg>

and with escaped <> e.g. to embed as data uri

<link id="favicon" rel="icon" href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='256' height='256'%3E%3Ccircle cx='128' cy='128' r='126' fill='none' stroke='%23929292' stroke-width='3' stroke-dasharray='13.2'/%3E%3Ccircle cx='128' cy='128' r='99' fill='%2300007D'/%3E%3Ccircle cx='168' cy='88' r='29' fill='white'/%3E%3Ccircle cx='226' cy='30' r='29' fill='%2300007D'/%3E%3Ctext x='55' y='177' style='font:88px Helvetica;fill:white'%3ELua%3C/text%3E%3C/svg%3E">

Also there is a dashed "trajectory" of the moon which is NOT going though the center of the moon. And now you all can not unsee that...

slightly scaled to fix it

<svg xmlns='http://www.w3.org/2000/svg' width='256' height='256'><circle cx='128' cy='128' r='126' fill='none' stroke='#929292' stroke-width='3' stroke-dasharray='13.2'/><circle cx='128' cy='128' r='92' fill='#00007D'/><circle cx='168' cy='88' r='25' fill='white'/><circle cx='216' cy='40' r='25' fill='#00007D'/><text x='55' y='177' style='font:88px Helvetica;fill:white'>Lua</text></svg>

среда, 3 декабря 2025 г. в 21:12:12 UTC+1, Bob Dellaca:

[Roberto Ierusalimschy]

> There has been an omission in the documentation for 5.5.0 since the beta
> release: the new LUA constants (LUA_GLIBK &c.) are not included in
> contents.html ("constants"), and there is no entry under

> "Incompatibilities" in manual.html. [...]

What would be the incompatibility?

-- Roberto

[Roberto Ierusalimschy]

> * for-loop variables are read only: does this mean in "for k,v in pairs(t)"
> I can no longer do "k = 42"?

Yes. Note that in Lua 5.4 you already "should not change the value of the
control variable during the loop." (It might not do what you expect.)

> * major collections done incrementally: what does this mean?

It means that major collections are done incrementally. Using the
generational collector, it sometimes has to do a major collection, that
is, a collection that considers all generations. In Lua 5.4, these
major collections were done atomically (stop-the-world); in Lua 5.5 they
are done incrementally.

-- Roberto

[Rett Berg]

> Yes. Note that in Lua 5.4 you already "should not change the value of the

control variable during the loop." (It might not do what you expect.)

Is there a reference for this? I often change the value of the key during loops and have never encountered an issue (and am running lua 5.4).

> It means that major collections are done incrementally. Using the

generational collector, it sometimes has to do a major collection, that
is, a collection that considers all generations.

Ah, this is related to the garbage collector. I thought it meant some form of internal collections (like lists, maps, etc).

Could this be changed to "garbage collector: major collections are done incrementally"?

--
You received this message because you are subscribed to a topic in the Google Groups "lua-l" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lua-l/KuCiQzliQzY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/20251204162950.GD279202%40arraial.inf.puc-rio.br.

[Roberto Ierusalimschy]

> > Yes. Note that in Lua 5.4 you already "should not change the value of the
> control variable during the loop." (It might not do what you expect.)
>
> Is there a reference for this? I often change the value of the key during
> loops and have never encountered an issue (and am running lua 5.4).

https://www.lua.org/manual/5.4/manual.html#3.3.5


To fix your code, as suggested in the manual, you can simply declare a
local variable with the same name of the key:

for k,v in whatever do
local k = k
-- now k is writeable, it is safe to write to it, and it is quite
-- clear that this writing does not affect the loop
...

-- Roberto

[Rett Berg]

This is the doc reference:

> You should not change the value of the control variable during the loop.

Okay, so it's _only_ the first variable in the loop that I shouldn't change -- that helps.

I could imagine this being useful, for instance if you wanted to skip or back-track on iteration in some way - such as during parsing. Are there such plans?

If there were no such plans, could the compiler detect that the control variable is being modified and insert the `local k = k` in the AST for such cases?

Best,

Rett

--
You received this message because you are subscribed to a topic in the Google Groups "lua-l" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lua-l/KuCiQzliQzY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/20251204190752.GB283426%40arraial.inf.puc-rio.br.

[Roberto Ierusalimschy]

> I could imagine this being *useful*, for instance if you wanted to skip or

> back-track on iteration in some way - such as during parsing. Are there
> such plans?

No.

> If there were no such plans, could the compiler detect that the control
> variable is being modified and insert the `local k = k` in the AST for such
> cases?

I don't see how it could do that, being a one-pass compiler. When it
starts generating code for 'k', it has no way to know whether there is
some assignment to 'k' later in the code.

-- Roberto

[Gé Weijers]

On Mon, Dec 8, 2025 at 10:23 AM Roberto Ierusalimschy <rob...@inf.puc-rio.br> wrote:

> If there were no such plans, could the compiler detect that the control
> variable is being modified and insert the `local k = k` in the AST for such
> cases?

I don't see how it could do that, being a one-pass compiler. When it
starts generating code for 'k', it has no way to know whether there is
some assignment to 'k' later in the code.

Even if you could, a "local k = k" declaration makes it explicit that the 'k' that's being changed is a copy of the loop counter,

which is a Good Thing™ in my book. It's less confusing for a reader.

--

Gé

[Luiz Henrique de Figueiredo]

> If there were no such plans, could the compiler detect that the control variable is being modified and insert the `local k = k` in the AST for such cases?

You can implement this using a token filter: look for 'for', capture
the next name, look for 'do', emit 'local name = name',