-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SP004: implement initialize list translation to ctor #5215
base: master
Are you sure you want to change the base?
SP004: implement initialize list translation to ctor #5215
Conversation
b4079bc
to
c759f4d
Compare
04c9a9f
to
65fa60d
Compare
65fa60d
to
0e8aa84
Compare
I rebase this PR to my another PR #5231 which just refactor the logic of synthesizing the body of the default constructor. This will make my next implementation easier. |
443609f
to
51b7311
Compare
f485378
to
b8094bd
Compare
This is the first change to implement part of SP004, what this change does: 1. We synthesize a member-wise constructor for each struct follow the rules described in SP004. 2. Add logic to translate the initialize list to constructor invoke TODO: what needs to be done next 1. We didn't fill the body of the synthesized constructor - This is relative easy task. 2. The fall back to legacy initialize list logic is not done - I found out that it's straight forward to put this logic after ResolveInvoke() call, because after ResolveInvoke() we will need to do a final 'coerce()' check to determine whether the candidate is applicable to use. If that fails, we can do the C-Style struct check and fall back to legacy logic. 3. Should we enable this for stdlib as well? - Our stdlib has some syntax that external users cannot use, so whether this change could break anything is unknown for now. It needs some extra effort to investigate and debugging the potential compile issue.
Separate the logic of _invokeExprForSynthesizedCtor from _readAggregateValueFromInitializerList. Because we don't really need to read and coerce the values recursively from the initializer list when we go this path. After we form a invoke expression to synthesized ctor, the ResolveInvoke logic will help us to coerce the arguments.
After we create the constructor invoke expression, we need to resolve this expression by ResolveInvoke(), and if it's failed we need a mechanism to fallback to the legacy initialization list logic. This change use sub visitor with a temporary diagnose sink to call the ResolveInvoke(), such that compile process won't be aborted if the error happens. The condition allowing the fall back is that the struct has to be a C-style struct, described in: https://github.com/shader-slang/slang/blob/master/docs/proposals/004-initialization.md
When searching the menbers of base type, we don't pick the fields of base type, instead, we will pick from parameter list of base type's constructor.
Don't report error when checking synthesized constructor, we will remove this constructor instead. Change the location where we create the member initialize constructor signature to SemanticsDeclAttributesVisitor to avoid the circular checking problem.
1. When extension of a struct defines __init, we should not synthesize __init anymore. 2. For the synthesized __init signature, we correct the default value for the parameter. Figuring out what exactly is "default initialize type". If a type has a ctor can take 0 parameter, it's default initialize type.
Struct Inheriting from a interface doesn't violate the rules of C-Style struct. Add the visibility modifier to the synthesized ctor.
cb9831a
to
1013d73
Compare
5a1ab65
to
406bc53
Compare
We need to ensure the definite checked for a struct before trying to use its constructor in the initialize list coerce.
|
First PR for #5192.
This is the first change to implement part of SP004, what this change does:
We synthesize a member-wise constructor for each struct follow the rules described in SP004.
Add logic to translate the initialize list to constructor invoke
TODO: what needs to be done next