• Remove unused code

Also moved the checker to lib/Object.

• Add custom section checking

Thank you all for comments!

Oh, and just FYI: the ARM code Github link in your CL description wouldn't work once they make changes to the code. You can take a permalink by clicking three dots in the left side of the code and click "Copy permalink", which will get you a link of the specified line in the latest commit. It looks like this: https://github.com/llvm-mirror/llvm/blob/2cc0a7da876c1d8c32775b0119e1e15aaa759b9e/lib/Target/ARM/ARMInstrInfo.td#L550
Also you can do that for for a block of code to by selecting a block by clicking shift and create a permalink for that, like
https://github.com/llvm-mirror/llvm/blob/2cc0a7da876c1d8c32775b0119e1e15aaa759b9e/lib/Target/ARM/ARMInstrInfo.td#L550-L555

• Could you add "Fixes PR39384." to the CL/commit description?
• Please run clang-format (and maybe also clang-tidy) on the patch

@dschuff Do you think this look OK?

@sbc100 Do you have any concerns on landing this?

In D55347#1325860, @aardappel wrote:

We have 4 possible paths of emitting code (backend vs assembler, binary vs asm), so my answer for "where should this setType call go" is "wherever it makes those 4 paths most uniform / least fragile".

That said, I'd say having the streamer setting state on symbols feels somewhat weird to me, given that a streamer is mostly a dumb byte/text writer, and not responsible for managing state (symbols are owned by MCContext, outside of the streamer). But again, the above rule is more important to me :) We have a lot of places in the code that are somewhat weird, because we're a nonstandard "CPU", so I don't think that should be of primary concern.

• Add unregisterScope() deleted in rL348647

• Address comments

Rebase onto D55406

• Address comments

• Minor fix

In D55353#1321483, @sbc100 wrote:

Since event types can't have return values (they are always no_return right?) should we split out "parseParamList" and have them look like this?

.eventtype  __cpp_exception i32
.eventtype  some_other_exception i32, i32

• Print only param list for eventtype

• Changed else if to if after returns

Ping

In D55347#1321482, @sbc100 wrote:

There is a presensent for the "emit" functions in the streamer modifying symbols. For example:

void MCELFStreamer::emitELFSize(MCSymbol *Symbol, const MCExpr *Value) {         
  cast<MCSymbolELF>(Symbol)->setSize(Value);                                     
}

I'm not saying this is the best, but it seems to have be designed or used this way in other targets, so I'd be tempted to use caution when refactoring. I myself don't have enough to background to know if this is a direction we want to move in. @sunfish and @aardappel might have a better idea.

• clang-format & clang-tidy

• remove stray newline

• clang-tidy

• Add some newlines

• clang-format & clang-tidy

• Move more setType to AsmPrinter

More cleanups

Reference: https://github.com/WebAssembly/exception-handling/issues/70

• Delete unused operators

• clang-format

@ruiu I add some comments here and there, but it's hard to explain the concept of wasm event fully in the comments only. Wasm globals seem to not have comments for the same reason.

• Address comments
• Remove dependencies from D54873/D54874

Abandoning because we decided to drop D54873.

No, I don't feel strong about this either. I just wanted to say this CL does not lose any sigindex info both in import and non-import cases, because you sounded like otherwise.

Yes in that case it's represented like sigindex of functions.

- Type:            FUNCTION                                                    
  FunctionTypes:   [ 0, 0 ]                                                    
- Type:            EVENT                                                       
  EventTypes:      [ 1 ]                   // here                                        
  Events:                                                 
    - Index:           0                                                       
      Attribute:       0

And why do we need this for specifying events themselves and for importing events?

I mean event imports need to specify their "type" and non-imported events also need to specify their "type". And in both cases the type needs to include the signature. So I think we should have a unified "eventType" that includes the signature index.

Style nits

In D54873#1315295, @sbc100 wrote:

In D54873#1315289, @aheejin wrote:

Ping. So the decision points are

1. Whether SigIndex should be in or out of WasmEventType?
   1. If SigIndex should be out of WasmEventType, should there even be WasmEventType anymore? Because then there's only Attribute left.
2. It seems to be people don't like the term Attribute. Should we change it to Kind or something? We can change the spec text, because it's not set in stone or anything.

Seems like we should keep the two member WasmEventType. We need this for specifying the events themselves, and also for importing events. It seems like this matches WasmGlobalType,

I'm not really sure what this means. Do you mean we should keep SigIndex as a part of WasmEventType and drop this CL? And why do we need this for specifying events themselves and for importing events? I don't think I understand what 'this' is actually. And why would it match WasmGlobalType? And do you also suggest, when we get to add multi-value globals later, we should insert SigIndex as a part of WasmGlobalType too?

Ping. So the decision points are

1. Whether SigIndex should be in or out of WasmEventType?
   1. If SigIndex should be out of WasmEventType, should there even be WasmEventType anymore? Because then there's only `Attribute' left.
2. It seems to be people don't like the term Attribute. Should we change it to Kind or something? We can change the spec text, because it's not set in stone or anything.