Annotate function with inferred types about luau HOT 7 OPEN

We don't have a way to do this right now, and enabling it in a Roblox environment is unlikely to be feasible in the near future - the type solver and the bytecode compiler have different performance requirements, and enabling RTTI on all platforms (including clients that didn't actually compile the bytecode they're running) is a pretty complex problem.

Can I ask what you're wanting this information for? If it's for debugging purposes, there may be a less general way to solve this.

from luau.

I want the information so that I could generate a type for the function so that tools like luau-lsp (or the luau type checker) can prevent me from breaking the api that my module allready defines (so I would write a function that takes a table and returns the type string)

from luau.

I'm not sure what is being asked here... is it a runtime function? Is it an editor feature that adds explicit annotations to existing code? E.g. we already have an --annotate mode in luau-analyze, is that the ask?

from luau.

huh --annotate exist but is not as good as luau-lsp type infrence? but I was told luau-lsp used functions avaliable in luau
also it appears to contradict it's self when you luau-analyze a file that requires anything which has a table in it (it generates the type infrence, and places it somewhere. but does not fill out the table since it is doing like local module_type: {a:number} = {} which then fails as module_type is still a table and is not being filled

from luau.

--annotate is not as complete as it could be, because it's written as a debugging tool, not a "canonically annotate this type" tool. Its output is also, by necessity, going to generate errors like what you mentioned, because it applies the "final type" of a variable to the variable declaration, which creates issues when you're partially initializing the table.

luau-lsp likely provides better inference than --annotate because it's working with Luau's C++ API, not the annotation syntax, and thus can handle types that we don't have syntax for, or unannotated types.

We've talked in the past about providing a way to generate an annotation that enforces the current inference results. I don't think it's coming in the next few months, but it is on our radar.

from luau.

I'm wondering if we need both this and #402 or if we can just keep one of these.

from luau.

i think that that issue is more about formatting (and not using pre-provided type-information)
my issue is more about the excessive use of any and not properly detecting types

from luau.