Skip to content
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

Draft
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

kaizhangNV
Copy link
Contributor

@kaizhangNV kaizhangNV commented Oct 2, 2024

First PR for #5192.

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.
  1. 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.
  1. 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.

@kaizhangNV kaizhangNV force-pushed the feature/initialize-list branch 3 times, most recently from b4079bc to c759f4d Compare October 2, 2024 20:39
@kaizhangNV kaizhangNV marked this pull request as draft October 2, 2024 21:39
source/slang/slang-check-conversion.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-conversion.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-conversion.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-conversion.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-conversion.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-decl.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-decl.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-decl.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-decl.cpp Outdated Show resolved Hide resolved
source/slang/slang-check-decl.cpp Outdated Show resolved Hide resolved
@kaizhangNV
Copy link
Contributor Author

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.

@kaizhangNV kaizhangNV force-pushed the feature/initialize-list branch 2 times, most recently from 443609f to 51b7311 Compare October 8, 2024 21:38
@kaizhangNV kaizhangNV added the pr: non-breaking PRs without breaking changes label Oct 8, 2024
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list branch 5 times, most recently from f485378 to b8094bd Compare October 9, 2024 17:33
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.
We need to ensure the definite checked for a struct before trying to
use its constructor in the initialize list coerce.
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr: non-breaking PRs without breaking changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants