app/lua53: catch up to lua 5.3.6 #3415
Conversation
|
Nobody here or #3414? |
There was a problem hiding this comment.
I am a bit concerned about the luaC_objbarrier calls, as it seems they belong to GC and we have some modifications in that area.
The rest I guess is just from upstream and I guess they know what they are doing, so that's OK.
@nwf what exactly do you mean by not checking the "I tested" checkbox. Did you run the code on ESP?
Did you run the Lua test suite?
Do we need to test GC in combination with our RO elements for this?
Maybe @TerryE can help out.
|
When I said "mostly guided by upstream", I meant that most of this was https://www.lua.org/work/diffs-lua-5.3.5-lua-5.3.6.html . The |
Adapt https://www.lua.org/work/diffs-lua-5.3.5-lua-5.3.6.html to NodeMCU. Mostly a straight application, but some small tweaks were required and, in lundump.c, some changes were elided and some additional diff reduction applied, as we have heavily diverged from upstream.
nwf
force-pushed
the
202103-lua53-dot6
branch
from
e6f2090 to
ef256de
Compare
|
Ah ha. After a day of debugging I have finally caught my mistake in this. Of course it was in the This now passes my |
|
Will merge after #3479 lands. |
Oh, that was a year ago 😄 Will merge now. |
Adapt https://www.lua.org/work/diffs-lua-5.3.5-lua-5.3.6.html to NodeMCU. Mostly a straight application, but some small tweaks were required and, in lundump.c, some changes were elided and some additional diff reduction applied, as we have heavily diverged from upstream.
Diff reduction to 5.3.6, mostly guided by upstream.
Tested lightly using a subset of the expect framework; enough to verify that LFS continues to function, at least!
devbranch rather than for thereleasebranch.docs/*.