Thanks, I'm able to reproduce. Seems to be a difference between -c and -cc1. With -c the global value of the mangled name of the constructor is not being found. Looking into it more...

@bkramer
I'm unable to reproduce the crash. What flags are you compiling with?

Rebase and fix unused variable warning.

@efriedma ping

@efriedma I've updated the patch to fix the decl-use-decl example and added a test for it. Anything else?

Cleanup some extra brackets.

Update deferred annotations whenever EmitGlobalDefinition is called
with a FunctionDecl and it has already been used or defined.

Switch to emitting annotations and the end.

I looked into the above issue with mixing declarations and definitions and I think I can fix that by leaving the AddGlobalAnnotations call in EmitGlobalFunctionDefinition and only calling AddGlobalAnnotations from GetOrCreateLLVMFunction when it's for a definition. However, with that I'm running into some duplicate annotations being created with C++ templates that I need to fix.

That example appears to still work the same with my patch:

A little more context for the new reviewers. Over in this patch I added support for annotations to be emitted into WebAssembly. We'd like to use this to mark imported (declarations) and exported (definitions) of functions with special attributes.

Rebase on main.

Remove annotate arguments. Change name from func_attr to llvm.func_attr.

In D150803#4440802, @aaron.ballman wrote:

Marking as requested changes so it's clear there's more worth discussing, so we don't accidentally land this.

Use the annotate attribute to generate custom sections.

@aaron.ballman or @erichkeane Did you want to re-review after that latest changes (more generic attribute) or are things good to go?

Review comments.

Fix few remaining issues.

After some feedback, a few people have indicated they'd like to do something similar to this, but for their own attributes. I've changed to a more generic attribute that allows arbitrary strings. Now a custom section will be created for each unique attribute.

In D150803#4389062, @sunfish wrote:

In D150803#4389040, @dschuff wrote:

Hm, this is interesting because in the long term we plan to have stack switching in wasm, which could allow for similar async behavior that JSPI has, and could be useful in non-web systems. But that's a ways off. The file format we are generating with this CL will be used in emscripten sooner (and we may want to try to stabilize it some point, possibly before pure wasm stack switching is usable in non-web systems).
So overall I kind of feel like I could go either way on this. Curious if @sunfish has had any thoughts about async outside of emscripten.

When we do have stack switching, would you anticipate still using this wasm_async attribute, or would we switch to something else at that point?

Review comments. Add tombstone for unused functions.

Address comments.

Review comments.