Skip to content

Generate EmbeddedBuiltinDefinitions.cpp - #181

Draft
tapple wants to merge 12 commits into
secondlife:mainfrom
tapple:EmbeddedBuiltinDefinitions.cpp
Draft

Generate EmbeddedBuiltinDefinitions.cpp#181
tapple wants to merge 12 commits into
secondlife:mainfrom
tapple:EmbeddedBuiltinDefinitions.cpp

Conversation

@tapple

@tapple tapple commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Generate EmbeddedBuiltinDefinitions.cpp so that luau-analyze knows about ll functions and such.

This generates a file intended for Luau 0.725 - 0.730

@tapple tapple changed the title Add generator for EmbeddedBuiltinDefinitions.cpp Generate EmbeddedBuiltinDefinitions.cpp Jul 11, 2026
@tapple
tapple force-pushed the EmbeddedBuiltinDefinitions.cpp branch from 12e0b16 to dc734fe Compare July 11, 2026 23:04
@tapple
tapple force-pushed the EmbeddedBuiltinDefinitions.cpp branch from 2b9784f to f8a351c Compare July 13, 2026 15:14
@@ -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"

@tapple tapple Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/Luau 0.710 use 2 fflags:

  1. LuauTypeCheckerUdtfRenameClassToExtern
  2. LuauMorePermissiveNewtableType

Both fflags only affect the types library, which this repository doesn't touch

Luau 0.723 uses 5 fflags:

  1. LuauIntegerLibrary
  2. LuauIntegerType2
  3. LuauAllowGlobalDeclarationToBeCalledClass
  4. DebugLuauUserDefinedClasses
  5. 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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose to generate a file for any of Luau 725, 726, 727, 728, or 729 because:

@@ -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"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure which version of Luau I should target for the first EmbeddedBuiltinDefinitions generator:

  1. 0.710 (SLua current)
  2. 0.723 (Luau latest)
  3. something else

Mostly it depends on how soon you plan to merge Luau:

  1. 0.710 has all the data in slua_definitions.yaml already
  2. 0.723 is missing data for the integer library, class library, and read-only indicators

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@tapple
tapple force-pushed the EmbeddedBuiltinDefinitions.cpp branch from 71f52cc to 43e169c Compare July 13, 2026 22:10
Comment on lines +62 to +67
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()

@tapple tapple Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. Only generate the parts of EmbeddedBuiltinDefinitions.cpp that SLua actually enables with it's released FFlag set
  2. Leave the FFlag-disabled parts of EmbeddedBuiltinDefinitions.cpp in the template, to be synced upstream from Luau

In practice, for Luau 0.729, this would mean:

  1. generating kBuiltinDefinitionBufferSrc_NOINTEGER
  2. NOT generating kBuiltinDefinitionBufferSrc
  3. NOT generating kBuiltinDefinitionIntegerSrc
  4. NOT generating kBuiltinDefinitionClassSrc
  5. Removing Luau 0.715 integer library #176, Luau 0.724 class library #179, and Exclude integer and class from generated files #180 as dependencies on this PR
  6. Closing Exclude integer and class from generated files #180 because it's no longer needed (it's what implements enable_fflags in the commented code)
  7. 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))

@tapple
tapple force-pushed the EmbeddedBuiltinDefinitions.cpp branch 2 times, most recently from 5c5861a to e62823d Compare July 14, 2026 00:42
@tapple
tapple force-pushed the EmbeddedBuiltinDefinitions.cpp branch from 3234f9b to 2ed3d9e Compare July 20, 2026 21:40
Comment thread gen_all_definitions.sh
$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"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Create a generator for EmbeddedBuiltinDefinitions.cpp

2 participants