-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autocompleting OO-Style methods is not working in the new type solver. #1239
Comments
It's because abc doesn't receive a type. It receives a freetype but idk, it needs to be a non-free type for this to be fixed. This is very very confusing. HOW does |
There's an issue here though. I did not write Doing name:new in this case, is going to lead to bad results. The fact that the it somehow makes it through the type check is interesting. |
I found out that the issue could be somewhere around here luau/Analysis/src/ConstraintGenerator.cpp Lines 2781 to 2790 in af15c3c
freshTypes work but it's very dank I do not understand how I am supposed to keep track of changes made because it's all dank, help
That's actually the only issue. If I can understand how this free fresh type gets modified to an actual type e.g. BUT I DO NOT understand how it gets it, because I don't know how it works, there's like a bunch of AST and pointers and idk. The type of |
I don't know what happens to the type of I don't know how I can check the value of |
Hi! I think this is a bug on our end. We are working on making sure the experimental new type solver (under the |
I was just testing a few things. I wanted to combine types together again, I was thinking about making an RFC for variadic generic types, because Then I noticed that something wasn't right with how the autocomplete works, and this is concerning. If THIS doesn't work, then what else might broke from it. That's about that. |
Oh, you edited the I don't seek the new solver. I was just using the new solver to see if a future update will break the old stuff. Break, in sense of "heavily".
I was curious on how I could figure out how to fix this bug here. But I have not enough knowledge about all of this. Way too many breakpoints, there's gotta be something more efficient.
Maybe ConstraintSolver.cpp does it, there's a part where I do see |
The sort of questions you're asking in trying to investigate the issue yourself are very architectural ones, and we don't have completed documentation available for the new solver since it is still in production, but in general, free types are how inference actually works, and most things (that do not have immediately determinable types) will be initially assigned a free type. Type inference is implemented between constraint generation ( |
Made a post here, where I just figured out something else local test = {}
test.__index = test
function test.new(input: string)
local self = setmetatable({}, test)
self.name = input
return self
end
function test:Get()
return self.name
end
local newTest = test.new("test")
newTest: This is where But if you mix it with
But there's something that local test = {}
test.__index = test
function test.new<free>()
local self = setmetatable({}, test)
self.emptyTable = {}
return self
end
function test:Get()
return "nothing"
end
local newTest = test.new()
newTest.emptyTable.AutoComplete = "test"
newTest.emptyTable. Here, But I can't explain how
I haven't checked |
My testing code that I put inside
Autocomplete.test.cpp
Description
As you see
DebugLuauDeferredConstraintResolution
is enabled here. And what happens is thatCHECK(ac1.entryMap.count("test"))
fails due to that.I tried to figure out why, and figured out, sort of a cause, but not an exact one, because there's too much going on. I wish I found more.
It has to do with this, though I am surprised to have never noticed this, but I barely test with
DebugLuauDeferredConstraintResolution
luau-lang/site@a48d849Cause starts here:
luau/Analysis/src/Frontend.cpp
Line 1372 in 259e509
If
DebugLuauDeferredConstraintResolution
is enabled, it will useLuau::check
, (which is where the issue is at)luau/Analysis/src/Frontend.cpp
Lines 1381 to 1384 in 259e509
If it's not enabled, it will use the previous typeChecker
luau/Analysis/src/Frontend.cpp
Line 1411 in 259e509
Now... I know, that this is literally what
DebugLuauDeferredConstraintResolution
is about... But that's what I figured out.Expected Result
You will get
:test
Actual Result
It seems like that only functions are affected, for some reason. You're forced to give the function type syntax... Generic types however won't work either. However, properties seem to recognise the type from generic types, just not functions within that one class table.
Research
I tried to find workarounds. I combo'd it like so as example:
But I had to comment this out
https://github.com/luau-lang/luau/blob/master/Analysis/src/Unifier.cpp#L407
But that just uses the old type checker....... but it's at that area, uhhh.... probably not really a special find. But Unifier supported it.
I don't even know how this is failing, it works fine outside that test. Unsure, I am probably enabling fast flags wrong.
The text was updated successfully, but these errors were encountered: