This is the funcref counterpart to 104bad5a. We introduce a new attribute
that marks a function pointer as a funcref. It also implements builtin
__builtin_wasm_ref_null_func(), that returns a null funcref value.
Completely refactored the initial solution to funcref implementation and design.
Now it works similarly to the __ptr32 attribute from -fms-extensions.
We keep _both_ attribute and address space through the frontend, which is then automatically
converted to the proper LLVM address space through the AddressSpaceMap.
It would be good to add tests for more error conditions like in the externref patch and also additional errors like trying to apply __funcref to types that aren't function pointers.
It would be good to document this!
Are the extra parentheses meaningful here?
How do these parts correspond to the original source code?
Same question here about an RFC for adding this new type to the type system and a design document for how the type behaves as in https://reviews.llvm.org/D122215.
It's a requirement that this be documented. Also, this should probably have a Subjects line that expects a function of some sort? (It doesn't impact the semantics of anything, but it self-documents the expectations for people reading Attr.td.)
Why is this a keyword in all language modes?
Formatting is off here.
I think there's a verb missing from this function identifier -- also, I don't think we need to continue the terrible trend of prepending Sema onto the function name which lives in the Sema object.
Where did this value come from?
Why that specific ordering as opposed to AR_VendorAttributesParsed?
Why would we need to do this?? And what do we do when there is no FunctionDecl to get back to (because it's a call expression through a function pointer, for example)?
Why are you guaranteed this function returns void?
This seems like it's not used.
What happens when the user's function already has an explicitly specified address space?
That's exactly what I was looking for -- I wanted to make sure this agreed with the LLVM side of things and any public documentation about address spaces for WASM.
Sure! Marking as done.
Yes, I meant __funcref. Thanks, will add test coverage for the diagnostic.
I might have misread the docs but this keyword should be available for both C and C++. Maybe I want KEYC99 | KEYCXX ?
Don't understand why. It's the same as CheckRISCVBuiltinFunctionCall ?