Member-wise constructor generation with visibility control

[kaizhangNV]

Rebased version of PR #4854.

[csyonghe]

I think we should delete all these logic here from 535 till 671, and reuse the existing ResolveInvoke logic to resolve the constructor call.

Once we reach here, we are about to turn initializer list {...} into a ctor call that is StructType(...).
This can be done by:

1. create a AST node that is InvokeExpr(calleeExpr, coercedArgs), where:
   calleeExpr is a VarExpr(declRef = toStructDeclRef, type = TypeType(toType), checked = true).
2. Create a clone of the current semantic visitor to try to check the invoke Expr in a sub context so that any checking errors will not leak into the current visitor:

DiagnosticSink tempSink(getSourceManager(), nullptr);
ExprLocalScope localScope;
SemanticsVisitor subVisitor(withSink(&tempSink).withParentFunc(synFuncDecl).withExprLocalScope(&localScope));

3. call subVisitor.ResolveInvoke() on the invokeExpr. If tempSink doesn't have any errors, then we succeeded in calling the ctor, and the result of ResolveInvoke is the *outToExpr we need to return, otherwise, we return false. We may want to copy out any error message here, and report them to the user if the legacy logic also failed at line 780.

This should handle all the generic case or the variadic case just fine using the same logic in ResolveInvoke.

[kaizhangNV]

Create a sub-task to address this issue: #5134.
Note, I won't submit a new PR for this. It just that I found out the original task took much longer than we estimated (estimation is just 1 day! And I already spent 3 days). And it could take longer, so split the task smaller so that I will have a clear goal what I'm going to resolve.

[csyonghe]

auto declRef = isDeclRefTypeOf<Decl>(argType);
if (!declRef)
    return nullptr;
return as<GenericAppDeclRef>(declRef.getDeclRefBase());

[csyonghe]

I want to understand why this change here, along with the change in line 151 is needed.

I think it should be fine if we revert all changes to this function and in 151.

If things break, I want to understand why.

[csyonghe]

This is going to be bad for performance because it revisits the entire type hierarchy for all the member types.

[csyonghe]

An alternative is to add the required CudaHost attribute in an IR pass to make things cleaner.

[kaizhangNV]

Create sub-task #5136 to address this.

[csyonghe]

There is a lot of code added to this checkAggType method. We really need to split them into separate functions for readability.

[kaizhangNV]

Create sub-task #5135 to address comment.

[csyonghe]

What will go wrong if we just leave the empty ctor there without deleting it?

[kaizhangNV]

I just figure out why Ariel wants to delete the empty default ctor.
Considering this case

struct S
{
    int a;
}

S s;

In this case, based on currently logic, we will synthesize a empty default ctor: S.$init(This), and for S s;, we will call this default ctor to construct the object. So this will cause an issue that slang will report a warning that a is not initialized.
While, if there is no default ctor (removing the default ctor), the default ctor won't be called to construct s, no warning will be reported.

I didn't participant in your previous discussion about what the expected behavior it is. I know that for C++, the default ctor will be called, and C++ won't report warning for that.

If we still want to insist this behavior, I think the warning reported here is actually helppful because it kind of reminds developers to initialize it or use s = {} to zero init it.

BTW, there is actually noting wrong that if we don't delete this ctor. But I need to fix bunch of the tests code.

[kaizhangNV]

@csyonghe to comment this reply first.

[16-Bit-Dog]

It is worth noting that there was a second reason that makes this change (in isolation) slightly problematic.

By auto generating init() functions, we will be changing how code-gen is structured since certain previously uninitialized struct values will now have an assignment to a function (even though this init() effectively does nothing).

Example of an init() function that effectively does nothing if user writes RayDesc ray; (assuming we don't delete init() anymore)

#line 15702 "hlsl.meta.slang"
RayDesc RayDesc_x24init_0()
{

#line 15702
    RayDesc _S1;

#line 15702
    return _S1;
}

This means that the following changes can be observed:

1. Certain tests will need to be adjusted due to making incorrect assumptions on how code-gen works with uninitialized values.
2. Code-gen will include init() function's that effectively do nothing.

[kaizhangNV]

create sub-task to remove this hack: Create a sub-task to remove this hack: #5138

[csyonghe]

I think we only need to execute part 1 if "-zero-init" option is set.

[csyonghe]

Can you explain this again? I still don't understand what it is trying to do. For the example shown in the comment here, haven't we already synthesized the default ctors for S, so that the overload resolution will resolve into a call to that defualt ctor already? Why do we need to run the coercion logic again here?

[16-Bit-Dog]

This is code that mostly carries over from how TOT did things. The quick answer is that "we need this function to handle an edge case related to how Slang always assigns default-constructors to uninitialized values if present".

I will break down why we have this function into 2 parts below.

---

What _tryOverloadWithDefaultInit does:

If I type the following code, _tryOverloadWithDefaultInit will be used to resolve MyStruct():

struct MyStruct
{
    float a;
};

[numthreads(1,1,1)]
void computeMain(int3 tid : SV_DispatchThreadID)
{
    MyStruct val = MyStruct(); // effectively `MyStruct val = {};`
}

Why do we have this function:

[using the code above] We have 2 requirements for any call to MyStruct() or related (Ex: RayDesc()):

1. We need to treat MyStruct() as a 'default-initialize'. This is a requirement since lots of code relies on this behavior.
2. We cannot treat MyStruct() as a 'default-initialize' using a compiler generated init() since this will force all uninitialized struct types into calling their init() ('default-initialize'). This is undesired behavior.

An example where rule 2 is important:

struct MyStruct
{
    float a;
};

[numthreads(1,1,1)]
void computeMain(int3 tid : SV_DispatchThreadID)
{
    MyStruct val1 = MyStruct(); // effectively `MyStruct val = {};`. This variable is default initialized.
    MyStruct val2; // Effectively `MyStruct val2;`. This variable is uninitialized.
}

[kaizhangNV]

Create a sub-task to remove this hack: #5138

[csyonghe]

Looks good overall, but I think there are few important cleanups we need to do before checking this in.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ kaizhangNV
❌ ArielG-NV
_{You have signed the CLA already but the status is still pending? Let us recheck it.}