High-complexity modules prevent the type checker from operating properly

[Xan_TheDragon (Xan)]

Reproduction Steps
This report relies on the Luau-powered Autocomplete beta being enabled. A script can be used to procedurally cause this issue.

1. Create a new ModuleScript in the workspace. It should not have its name changed.
2. Execute the following script in the command bar. This will set the module to use strict type checking, contain 250 methods, and each method will cast self to a type representing the module.

local src = "--!strict\nlocal Module = {}\n"
for i = 1, 250 do
	local methodName = "Method" .. tostring(i) .. "()"
	src ..= "function Module:" .. methodName .. "\n\tlocal self = self::ModuleType\nend\n"
end
src ..= "type ModuleType = typeof(Module)\n"
src ..= "return Module"
workspace.ModuleScript.Source = src

3. Create a new Script in the workspace. Set its source to local Module = require(workspace.ModuleScript). This will now raise a warning stating that the module does not return one value.

EDIT: The cast on self does not affect this issue (it can be removed and the issue will still occur), though doing a cast of local self = self::MyType can wreak havoc on the analysis of larger modules. Doing something like local self: MyType = self::any achieves the same purpose without the side effect related to the cast.

The place file to reproduce this issue can be downloaded for ease of access:
Repro_TypeCheckerFault.rbxl (33.7 KB)

Expected Behavior
I expect module type loading to not behave differently based on the size of the module.

Actual Behavior

Issue Area: Studio
Issue Type: Other
Impact: Moderate
Frequency: Often

[WheretIB]

Thank you for the report, we plan to fix the error message when complex module is required.

[WheretIB]

We have raised the limit so the the issue is no longer reproduced in the provided test file.
But we understand that a bigger example can be generated easily and we are still planning to fix the underlying issue.

[Xan_TheDragon (Xan)]

So far this limit increase has been beneficial for work thus far and I’ve not run into the problem again yet. Thanks for the change.