it was like a couple weeks ago but i had it happen yesterday as well, i’ve filed a bug report for the latter at `typeof` with invalid `setmetatable` arguments and a table intersection crashes new solver's strict mode · Issue #1405 · luau-lang/luau · GitHub but it wasn’t the same error
2 Likes
I was pretty excited for this, but it’s pretty unusable in it’s current state.
My game seems to just not work with this change, with no autocomplete being present, or even error underlining. While script analysis previously showed ~1500 warnings (don’t ask), it’s now at 29, and does not change.
I also noticed my fans being noticeably louder, and studio is making my memory go up to 98% for some reason.
3 Likes
Studio just closes for me after loading up the game
I was learning functional programming and came upon an error that only happens on the new type checker which I’m not sure is a bug or not.
Setup code
Also, I saw in the post that you guys wanted us to report any *blocked-1234* type errors, and while I don’t have any idea what causes these, I do have a script and module scripts that have like 15 of them in some what different contexts. I can send a file in DMs if that’d help.
Also looking forward to metatable type imorovements and a potential standardised type syntax for standard OOP implementations
Legendary, exciting stuff going on
Encountered an issue with RemoteFunction callback parameters being unknown
Also happens if you define with the syntax remote.OnServerInvoke = function(player, ...)
I got curious and tried this on TextChatService as well (OnBubbleAdded & OnIncomingMessage), and the same thing occured, so it’s probably an issue for all classes with callbacks
Also, apologies if this has been reported already, I assumed not since searching for “callback” in this topic showed no replies
1 Like
This is a fantastic update to Luau!!! But unfortunately I tried enabling the setting for our game (Pet Simulator 99, and Pet RNG) and the solver freezes internally and starts allocating gigabytes of RAM until my computer completely runs out of memory. This happens to all of us who try turning it on unfortunately. Looking forward to seeing this come out of beta! Joe
2 Likes
Does this fix the issue where using type annotations makes it so that Studio doesn’t suggest children when using dot notation?
1 Like
just like a few other people i think i found a bug…
and
(i cant report to github so i report here instead)
i dont think thats supposed to happen… it’s warning me in my chat tag script when i use Players:GetPlayerByUserId().
edit: it only happens in strict mode and the strict comment is highlighted bright orange
Very good update in general. I was really in need of an updated type checker and the read-only modifier is awesome. But I’ve ran into an interesting scenario while doing some triangle calculations…
NOTE: same issue is happening at line 35. Solved by appending “:: number” override at the end
1 Like
So excited to finally see this in Studio!! Been using the new solver almost daily in VSCode & following the Luau team’s progress for a pretty long while now, and this solver’s just getting better every day.
If y’all didn’t already know, the amount of time, effort, and love the Luau team (and OSS contributers/testers!) have put into the new solver, spending countless months-worth of hours over weekends, 9-2 AMs all throughout the nights engaging with our open source community, tracking down weird refinement issues and ~(false?)s & the glorious type family comparison issues, in order to make this a legitimately good product to use, is truly inspiring. Thanks to aatxe, WheretIB, Drakontas, and the awesome team working on Luau, we have an incredibly simple yet powerful programming language we can use both on and off (using OSS runtimes such as @filiptibell’s Lune) the Roblox platform, and it’s truly a pleasure to code in.
So, without further ado, may Hina bless this new beta!!
10 Likes
I’m not sure if this is intended or not, but this new type solver interprets the following code differently than the present type solver:
--!strict
local replicatedStorage = game:GetService("ReplicatedStorage")
local librariesModule
repeat
local possibleInstance = replicatedStorage:FindFirstChild("Libraries")
if typeof(possibleInstance) == "Instance" and possibleInstance:IsA("ModuleScript") then
librariesModule = possibleInstance
else
print("Waiting for replicatedStorage.Libraries")
replicatedStorage.ChildAdded:Wait()
end
until librariesModule ~= nil
The present type solver sees "librariesModule " as “ModuleScript”, but the new type solver sees it as “ModuleScript?” Is there an explanation of why the present and new type solver interprets this code block differently?
2 Likes
For what it’s worth, it’s likely that the mascot’s name will be changed in some capacity because of some concerns brought up. There’s a thread in the OSS server about it.
EDIT: I am in fact dumb! You’ll have to forgive me, this is my first time reading ever. 
The real troopers are people who had it on from the getgo. There’s a bunch of those, and they’re really the ones that deserve credit for helping.
2 Likes
Why arent you just using WaitForChild here?
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Libraries = require(ReplicatedStorage:WaitForChild("Libraries"))
3 Likes
I was experimenting a lot with the Luau Source Code and found fixes to a few problems.
And I found a fix to a huge problem, which includes this one as well, as I assumed it would solve the issue.
As you see:
This is the current Luau Behavior:
After the fix I found:
Error is gone.
However
Since I did research about it. I also know the workaround.
Put your type Keys = keyof<typeof(PlayerData)> function under UpdateData this fixes the issue temporarily and permanently**. Because my fix doesn’t change the behavior nor breaks anything so it will and should still work if you keep it under UpdateData.
The reason why this happens is because of something that I believe was not meant and unintended.
Why did it happen?
Basically if keyof gets read by the solver, it will create two new sort of “messages”.
The Solver reads messages from an “Array” starting at the beginning and moving to the end.
When it reaches the end, if it hasn’t finished solving everything, it will move back to the beginning and re-loop from there.
When the Solver created these messages, it pushes it AT THE END of the entire Array which the solver goes through. This is why the workaround I mentioned works.
The fact that it gets solved earlier when you put it at the end, doesn’t make sense for the type functions put at the beginning. Finding this fix is going to solve A LOT of issues with future customizable type functions.
Not only do I believe it fixes issues, it also makes solving faster.
Initially, I was after this fix for longer when I was trying to make a custom type function to return a “Free Table”. It took me like 3 or more days to figure out the concept of the Luau Solver, to properly fix things.
But when I tested it with keyof it had issues, and this is finally gone with the fix.
I hope that this fix, similar to the index crashing one will also become soon available in the next Studio update, because I am making a PR for the fix.
2 Likes
This one causes problems to mine studio (I can not get feedback on my code anymore) so i disabled it. I rather be using the current Type Solver.
You might want to check out the RFC on User-Defined Type Functions, which is probably the closest thing to your request. Theoretically, your example could be something like
type function FrameworkGet(path)
if not path:is "string" then
error "path to get must be a string!"
end
-- From here on, this wouldn't actually work even if the RFC was accepted, but still interesting to think about
local found = game.ReplicatedStorage:FindFirstChild(path)
if not found then
error "path not found"
end
local ok, script = pcall(require, found)
if not ok then
error "failed to require script"
end
return script:properties()
end
function Framework.Get(string: T): FrameworkGet<T> end
However, this example wouldn’t work because globals including “game” and “require” shouldn’t exist in type functions, as their runtime is designed to be constrained so they could be run both at compile-time and at runtime. They’re also designed to run only in the Luau VM, so Roblox-specific features wouldn’t work, and an API to allow this seems like it would be out of scope for Luau itself.
Type functions would still have loads of uses in their state in the RFC though, and I’m still really excited about them.
2 Likes
local Selection = game:GetService("Selection")
for _, v in Selection:Get() do
if v:IsA("ImageLabel") or v:IsA("ImageButton") then
print(v)
end
end
It refuses to give autocomplete if there is more than one possible type it could be.
I would personally prefer it showed variables both classes have such as .Image while hiding .PressedImage since only textButton has it.
This is a known issue and one of the reasons we mentioned that the Beta does not work well in larger projects.
We also can’t promise that some of these issues will be solved soon, but we are certainly looking to solve them before the full release.
1 Like
For the reasons we mentioned in previous feature requests for this feature, we do not have plans for type inference of custom require function wrappers.
Reason being that cross-module dependencies are resolved before typechecking can even start. It’s unrelated to the architecture of old or new solver themselves.
3 Likes