Vector.lerp type expects number return

Crazyblox · September 25, 2025, 2:51pm

This isn’t a dot product fellas.

Crazyblox · September 27, 2025, 12:12pm

Type still expects number to return. vector is not a number.
I have to absolve the issue by slapping a good old :: any on the returned value

Crazyblox · September 27, 2025, 1:43pm

Oh yeah the language itself is the issue; just pulled up vscodium and that’s also reporting the return type as number. Will go ahead and report that now if not done so already. Will provide link here when done

Judgy_Oreo · September 27, 2025, 1:58pm

Yes, all built-in type definitions are part of Luau itself, so the Issue would be valid:

github.com/luau-lang/luau

Analysis/src/EmbeddedBuiltinDefinitions.cpp

master


      
              cross: @checked (vec1: vector, vec2: vector) -> vector,
              dot: @checked (vec1: vector, vec2: vector) -> number,
              angle: @checked (vec1: vector, vec2: vector, axis: vector?) -> number,
              floor: @checked (vec: vector) -> vector,
              ceil: @checked (vec: vector) -> vector,
              abs: @checked (vec: vector) -> vector,
              sign: @checked (vec: vector) -> vector,
              clamp: @checked (vec: vector, min: vector, max: vector) -> vector,
              max: @checked (vector, ...vector) -> vector,
              min: @checked (vector, ...vector) -> vector,
              lerp: @checked (vec1: vector, vec2: vector, t: number) -> number,
          
              zero: vector,
              one: vector,
          }
          
          )BUILTIN_SRC";
          
          static const char* const kBuiltinDefinitionVectorSrc_DEPRECATED = R"BUILTIN_SRC(
          
          -- While vector would have been better represented as a built-in primitive type, type solver extern type handling covers most of the properties

Crazyblox · September 27, 2025, 2:53pm

Thanks for the link.

I’ve created the issue here:

github.com/luau-lang/luau

vector.lerp return type definition is incorrect

opened 02:52PM - 27 Sep 25 UTC

Crazyblox

bug

Change return type from 'number' to 'vector' in order to reflect demonstrated be…haviour in runtime Tested versions where issue is present: 0.692 [Via Roblox 0.692.0.6920844] 0.688 [Via Lune 0.10.2] Image showcasing issue: <img width="544" height="127" alt="Image" src="https://github.com/user-attachments/assets/dd32cc0c-e055-498a-a50d-cf85097a7193" /> Possible source link: https://github.com/luau-lang/luau/blob/0084576e6f8dc9865f27d296f0357794894bd38d/Analysis/src/EmbeddedBuiltinDefinitions.cpp#L342

If there’s any conventions that I’ve failed to adhere to since this is my first issue creation, let me know.

trigophi · September 27, 2025, 3:03pm

How does something like this get pushed? Just wondering

Judgy_Oreo · September 27, 2025, 3:52pm

I mean, it’s a simple typo to make. It doesn’t fail any types of existing unit tests in Luau, those can only check the runtime behaviour. Maybe you could make the argument that there should be a test that verifies every function returns the same value types as the type definitions say they do, but otherwise they are pretty disconnected from each other.

trigophi · September 27, 2025, 3:56pm

I guess yeah, but this also denotes that there were no tests for vector.lerp to return a vector right? And whatever tests were made were written with a number return? Assuming that returning a vector is the original intent of vector.lerp (aside from its return type being set to number). I don’t know how tests work

Judgy_Oreo · September 27, 2025, 4:00pm

There are tests which ensure vector.lerp behaves as expected:

github.com/luau-lang/luau

tests/conformance/vector_library.luau

master


      
          
          assert(vector.max(vector.create(1, 2, 3),vector.create(2, 3, 4),vector.create(3, 4, 5),vector.create(4, 5, 6)) == vector.create(4, 5, 6))
          assert(vector.min(vector.create(1, 2, 3),vector.create(2, 3, 4),vector.create(3, 4, 5),vector.create(4, 5, 6)) == vector.create(1, 2, 3))
          
          -- clamp
          assert(vector.clamp(vector.create(1, 1, 1), vector.create(0, 1, 2), vector.create(3, 3, 3)) == vector.create(1, 1, 2))
          assert(vector.clamp(vector.create(1, 1, 1), vector.create(-1, -1, -1), vector.create(0, 1, 2)) == vector.create(0, 1, 1))
          assert(select("#", vector.clamp(vector.zero, vector.zero, vector.one)) == 1)
          
          -- lerp
          assert(vector.lerp(vector.zero, vector.one, 0) == vector.zero)
          assert(vector.lerp(vector.zero, vector.one, 1) == vector.one)
          assert(vector.lerp(vector.zero, vector.one, 0.5) == vector.create(0.5, 0.5, 0.5))
          assert(vector.lerp(vector.one, vector.zero, 0.5) == vector.create(0.5, 0.5, 0.5))
          assert(vector.lerp(vector.one, vector.zero, 0.5) == vector.create(0.5, 0.5, 0.5))
          assert(vector.lerp(vector.create(1, 2, 3), vector.create(3, 2, 1), 0.5) == vector.create(2, 2, 2))
          assert(vector.lerp(vector.create(-1, -1, -3), vector.zero, 0.5) == vector.create(-0.5, -0.5, -1.5))
          assert(ecall(function() return vector.lerp(vector.zero, vector.one, vector.one) end) == "invalid argument #3 to 'lerp' (number expected, got vector)")
          
          -- validate component access
          assert(vector.create(1, 2, 3).x == 1)

It’s just that the Type System and the Runtime are not connected at all. The Type System could tell Studio that vector.lerp returns a SlidingBallConstraint, and Studio could give you a warning if your code assumes it returns a vector, but that has no influence on how your code actually runs. You won’t get any errors, and type definitions are not observable by code, only the types of values. typeof(vector.lerp(a, b, t)) will still be "vector" regardless of what the Type System says

trigophi · September 27, 2025, 4:04pm

Ok, I understand now thanks! As for

Maybe you could make the argument that there should be a test that verifies every function returns the same value types as the type definitions say they do, but otherwise they are pretty disconnected from each other.

How could this get suggested? I think this would be nice

Judgy_Oreo · September 27, 2025, 6:08pm

It would probably go through the Luau GitHub repository because it’s not really relevant to Roblox, but I’m not sure this would really be implemented because the impact is generally pretty small and this is not really a common occurrence, and it seems like it would be a little difficult to implement. Maybe a better suggestion would be to run the Type Checker over all the behavior tests (such as the one I linked) as a test itself, which should be a lot simpler to implement for basically the same effect.

ClimbingPotato · October 2, 2025, 9:48pm

The dev is here.

The fix is on the way and will be available according our release cycle soon.

It is the first thing I tried to add after noticing this bug. Unfortunately it doesn’t work because conformance tests contain a lot of incorrectly typed(but still valid!) code. For example from tests:

-- function calls
local function foo(a, b) return b end
assert(foo(1) == nil)
assert(foo(1, 2) == 2)
assert(foo(1, 2, 3) == 2)

It is a type error from the point of view of type checker even with nonstrict flag to call foo with not enough arguments.

Starveldt · October 3, 2025, 6:07am

Hey, can you do some extra tests for native codegen? vector.lerp appears to be.. incredibly wrong in some cases, caused my NPCs to teleport around like this:

I traced it down to my GetPosition function, which I recently swapped to vector.lerp under native codegen. So, I debugged the values very sloppily like this:

…and, it seemed to never interpolate X. It always ends up being 0, despite 10 - (13 * 0.431) definitely not being 0.

Turning off native codegen completely fixed this:

I’m happy to make a new bug report for this, but I would rather not create another post for vector.lerp - something’s just up with it in general lol (probably something to do with an FMA optimization if I had to guess), really weird rollout

ClimbingPotato · October 7, 2025, 4:23pm

Thank you for reporting it.
It is incredible how that bug in x64 instruction encoding slipped through tests we have. it was executed but by accident it well behaved on test cases.
I’ve disabled native codegen for vector.lerp until the bugfix reaches the prod.

Starveldt · October 7, 2025, 4:43pm

Thank you very much for getting to it so quick!