2021-10-30 04:25:12 +08:00
|
|
|
# This file is part of the Luau programming language and is licensed under MIT License; see LICENSE.txt for details
|
2021-11-05 23:47:21 +08:00
|
|
|
.SUFFIXES:
|
2021-10-30 04:25:12 +08:00
|
|
|
MAKEFLAGS+=-r -j8
|
|
|
|
|
COMMA=,
|
|
|
|
|
|
2023-11-11 05:10:07 +08:00
|
|
|
CMAKE_PATH=cmake
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
config=debug
|
2022-10-07 08:23:29 +08:00
|
|
|
protobuf=system
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
BUILD=build/$(config)
|
|
|
|
|
|
|
|
|
|
AST_SOURCES=$(wildcard Ast/src/*.cpp)
|
|
|
|
|
AST_OBJECTS=$(AST_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
AST_TARGET=$(BUILD)/libluauast.a
|
|
|
|
|
|
|
|
|
|
COMPILER_SOURCES=$(wildcard Compiler/src/*.cpp)
|
|
|
|
|
COMPILER_OBJECTS=$(COMPILER_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
COMPILER_TARGET=$(BUILD)/libluaucompiler.a
|
|
|
|
|
|
2023-08-19 02:15:41 +08:00
|
|
|
CONFIG_SOURCES=$(wildcard Config/src/*.cpp)
|
|
|
|
|
CONFIG_OBJECTS=$(CONFIG_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
CONFIG_TARGET=$(BUILD)/libluauconfig.a
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
ANALYSIS_SOURCES=$(wildcard Analysis/src/*.cpp)
|
|
|
|
|
ANALYSIS_OBJECTS=$(ANALYSIS_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
ANALYSIS_TARGET=$(BUILD)/libluauanalysis.a
|
|
|
|
|
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
EQSAT_SOURCES=$(wildcard EqSat/src/*.cpp)
|
|
|
|
|
EQSAT_OBJECTS=$(EQSAT_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
EQSAT_TARGET=$(BUILD)/libluaueqsat.a
|
|
|
|
|
|
2022-05-27 06:08:16 +08:00
|
|
|
CODEGEN_SOURCES=$(wildcard CodeGen/src/*.cpp)
|
|
|
|
|
CODEGEN_OBJECTS=$(CODEGEN_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
CODEGEN_TARGET=$(BUILD)/libluaucodegen.a
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
VM_SOURCES=$(wildcard VM/src/*.cpp)
|
|
|
|
|
VM_OBJECTS=$(VM_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
VM_TARGET=$(BUILD)/libluauvm.a
|
|
|
|
|
|
2022-02-05 00:45:57 +08:00
|
|
|
ISOCLINE_SOURCES=extern/isocline/src/isocline.c
|
|
|
|
|
ISOCLINE_OBJECTS=$(ISOCLINE_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
ISOCLINE_TARGET=$(BUILD)/libisocline.a
|
|
|
|
|
|
2023-12-02 15:46:57 +08:00
|
|
|
TESTS_SOURCES=$(wildcard tests/*.cpp) CLI/FileUtils.cpp CLI/Flags.cpp CLI/Profiler.cpp CLI/Coverage.cpp CLI/Repl.cpp CLI/Require.cpp
|
2021-10-30 04:25:12 +08:00
|
|
|
TESTS_OBJECTS=$(TESTS_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
TESTS_TARGET=$(BUILD)/luau-tests
|
|
|
|
|
|
2023-12-02 15:46:57 +08:00
|
|
|
REPL_CLI_SOURCES=CLI/FileUtils.cpp CLI/Flags.cpp CLI/Profiler.cpp CLI/Coverage.cpp CLI/Repl.cpp CLI/ReplEntry.cpp CLI/Require.cpp
|
2021-10-30 04:25:12 +08:00
|
|
|
REPL_CLI_OBJECTS=$(REPL_CLI_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
REPL_CLI_TARGET=$(BUILD)/luau
|
|
|
|
|
|
2022-07-22 05:16:54 +08:00
|
|
|
ANALYZE_CLI_SOURCES=CLI/FileUtils.cpp CLI/Flags.cpp CLI/Analyze.cpp
|
2021-10-30 04:25:12 +08:00
|
|
|
ANALYZE_CLI_OBJECTS=$(ANALYZE_CLI_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
ANALYZE_CLI_TARGET=$(BUILD)/luau-analyze
|
|
|
|
|
|
2023-06-10 01:08:00 +08:00
|
|
|
COMPILE_CLI_SOURCES=CLI/FileUtils.cpp CLI/Flags.cpp CLI/Compile.cpp
|
|
|
|
|
COMPILE_CLI_OBJECTS=$(COMPILE_CLI_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
COMPILE_CLI_TARGET=$(BUILD)/luau-compile
|
|
|
|
|
|
2023-11-18 02:46:18 +08:00
|
|
|
BYTECODE_CLI_SOURCES=CLI/FileUtils.cpp CLI/Flags.cpp CLI/Bytecode.cpp
|
|
|
|
|
BYTECODE_CLI_OBJECTS=$(BYTECODE_CLI_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
BYTECODE_CLI_TARGET=$(BUILD)/luau-bytecode
|
|
|
|
|
|
2021-12-03 14:41:04 +08:00
|
|
|
FUZZ_SOURCES=$(wildcard fuzz/*.cpp) fuzz/luau.pb.cpp
|
2021-10-30 04:25:12 +08:00
|
|
|
FUZZ_OBJECTS=$(FUZZ_SOURCES:%=$(BUILD)/%.o)
|
|
|
|
|
|
|
|
|
|
TESTS_ARGS=
|
|
|
|
|
ifneq ($(flags),)
|
|
|
|
|
TESTS_ARGS+=--fflags=$(flags)
|
|
|
|
|
endif
|
2022-07-15 06:52:26 +08:00
|
|
|
ifneq ($(opt),)
|
|
|
|
|
TESTS_ARGS+=-O$(opt)
|
|
|
|
|
endif
|
2021-10-30 04:25:12 +08:00
|
|
|
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
OBJECTS=$(AST_OBJECTS) $(COMPILER_OBJECTS) $(CONFIG_OBJECTS) $(ANALYSIS_OBJECTS) $(EQSAT_OBJECTS) $(CODEGEN_OBJECTS) $(VM_OBJECTS) $(ISOCLINE_OBJECTS) $(TESTS_OBJECTS) $(REPL_CLI_OBJECTS) $(ANALYZE_CLI_OBJECTS) $(COMPILE_CLI_OBJECTS) $(BYTECODE_CLI_OBJECTS) $(FUZZ_OBJECTS)
|
2023-11-18 02:46:18 +08:00
|
|
|
EXECUTABLE_ALIASES = luau luau-analyze luau-compile luau-bytecode luau-tests
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
# common flags
|
2021-11-12 22:56:25 +08:00
|
|
|
CXXFLAGS=-g -Wall
|
2021-10-30 04:25:12 +08:00
|
|
|
LDFLAGS=
|
|
|
|
|
|
2021-11-12 22:56:25 +08:00
|
|
|
# some gcc versions treat var in `if (type var = val)` as unused
|
|
|
|
|
# some gcc versions treat variables used in constexpr if blocks as unused
|
2021-11-06 03:39:27 +08:00
|
|
|
ifeq ($(findstring g++,$(shell $(CXX) --version)),g++)
|
|
|
|
|
CXXFLAGS+=-Wno-unused
|
|
|
|
|
endif
|
2021-10-30 04:25:12 +08:00
|
|
|
|
2021-11-12 22:56:25 +08:00
|
|
|
# enabled in CI; we should be warning free on our main compiler versions but don't guarantee being warning free everywhere
|
|
|
|
|
ifneq ($(werror),)
|
|
|
|
|
CXXFLAGS+=-Werror
|
|
|
|
|
endif
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
# configuration-specific flags
|
|
|
|
|
ifeq ($(config),release)
|
2022-10-28 18:37:29 +08:00
|
|
|
CXXFLAGS+=-O2 -DNDEBUG -fno-math-errno
|
2021-10-30 04:25:12 +08:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(config),coverage)
|
|
|
|
|
CXXFLAGS+=-fprofile-instr-generate -fcoverage-mapping
|
|
|
|
|
LDFLAGS+=-fprofile-instr-generate
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(config),sanitize)
|
|
|
|
|
CXXFLAGS+=-fsanitize=address -O1
|
|
|
|
|
LDFLAGS+=-fsanitize=address
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(config),analyze)
|
|
|
|
|
CXXFLAGS+=--analyze
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(config),fuzz)
|
2022-08-26 05:53:50 +08:00
|
|
|
CXXFLAGS+=-fsanitize=address,fuzzer -Ibuild/libprotobuf-mutator -O2
|
2021-10-30 04:25:12 +08:00
|
|
|
LDFLAGS+=-fsanitize=address,fuzzer
|
2022-10-07 08:23:29 +08:00
|
|
|
LPROTOBUF=-lprotobuf
|
|
|
|
|
DPROTOBUF=-D CMAKE_BUILD_TYPE=Release -D LIB_PROTO_MUTATOR_TESTING=OFF
|
|
|
|
|
EPROTOC=protoc
|
2021-10-30 04:25:12 +08:00
|
|
|
endif
|
|
|
|
|
|
2022-08-12 05:01:33 +08:00
|
|
|
ifeq ($(config),profile)
|
2022-10-28 18:37:29 +08:00
|
|
|
CXXFLAGS+=-O2 -DNDEBUG -fno-math-errno -gdwarf-4 -DCALLGRIND=1
|
2022-07-05 02:13:07 +08:00
|
|
|
endif
|
|
|
|
|
|
2022-10-07 08:23:29 +08:00
|
|
|
ifeq ($(protobuf),download)
|
|
|
|
|
CXXFLAGS+=-Ibuild/libprotobuf-mutator/external.protobuf/include
|
|
|
|
|
LPROTOBUF=build/libprotobuf-mutator/external.protobuf/lib/libprotobuf.a
|
|
|
|
|
DPROTOBUF+=-D LIB_PROTO_MUTATOR_DOWNLOAD_PROTOBUF=ON
|
|
|
|
|
EPROTOC=../build/libprotobuf-mutator/external.protobuf/bin/protoc
|
|
|
|
|
endif
|
|
|
|
|
|
2022-10-15 03:48:41 +08:00
|
|
|
ifneq ($(native),)
|
|
|
|
|
TESTS_ARGS+=--codegen
|
|
|
|
|
endif
|
|
|
|
|
|
2023-03-25 02:03:04 +08:00
|
|
|
ifneq ($(nativelj),)
|
2023-08-26 01:23:55 +08:00
|
|
|
CXXFLAGS+=-DLUA_USE_LONGJMP=1
|
2023-03-25 02:03:04 +08:00
|
|
|
TESTS_ARGS+=--codegen
|
|
|
|
|
endif
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
# target-specific flags
|
2022-05-27 06:08:16 +08:00
|
|
|
$(AST_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include
|
|
|
|
|
$(COMPILER_OBJECTS): CXXFLAGS+=-std=c++17 -ICompiler/include -ICommon/include -IAst/include
|
2023-08-19 02:15:41 +08:00
|
|
|
$(CONFIG_OBJECTS): CXXFLAGS+=-std=c++17 -IConfig/include -ICommon/include -IAst/include
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(ANALYSIS_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include -IAnalysis/include -IEqSat/include -IConfig/include
|
|
|
|
|
$(EQSAT_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IEqSat/include
|
2022-09-24 03:17:25 +08:00
|
|
|
$(CODEGEN_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -ICodeGen/include -IVM/include -IVM/src # Code generation needs VM internals
|
2022-05-27 06:08:16 +08:00
|
|
|
$(VM_OBJECTS): CXXFLAGS+=-std=c++11 -ICommon/include -IVM/include
|
2022-02-05 00:45:57 +08:00
|
|
|
$(ISOCLINE_OBJECTS): CXXFLAGS+=-Wno-unused-function -Iextern/isocline/include
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(TESTS_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include -ICompiler/include -IConfig/include -IAnalysis/include -IEqSat/include -ICodeGen/include -IVM/include -ICLI -Iextern -DDOCTEST_CONFIG_DOUBLE_STRINGIFY
|
2022-10-15 03:48:41 +08:00
|
|
|
$(REPL_CLI_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include -ICompiler/include -IVM/include -ICodeGen/include -Iextern -Iextern/isocline/include
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(ANALYZE_CLI_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include -IAnalysis/include -IEqSat/include -IConfig/include -Iextern
|
2023-06-10 01:08:00 +08:00
|
|
|
$(COMPILE_CLI_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include -ICompiler/include -IVM/include -ICodeGen/include
|
2023-11-18 02:46:18 +08:00
|
|
|
$(BYTECODE_CLI_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include -ICompiler/include -IVM/include -ICodeGen/include
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(FUZZ_OBJECTS): CXXFLAGS+=-std=c++17 -ICommon/include -IAst/include -ICompiler/include -IAnalysis/include -IEqSat/include -IVM/include -ICodeGen/include -IConfig/include
|
2021-10-30 04:25:12 +08:00
|
|
|
|
2022-01-28 07:46:05 +08:00
|
|
|
$(TESTS_TARGET): LDFLAGS+=-lpthread
|
2021-10-30 04:25:12 +08:00
|
|
|
$(REPL_CLI_TARGET): LDFLAGS+=-lpthread
|
2023-05-20 03:37:30 +08:00
|
|
|
$(ANALYZE_CLI_TARGET): LDFLAGS+=-lpthread
|
2022-10-07 08:23:29 +08:00
|
|
|
fuzz-proto fuzz-prototest: LDFLAGS+=build/libprotobuf-mutator/src/libfuzzer/libprotobuf-mutator-libfuzzer.a build/libprotobuf-mutator/src/libprotobuf-mutator.a $(LPROTOBUF)
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
# pseudo targets
|
2022-07-22 05:16:54 +08:00
|
|
|
.PHONY: all test clean coverage format luau-size aliases
|
2021-10-30 04:25:12 +08:00
|
|
|
|
2022-07-22 05:16:54 +08:00
|
|
|
all: $(REPL_CLI_TARGET) $(ANALYZE_CLI_TARGET) $(TESTS_TARGET) aliases
|
|
|
|
|
|
2022-08-05 06:35:33 +08:00
|
|
|
aliases: $(EXECUTABLE_ALIASES)
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
test: $(TESTS_TARGET)
|
|
|
|
|
$(TESTS_TARGET) $(TESTS_ARGS)
|
|
|
|
|
|
2023-03-18 03:20:37 +08:00
|
|
|
conformance: $(TESTS_TARGET)
|
|
|
|
|
$(TESTS_TARGET) $(TESTS_ARGS) -ts=Conformance
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
clean:
|
|
|
|
|
rm -rf $(BUILD)
|
2022-08-05 06:35:33 +08:00
|
|
|
rm -rf $(EXECUTABLE_ALIASES)
|
2021-10-30 04:25:12 +08:00
|
|
|
|
2023-06-24 14:19:39 +08:00
|
|
|
coverage: $(TESTS_TARGET) $(COMPILE_CLI_TARGET)
|
2021-10-30 04:25:12 +08:00
|
|
|
$(TESTS_TARGET)
|
2022-10-18 01:02:21 +08:00
|
|
|
mv default.profraw tests.profraw
|
|
|
|
|
$(TESTS_TARGET) --fflags=true
|
|
|
|
|
mv default.profraw tests-flags.profraw
|
2024-08-24 00:35:30 +08:00
|
|
|
$(TESTS_TARGET) --fflags=true,DebugLuauDeferredConstraintResolution=true
|
2024-07-23 23:08:32 +08:00
|
|
|
mv default.profraw tests-dcr.profraw
|
2022-10-18 01:02:21 +08:00
|
|
|
$(TESTS_TARGET) -ts=Conformance --codegen
|
|
|
|
|
mv default.profraw codegen.profraw
|
|
|
|
|
$(TESTS_TARGET) -ts=Conformance --codegen --fflags=true
|
|
|
|
|
mv default.profraw codegen-flags.profraw
|
2023-06-24 14:19:39 +08:00
|
|
|
$(COMPILE_CLI_TARGET) --codegennull --target=a64 tests/conformance
|
|
|
|
|
mv default.profraw codegen-a64.profraw
|
|
|
|
|
$(COMPILE_CLI_TARGET) --codegennull --target=x64 tests/conformance
|
|
|
|
|
mv default.profraw codegen-x64.profraw
|
|
|
|
|
llvm-profdata merge *.profraw -o default.profdata
|
2022-10-18 01:02:21 +08:00
|
|
|
rm *.profraw
|
2023-07-08 04:10:48 +08:00
|
|
|
llvm-cov show -format=html -show-instantiations=false -show-line-counts=true -show-region-summary=false -ignore-filename-regex=\(tests\|extern\|CLI\)/.* -output-dir=coverage --instr-profile default.profdata -object build/coverage/luau-tests -object build/coverage/luau-compile
|
|
|
|
|
llvm-cov report -ignore-filename-regex=\(tests\|extern\|CLI\)/.* -show-region-summary=false --instr-profile default.profdata -object build/coverage/luau-tests -object build/coverage/luau-compile
|
|
|
|
|
llvm-cov export -ignore-filename-regex=\(tests\|extern\|CLI\)/.* -format lcov --instr-profile default.profdata -object build/coverage/luau-tests -object build/coverage/luau-compile >coverage.info
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
format:
|
2022-09-09 06:14:25 +08:00
|
|
|
git ls-files '*.h' '*.cpp' | xargs clang-format-11 -i
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
luau-size: luau
|
|
|
|
|
nm --print-size --demangle luau | grep ' t void luau_execute<false>' | awk -F ' ' '{sum += strtonum("0x" $$2)} END {print sum " interpreter" }'
|
|
|
|
|
nm --print-size --demangle luau | grep ' t luauF_' | awk -F ' ' '{sum += strtonum("0x" $$2)} END {print sum " builtins" }'
|
|
|
|
|
|
2022-09-09 06:14:25 +08:00
|
|
|
check-source:
|
|
|
|
|
git ls-files '*.h' '*.cpp' | xargs -I+ sh -c 'grep -L LICENSE +'
|
|
|
|
|
git ls-files '*.h' ':!:extern' | xargs -I+ sh -c 'grep -L "#pragma once" +'
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
# executable target aliases
|
|
|
|
|
luau: $(REPL_CLI_TARGET)
|
2021-12-11 06:05:05 +08:00
|
|
|
ln -fs $^ $@
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
luau-analyze: $(ANALYZE_CLI_TARGET)
|
2021-12-11 06:05:05 +08:00
|
|
|
ln -fs $^ $@
|
2021-10-30 04:25:12 +08:00
|
|
|
|
2023-06-10 01:08:00 +08:00
|
|
|
luau-compile: $(COMPILE_CLI_TARGET)
|
|
|
|
|
ln -fs $^ $@
|
|
|
|
|
|
2023-11-18 02:46:18 +08:00
|
|
|
luau-bytecode: $(BYTECODE_CLI_TARGET)
|
|
|
|
|
ln -fs $^ $@
|
|
|
|
|
|
2022-08-05 06:35:33 +08:00
|
|
|
luau-tests: $(TESTS_TARGET)
|
|
|
|
|
ln -fs $^ $@
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
# executable targets
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(TESTS_TARGET): $(TESTS_OBJECTS) $(ANALYSIS_TARGET) $(EQSAT_TARGET) $(COMPILER_TARGET) $(CONFIG_TARGET) $(AST_TARGET) $(CODEGEN_TARGET) $(VM_TARGET) $(ISOCLINE_TARGET)
|
2023-12-02 15:46:57 +08:00
|
|
|
$(REPL_CLI_TARGET): $(REPL_CLI_OBJECTS) $(COMPILER_TARGET) $(CONFIG_TARGET) $(AST_TARGET) $(CODEGEN_TARGET) $(VM_TARGET) $(ISOCLINE_TARGET)
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(ANALYZE_CLI_TARGET): $(ANALYZE_CLI_OBJECTS) $(ANALYSIS_TARGET) $(EQSAT_TARGET) $(AST_TARGET) $(CONFIG_TARGET)
|
2023-06-10 01:08:00 +08:00
|
|
|
$(COMPILE_CLI_TARGET): $(COMPILE_CLI_OBJECTS) $(COMPILER_TARGET) $(AST_TARGET) $(CODEGEN_TARGET) $(VM_TARGET)
|
2023-11-18 02:46:18 +08:00
|
|
|
$(BYTECODE_CLI_TARGET): $(BYTECODE_CLI_OBJECTS) $(COMPILER_TARGET) $(AST_TARGET) $(CODEGEN_TARGET) $(VM_TARGET)
|
2021-10-30 04:25:12 +08:00
|
|
|
|
2023-11-18 02:46:18 +08:00
|
|
|
$(TESTS_TARGET) $(REPL_CLI_TARGET) $(ANALYZE_CLI_TARGET) $(COMPILE_CLI_TARGET) $(BYTECODE_CLI_TARGET):
|
2021-10-30 04:25:12 +08:00
|
|
|
$(CXX) $^ $(LDFLAGS) -o $@
|
|
|
|
|
|
|
|
|
|
# executable targets for fuzzing
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
fuzz-%: $(BUILD)/fuzz/%.cpp.o $(ANALYSIS_TARGET) $(EQSAT_TARGET) $(COMPILER_TARGET) $(AST_TARGET) $(CONFIG_TARGET) $(CODEGEN_TARGET) $(VM_TARGET)
|
2021-11-12 22:27:34 +08:00
|
|
|
$(CXX) $^ $(LDFLAGS) -o $@
|
|
|
|
|
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
fuzz-proto: $(BUILD)/fuzz/proto.cpp.o $(BUILD)/fuzz/protoprint.cpp.o $(BUILD)/fuzz/luau.pb.cpp.o $(ANALYSIS_TARGET) $(EQSAT_TARGET) $(COMPILER_TARGET) $(AST_TARGET) $(CONFIG_TARGET) $(VM_TARGET) | build/libprotobuf-mutator
|
|
|
|
|
fuzz-prototest: $(BUILD)/fuzz/prototest.cpp.o $(BUILD)/fuzz/protoprint.cpp.o $(BUILD)/fuzz/luau.pb.cpp.o $(ANALYSIS_TARGET) $(EQSAT_TARGET) $(COMPILER_TARGET) $(AST_TARGET) $(CONFIG_TARGET) $(VM_TARGET) | build/libprotobuf-mutator
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
# static library targets
|
|
|
|
|
$(AST_TARGET): $(AST_OBJECTS)
|
|
|
|
|
$(COMPILER_TARGET): $(COMPILER_OBJECTS)
|
2023-08-19 02:15:41 +08:00
|
|
|
$(CONFIG_TARGET): $(CONFIG_OBJECTS)
|
2021-10-30 04:25:12 +08:00
|
|
|
$(ANALYSIS_TARGET): $(ANALYSIS_OBJECTS)
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(EQSAT_TARGET): $(EQSAT_OBJECTS)
|
2022-05-27 06:08:16 +08:00
|
|
|
$(CODEGEN_TARGET): $(CODEGEN_OBJECTS)
|
2021-10-30 04:25:12 +08:00
|
|
|
$(VM_TARGET): $(VM_OBJECTS)
|
2022-02-05 00:45:57 +08:00
|
|
|
$(ISOCLINE_TARGET): $(ISOCLINE_OBJECTS)
|
2021-10-30 04:25:12 +08:00
|
|
|
|
Equality graphs (#1285)
Working towards a full e-graph implementation as described by the [egg
paper](https://arxiv.org/pdf/2004.03082).
The type system has a couple of places where e-graphs would've been
useful and solved some classes of problems trivially. For example:
1. Normalization and simplification cannot handle cyclic types due to
the nature of their implementation.
2. Normalization can't tell when two tables or functions are equivalent,
but simplification theoretically can albeit not implemented.
3. Normalization requires deep normalization for inhabitance check,
whereas simplification would've returned the `never` type itself
indicating uninhabited.
4. Simplification requires constraint ordering to have perfect timing to
simplify.
5. Adding a rewrite rule requires implementing it twice, once in
simplification and once again in normalization with completely different
code design making it hard to verify that their behavior is materially
equivalent.
6. In cases where we must cache for performance, two different types
that are isomorphic have different cache entries resulting in cache
misses.
7. Type family reduction can handle cyclic type families, but only if
the cycle is not obscured by a different type family instance. (`t1
where t1 = union<number, add<t1, number>>` is irreducible)
I think we're getting the point!
---
Currently the implementation is missing a few features that makes
e-graphs actually useful. Those will be coming in a future PR.
1. Pattern matching,
6. Applying rewrites,
7. Rewrite until saturation, and
8. Extracting the best e-node according to some cost function.
2024-07-17 01:35:20 +08:00
|
|
|
$(AST_TARGET) $(COMPILER_TARGET) $(CONFIG_TARGET) $(ANALYSIS_TARGET) $(EQSAT_TARGET) $(CODEGEN_TARGET) $(VM_TARGET) $(ISOCLINE_TARGET):
|
2021-10-30 04:25:12 +08:00
|
|
|
ar rcs $@ $^
|
|
|
|
|
|
|
|
|
|
# object file targets
|
|
|
|
|
$(BUILD)/%.cpp.o: %.cpp
|
|
|
|
|
@mkdir -p $(dir $@)
|
|
|
|
|
$(CXX) $< $(CXXFLAGS) -c -MMD -MP -o $@
|
|
|
|
|
|
2022-02-05 00:45:57 +08:00
|
|
|
$(BUILD)/%.c.o: %.c
|
|
|
|
|
@mkdir -p $(dir $@)
|
|
|
|
|
$(CXX) -x c $< $(CXXFLAGS) -c -MMD -MP -o $@
|
|
|
|
|
|
2021-10-30 04:25:12 +08:00
|
|
|
# protobuf fuzzer setup
|
|
|
|
|
fuzz/luau.pb.cpp: fuzz/luau.proto build/libprotobuf-mutator
|
2022-10-07 08:23:29 +08:00
|
|
|
cd fuzz && $(EPROTOC) luau.proto --cpp_out=.
|
2021-10-30 04:25:12 +08:00
|
|
|
mv fuzz/luau.pb.cc fuzz/luau.pb.cpp
|
|
|
|
|
|
2021-12-03 14:41:04 +08:00
|
|
|
$(BUILD)/fuzz/proto.cpp.o: fuzz/luau.pb.cpp
|
|
|
|
|
$(BUILD)/fuzz/protoprint.cpp.o: fuzz/luau.pb.cpp
|
2023-11-11 05:10:07 +08:00
|
|
|
$(BUILD)/fuzz/prototest.cpp.o: fuzz/luau.pb.cpp
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
build/libprotobuf-mutator:
|
|
|
|
|
git clone https://github.com/google/libprotobuf-mutator build/libprotobuf-mutator
|
2023-09-02 01:58:27 +08:00
|
|
|
git -C build/libprotobuf-mutator checkout 212a7be1eb08e7f9c79732d2aab9b2097085d936
|
2023-11-11 05:10:07 +08:00
|
|
|
$(CMAKE_PATH) -DCMAKE_CXX_COMPILER=$(CMAKE_CXX) -DCMAKE_C_COMPILER=$(CMAKE_CC) -DCMAKE_CXX_COMPILER_LAUNCHER=$(CMAKE_PROXY) -S build/libprotobuf-mutator -B build/libprotobuf-mutator $(DPROTOBUF)
|
|
|
|
|
$(MAKE) -C build/libprotobuf-mutator
|
2021-10-30 04:25:12 +08:00
|
|
|
|
|
|
|
|
# picks up include dependencies for all object files
|
|
|
|
|
-include $(OBJECTS:.o=.d)
|