Consider the following WHLSL statement: *x = y; When we compile this, we naively turn this into auto temp1 = *x; temp1 = y; This doesn't actually assign through the pointer, instead it just reassigns a temporary The WHLSLFunctionWriter needs to be smart enough to understand how to emit code that assigns through a pointer. We also need to determine which situations it needs to be made smarter about.
It looks like after the property resolver runs, lvalues can only be either variable references or dereference expressions. Assigning to a variable reference will just work, so it looks like we only need to special case assigning to a dereference expression. Also, we shouldn't need to go digging through the AST; we can just handle the outermost dereference expression.
Created attachment 368638 [details] WIP
<rdar://problem/50746281>
Comment on attachment 368638 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=368638&action=review > Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:495 > + m_stack.append(rightName); This "if" block needs a return.
Myles is doing the WIP here in the property resolver patch. The only question we need to answer is if there are other areas where this matters? Maybe things to consider: *p++, etc These should probably be desugared though. Need to verify
This is needed for https://bugs.webkit.org/show_bug.cgi?id=198399.
void FunctionDefinitionWriter::visit(AST::DereferenceExpression& dereferenceExpression) { checkErrorAndVisit(dereferenceExpression.pointer()); auto right = m_stack.takeLast(); auto variableName = generateNextVariableName(); m_stringBuilder.append(makeString(AST::toString(*dereferenceExpression.typeAnnotation().leftAddressSpace()), ' ', m_typeNamer.mangledNameForType(dereferenceExpression.resolvedType()), "& ", variableName, " = *", right, ";\n")); m_stack.append(variableName); }
(In reply to Myles C. Maxfield from comment #6) > This is needed for https://bugs.webkit.org/show_bug.cgi?id=198399. Maybe you were running into the "&*x" problem? I also ran into this issue while trying to test the zero filling code. I took your change and turned it into a patch with a test here: https://bugs.webkit.org/show_bug.cgi?id=198198
*** This bug has been marked as a duplicate of bug 198198 ***