Added array of valid architectures and function returning array.
Modified llvm-lipo to include list of valid architectures in error message for invalid arch.
Test Plan:
Differential D63735
[MachOObjectFile]Added Valid Architecture Function anushabasana on Jun 24 2019, 12:26 PM. Authored by
Details Added array of valid architectures and function returning array. Test Plan:
Diff Detail
Event Timeline
Comment Actions Looking good, just a few style nits.
Comment Actions I'll wait for a day in case any other reviewers have comments and then commit this for you.
Comment Actions Given that we're following an existing name here, and we'd have to change that existing name as well were we to decide on a new name, I'm going to go ahead and commit this on @anushabasana's behalf. We can figure out the best name to use here and then change all of them at once post-commit. Comment Actions This adds an unnecessary static initializer to the MachOObject.cpp. Can you move the array of validArchs into filescope? You can declare it in getValidArchs() and use getValidArchs() in isValidArchs.
Comment Actions I was hoping that std::array wouldn't necessitate a static initializer, since it's just supposed to be a zero-cost wrapper around a C array. Could you clarify what you mean by file scope? It's already a static const inside MachOObjectFile.cpp; do you mean moving the declaration into getValidArchs()? Comment Actions Not if you create std::array<StringRef>.
ArrayRef<StringRef> MachOObjectFile::getValidArchs() { static const std::array<StringRef, 17> validArchs = { "i386", "x86_64", "x86_64h", "armv4t", "arm", "armv5e", "armv6", "armv6m", "armv7", "armv7em", "armv7k", "armv7m", "armv7s", "arm64", "arm64_32", "ppc", "ppc64", }; return validArchs; } |
Super duper nitty nit: consider "getKnownArchs" instead of "getValidArchs". I'm wrestling with the idea of what makes an arch "valid", considering the list supported here is only the subset of archs that llvm knows about. E.g., is m68k an invalid Mach-O file? And so on. I readily concede this is the most pedantic of concerns.
I can see how an argument can be invalid, and so have no concerns over llvm-lipo's validateArchitectureName function name.