New Type Solver [Beta]

one thing iv run into is this

not sure if this is the expected behaviour for the new type solver or can we expect this to change back to working like the old type solver in future updates?

8 Likes

also dont try using typeof for this, it doesnt work

Could we get wait to be linted aginst?

I’m aware why its not, but I think it should be because some people still use it without knowing its issues. Esp younger devs most likely.
Also for those who are stubborn there could be a setting to disable the lint

1 Like

It crashes due to a stack overflow of an unique case. index is needs to wait for PlayerData, but it doesn’t. And the reason why it needs to wait, is because the type solver found out that PlayerData could maybe potentially get modified by the UpdateData function.

It’s an issue with the type solver, and the fix is to tell the type solver to make index wait, or to make the type solver a little bit more smarter. I hope that this fix will get applied soon, I made a PR!

2 Likes

The fact there will always be someone trying to make fun of you for anything you do, instead of just letting you exist in peace, is insane to me.

3 Likes

I have a module loader (run over each ModuleScript under x container(s)), I don’t require each module individually. Pretty unusable for me so I just turned it off for now heh

Please! Don’t infer Players.LocalPlayer as Player? !!!

9 Likes

i think this is not working because its being set in scripts, as i know shared is just a table, if you will add value to table (for example to module) somewhere in script1, script2 cant access it because script1 is not currently working

1 Like

I’m also getting an infer of Model? For player.Character or player.CharacterAdded:Wait()

I can’t even type assert it to Model


its a bit more complicated but possible now!

3 Likes

Yes, you could do it that way. But I don’t want to add all classes into a table. It should be a built in thing where it detects the type of the output of a function based on the inputs and the process.

1 Like

This is not expected behavior, definitely a bug we’d like to fix.

3 Likes

Loving the table type inferences and new support for read-only values. :eyes:

Hoping that the relaxed type-casting will assist with some of the workarounds I’ve had to do when attempting multiple inheritance table relationships and optional table values.

1 Like

Finally we are getting read-only tables. So excited for this update!

1 Like

изображение
Please do not ALWAYS infer any assignments in inner scopes as nilable.
Here it’s guranteed that foo will be number value, because do end simply runs it in an inner scope (which can be useful not to pollute the outer scope or to encapsulate values)
I hope it’s only a temporary side effect and will be polished out in the near future.
(fyi this never happened with old solver)

I also figured out that plugin like Zappy that uses codegen transpiled from WebAssembly to lua crashes solver. I mean it doesn’t sound surprising but this wasn’t a problem with an old solver.
Since I frequently use Fusion in my games, it is borderline impossible to take advantage of new solver, which been already mentioned to even crash the solver if you tend to use React/Fusion.
I do want to take advantage of new solver, but currently it isn’t usable enough for me with these obvious drawbacks. I’ll wait once those issues get solved.

3 Likes

This is a real bug (thanks for the report!) but it’s actually an autocomplete bug. You can see it in this example code:

--!strict
local foo
do
    foo = 8
end

local bar: number? = 8

math.abs(foo) -- ok because we know that foo : number
math.abs(bar) -- error because bar : number?
5 Likes

The flag you enabled is solely for parsing user-defined type functions, an initial implementation of them is coming soon, but it wasn’t finished in time to include in this beta at launch. We’ll probably have some “major update” announcements at various points in the beta (maybe in this thread, maybe in a new thread, honestly not sure yet!), and that will definitely be announced in one of those.

5 Likes

Thank you for the great efforts made in this update :smiley:

There appears to be some instability problems with the new keywords.

kuva

On the first typing, it should error due to “foo” not being a valid key of TextButton.
Second example should not error since Name is a valid key found in TextButton. Instead it throws this error:
Type Error: (35,26) Property '"AbsolutePosition" | "AbsoluteRotation" | "AbsoluteSize" | "Activated" | "Active" | "AddTag" | "AncestryChanged" | "AnchorPoint" | "Archivable" | "AttributeChanged" | "AutoButtonColor" | "AutoLocalize" | "AutomaticSize" | "BackgroundColor" | "BackgroundColor3" | "BackgroundTransparency" | "BorderColor" | "BorderColor3" | "BorderMode" | "BorderSizePixel" | "Capabilities" | "Changed" | "ChildAdded" | "ChildRemoved" | "ClassName" | "ClearAllChildren" | "ClippedRect" | "ClipsDescendants" | "Clone" | ... *TRUNCATED*' does not exist on type 'TextButton'

It appears rawget doesn’t work well with Instance types since the error is no longer showed after changing target type. (The first issue still occurs on both)
kuva

1 Like

I am happy that this is finally in a state where we can use it!


Some feedback/issues:

  • I’m getting a bunch of “Type inference failed to complete” in many different scenarios, even on short scripts. In these cases the entire first line is highlighted in orange, and hovering over it doesn’t yield any error message; you actually have to open the script analyzer for that.

For a short example that fails,

Open me
local module = {}
module.__index = module

function module.new(...: RBXScriptConnection)
	return setmetatable({
		tasks = { ... }
	}, module)
end

function module:GiveTask(...: RBXScriptConnection)
	if not self.tasks then
		return
	end

	for _, connection in { ... } do
		table.insert(self.tasks, connection)
	end

	return self
end

function module:DoCleaning()
	if not self.tasks then
		return
	end

	for _, connection in self.tasks do
		connection:Disconnect()
	end

	self.tasks = nil
end

return module
  • Type checker seems to have trouble with FindFirstAncestorWhichIsA/OfClass.
    Example line that fails: local framework = require(script:FindFirstAncestorWhichIsA('ReplicatedStorage'):WaitForChild('Framework'))

  • require(module) gives a warning when module is of type ModuleScript but doesn’t actually refer to a ModuleScript in the game. An example:

		for index, itemCategory in itemCategories do
			if not itemCategory:IsA('ModuleScript') then
				continue
			end

			local requriedItemCategory = require(itemCategory) -- unsupported path
  • A typecast of localPlayer.PlayerGui to game.StarterGui gives a warning when trying to access a module that is present in the StarterGui. I would assume this is the case for other typecasts. Example:
local playerGui = game:GetService('Players').LocalPlayer:WaitForChild('PlayerGui') :: typeof(game.StarterGui)
	
require(playerGui
    :WaitForChild('MainUI')
    :WaitForChild('Client')
    :WaitForChild('ClientInitializer')
):Initialize() -- unsupported path
4 Likes

Yeah, it would be cool if modules/tables in other modules were automatically type checked like a module loader

3 Likes