forked from OSchip/llvm-project
705cd965e3
contents than the header file by the same name under the system header search root. Surprisingly, this is required to get the test to pass on some systems. So, it turns out that there exist filesystems in the world which unique the inode of all files based on their contents. This results in two files with the same contents at different paths suddenly having the same inode. This doesn't actually cause any problems in practice as the contents are the same, and the path used to access the files are the same. However, it can cause tests like this one to be more brittle because the file manager ends up de-duplicating the file entries by inode. We don't have any other really easy ways to observe the behavior shift because the whole point is that the #include written in the source code doesn't contain the information -- instead it is contained in the header map. If folks have other solutions they would prefer, I'm more than happy to work on them, but this seems a reasonable way to ensure that the test in question exercises the code it wants to exercise. llvm-svn: 205149 |
||
|---|---|---|
| .. | ||
| TestFramework.framework | ||
| headermap-rel | ||
| headermap-rel2 | ||
| microsoft-header-search | ||