Resubmission of https://reviews.llvm.org/D126254 with where decodeBase64Byte is no longer a lambda but a static function. Some compilers have different errors or warnings with respect to what needs to be captured and what doesn't (see comments in https://reviews.llvm.org/D126254 for details).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
FWIW, llvm/lib/Object/COFFObjectFile.cpp also contains a decodeBase64StringEntry function that probably should be refactored into using this, if we make a more proper toplevel API for it.
Any updates here? I would love to see this land in some form (haven't looked closely at the patch, but I have several places I would love to use this in MLIR)
Don't expose the invalid byte definition since this is in a header file. decodeBase64Byte() now makes its own "Inv" version so it can be used to initialize a large array and the name needs to be short, and the decodeBase64() function makes its own version named Base64InvalidByte for readability. No one outside of this header file needs to access this variable so we shouldn't expose it.
For compilation speed I would prefer sinking decodeBase64Byte() into a .cpp file and I would probably also prefer to move the implementation of decodeBase64() even if that means it can no longer be a template and we would need to require i.e., a SmallVectorImpl or something like that. Are there any really big advantages of making this a template?
I agree as I was wondering if decodeBase64Byte would cause problems being a static in the header file. I can make a cpp file and remove the template aspect.
Outside of commentary on the rest of the patch/design, I can say that making a function namespace (not class) scoped static in a header is a problem, as it leads to ODR violations in any inline function that calls the static one (since every definition of an inline function must be identical, including it must refer to the same entities by name - but the static function is distinct in each TU, so the inline functions refer to different functions (though they have the same name) - so ODR violation). But a direct fix for that in this case would be to make the function inline (think of inline as a linkage, not as telling the compiler to inline the function (it does bias the inliner slightly, but not a big deal) - "inline" just means "let me define this repeatedly, I guarantee all the definitions will be the same"), rather than static.
But yeah, probably moving the definition to the .cpp file is more suitable here in any case.
Maybe use a more explicit name now that it has file-scope, Base64InvalidByte or something along these line