Bug 251111
Summary: | StrongInlines.h methods should be marked as "inline" in Strong.h | ||
---|---|---|---|
Product: | WebKit | Reporter: | Jer Noble <jer.noble> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | Hironori.Fujii, mark.lam, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Jer Noble
Because they're not marked as "inline", if you include Strong.h and use Strong::Strong() or Strong::set() and _don't_ include StrongInlines.h, you will end up with a linker error, as these methods are not exported.
However, adding "inline" to these methods expose a number of build errors. Someone should do the work to mark these as "inline" and clean up all the places where these methods are used without including StrongInlines.h.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Jer Noble
E.g.:
OpenSource/Source/JavaScriptCore/heap/Strong.h:97:17: error: inline function 'JSC::Strong<JSC::JSObject, JSC::ShouldStrongDestructorGrabLock::No>::set' is not defined [-Werror,-Wundefined-inline]
inline void set(VM&, ExternalType);
^
In file included from OpenSource/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:31:
In file included from OpenSource/WebKitBuild/Debug/DerivedSources/JavaScriptCore/BytecodeStructs.h:31:
In file included from OpenSource/Source/JavaScriptCore/bytecode/BytecodeDumper.h:31:
In file included from OpenSource/Source/JavaScriptCore/bytecode/CallLinkInfo.h:34:
In file included from OpenSource/Source/JavaScriptCore/jit/PolymorphicCallStubRoutine.h:30:
In file included from OpenSource/Source/JavaScriptCore/bytecode/CallEdge.h:28:
In file included from OpenSource/Source/JavaScriptCore/bytecode/CallVariant.h:28:
In file included from OpenSource/Source/JavaScriptCore/runtime/ExecutableBaseInlines.h:28:
In file included from OpenSource/Source/JavaScriptCore/runtime/ExecutableBase.h:33:
OpenSource/Source/JavaScriptCore/runtime/JSGlobalObject.h:1092:99: note: used here
void setUnhandledRejectionCallback(VM& vm, JSObject* function) { m_unhandledRejectionCallback.set(vm, function); }
Radar WebKit Bug Importer
<rdar://problem/104882770>
Mark Lam
Some methods are deliberately not marked as `inline` to avoid this dance. The user of these methods should know to inline the Inlines.h if they actually needed the implementation of the inline function. The alternative is an expensive exercise to move a lot of code around for little benefit.
Mark Lam
(In reply to Mark Lam from comment #3)
> Some methods are deliberately not marked as `inline` to avoid this dance.
> The user of these methods should know to inline the Inlines.h if they
> actually needed the implementation of the inline function. The alternative
> is an expensive exercise to move a lot of code around for little benefit.
"should know to inline the Inlines.h" => "should know to #include the Inlines.h"