//

// @license

// Copyright 2010 The Emscripten Authors

// SPDX-License-Identifier: MIT

//

//

// Various compiler settings. These are simply variables present when the

// JS compiler runs. To set them, do something like:

//

// emcc -s OPTION1=VALUE1 -s OPTION2=VALUE2 [..other stuff..]

//

// For convenience and readability `-s OPTION` expands to `-s OPTION=1`

// and `-s NO_OPTION` expands to `-s OPTION=0` (assuming OPTION is a valid

// option).

//

// See https://github.com/emscripten-core/emscripten/wiki/Code-Generation-Modes/

//

// Note that the values here are the defaults in -O0, that is, unoptimized

// mode. See apply_opt_level in tools/shared.py for how -O1,2,3 affect these

// flags.

//

// These flags should only have an effect when compiling to JS, so there

// should not be a need to have them when just compiling source to

// bitcode. However, there will also be no harm either, so it is ok to.

//

// Settings in this file can be directly set from the command line. Internal

// settings that are not part of the user ABI live in the settings_internal.js.

//

// In general it is best to pass the same arguments at both compile and link

// time, as whether wasm object files are used or not affects when codegen

// happens (without wasm object files, codegen is done entirely during

// link; otherwise, it is during compile). Flags affecting codegen must

// be passed when codegen happens, so to let a build easily switch when codegen

// happens (LTO vs normal), pass the flags at both times. The flags are also

// annotated in this file:

//

// [link] - Should be passed at link time. This is the case for all JS flags,

// as we emit JS at link (and that is most of the flags here, and

// hence the default).

// [compile+link] - A flag that has an effect at both compile and link time,

// basically any time emcc is invoked. The same flag should be

// passed at both times in most cases.

//

// If not otherwise specified, a flag is [link]. Note that no flag is only

// relevant during compile time, as during link we may do codegen for system

// libraries and other support code, so all flags are either link or

// compile+link.

//

// Tuning

// Whether we should add runtime assertions, for example to

// check that each allocation to the stack does not

// exceed its size, whether all allocations (stack and static) are

// of positive size, etc., whether we should throw if we encounter a bad __label__, i.e.,

// if code flow runs into a fault

// ASSERTIONS == 2 gives even more runtime checks, that may be very slow. That

// includes internal dlmalloc assertions.

// [link]

var ASSERTIONS = 1;

// Whether extra logging should be enabled.

// This logging isn't quite assertion-quality in that it isn't necessarily a

// symptom that something is wrong.

// [link]

var RUNTIME_LOGGING = 0;

// Chooses what kind of stack smash checks to emit to generated code:

// Building with ASSERTIONS=1 causes STACK_OVERFLOW_CHECK default to 1.

// Since ASSERTIONS=1 is the default at -O0, which itself is the default

// optimization level this means that this setting also effectively

// defaults 1, absent any other settings.

// 0: Stack overflows are not checked.

// 1: Adds a security cookie at the top of the stack, which is checked at end of

// each tick and at exit (practically zero performance overhead)

// 2: Same as above, but also runs a binaryen pass which adds a check to all

// stack pointer assignments. Has a small performance cost.

// [link]

var STACK_OVERFLOW_CHECK = 0;

// When set to 1, will generate more verbose output during compilation.

// [general]

var VERBOSE = 0;

// Whether we will run the main() function. Disable if you embed the generated

// code in your own, and will call main() yourself at the right time (which you

// can do with Module.callMain(), with an optional parameter of commandline args).

// [link]

var INVOKE_RUN = 1;

// If 0, the runtime is not quit when main() completes (allowing code to

// run afterwards, for example from the browser main event loop). atexit()s

// are also not executed, and we can avoid including code for runtime shutdown,

// like flushing the stdio streams.

// Set this to 1 if you do want atexit()s or stdio streams to be flushed

// on exit.

// This setting is controlled automatically in STANDALONE_WASM mode:

// - For a command (has a main function) this is always 1

// - For a reactor (no a main function) this is always 0

// [link]

var EXIT_RUNTIME = 0;

// How to represent the initial memory content.

// 0: embed a base64 string literal representing the initial memory data

// 1: create a *.mem file containing the binary data of the initial memory;

// use the --memory-init-file command line switch to select this method

// [link]

var MEM_INIT_METHOD = 0;

// The total stack size. There is no way to enlarge the stack, so this

// value must be large enough for the program's requirements. If

// assertions are on, we will assert on not exceeding this, otherwise,

// it will fail silently.

// [link]

var TOTAL_STACK = 5*1024*1024;

// What malloc()/free() to use, out of

// * dlmalloc - a powerful general-purpose malloc

// * emmalloc - a simple and compact malloc designed for emscripten

// * emmalloc-debug - use emmalloc and add extra assertion checks

// * emmalloc-memvalidate - use emmalloc with assertions+heap consistency

// checking.

// * emmalloc-verbose - use emmalloc with assertions + verbose logging.

// * emmalloc-memvalidate-verbose - use emmalloc with assertions + heap

// consistency checking + verbose logging.

// * none - no malloc() implementation is provided, but you must implement

// malloc() and free() yourself.

// dlmalloc is necessary for split memory and other special modes, and will be

// used automatically in those cases.

// In general, if you don't need one of those special modes, and if you don't

// allocate very many small objects, you should use emmalloc since it's

// smaller. Otherwise, if you do allocate many small objects, dlmalloc

// is usually worth the extra size. dlmalloc is also a good choice if you want

// the extra security checks it does (such as noticing metadata corruption in

// its internal data structures, which emmalloc does not do).

// [link]

var MALLOC = "dlmalloc";

// If 1, then when malloc would fail we abort(). This is nonstandard behavior,

// but makes sense for the web since we have a fixed amount of memory that

// must all be allocated up front, and so (a) failing mallocs are much more

// likely than on other platforms, and (b) people need a way to find out

// how big that initial allocation (INITIAL_MEMORY) must be.

// If you set this to 0, then you get the standard malloc behavior of

// returning NULL (0) when it fails.

//

// Setting ALLOW_MEMORY_GROWTH turns this off, as in that mode we default to

// the behavior of trying to grow and returning 0 from malloc on failure, like

// a standard system would. However, you can still set this flag to override

// that.

// * This is a mostly-backwards-compatible change. Previously this option

// was ignored when growth was on. The current behavior is that growth

// turns it off by default, so for users that never specified the flag

// nothing changes. But if you do specify it, it will have an effect now,

// which it did not previously. If you don't want that, just stop passing

// it in at link time.

//

// [link]

var ABORTING_MALLOC = 1;

// The initial amount of memory to use. Using more memory than this will

// cause us to expand the heap, which can be costly with typed arrays:

// we need to copy the old heap into a new one in that case.

// If ALLOW_MEMORY_GROWTH is set, this initial amount of memory can increase

// later; if not, then it is the final and total amount of memory.

//

// (This option was formerly called TOTAL_MEMORY.)

// [link]

var INITIAL_MEMORY = 16777216;

// Set the maximum size of memory in the wasm module (in bytes). This is only

// relevant when ALLOW_MEMORY_GROWTH is set, as without growth, the size of

// INITIAL_MEMORY is the final size of memory anyhow.

//

// If this value is -1, it means there is no specified limit.

//

// Note that the default value here is 2GB, which means that by default if you

// enable memory growth then we can grow up to 2GB but no higher. 2GB is a

// natural limit for several reasons:

//

// * If the maximum heap size is over 2GB, then pointers must be unsigned in

// JavaScript, which increases code size. We don't want memory growth builds

// to be larger unless someone explicitly opts in to >2GB+ heaps.

// * Historically no VM has supported more >2GB+, and only recently (Mar 2020)

// has support started to appear. As support is limited, it's safer for

// people to opt into >2GB+ heaps rather than get a build that may not

// work on all VMs.

//

// (This option was formerly called WASM_MEM_MAX and BINARYEN_MEM_MAX.)

// [link]

var MAXIMUM_MEMORY = 2147483648;

// If false, we abort with an error if we try to allocate more memory than

// we can (INITIAL_MEMORY). If true, we will grow the memory arrays at

// runtime, seamlessly and dynamically.

// See https://code.google.com/p/v8/issues/detail?id=3907 regarding

// memory growth performance in chrome.

// Note that growing memory means we replace the JS typed array views, as

// once created they cannot be resized. (In wasm we can grow the Memory, but

// still need to create new views for JS.)

// Setting this option on will disable ABORTING_MALLOC, in other words,

// ALLOW_MEMORY_GROWTH enables fully standard behavior, of both malloc

// returning 0 when it fails, and also of being able to allocate more

// memory from the system as necessary.

// [link]

var ALLOW_MEMORY_GROWTH = 0;

// If ALLOW_MEMORY_GROWTH is true, this variable specifies the geometric

// overgrowth rate of the heap at resize. Specify MEMORY_GROWTH_GEOMETRIC_STEP=0

// to disable overgrowing the heap at all, or e.g.

// MEMORY_GROWTH_GEOMETRIC_STEP=1.0 to double the heap (+100%) at every grow step.

// The larger this value is, the more memory the WebAssembly heap overreserves

// to reduce performance hiccups coming from memory resize, and the smaller

// this value is, the more memory is conserved, at the performance of more

// stuttering when the heap grows. (profiled to be on the order of ~20 msecs)

// [link]

var MEMORY_GROWTH_GEOMETRIC_STEP = 0.20;

// Specifies a cap for the maximum geometric overgrowth size, in bytes. Use

// this value to constrain the geometric grow to not exceed a specific rate.

// Pass MEMORY_GROWTH_GEOMETRIC_CAP=0 to disable the cap and allow unbounded

// size increases.

// [link]

var MEMORY_GROWTH_GEOMETRIC_CAP = 96*1024*1024;

// If ALLOW_MEMORY_GROWTH is true and MEMORY_GROWTH_LINEAR_STEP == -1, then

// geometric memory overgrowth is utilized (above variable). Set

// MEMORY_GROWTH_LINEAR_STEP to a multiple of WASM page size (64KB), eg. 16MB to

// replace geometric overgrowth rate with a constant growth step size. When

// MEMORY_GROWTH_LINEAR_STEP is used, the variables MEMORY_GROWTH_GEOMETRIC_STEP

// and MEMORY_GROWTH_GEOMETRIC_CAP are ignored.

// [link]

var MEMORY_GROWTH_LINEAR_STEP = -1;

// The "architecture" to compile for. 0 means the default wasm32, 1 is

// the full end-to-end wasm64 mode, and 2 is wasm64 for clang/lld but lowered to

// wasm32 in Binaryen (such that it can run on wasm32 engines, while internally

// using i64 pointers).

// [compile+link]

var MEMORY64 = 0;

// Sets the initial size of the table when MAIN_MODULE or SIDE_MODULE is use

// (and not otherwise). Normally Emscripten can determine the size of the table

// at link time, but in SPLIT_MODULE mode, wasm-split often needs to grow the

// table, so the table size baked into the JS for the instrumented build will be

// too small after the module is split. This is a hack to allow users to specify

// a large enough table size that can be consistent across both builds. This

// setting may be removed at any time and should not be used except in

// conjunction with SPLIT_MODULE and dynamic linking.

// [link]

var INITIAL_TABLE = -1;

// If true, allows more functions to be added to the table at runtime. This is

// necessary for dynamic linking, and set automatically in that mode.

// [link]

var ALLOW_TABLE_GROWTH = 0;

// where global data begins; the start of static memory. -1 means use the

// default, any other value will be used as an override

// [link]

var GLOBAL_BASE = -1;

// Whether closure compiling is being run on this output

// [link]

var USE_CLOSURE_COMPILER = 0;

// Specifies how warnings emitted by Closure are treated. Possible

// options: 'quiet', 'warn', 'error'. If set to 'warn', Closure warnings are printed

// out to console. If set to 'error', Closure warnings are treated like errors,

// similar to -Werror compiler flag.

// [link]

var CLOSURE_WARNINGS = 'quiet';

// Ignore closure warnings and errors (like on duplicate definitions)

// [link]

var IGNORE_CLOSURE_COMPILER_ERRORS = 0;

// If set to 1, each wasm module export is individually declared with a

// JavaScript "var" definition. This is the simple and recommended approach.

// However, this does increase code size (especially if you have many such

// exports), which can be avoided in an unsafe way by setting this to 0. In that

// case, no "var" is created for each export, and instead a loop (of small

// constant code size, no matter how many exports you have) writes all the

// exports received into the global scope. Doing so is dangerous since such

// modifications of the global scope can confuse external JS minifier tools, and

// also things can break if the scope the code is in is not the global scope

// (e.g. if you manually enclose them in a function scope).

// [link]

var DECLARE_ASM_MODULE_EXPORTS = 1;

// If 0, prevents inlining if set to 1. If 0, we will inline normally in LLVM.

// This does not affect the inlining policy in Binaryen.

// [compile]

var INLINING_LIMIT = 0;

// If set to 1, perform acorn pass that converts each HEAP access into a

// function call that uses DataView to enforce LE byte order for HEAP buffer;

// This makes generated JavaScript run on BE as well as LE machines. (If 0, only

// LE systems are supported). Does not affect generated wasm.

var SUPPORT_BIG_ENDIAN = 0;

// Check each write to the heap, for example, this will give a clear

// error on what would be segfaults in a native build (like dereferencing

// 0). See runtime_safe_heap.js for the actual checks performed.

// [link]

var SAFE_HEAP = 0;

// Log out all SAFE_HEAP operations

// [link]

var SAFE_HEAP_LOG = 0;

// Allows function pointers to be cast, wraps each call of an incorrect type

// with a runtime correction. This adds overhead and should not be used

// normally. It also forces ALIASING_FUNCTION_POINTERS to 0. Aside from making

// calls not fail, this tries to convert values as best it can.

// We use 64 bits (i64) to represent values, as if we wrote the sent value to

// memory and loaded the received type from the same memory (using

// truncs/extends/ reinterprets). This means that when types do not match the

// emulated values may not match (this is true of native too, for that matter -

// this is all undefined behavior). This approaches appears good enough to

// support Python, which is the main use case motivating this feature.

// [link]

var EMULATE_FUNCTION_POINTER_CASTS = 0;

// Print out exceptions in emscriptened code.

// [link]

var EXCEPTION_DEBUG = 0;

// If 1, build in libcxxabi's full c++ demangling code, to allow stackTrace()

// to emit fully proper demangled c++ names

// [link]

var DEMANGLE_SUPPORT = 0;

// Print out when we enter a library call (library*.js). You can also unset

// Runtime.debug at runtime for logging to cease, and can set it when you want

// it back. A simple way to set it in C++ is

// emscripten_run_script("Runtime.debug = ...;");

// [link]

var LIBRARY_DEBUG = 0;

// Print out all musl syscalls, including translating their numeric index

// to the string name, which can be convenient for debugging. (Other system

// calls are not numbered and already have clear names; use LIBRARY_DEBUG

// to get logging for all of them.)

// [link]

var SYSCALL_DEBUG = 0;

// Log out socket/network data transfer.

// [link]

var SOCKET_DEBUG = 0;

// Log dynamic linker information

// [link]

var DYLINK_DEBUG = 0;

// Select socket backend, either webrtc or websockets. XXX webrtc is not

// currently tested, may be broken

// As well as being configurable at compile time via the "-s" option the

// WEBSOCKET_URL and WEBSOCKET_SUBPROTOCOL

// settings may configured at run time via the Module object e.g.

// Module['websocket'] = {subprotocol: 'base64, binary, text'};

// Module['websocket'] = {url: 'wss://', subprotocol: 'base64'};

// You can set 'subprotocol' to null, if you don't want to specify it

// Run time configuration may be useful as it lets an application select

// multiple different services.

// [link]

var SOCKET_WEBRTC = 0;

// A string containing either a WebSocket URL prefix (ws:// or wss://) or a complete

// RFC 6455 URL - "ws[s]:" "//" host [ ":" port ] path [ "?" query ].

// In the (default) case of only a prefix being specified the URL will be constructed from

// prefix + addr + ':' + port

// where addr and port are derived from the socket connect/bind/accept calls.

// [link]

var WEBSOCKET_URL = 'ws://';

// If 1, the POSIX sockets API uses a native bridge process server to proxy sockets calls

// from browser to native world.

// [link]

var PROXY_POSIX_SOCKETS = 0;

// A string containing a comma separated list of WebSocket subprotocols

// as would be present in the Sec-WebSocket-Protocol header.

// You can set 'null', if you don't want to specify it.

// [link]

var WEBSOCKET_SUBPROTOCOL = 'binary';

// Print out debugging information from our OpenAL implementation.

// [link]

var OPENAL_DEBUG = 0;

// If 1, prints out debugging related to calls from emscripten_web_socket_* functions

// in emscripten/websocket.h.

// If 2, additionally traces bytes communicated via the sockets.

// [link]

var WEBSOCKET_DEBUG = 0;

// Adds extra checks for error situations in the GL library. Can impact

// performance.

// [link]

var GL_ASSERTIONS = 0;

// If enabled, prints out all API calls to WebGL contexts. (*very* verbose)

// [link]

var TRACE_WEBGL_CALLS = 0;

// Enables more verbose debug printing of WebGL related operations. As with

// LIBRARY_DEBUG, this is toggleable at runtime with option GL.debug.

// [link]

var GL_DEBUG = 0;

// When enabled, sets preserveDrawingBuffer in the context, to allow tests to

// work (but adds overhead)

// [link]

var GL_TESTING = 0;

// How large GL emulation temp buffers are

// [link]

var GL_MAX_TEMP_BUFFER_SIZE = 2097152;

// Enables some potentially-unsafe optimizations in GL emulation code

// [link]

var GL_UNSAFE_OPTS = 1;

// Forces support for all GLES2 features, not just the WebGL-friendly subset.

// [link]

var FULL_ES2 = 0;

// If true, glGetString() for GL_VERSION and GL_SHADING_LANGUAGE_VERSION will

// return strings OpenGL ES format "Open GL ES ... (WebGL ...)" rather than the

// WebGL format. If false, the direct WebGL format strings are returned. Set

// this to true to make GL contexts appear like an OpenGL ES context in these

// version strings (at the expense of a little bit of added code size), and to

// false to make GL contexts appear like WebGL contexts and to save some bytes

// from the output.

// [link]

var GL_EMULATE_GLES_VERSION_STRING_FORMAT = 1;

// If true, all GL extensions are advertised in both unprefixed WebGL extension

// format, but also in desktop/mobile GLES/GL extension format with "GL_" prefix.

// [link]

var GL_EXTENSIONS_IN_PREFIXED_FORMAT = 1;

// If true, adds support for automatically enabling all GL extensions for

// GLES/GL emulation purposes. This takes up code size. If you set this to 0,

// you will need to manually enable the extensions you need.

// [link]

var GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS = 1;

// If true, the function emscripten_webgl_enable_extension() can be called to

// enable any WebGL extension. If false, to save code size,

// emscripten_webgl_enable_extension() cannot be called to enable any of extensions

// 'ANGLE_instanced_arrays', 'OES_vertex_array_object', 'WEBGL_draw_buffers',

// 'WEBGL_multi_draw', 'WEBGL_draw_instanced_base_vertex_base_instance',

// or 'WEBGL_multi_draw_instanced_base_vertex_base_instance',

// but the dedicated functions emscripten_webgl_enable_*()

// found in html5.h are used to enable each of those extensions.

// This way code size is increased only for the extensions that are actually used.

// N.B. if setting this to 0, GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS must be set

// to zero as well.

// [link]

var GL_SUPPORT_SIMPLE_ENABLE_EXTENSIONS = 1;

// If set to 0, Emscripten GLES2->WebGL translation layer does not track the kind

// of GL errors that exist in GLES2 but do not exist in WebGL. Settings this to 0

// saves code size. (Good to keep at 1 for development)

// [link]

var GL_TRACK_ERRORS = 1;

// If true, GL contexts support the explicitSwapControl context creation flag.

// Set to 0 to save a little bit of space on projects that do not need it.

// [link]

var GL_SUPPORT_EXPLICIT_SWAP_CONTROL = 0;

// If true, calls to glUniform*fv and glUniformMatrix*fv utilize a pool of

// preallocated temporary buffers for common small sizes to avoid generating

// temporary garbage for WebGL 1. Disable this to optimize generated size of the

// GL library a little bit, at the expense of generating garbage in WebGL 1. If

// you are only using WebGL 2 and do not support WebGL 1, this is not needed and

// you can turn it off.

// [link]

var GL_POOL_TEMP_BUFFERS = 1;

// Some old Android WeChat (Chromium 37?) browser has a WebGL bug that it ignores

// the offset of a typed array view pointing to an ArrayBuffer. Set this to

// 1 to enable a polyfill that works around the issue when it appears. This

// bug is only relevant to WebGL 1, the affected browsers do not support WebGL 2.

// [link]

var WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG = 0;

// If true, enables support for the EMSCRIPTEN_explicit_uniform_location WebGL

// extension. See docs/EMSCRIPTEN_explicit_uniform_location.txt

var GL_EXPLICIT_UNIFORM_LOCATION = 0;

// Deprecated. Pass -s MAX_WEBGL_VERSION=2 to target WebGL 2.0.

// [link]

var USE_WEBGL2 = 0;

// Specifies the lowest WebGL version to target. Pass -s MIN_WEBGL_VERSION=1

// to enable targeting WebGL 1, and -s MIN_WEBGL_VERSION=2 to drop support

// for WebGL 1.0

// [link]

var MIN_WEBGL_VERSION = 1;

// Specifies the highest WebGL version to target. Pass -s MAX_WEBGL_VERSION=2

// to enable targeting WebGL 2. If WebGL 2 is enabled, some APIs (EGL, GLUT, SDL)

// will default to creating a WebGL 2 context if no version is specified.

// Note that there is no automatic fallback to WebGL1 if WebGL2 is not supported

// by the user's device, even if you build with both WebGL1 and WebGL2

// support, as that may not always be what the application wants. If you want

// such a fallback, you can try to create a context with WebGL2, and if that

// fails try to create one with WebGL1.

// [link]

var MAX_WEBGL_VERSION = 1;

// If true, emulates some WebGL 1 features on WebGL 2 contexts, meaning that

// applications that use WebGL 1/GLES 2 can initialize a WebGL 2/GLES3 context,

// but still keep using WebGL1/GLES 2 functionality that no longer is supported

// in WebGL2/GLES3. Currently this emulates GL_EXT_shader_texture_lod extension

// in GLSLES 1.00 shaders, support for unsized internal texture formats, and the

// GL_HALF_FLOAT_OES != GL_HALF_FLOAT mixup.

// [link]

var WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION = 0;

// Forces support for all GLES3 features, not just the WebGL2-friendly subset.

// This automatically turns on FULL_ES2 and WebGL2 support.

// [link]

var FULL_ES3 = 0;

// Includes code to emulate various desktop GL features. Incomplete but useful

// in some cases, see

// http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html

// [link]

var LEGACY_GL_EMULATION = 0;

// If you specified LEGACY_GL_EMULATION = 1 and only use fixed function pipeline

// in your code, you can also set this to 1 to signal the GL emulation layer

// that it can perform extra optimizations by knowing that the user code does

// not use shaders at all. If LEGACY_GL_EMULATION = 0, this setting has no

// effect.

// [link]

var GL_FFP_ONLY = 0;

// If you want to create the WebGL context up front in JS code, set this to 1

// and set Module['preinitializedWebGLContext'] to a precreated WebGL context.

// WebGL initialization afterwards will use this GL context to render.

// [link]

var GL_PREINITIALIZED_CONTEXT = 0;

// Enables support for WebGPU (via "webgpu/webgpu.h").

// [link]

var USE_WEBGPU = 0;

// Enables building of stb-image, a tiny public-domain library for decoding

// images, allowing decoding of images without using the browser's built-in

// decoders. The benefit is that this can be done synchronously, however, it

// will not be as fast as the browser itself. When enabled, stb-image will be

// used automatically from IMG_Load and IMG_Load_RW. You can also call the

// stbi_* functions directly yourself.

// [link]

var STB_IMAGE = 0;

// From Safari 8 (where WebGL was introduced to Safari) onwards, OES_texture_half_float and OES_texture_half_float_linear extensions

// are broken and do not function correctly, when used as source textures.

// See https://bugs.webkit.org/show_bug.cgi?id=183321, https://bugs.webkit.org/show_bug.cgi?id=169999,

// https://stackoverflow.com/questions/54248633/cannot-create-half-float-oes-texture-from-uint16array-on-ipad

// [link]

var GL_DISABLE_HALF_FLOAT_EXTENSION_IF_BROKEN = 0;

// Workaround Safari WebGL issue: After successfully acquiring WebGL context on a canvas,

// calling .getContext() will always return that context independent of which 'webgl' or 'webgl2'

// context version was passed. See https://bugs.webkit.org/show_bug.cgi?id=222758 and

// https://github.com/emscripten-core/emscripten/issues/13295.

// Set this to 0 to force-disable the workaround if you know the issue will not affect you.

var GL_WORKAROUND_SAFARI_GETCONTEXT_BUG = 1;

// Use JavaScript math functions like Math.tan. This saves code size as we can avoid shipping

// compiled musl code. However, it can be significantly slower as it calls out to JS. It

// also may give different results as JS math is specced somewhat differently than libc, and

// can also vary between browsers.

// [link]

var JS_MATH = 0;

// If set, enables polyfilling for Math.clz32, Math.trunc, Math.imul, Math.fround.

// [link]

var POLYFILL_OLD_MATH_FUNCTIONS = 0;

// Set this to enable compatibility emulations for old JavaScript engines. This gives you

// the highest possible probability of the code working everywhere, even in rare old

// browsers and shell environments. Specifically:

// * Add polyfilling for Math.clz32, Math.trunc, Math.imul, Math.fround. (-s POLYFILL_OLD_MATH_FUNCTIONS=1)

// * Work around old Chromium WebGL 1 bug (-s WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG=1)

// * Disable WebAssembly. (Must be paired with -s WASM=0)

// * Adjusts MIN_X_VERSION settings to 0 to include support for all browser versions.

// You can also configure the above options individually.

// [link]

var LEGACY_VM_SUPPORT = 0;

// By default, emscripten output will run on the web, in a web worker,

// in node.js, or in a JS shell like d8, js, or jsc. You can set this option to

// specify that the output should only run in one particular environment, which

// must be one of

// 'web' - the normal web environment.

// 'webview' - just like web, but in a webview like Cordova;

// considered to be same as "web" in almost every place

// 'worker' - a web worker environment.

// 'node' - Node.js.

// 'shell' - a JS shell like d8, js, or jsc.

// Or it can be a comma-separated list of them, e.g., "web,worker". If this is

// the empty string, then all runtime environments are supported.

//

// Note that the set of environments recognized here is not identical to the

// ones we identify at runtime using ENVIRONMENT_IS_*. Specifically:

// * We detect whether we are a pthread at runtime, but that's set for workers

// and not for the main file so it wouldn't make sense to specify here.

// * The webview target is basically a subset of web. It must be specified

// alongside web (e.g. "web,webview") and we only use it for code generation

// at compile time, there is no runtime behavior change.

// [link]

var ENVIRONMENT = '';

// Enable this to support lz4-compressed file packages. They are stored compressed in memory, and

// decompressed on the fly, avoiding storing the entire decompressed data in memory at once.

// If you run the file packager separately, you still need to build the main program with this flag,

// and also pass --lz4 to the file packager.

// (You can also manually compress one on the client, using LZ4.loadPackage(), but that is less

// recommended.)

// Limitations:

// * LZ4-compressed files are only decompressed when needed, so they are not available

// for special preloading operations like pre-decoding of images using browser codecs,

// preloadPlugin stuff, etc.

// * LZ4 files are read-only.

// [link]

var LZ4 = 0;

// Emscripten exception handling options.

// These options only pertain to Emscripten exception handling and do not

// control the experimental native wasm exception handling option.

// Disables generating code to actually catch exceptions. This disabling is on

// by default as the overhead of exceptions is quite high in size and speed

// currently (in the future, wasm should improve that). When exceptions are

// disabled, if an exception actually happens then it will not be caught

// and the program will halt (so this will not introduce silent failures).

//

// XXX note that this removes *catching* of exceptions, which is the main

// issue for speed, but you should build source files with

// -fno-exceptions to really get rid of all exceptions code overhead,

// as it may contain thrown exceptions that are never caught (e.g.

// just using std::vector can have that). -fno-rtti may help as well.

//

// This option is mutually exclusive with EXCEPTION_CATCHING_ALLOWED.

//

// [compile+link] - affects user code at compile and system libraries at link

var DISABLE_EXCEPTION_CATCHING = 1;

// Enables catching exception but only in the listed functions. This

// option acts like a more precise version of `DISABLE_EXCEPTION_CATCHING=0`.

//

// This option is mutually exclusive with DISABLE_EXCEPTION_CATCHING.

//

// [compile+link] - affects user code at compile and system libraries at link

var EXCEPTION_CATCHING_ALLOWED = [];

// By default we handle exit() in node, by catching the Exit exception. However,

// this means we catch all process exceptions. If you disable this, then we no

// longer do that, and exceptions work normally, which can be useful for libraries

// or programs that don't need exit() to work.

// Emscripten uses an ExitStatus exception to halt when exit() is called.

// With this option, we prevent that from showing up as an unhandled

// exception.

// [link]

var NODEJS_CATCH_EXIT = 1;

// Catch unhandled rejections in node. Without this, node may print the error,

// and that this behavior will change in future node, wait a few seconds, and

// then exit with 0 (which hides the error if you don't read the log). With

// this, we catch any unhandled rejection and throw an actual error, which will

// make the process exit immediately with a non-0 return code.

// This should be fixed in Node 15+.

// [link]

var NODEJS_CATCH_REJECTION = 1;

// Whether to transform the code using asyncify. This makes it possible to

// call JS functions from synchronous-looking code in C/C++.

// See https://emscripten.org/docs/porting/asyncify.html

// [link]

var ASYNCIFY = 0;

// Imports which can do an sync operation, in addition to the default ones that

// emscripten defines like emscripten_sleep. If you add more you will need to

// mention them to here, or else they will not work (in ASSERTIONS builds an

// error will be shown).

// Note that this list used to contain the default ones, which meant that you

// had to list them when adding your own; the default ones are now added

// automatically.

// [link]

var ASYNCIFY_IMPORTS = [];

// Whether indirect calls can be on the stack during an unwind/rewind.

// If you know they cannot, then setting this can be extremely helpful, as otherwise asyncify

// must assume an indirect call can reach almost everywhere.

// [link]

var ASYNCIFY_IGNORE_INDIRECT = 0;

// The size of the asyncify stack - the region used to store unwind/rewind

// info. This must be large enough to store the call stack and locals. If it is too

// small, you will see a wasm trap due to executing an "unreachable" instruction.

// In that case, you should increase this size.

// [link]

var ASYNCIFY_STACK_SIZE = 4096;

// If the Asyncify remove-list is provided, then the functions in it will not

// be instrumented even if it looks like they need to. This can be useful

// if you know things the whole-program analysis doesn't, like if you

// know certain indirect calls are safe and won't unwind. But if you

// get the list wrong things will break (and in a production build user

// input might reach code paths you missed during testing, so it's hard

// to know you got this right), so this is not recommended unless you

// really know what are doing, and need to optimize every bit of speed

// and size.

//

// The names in this list are names from the WebAssembly Names section. The

// wasm backend will emit those names in *human-readable* form instead of

// typical C++ mangling. For example, you should write Struct::func()

// instead of _ZN6Struct4FuncEv. C is also different from C++, as C

// names don't end with parameters; as a result foo(int) in C++ would appear

// as just foo in C (C++ has parameters because it needs to differentiate

// overloaded functions). You will see warnings in the console if a name in the

// list is missing (these are not errors because inlining etc. may cause

// changes which would mean a single list couldn't work for both -O0 and -O1

// builds, etc.). You can inspect the wasm binary to look for the actual names,

// either directly or using wasm-objdump or wasm-dis, etc.

//

// Simple '*' wildcard matching is supported.

//

// To avoid dealing with limitations in operating system shells or build system

// escaping, the following substitutions can be made:

// - ' ' -> '.',

// - '&' -> '#',

// - ',' -> '?'.

//

// That is, the function

// "foo(char const*, int&)" can be inputted as

// "foo(char.const*?.int#)" on the command line instead.

//

// Note: Whitespace is part of the function signature! I.e.

// "foo(char const *, int &)" will not match "foo(char const*, int&)", and

// neither would "foo(const char*, int &)".

//

// [link]

var ASYNCIFY_REMOVE = [];

// Functions in the Asyncify add-list are added to the list of instrumented

// functions, that is, they will be instrumented even if otherwise asyncify

// thinks they don't need to be. As by default everything will be instrumented

// in the safest way possible, this is only useful if you use IGNORE_INDIRECT

// and use this list to fix up some indirect calls that *do* need to be

// instrumented.

// See notes on ASYNCIFY_REMOVE about the names.

// [link]

var ASYNCIFY_ADD = [];

// If the Asyncify only-list is provided, then *only* the functions in the list

// will be instrumented. Like the remove-list, getting this wrong will break

// your application.

// See notes on ASYNCIFY_REMOVE about the names.

// [link]

var ASYNCIFY_ONLY = [];

// If enabled will output which functions have been instrumented and why.

// [link]

var ASYNCIFY_ADVISE = 0;

// Allows lazy code loading: where emscripten_lazy_load_code() is written, we

// will pause execution, load the rest of the code, and then resume.

// [link]

var ASYNCIFY_LAZY_LOAD_CODE = 0;

// Runtime debug logging from asyncify internals.

// [link]

var ASYNCIFY_DEBUG = 0;

// Runtime elements that are exported on Module by default. We used to export

// quite a lot here, but have removed them all, so this option is redundant

// given that EXTRA_EXPORTED_RUNTIME_METHODS exists, and so this option exists

// only for backwards compatibility. You should use

// EXTRA_EXPORTED_RUNTIME_METHODS for things you want to export from the

// runtime. Note that methods on this list are only exported if they are

// included (either automatically from linking, or due to being in

// DEFAULT_LIBRARY_FUNCS_TO_INCLUDE).

// Note that the name may be slightly misleading, as this is for any JS library

// element, and not just methods. For example, we can export the FS object by

// having "FS" in this list.

// [link]

var EXPORTED_RUNTIME_METHODS = [];

// Additional methods to those in EXPORTED_RUNTIME_METHODS. Adjusting that list

// lets you remove methods that would be exported by default; setting values in

// this list lets you add to the default list without modifying it.

// [link]

var EXTRA_EXPORTED_RUNTIME_METHODS = [];

// A list of incoming values on the Module object in JS that we care about. If

// a value is not in this list, then we don't emit code to check if you provide

// it on the Module object. For example, if

// you have this:

//

// var Module = {

// print: function(x) { console.log('print: ' + x) },

// preRun: [function() { console.log('pre run') }]

// };

//

// Then MODULE_JS_API must contain 'print' and 'preRun'; if it does not then

// we may not emit code to read and use that value. In other words, this

// option lets you set, statically at compile time, the list of which Module

// JS values you will be providing at runtime, so the compiler can better

// optimize.

//

// Setting this list to [], or at least a short and concise set of names you

// actually use, can be very useful for reducing code size. By default the

// list contains all the possible APIs.

//

// FIXME: should this just be 0 if we want everything?

// [link]

var INCOMING_MODULE_JS_API = [

'ENVIRONMENT', 'GL_MAX_TEXTURE_IMAGE_UNITS', 'SDL_canPlayWithWebAudio',

'SDL_numSimultaneouslyQueuedBuffers', 'INITIAL_MEMORY', 'wasmMemory', 'arguments',

'buffer', 'canvas', 'doNotCaptureKeyboard', 'dynamicLibraries',

'elementPointerLock', 'extraStackTrace', 'forcedAspectRatio',

'instantiateWasm', 'keyboardListeningElement', 'freePreloadedMediaOnUse',

'locateFile', 'logReadFiles', 'mainScriptUrlOrBlob', 'mem',

'monitorRunDependencies', 'noExitRuntime', 'noInitialRun', 'onAbort',

'onCustomMessage', 'onExit', 'onFree', 'onFullScreen', 'onMalloc',

'onRealloc', 'onRuntimeInitialized', 'postMainLoop', 'postRun', 'preInit',

'preMainLoop', 'preRun',

'preinitializedWebGLContext', 'memoryInitializerRequest', 'preloadPlugins',

'print', 'printErr', 'quit', 'setStatus', 'statusMessage', 'stderr',

'stdin', 'stdout', 'thisProgram', 'wasm', 'wasmBinary', 'websocket'

];

// If set to nonzero, the provided virtual filesystem if treated

// case-insensitive, like Windows and macOS do. If set to 0, the VFS is

// case-sensitive, like on Linux.

// [link]

var CASE_INSENSITIVE_FS = 0;

// If set to 0, does not build in any filesystem support. Useful if you are just

// doing pure computation, but not reading files or using any streams (including

// fprintf, and other stdio.h things) or anything related. The one exception is

// there is partial support for printf, and puts, hackishly. The compiler will

// automatically set this if it detects that syscall usage (which is static)

// does not require a full filesystem. If you still want filesystem support, use

// FORCE_FILESYSTEM

// [link]

var FILESYSTEM = 1;

// Makes full filesystem support be included, even if statically it looks like

// it is not used. For example, if your C code uses no files, but you include

// some JS that does, you might need this.

// [link]

var FORCE_FILESYSTEM = 0;

// Enables support for the NODERAWFS filesystem backend. This is a special

// backend as it replaces all normal filesystem access with direct Node.js

// operations, without the need to do `FS.mount()`, and this backend only

// works with Node.js. The initial working directory will be same as

// process.cwd() instead of VFS root directory. Because this mode directly uses

// Node.js to access the real local filesystem on your OS, the code will not

// necessarily be portable between OSes - it will be as portable as a Node.js

// program would be, which means that differences in how the underlying OS

// handles permissions and errors and so forth may be noticeable. This has

// mostly been tested on Linux so far.

// [link]

var NODERAWFS = 0;

// This saves the compiled wasm module in a file with name

// $WASM_BINARY_NAME.$V8_VERSION.cached

// and loads it on subsequent runs. This caches the compiled wasm code from

// v8 in node, which saves compiling on subsequent runs, making them start up

// much faster.

// The V8 version used in node is included in the cache name so that we don't

// try to load cached code from another version, which fails silently (it seems

// to load ok, but we do actually recompile).

// * The only version known to work for sure is node 12.9.1, as this has

// regressed, see

// https://github.com/nodejs/node/issues/18265#issuecomment-622971547

// * The default location of the .cached files is alongside the wasm binary,

// as mentioned earlier. If that is in a read-only directory, you may need

// to place them elsewhere. You can use the locateFile() hook to do so.

// [link]

var NODE_CODE_CACHING = 0;

// Functions that are explicitly exported. These functions are kept alive

// through LLVM dead code elimination, and also made accessible outside of the

// generated code even after running closure compiler (on "Module"). The

// symbols listed here require an `_` prefix.

//

// By default if this setting is not specified on the command line the

// `_main` function will be implicitly exported. In STANDALONE_WASM mode the

// default export is `__start` (or `__initialize` if --no-entry is specified).

// [link]

var EXPORTED_FUNCTIONS = [];

// If true, we export all the symbols that are present in JS onto the Module

// object. This does not affect which symbols will be present - it does not

// prevent DCE or cause anything to be included in linking. It only does

// Module['X'] = X;

// for all X that end up in the JS file. This is useful to export the JS

// library functions on Module, for things like dynamic linking.

// [link]

var EXPORT_ALL = 0;

// Remembers the values of these settings, and makes them accessible

// through Runtime.getCompilerSetting and emscripten_get_compiler_setting.

// To see what is retained, look for compilerSettings in the generated code.

// [link]

var RETAIN_COMPILER_SETTINGS = 0;

// JS library elements (C functions implemented in JS) that we include by

// default. If you want to make sure something is included by the JS compiler,

// add it here. For example, if you do not use some emscripten_* C API call

// from C, but you want to call it from JS, add it here (and in EXPORTED

// FUNCTIONS with prefix "_", if you use closure compiler). Note that the name

// may be slightly misleading, as this is for any JS library element, and not

// just functions. For example, you can include the Browser object by adding

// "$Browser" to this list.

// [link]

var DEFAULT_LIBRARY_FUNCS_TO_INCLUDE = [];

// This list is also used to determine auto-exporting of library dependencies

// (i.e., functions that might be dependencies of JS library functions, that if

// so we must export so that if they are implemented in C they will be

// accessible, in ASM_JS mode).

// [link]

var LIBRARY_DEPS_TO_AUTOEXPORT = ['memcpy'];

// Include all JS library functions instead of the sum of

// DEFAULT_LIBRARY_FUNCS_TO_INCLUDE + any functions used by the generated code.

// This is needed when dynamically loading (i.e. dlopen) modules that make use

// of runtime library functions that are not used in the main module. Note that

// this only applies to js libraries, *not* C. You will need the main file to

// include all needed C libraries. For example, if a module uses malloc or new,

// you will need to use those in the main file too to pull in malloc for use by

// the module.

// [link]

var INCLUDE_FULL_LIBRARY = 0;

// Set this to a string to override the shell file used

// [link]

var SHELL_FILE = 0;

// If set to 1, we emit relocatable code from the LLVM backend; both

// globals and function pointers are all offset (by gb and fp, respectively)

// Automatically set for SIDE_MODULE or MAIN_MODULE.

// [compile+link]

var RELOCATABLE = 0;

// A main module is a file compiled in a way that allows us to link it to

// a side module at runtime.

// 1: Normal main module.

// 2: DCE'd main module. We eliminate dead code normally. If a side

// module needs something from main, it is up to you to make sure

// it is kept alive.

// [compile+link]

var MAIN_MODULE = 0;

// Corresponds to MAIN_MODULE (also supports modes 1 and 2)

// [compile+link]

var SIDE_MODULE = 0;

// If this is a shared object (MAIN_MODULE == 1 || SIDE_MODULE == 1), then we

// will link these at runtime. They must have been built with SIDE_MODULE == 1.

// In most cases it is simpler to pass the filenames directly on the commandline

// instead.

// [link]

var RUNTIME_LINKED_LIBS = [];

// If set to 1, this is a worker library, a special kind of library that is run

// in a worker. See emscripten.h

// [link]

var BUILD_AS_WORKER = 0;

// If set to 1, we build the project into a js file that will run in a worker,

// and generate an html file that proxies input and output to/from it.

// [link]

var PROXY_TO_WORKER = 0;

// If set, the script file name the main thread loads. Useful if your project

// doesn't run the main emscripten- generated script immediately but does some

// setup before

// [link]

var PROXY_TO_WORKER_FILENAME = '';

// If set to 1, compiles in a small stub main() in between the real main() which

// calls pthread_create() to run the application main() in a pthread. This is