Fixes a bug where the environment scope is not passed to the autocomplete typechecker, so environment-related types are not provided.
This caused an issue where `getModuleEnvironment` returns `typeChecker.globalScope` when there is no environment. We pass this through to `typeCheckerForAutocomplete.check()` then environmentscope is no longer nullopt and it will use `typeChecker.globalScope` instead of falling back to `typeCheckerForAutocomplete.globalScope`.
This is solved by passing `forAutocomplete` to `getModuleEnvironment` so it falls back to the autocomplete global scope if none found.
- Fix autocomplete not suggesting globals defined after the cursor (fixes#622)
- Improve type checker stability
- Reduce parser C stack consumption which fixes some stack overflow crashes on deeply nested sources
- Improve performance of bit32.extract/replace when width is implied (~3% faster chess)
- Improve performance of bit32.extract when field/width are constants (~10% faster base64)
- Heap dump now annotates thread stacks with local variable/function names
In case a large userdata size is passed to lua_newuserdatadtor it might overflow the size resulting in luaU_newudata actually allocating the object without a memory error. This will then result in overwriting part of the metatable pointer of the userdata.
This PR fixes this issue by checking for the overflow and in such cases pass a size value which will cause a memory error in luaU_newudata.
Closes#599
Not sure if these context definitions are distinct enough, but they work for my use cases.
I repurposed (a majority of) the existing unit tests for this, but if it should live in separate test cases let me know
---
* Add autocomplete context to result
* Update tests
* Remove comments
* Fix expression context issues
We make four adjustments in this RFC:
1. `{{` is not allowed. This is likely a valid but poor attempt at escaping coming from C#, Rust, or Python.
2. We now allow `` `this` `` with zero interpolating expressions.
3. We now allow `` f `this` `` also.
4. Explicitly say that `` `this` `` and `` `this {that}` `` are not valid type annotation syntax.
When considering new standard library functions, we essentially need to strongly justify their existence over their implementation in Luau in user library code.
This PR attempts to provide a few axes of consideration; ideally new library functions tick many of the boxes, eg "used often + is more performant + clear unambiguous interface" is an ideal consideration for a library function, whereas if it's merely accelerating a single specific use case for a single application it's unlikely to be a good justification for inclusion.
Fix description incorrectly saying that parameter w specifies an upper range. w is actually a width. Proof:
print(bit32.extract(2^32-1, 3, 4)) -- prints 15, not 1.
Also indicate that the position is 0-based, and that the function will error if the selected range exceeds the allowed bounds.
