Duplicate table key triggers assert in new solver

[nothing1649]

As of version 0.652, the following code crashes the new solver, regardless of strict mode being used:

--!strict
type dict = {
    read vals: {[string]:number}
}

local _:dict = {
    vals = {
        key = 1,
        key = 1
    }
}

Relevant assert:
https://github.com/luau-lang/luau/blob/7a6142e792eebae628916220b58faf7465d3ff59/Analysis/src/TableLiteralInference.cpp#L246C1-L246C57

Worth noting is that on my PC running Arch (Intel i5-10400F) and laptop (Intel i5-12450H) the code crashed luau-analyze every time, however when using the prebuilt binaries for Windows it only crashed some of the time; on my PC it crashed about 50% of the time but on my laptop it was more like 10% of the time.

[hgoldstein]

Thanks for the report! Definitely new solver, definitely a bug.

[hgoldstein]

It's not a race condition, the issue is that matchLiteralType (in TableLiteralInference) mutates types in place. We want to transform { key: number } into { [string]: number }. We traverse over the table members, and when we get to key = 1 we actually clip that part of the type ... but when we come back to the next key = 1 we panic (assert) because we expect all of the literal members to be represented in the type.

[nothing1649]

got it, will remove mentions of it

[hgoldstein]

Oh no worries there! I was commenting as a note for myself (or someone else if I don't get to this). It's a good guess: the LUAU_ASSERT is guarding against memory corruption, which kind of looks like a race condition (maybe one can think of it as a race condition against the operating system).

The prebuilt binaries are built in release mode which turns off asserts. You might see similar behavior for your example (crashing some percentage of the time but not always) if you build from source on Linux and pass -DCMAKE_BUILD_TYPE=Release to cmake.