Pass environment scope to autocomplete typechecker

[JohnnyMorganz]

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.

[JohnnyMorganz]

There is a potential issue here since when you create a new environment scope, it uses typeChecker.globalScope as the base, not the autocomplete one.

If typeCheckerForAutocomplete.globalScope deviates from typeChecker.globalScope, this will not be replicated to environment scopes.

This might require unique environment scopes being created for each type checker instead

[andyfriesen]

Thanks!

[JohnnyMorganz]

@andyfriesen Any thoughts on the problem above?

In Luau LSP we modify typeCheckerForAutocomplete to provide more expressive DM types not present in the base type checker (which AIUI Studio does as well). For environment scopes though, there is no differentiation between the two so we can't do this.

Probably a separate issue to this though.

[andyfriesen]

What we're doing now is wrong but benign because we should be properly respecting scope and type lifetimes, but I see what you're saying.

The least-worst thing is probably to have a parallel data structure to Frontend::environments for the autocomplete environments, but that invites a whole lot more unpleasantness as that trickles out into the rest of the class.