dexonsmith added a comment. I don't have access to rdar these days to look into the current state or to refresh my memory.
My memory is that the high-level goal was to move the libc++ headers from the toolchain to the SDK. For the transition, this was staged in such a way that they were in both locations for some period of time (internally, the transition may be ongoing, for all I know). Apple clang needed to prefer the SDK, since that was the "new" place. I don't remember the reasoning for inverting this behaviour for LLVM clang. - Maybe, because this way an LLVM toolchain could still override the C++ headers, like it could previously? - Maybe, there was a plan to eventually switch the default in LLVM clang, but that got dropped/forgotten? - Maybe, there was a plan to eventually switch the default in Apple clang, but that was dropped/forgotten, or the internal transition is ongoing? (This rings a bell. "Change LLVM clang to the desired end state, and we'll flip the direction temporarily in Apple clang for the duration of the transition...") Anyway, I'm not sure the best way forward here. Perhaps clang should have a flag to decide which is preferred. Or perhaps LLVM clang should just change to match Apple clang for now. @ldionne, thoughts? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89001/new/ https://reviews.llvm.org/D89001 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
