Fragmental AC - table mutation with metatable through functions is broken

[karl-police]

Description

If you pass a table with a metatable through a function to mutate the table, it seems like the new solver puts the tables together in a strange way.

Autocomplete marker marked at obj.@1

local name = {}
name.__index = name

function name.new()
	local obj = setmetatable({}, name)
	
	obj = name.prepare(obj)
	
	obj.@1
	
	return obj
end


function name.prepare(obj)
	obj.Entry1 = {
		entries = {} :: {string}
	}
	
	obj.Value1 = 2
	
	
	return obj
end


return name

Expected Result

That obj.@1 contains Entry1 and Value1 in a normal way. Works in the Old Solver.

Actual Result

At obj.@1 there's now a problem { @metatable name, { } } | { Entry1: { entries: {string} }, Value1: number }

because of this, the autocomplete doesn't work

[karl-police]

Smaller example

local mt = {}
mt.__index = mt

function mt.prepare(obj)
	obj.Value1 = 2
	return obj
end

local obj = setmetatable({}, mt)
obj = mt.prepare(obj)

[karl-police]

Some flag seems to fix this, but I don't know which one yet.

so far when doing an AC Builtins Fixture, I could not re-produce this somehow, what is happening?

Fragmental AC causes it

[karl-police]

TEST_CASE_FIXTURE(FragmentAutocompleteFixture, "idk_test1_frag")
{

    const std::string source = R"(
    --!strict
    local mt = {}
    mt.__index = mt

    function mt.prepare(obj)
	    obj.Value1 = 2
	    return obj
    end

    local obj = setmetatable({}, mt)
    obj = mt.prepare(obj)

    
    )";

    const std::string updated = R"(
    --!strict
    local mt = {}
    mt.__index = mt

    function mt.prepare(obj)
	    obj.Value1 = 2
	    return obj
    end

    local obj = setmetatable({}, mt)
    obj = mt.prepare(obj)

    obj.@1
    )";

    autocompleteFragmentInNewSolver(
        source,
        updated,
        '1',
        [](FragmentAutocompleteStatusResult& fragment)
        {
            REQUIRE(fragment.result);
            auto acResults = fragment.result->acResults;

            CHECK(acResults.entryMap.size());
        }
    );
}

[karl-police]

[karl-police]

https://www.diffchecker.com/qpJINo3u/

[karl-police]

how do I force run Simplify Constraint to see if it's because of that?

[karl-police]

why is the result on the Fragment AC

obj : { @metatable t1, { } } | { Value1: number } where t1 = { __index: t1, prepare: ({ Value1: number }) -> { Value1: number } }

or something like that

while the other one not

[hgoldstein]

You are probably encountering two bugs.

Fragment autocomplete seems to be grabbing a less precise type than it ought to, for example in:

local mt = {}
mt.__index = mt

function mt.prepare(obj)
	obj.Value1 = 2
	return obj
end

local obj = setmetatable({}, mt)
obj = mt.prepare(obj)

... obj at this point should definitely have a key Value1, but fragment autocomplete appears to be grabbing the type of obj from it's binding, so it's a union between the result of setmetatable (which does not have that key) and the table returned by prepare (which does have that key). You can see that in action if you write something like:

--!strict
local mt = {}
mt.__index = mt

function mt.prepare(obj)
	obj.Value1 = 2
	obj.Value2 = true
	return obj
end

local obj = setmetatable({Value2 = "interesting"}, mt)
obj = mt.prepare(obj)
obj.| -- `Value2` appears here but not `Value1`

I think you're running into a different bug with your initial snippet, I'm not quite sure what's happening there.

[karl-police]

The original snippet is just a larger version, but the issue should be the same. Where it also grabs a strange union type.