[PATCH] D56188: Adopt SwiftABIInfo for WebAssembly.

This revision was automatically updated to reflect the committed changes. Closed by commit rC350372: Adopt SwiftABIInfo for WebAssembly. (authored by ddunbar, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56188/new/ https://reviews.llvm.org/D56188

[PATCH] D56188: Adopt SwiftABIInfo for WebAssembly.

ddunbar added a comment. In D56188#1343667 , @rjmccall wrote: > ...although it might be reasonable to extract the method implementations on > `DefaultABIInfo` as helper functions so that the code can be reused without > requiring a particular inheritance

[PATCH] D56188: Adopt SwiftABIInfo for WebAssembly.

ddunbar created this revision. ddunbar added reviewers: rjmccall, sunfish. Herald added subscribers: cfe-commits, aheejin, jgravelle-google, sbc100, dschuff. - This adopts SwiftABIInfo as the base class for WebAssemblyABIInfo, which is in keeping with what is done for other targets for which Swi

[PATCH] D53354: [WIP][NOT FOR COMMIT][PROTOTYPE] clang-scan-deps: dependency scanning tool rough prototype

ddunbar added inline comments. Comment at: lib/Lex/FilterToIncludes.cpp:628 + First = Id.Last; + auto Kind = llvm::StringSwitch(Id.Name) + .Case("include", pp_include) What is our feeling w.r.t. _Pragma, which can in theory influence the prepr

[PATCH] D30882: Add a callback for __has_include and use it for dependency scanning

ddunbar added a comment. In https://reviews.llvm.org/D30882#1074822, @dexonsmith wrote: > I don't think this is quite right. I know at least `make`-based incremental > builds wouldn't deal well with this. This is actually not a novel problem w.r.t. this patch. The exact same situation comes