Open Teemperor opened 7 years ago
See also this PR: https://github.com/Teemperor/ClangModulesCMake/pull/44
So, the "workaround" seems to be no longer around? The comment from the header is from 2010 and the workaround back then was this:
// The new function declaration is only missing an empty exception
// specification "throw()". If the throw() specification came from a
// function in a system header that has C linkage, just add an empty
// exception specification to the "new" declaration. This is an
// egregious workaround for glibc, which adds throw() specifications
// to many libc functions as an optimization. Unfortunately, that
// optimization isn't permitted by the C++ standard, so we're forced
// to work around it here.
if (MissingEmptyExceptionSpecification &&
isa<FunctionProtoType>(New->getType()) &&
(Old->getLocation().isInvalid() ||
Context.getSourceManager().isInSystemHeader(Old->getLocation())) &&
Old->isExternC()) {
const FunctionProtoType *NewProto
= cast<FunctionProtoType>(New->getType());
QualType NewType = Context.getFunctionType(NewProto->getResultType(),
NewProto->arg_type_begin(),
NewProto->getNumArgs(),
NewProto->isVariadic(),
NewProto->getTypeQuals(),
true, false, 0, 0,
NewProto->getExtInfo());
New->setType(NewType);
return false;
}
Ah, seems Richard has just adapted this workaround in 2016:
// The new function declaration is only missing an empty exception
// specification "throw()". If the throw() specification came from a
// function in a system header that has C linkage, just add an empty
// exception specification to the "new" declaration. Note that C library
// implementations are permitted to add these nothrow exception
// specifications.
//
// Likewise if the old function is a builtin.
if (MissingEmptyExceptionSpecification && NewProto &&
(Old->getLocation().isInvalid() ||
Context.getSourceManager().isInSystemHeader(Old->getLocation()) ||
Old->getBuiltinID()) &&
Old->isExternC()) {
New->setType(Context.getFunctionType(
NewProto->getReturnType(), NewProto->getParamTypes(),
NewProto->getExtProtoInfo().withExceptionSpec(EST_DynamicNone)));
return false;
}
Added a reproducer to the repo: https://github.com/Teemperor/clang-modules-bugs/tree/master/posix_memalign_repro
Our modulemap was not marked as system, so event though it was a in a system include it got built as a non-system and then above's check obviously fails.
So when modularizing libc, I encountered this problem:
Example error in travis
Looking at the mm_malloc.h, it seems this error is known and just needs to be properly fixed in modules: