Generate EmbeddedBuiltinDefinitions.cpp - #181
Conversation
EmbeddedBuiltinDefinitions.cpp
12e0b16 to
dc734fe
Compare
2b9784f to
f8a351c
Compare
| @@ -0,0 +1,523 @@ | |||
| // This file is part of the Luau programming language and is licensed under MIT License; see LICENSE.txt for details | |||
| #include "Luau/BuiltinDefinitions.h" | |||
There was a problem hiding this comment.
My design thoughts regarding the structure of EmbeddedBuiltinDefinitions.cpp:
Logically, the whole module just needs to return a single string (ignoring the types library). So, it could just embed the existing secondlife.d.luau file as-is in the cpp source code
The technical reason not to is fflags.
- SLua's version (Luau 0.710)
- Luau's version (Luau 0.725)
SLua/Luau 0.710 use 2 fflags:
- LuauTypeCheckerUdtfRenameClassToExtern
- LuauMorePermissiveNewtableType
Both fflags only affect the types library, which this repository doesn't touch
Luau 0.723 uses 5 fflags:
- LuauIntegerLibrary
- LuauIntegerType2
- LuauAllowGlobalDeclarationToBeCalledClass
- DebugLuauUserDefinedClasses
- LuauUdtfTypeIsSubtypeOf
fflags 1-2 affect the inclusion of the integer library and 2 buffer functions
fflags 3-4 affect the inclusion of the class library
fflags 2 and 5 affect the types library, which this repository doesn't care about
@HaroldCindy mentioned in the 2026-06-23 Server User Group that SLua is going to merge upstream from Luau soon, and that it will leave the integer and class libraries disabled by fflags for now.
Therefore, I think it best to match the structure of the generated file as closely to upstream as possible, so that it can keep the fflags working. Is that ok?
There was a problem hiding this comment.
I chose to generate a file for any of Luau 725, 726, 727, 728, or 729 because:
EmbeddedBuiltinDefinitions.cppis identical in those 5 versions- it has minimal fflags that my generator needs to worry about (especially no fflags that switch between 2 definitions of one function, which the generator doesn't support
- The file has been stable for quite a few versions (5), but there's upcoming PR's that will add more FFlags to worry about:
| @@ -0,0 +1,523 @@ | |||
| // This file is part of the Luau programming language and is licensed under MIT License; see LICENSE.txt for details | |||
| #include "Luau/BuiltinDefinitions.h" | |||
There was a problem hiding this comment.
I'm unsure which version of Luau I should target for the first EmbeddedBuiltinDefinitions generator:
- 0.710 (SLua current)
- 0.723 (Luau latest)
- something else
Mostly it depends on how soon you plan to merge Luau:
- 0.710 has all the data in slua_definitions.yaml already
- 0.723 is missing data for the integer library, class library, and read-only indicators
There was a problem hiding this comment.
I've gone ahead and targeted Luau 0.729 for EmbeddedBuiltinDefinitions.cpp: #181
I made the following Luau update PR's in preparation:
| @@ -0,0 +1,523 @@ | |||
| // This file is part of the Luau programming language and is licensed under MIT License; see LICENSE.txt for details | |||
| #include "Luau/BuiltinDefinitions.h" | |||
There was a problem hiding this comment.
I'm also curious if you want me to put an EmbeddedBuiltinDefinitions.cpp generator here or in the slua repo. I know you had opinions on Rider making the dict wrappers here vs slua repo. I'll put it in lsl-definitions repo unless you say otherwise. It can be moved later if needed
There was a problem hiding this comment.
I generate the wrappers here and include them in the actual simulator since putting them into the VM would require a new VM every time we added a flag to any function. (I have the same opinion about prim params, but it is not a hill I'm willing to die on.)
We provide the generators, and the pregenerated .cpp files in the distribution so 3rd parties can include them easily.
71f52cc to
43e169c
Compare
| with io.StringIO() as defs: | ||
| slua_definitions.modules["buffer"].write_luau_def(defs) | ||
| inserts["BUFFER_TABLE_NOINTEGER"] = defs.getvalue() | ||
| with io.StringIO() as defs: | ||
| slua_definitions.modules.pop("buffer").write_luau_def(defs, enable_fflags=True) | ||
| inserts["BUFFER_TABLE"] = defs.getvalue() |
There was a problem hiding this comment.
yunno, it's not really sustainable trying to generate 2 different versions of a definition for different FFlags.
I think a better idea would be to:
- Only generate the parts of
EmbeddedBuiltinDefinitions.cppthat SLua actually enables with it's releasedFFlagset - Leave the
FFlag-disabled parts ofEmbeddedBuiltinDefinitions.cppin the template, to be synced upstream from Luau
In practice, for Luau 0.729, this would mean:
- generating
kBuiltinDefinitionBufferSrc_NOINTEGER - NOT generating
kBuiltinDefinitionBufferSrc - NOT generating
kBuiltinDefinitionIntegerSrc - NOT generating
kBuiltinDefinitionClassSrc - Removing Luau 0.715 integer library #176, Luau 0.724 class library #179, and Exclude
integerandclassfrom generated files #180 as dependencies on this PR - Closing Exclude
integerandclassfrom generated files #180 because it's no longer needed (it's what implementsenable_fflagsin the commented code) - Leaving Luau 0.715 integer library #176 and Luau 0.724 class library #179 unmerged until they are actually enabled via
FFlags in SLua, and not just present and disabled in the code
This would also mean that I don't need to ask Harold not to base SLua on a particular Luau version just because of what FFlags Luau happened to put in EmbeddedBuiltinDefinitions.cpp that week (see above comment #181 (comment))
5c5861a to
e62823d
Compare
3234f9b to
2ed3d9e
Compare
| $CMD $DEFS gen_lexer_file ./templates/indra.in.l "$outdir/templated/indra.l" | ||
| $CMD $DEFS gen_parser_file ./templates/indra.in.y "$outdir/templated/indra.y" | ||
| $CMD $DEFS gen_mono_library_defs ./templates/LslLibrary.cs "$outdir/templated/LslLibrary.cs" | ||
| $CMD $DEFS gen_slua_embedded_defs ./templates/EmbeddedBuiltinDefinitions.in.cpp $SLUA "$outdir/cpp/EmbeddedBuiltinDefinitions.cpp" |
There was a problem hiding this comment.
- I may close this PR as lute just gained definitions-loading capabilities, and that sounds more sustainable than this approach:
lute check: Support loading definition files luau-lang/lute#1234
Generate
EmbeddedBuiltinDefinitions.cppso thatluau-analyzeknows aboutllfunctions and such.This generates a file intended for Luau 0.725 - 0.730
EmbeddedBuiltinDefinitions.cpp#122EmbeddedBuiltinDefinitions.cppagainst slua 0.729 tapple/lsl-definitions#3