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

Feature/initialize list side branch #6058

Open
wants to merge 39 commits into
base: master
Choose a base branch
from

Conversation

kaizhangNV
Copy link
Contributor

No description provided.

@kaizhangNV kaizhangNV marked this pull request as draft January 10, 2025 18:37
@kaizhangNV kaizhangNV added the pr: breaking change PRs with breaking changes label Jan 10, 2025
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch 12 times, most recently from 282ad96 to 8be343e Compare January 16, 2025 04:51
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch 6 times, most recently from 2f3c992 to 7c5a8e8 Compare January 17, 2025 05:16
@kaizhangNV kaizhangNV marked this pull request as ready for review January 17, 2025 16:57
We should not use parameter's default value in the synthesized
member-init ctor. The default value should only be used when
call site doesn't provide enough arguments, and our invoke system
will use those default value to make up the missing arguments.

Add '-vk' to few tests to enable vulkan backend test.
Fix gfx-smoke test, for non-C style struct,

StructType a = {}; will never work anymore.
…ructor

When successfully check the synthesized member initializer list
constructor, we don't need the default constructor anymore, so we
can safely remove it.
Disable -zero-initialize option and disable all the related tests.
File shader-slang#6109 to track this issue.
Add cuda-host decoration for the synthesized constructor if there
is any usage of TorchTensor.
When creating invoke expression for ctor, we need to call
ResolveInvoke() to find us the best candidates, however
the existing lookup logic could find us the base constructor
for child struct, we should eliminate this case by providing
the LookupOptions::IgnoreInheritance to lookup, this requires
us to create a subcontext on SemanticsVisitor to indicate that
we only want to use this option on looking the constructor.

This change implements this.
Apply all the initializer list logic on core moduls structs as well.

Add special case handling for backwards-compatibility feature for HLSL
when type cast a literal zero to a 'struct'.
Instead of checking what is C-Style struct, we should check C-Style
type.

Proposal is not very clear about this. Will also update proposal.
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch 4 times, most recently from 97a71c7 to 1788d3b Compare January 23, 2025 22:29
@kaizhangNV kaizhangNV force-pushed the feature/initialize-list-side-branch branch from 1788d3b to 55ea908 Compare January 24, 2025 01:20
@@ -12332,8 +12295,8 @@ void SemanticsDeclAttributesVisitor::_synthesizeCtorSignature(StructDecl* struct

// Only the members whose visibility level is higher or equal than the
// constructor's visibility level will appear in the constructor's parameter list.
List<VarDeclBase*> resultMembers;
if (!_searchMembersWithHigherVisibility(structDecl, ctorVisibility, resultMembers))
List<KeyValuePair<VarDeclBase*, String>> resultMembers;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is necessary for _searchInitializableMembers to return the name of the enclosing struct, because you can easily obtain the struct decl from VarDeclBase->getParent.

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

Successfully merging this pull request may close these issues.

3 participants