This is an archive of the discontinued LLVM Phabricator instance.

[clang][test] Disallow using the default module cache path in lit tests
ClosedPublic

Authored by benlangmuir on Sep 9 2022, 4:16 PM.

Details

Summary

Make the default module cache path invalid when running lit tests so
that tests are forced to provide a cache path. This avoids accidentally
escaping to the system default location, and would have caught the
failure recently found in ClangScanDeps/multiple-commands.c.

Diff Detail

Event Timeline

benlangmuir created this revision.Sep 9 2022, 4:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 9 2022, 4:16 PM
Herald added a subscriber: delcypher. · View Herald Transcript
benlangmuir requested review of this revision.Sep 9 2022, 4:16 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptSep 9 2022, 4:16 PM
bruno accepted this revision.Sep 9 2022, 5:26 PM

Awesome!

This revision is now accepted and ready to land.Sep 9 2022, 5:26 PM

Reverted due to failure on a bot https://lab.llvm.org/buildbot/#/builders/214/builds/3252

I'm not sure how to deal with missing env -u.

  • We could do env CLANG_MODULE_CACHE_PATH= and change the compiler's interpretation of empty string for this variable. I'm not sure if the current behaviour (there will be no module cache in the cc1 at all) is intentional or useful. Hesitant to change this behaviour.
  • We could try to enumerate all the environments that don't support env -u and disable these two tests on those platforms. So far it was just one AIX bot, but I wouldn't be surprised if other less commonly used unixes have the same issue.
  • We could make the command inscrutable, like not env -u X true || env -u ... real command ... so that if env -u X true fails (presumably due to not supporting -u option) we won't run the rest of the RUN line.

If someone has a suggestion for a simple fix, I can try again. But otherwise I doubt it's worth putting much time into this.

bruno added a comment.Sep 13 2022, 6:08 PM

I'm not sure how to deal with missing env -u.

  • We could do env CLANG_MODULE_CACHE_PATH= and change the compiler's interpretation of empty string for this variable. I'm not sure if the current behaviour (there will be no module cache in the cc1 at all) is intentional or useful. Hesitant to change this behaviour.

How about using self.with_environment('CLANG_MODULE_CACHE_PATH', '') so we don't need to worry about using env -u to unset? My understand is that (1) getDefaultModuleCachePath is the only place using CLANG_MODULE_CACHE_PATH, and (2) std::getenv return nullptr if it's empty, which will fallback to system provided path instead.

  • We could try to enumerate all the environments that don't support env -u and disable these two tests on those platforms. So far it was just one AIX bot, but I wouldn't be surprised if other less commonly used unixes have the same issue.
  • We could make the command inscrutable, like not env -u X true || env -u ... real command ... so that if env -u X true fails (presumably due to not supporting -u option) we won't run the rest of the RUN line.

Not sure it helps much but according to option-X.test, system-aix support unset.

If someone has a suggestion for a simple fix, I can try again. But otherwise I doubt it's worth putting much time into this.

Thanks for trying to improve this :)

I'm not sure how to deal with missing env -u.

  • We could do env CLANG_MODULE_CACHE_PATH= and change the compiler's interpretation of empty string for this variable. I'm not sure if the current behaviour (there will be no module cache in the cc1 at all) is intentional or useful. Hesitant to change this behaviour.

How about using self.with_environment('CLANG_MODULE_CACHE_PATH', '') so we don't need to worry about using env -u to unset? My understand is that (1) getDefaultModuleCachePath is the only place using CLANG_MODULE_CACHE_PATH, and (2) std::getenv return nullptr if it's empty, which will fallback to system provided path instead.

Where are you thinking we would call self.with_environment in this case? We explicitly do not want the system-provided path in most tests. I think we would need to set it to None, since

(2) std::getenv return nullptr if it's empty, which will fallback to system provided path instead.

getenv returns empty string, not nullptr.

Not sure it helps much but according to option-X.test, system-aix support unset.

Heh, I'm worried we'll just hit an issue with a different platform (Windows?). If we can't find a better fix I guess I can at least attempt it and see what breaks.