<div dir="ltr">Dear John,<br><br> I didn't quite realize you could do that! Thank you for that. I managed to make a lot of progress from your tip, and I'm almost done with the builtin!<br><br> I hope I can get something done to put up for basic discussion to the clang mailing list soon. As a slight side question, if I'm looking for "review" (but not necessarily with the goal of upstreaming to Clang just yet), would it be appropriate to send a diff to the mailing list here?<br><br>Sincerely,<br>ThePhD<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 26, 2018 at 4:39 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div>On May 26, 2018, at 1:51 PM, ThePhD via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><div><div dir="ltr"><div><div><div><div><div><div><div><div><div>Dear cfe-dev,<br><br></div> I am new at hacking on Clang and I've made a decent amount of forward progress in defining my own Constant Expression builtin for C++. It takes arguments which must be compile-time evaluatable. This worked out just fine so far, and has allowed me to get started on implementing <a href="https://rawgit.com/ThePhD/embed/master/papers/P1040%20-%20embed.html" target="_blank">std::embed</a>.<br><br></div> I wanted to wrap my Constant Expression builtin in a C++-defined `constexpr` function. The problem with this is that any argument passed to my wrapping function that used my builtin ended up becoming non-evaluatable in *Visit calls during the Sema::ActOnFinish* phase.<br><br></div> This has a few consequences. My wrapper function uses 2 less arguments than my builtin currently, passing 2 variables to the builtin to be filled in as output parameters, and then placed into a nice struct the user can use (unsigned char* and a size_t). I lose the interface if I use the builtin directly and someone has to provide the output parameters.<br><br></div> I tried to use the "t" specifier on the Builtin in Builtin.def to let me define my own type checking, but so far it seems like even with "t" I can't make my builtin have a signature that returns a custom structure.<br></div></div></div></div></div></div></div></blockquote><div><br></div></span>Are you trying to cast the result of the CallExpr? You should just set it directly; that's allowed for custom-typechecked builtins.</div><div><br></div><div>John.</div><div><br><blockquote type="cite"><div><span class="gmail-"><div dir="ltr"><div><div><div><div><div><br></div> Does anyone know how I would begin to work around these problems? My first interest is to make the builtin I wrote match the struct-returning interface I need. That would allow me to drop the 2 output parameters and instead return a structure. I do not know how to do this.<br><br></div> My second idea is to abandon defining it through Builtins.def altogether, but I'm not sure how to go about defining a builtin that's not part of that list.<br><br></div> Does anyone have any insight into this?<br><br></div>Sincerely and Hopefully,<br></div>ThePhD<br></div></span>
______________________________<wbr>_________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br></div></blockquote></div><br></div></blockquote></div><br></div>