This is an archive of the discontinued LLVM Phabricator instance.

[include-cleaner] Improve header spelling in the presence of links
ClosedPublic

Authored by sammccall on Jan 11 2023, 3:06 AM.

Details

Summary

HeaderSearch uses FileEntry::getName() to determine the best spelling of a
header. FileEntry::getName() is now the name of the *last* retrieved ref.
This means that when FileManager::getFile() hits an existing inode through a new
path, it changes the spelling of that header.

In the absence of explicit logic to track the preferred name(s) of header files,
we should avoid gratuitously calling getFile() with paths different than how
the header was originally included, such as the result of realpath().

The originally-specified path should be fine here:

  • if the same filemanager is being used for record/analysis, we'll hit the filename cache
  • if a different filemanager is being used e.g. preamble scenario, we should get the same result unless either the working directory has changed (which it shouldn't, else many other things will fail) or the file has gone/changed inode (in which case the old method doesn't work either)

Needless to say this is fragile, but talking to @kadircet offline, it's good
enough for our purposes for now.

Diff Detail

Event Timeline

sammccall created this revision.Jan 11 2023, 3:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 11 2023, 3:06 AM
sammccall requested review of this revision.Jan 11 2023, 3:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 11 2023, 3:06 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Thanks for tracking it down. The solution looks good to me. Since this is a fragile and subtle issue, is it possible to have a unittest for it? If it is not too hard, it would be nice to have a test.

hokein accepted this revision.Jan 11 2023, 5:39 AM
This revision is now accepted and ready to land.Jan 11 2023, 5:39 AM

Thanks for tracking it down. The solution looks good to me. Since this is a fragile and subtle issue, is it possible to have a unittest for it? If it is not too hard, it would be nice to have a test.

I think it's hard to write a test that's worth anything :-(

It can't be a test that poking FileManager doesn't affect spelling, because I didn't fix that.
I can test specifically that getExports() doesn't affect the getName() of relevant fileentries, but if we regress this symptom that's very unlikely to be the mechanism.
An end-to-end test for the symptom needs to be set up in a way that tickles the bad side-effect at exactly the wrong time, and it's hard to predict how to do that in general.

I'm not happy with this patch, but I'm not sure a bad test would help with that :-\

This revision was landed with ongoing or failed builds.Jan 11 2023, 5:44 AM
This revision was automatically updated to reflect the committed changes.