This is an archive of the discontinued LLVM Phabricator instance.

[clang][lex] Remove `PPCallbacks::FileNotFound()`
ClosedPublic

Authored by jansvoboda11 on Feb 14 2022, 6:09 AM.

Details

Summary

The purpose of the FileNotFound preprocessor callback was to add the ability to recover from failed header lookups. This was to support downstream project.

However, injecting additional search path while performing header search can invalidate currently used iterators/references to DirectoryLookup in Preprocessor and HeaderSearch.

The downstream project ended up maintaining a separate patch to further tweak the functionality. Since we don't have any upstream users nor open source downstream users, I'd like to remove this callback for good to prevent future misuse. I doubt there are any actual downstream users, since the functionality is definitely broken at the moment.

Diff Detail

Event Timeline

jansvoboda11 created this revision.Feb 14 2022, 6:09 AM
jansvoboda11 requested review of this revision.Feb 14 2022, 6:09 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 14 2022, 6:09 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
ahoppen accepted this revision.Feb 14 2022, 9:41 AM

Assuming that this is indeed never used, removing dead code always sounds good to me.

This revision is now accepted and ready to land.Feb 14 2022, 9:41 AM

Hello, sorry for the late heads-up, but this functionality is used by ROOT: https://github.com/root-project/root/blob/f58cccf5ce7fd67894c7fd9e9e74d3f37bc1acba/core/metacling/src/TClingCallbacks.cxx#L282 Any chance of bringing this back?

Herald added a project: Restricted Project. · View Herald TranscriptJan 17 2023, 8:26 AM
Herald added a subscriber: ributzka. · View Herald Transcript

Hello, sorry for the late heads-up, but this functionality is used by ROOT: https://github.com/root-project/root/blob/f58cccf5ce7fd67894c7fd9e9e74d3f37bc1acba/core/metacling/src/TClingCallbacks.cxx#L282 Any chance of bringing this back?

Hi. Your downstream callback never fills in RecoveryPath and always returns false, meaning it will never reach the unsafe block of code I had issue with: HeaderInfo.AddSearchPath(DL, isAngled).
Technically, we could bring back a safe/trimmed-down version of this callback that doesn't take the out-parameter and returns void. But I don't think it's the right call, since that would essentially re-introduce dead code to upstream.
This is probably best kept downstream, unless there are other downstream users.

Hello, sorry for the late heads-up, but this functionality is used by ROOT: https://github.com/root-project/root/blob/f58cccf5ce7fd67894c7fd9e9e74d3f37bc1acba/core/metacling/src/TClingCallbacks.cxx#L282 Any chance of bringing this back?

Hi. Your downstream callback never fills in RecoveryPath and always returns false, meaning it will never reach the unsafe block of code I had issue with: HeaderInfo.AddSearchPath(DL, isAngled).

This is true, but it provides us a hook to do something in case a file is not found. For ROOT, we "extend" the #include syntax and allow "modifiers" at the end. Then we do something special (completely on our own) for things like #include "myfile.C+" (note the plus).

Technically, we could bring back a safe/trimmed-down version of this callback that doesn't take the out-parameter and returns void. But I don't think it's the right call, since that would essentially re-introduce dead code to upstream.
This is probably best kept downstream, unless there are other downstream users.

Sure, but how would we do that without a hook? At the moment, we try very hard to reduce the number of patches that we carry for Clang (which is also why parts of Cling are upstreamed into clang-repl).

Hello, sorry for the late heads-up, but this functionality is used by ROOT: https://github.com/root-project/root/blob/f58cccf5ce7fd67894c7fd9e9e74d3f37bc1acba/core/metacling/src/TClingCallbacks.cxx#L282 Any chance of bringing this back?

Hi. Your downstream callback never fills in RecoveryPath and always returns false, meaning it will never reach the unsafe block of code I had issue with: HeaderInfo.AddSearchPath(DL, isAngled).
Technically, we could bring back a safe/trimmed-down version of this callback that doesn't take the out-parameter and returns void. But I don't think it's the right call, since that would essentially re-introduce dead code to upstream.
This is probably best kept downstream, unless there are other downstream users.

+1 for bringing back that piece of code because it seems an interesting event to listen to anyways. Would you be more comfortable if we provide also a test case and relevant comments explaining the use-case?

If the plan is to eventually upstream that part of Cling, I'm fine with re-adding a safe version of this API.

If the plan is to eventually upstream that part of Cling, I'm fine with re-adding a safe version of this API.

I'll be honest here and say that I personally find it unlikely that this part of ROOT will be upstreamed, it is very specific and also there for backwards-compatibility in a very specific case. Nevertheless, I understand that Clang should offer its clients a rich API to get all information they need, so I put together https://reviews.llvm.org/D142196 with a hopefully "safe" version of a FileNotFound callback, that optionally even supports silently skipping this file. This would provide exactly what we need.

Another possibility that I considered is extending InclusionDirective and always call it, also for missing files. However, I find this much less clear and we already have FileSkipped...