Add a #include <pal/Logging.h> to a .cpp file can break the build, because subsequent files in the same UnifiedSources*.cpp may use the LOG macro, and pal/Logging.h and Logging.h #define LOG_CHANNEL_PREFIX to different things. I don't think pal/Logging.h should define any log channels, nor define LOG_CHANNEL_PREFIX.
Errors look like: Undefined symbols for architecture x86_64: "WebCore::PALLogIndexedDB", referenced from: WebCore::injectIDBKeyIntoScriptValue(JSC::ExecState&, WebCore::IDBKeyData const&, JSC::JSValue, WTF::Variant<WTF::String, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul> > const&) in UnifiedSource170.o "WebCore::PALLogStorageAPI", referenced from: WebCore::canInjectIDBKeyIntoScriptValue(JSC::ExecState&, JSC::JSValue const&, WTF::Variant<WTF::String, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul> > const&) in UnifiedSource170.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
I think we can just gut pal/Logging.h
Might we want to move commonality up to WTF then specialize based on WebCore/PAL etc?
Yes, we should.
Created attachment 341941 [details] Patch
Comment on attachment 341941 [details] Patch Clearing flags on attachment: 341941 Committed r232550: <https://trac.webkit.org/changeset/232550>
All reviewed patches have been landed. Closing bug.
<rdar://problem/40859215>