Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3931 | Will this ever have an issue with lifetime? I can see various values for EXTRACTOR causing issues here. https://abseil.io/tips/107 It would be good to at least document somewhere the restrictions on EXTRACTOR. |
Addressed review feedback. WDYT @Bigcheese?
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3931 | Mentioned the reference lifetime extension in a comment near extractor definitions. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3931 | It might be safer to refactor as: // Capture the extracted value as a lambda argument to avoid potential // lifetime extension issues. [&](const auto &Extracted) { if (ALWAYS_EMIT || Extracted != (DEFAULT_VALUE)) DENORMALIZER(Args, SPELLING, SA, TABLE_INDEX, Extracted); }(EXTRACTOR(this->KEYPATH)); | |
3931 | IIUC, then we can do this more simply as: bool Extracted = EXTRACTOR(this->KEYPATH); That might clarify why we don't have lifetime extension concerns here. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3931 | Might be even better to avoid the generic lambda: // Capture the extracted value as a lambda argument to avoid potential // lifetime extension issues. using ExtractedType = std::remove_const_t<std::remove_reference_t< decltype(EXTRACTOR(this->KEYPATH))>> [&](const ExtractedType &Extracted) { if (ALWAYS_EMIT || Extracted != (DEFAULT_VALUE)) DENORMALIZER(Args, SPELLING, SA, TABLE_INDEX, Extracted); }(EXTRACTOR(this->KEYPATH)); (since generic vs. non-generic could affect compile-time of CompilerInvocation.cpp given how many instances there will be). |
Marking as "requested changes" to get this off my queue, but if my lambda suggestion doesn't work well for some reason (maybe it significantly increases compile-time), I'm open to sticking to the documentation @Bigcheese suggested.
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3931 | Thanks for the suggestions @dexonsmith. I'm having trouble writing a test case where the lambda workaround produces a different result than const auto & variable. | |
3931 | Yes, we could simplify this for booleans. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3931 | I think I was confused about when this can happen. The const auto & will never cause a conversion that would prevent lifetime extension. The only place this would break is if the copy constructor of the type is rather broken, which isn't a reasonable case to support. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3931 | Now I remember what the issue was, it's if the EXTRACTOR itself creates an owning temporary and converts back to a reference type: https://godbolt.org/z/xsvh4f This is kind of weird to do, the EXTRACTOR would need to take an owning type with an implicit conversion from the type of KEYPATH, and then return a reference type. I'm not sure how realistic that situation is, but it seems fine to defend against with Duncan's suggestion. |
Will this ever have an issue with lifetime? I can see various values for EXTRACTOR causing issues here. https://abseil.io/tips/107
It would be good to at least document somewhere the restrictions on EXTRACTOR.