luau/.gitignore

/build/
/build[.-]*/
/out
/cmake/
/cmake[.-]*/
/coverage/
/.vs/
/.vscode/
/fuzz/luau.pb.*
/crash-*
/default.prof*
/fuzz-*
/luau
/luau-tests
/luau-analyze
/luau-compile
__pycache__
.cache
.clangd
Sync to upstream/release/509 (#303) - Rework transaction log used for type checking which should result in more robust type checking internals with fewer bugs - Reduce the amount of memory consumed by type checker on large module graphs - Type checker now errors on attempts to change the type of imported module fields - The return type of newproxy is now any (fixes #296) - Implement new number printing algorithm (Schubfach) which makes tostring() produce precise (round-trippable) and short decimal output up to 10x faster - Fix lua_Debug::linedefined to point to the line with the function definition instead of the first statement (fixes #265) - Fix minor bugs in Tab completion in Repl - Repl now saves/restores command history in ~/.luau_history 2022-01-07 01:46:53 +00:00			`/build/`
			`/build[.-]*/`
Add default "out" folder for CMake Project Visual Studio (#1394) https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=msvc-170#ide-integration Apparently ``/out`` is a default folder when opening the project as a CMake project in Visual Studio.   Could it be added to the ``.gitignore`` please. ![image](https://github.com/user-attachments/assets/10add17c-bbfc-4811-8c43-0ed2e84c5b9e) 2024-09-13 17:51:10 +01:00			`/out`
add cmake folder to .gitignore (#1246) In the readme file under the building section, it specifies that you should run the command `mkdir cmake && cd cmake`; however, the folder is not currently being ignored. 2024-05-22 21:07:15 +01:00			`/cmake/`
			`/cmake[.-]*/`
Sync to upstream/release/509 (#303) - Rework transaction log used for type checking which should result in more robust type checking internals with fewer bugs - Reduce the amount of memory consumed by type checker on large module graphs - Type checker now errors on attempts to change the type of imported module fields - The return type of newproxy is now any (fixes #296) - Implement new number printing algorithm (Schubfach) which makes tostring() produce precise (round-trippable) and short decimal output up to 10x faster - Fix lua_Debug::linedefined to point to the line with the function definition instead of the first statement (fixes #265) - Fix minor bugs in Tab completion in Repl - Repl now saves/restores command history in ~/.luau_history 2022-01-07 01:46:53 +00:00			`/coverage/`
			`/.vs/`
			`/.vscode/`
			`/fuzz/luau.pb.*`
			`/crash-*`
			`/default.prof*`
			`/fuzz-*`
			`/luau`
Sync to upstream/release/539 (#625) 2022-08-04 23:35:33 +01:00			`/luau-tests`
			`/luau-analyze`
Add luau-compile to .gitignore (#995) 2023-08-08 00:26:16 +01:00			`/luau-compile`
Sync to upstream/release/538 (#616) 2022-07-29 05:24:07 +01:00			`__pycache__`
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-16 18:35:20 +01:00			`.cache`
			`.clangd`