bcm5719-llvm/clang/test/VFS, branch meklort-10.0.0

Fix external-names.c test when separator is \\

2019-12-31T11:15:46+00:00

This fixes the following failure: C:\[...]\llvm\tools\clang\test\VFS\external-names.c:34:26: error: CHECK-DEBUG-EXTERNAL: expected string not found in input // CHECK-DEBUG-EXTERNAL: ![[Num]] = !DIFile(filename: "{{[^"]*}}Inputs{{.}}external-names.h" ^ [...] :42:54: note: possible intended match here !10 = !DIFile(filename: "C:/[...]\\llvm\\tools\\clang\\test\\VFS\\Inputs\\external-names.h", directory: "") Differential Revision: https://reviews.llvm.org/D71991

[VFS] Don't run symlink test on Windows, it may pass or fail

2019-12-27T18:39:47+00:00

This test was XFAILed because of symlinks, but some versions of ln -s seem to work on Windows, so the test was unexpectedly passing on our bot: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/13233 Unexpected Passing Tests (1): Clang :: VFS/subframework-symlink.m I don't know how or why, but it seems dependent on system configuration, and is not something worth debugging. Avoid the problem by marking the test UNSUPPORTED: system-windows instead of XFAIL: system-windows.

[NFC] Update FIXME for one VFS test

2019-12-18T19:38:04+00:00

The VFS/subframework-symlink.m test is still XFAIL on Windows, but for a different reason than those fixed in PR43272, so I've updated the PR number.

Fix more VFS tests on Windows

2019-12-18T19:38:04+00:00

Since VFS paths can be in either Posix or Windows style, we have to use a more flexible definition of "absolute" path. The key here is that FileSystem::makeAbsolute is now virtual, and the RedirectingFileSystem override checks for either concept of absolute before trying to make the path absolute by combining it with the current directory. Differential Revision: https://reviews.llvm.org/D70701

Fix `sed -e s@FOO@%/S@` and similar when there's @'s in the working directory

2019-12-03T23:44:01+00:00

Jenkins sometimes starts a new working directory by appending @2 (or incrementing the number if the @n suffix is already there). This causes several clang tests to fail as: s@INPUT_DIR@%/S/Inputs@g gets expanded to the invalid: s@INPUT_DIR@/path/to/workdir@2/Inputs@g ~~~~~~~~~~ where the part marked with ~'s is interpreted as the flags. These are invalid and the test fails. Previous fixes simply exchanged the @ character for another like | but that's just moving the problem. Address it by adding an expansion that escapes the @ character we're using as a delimiter as well as other magic characters in the replacement of sed's s@@@. There's still room for expansions to cause trouble though. One I ran into while testing this was that having a directory called foo@bar causes lots of `CHECK-NOT: foo` directives to match. There's also things like directories containing `\1`

Improve VFS compatibility on Windows

2019-11-14T16:48:47+00:00

Keys in a virtual file system can be in Posix or Windows form or even a combination of the two. Many VFS tests (and a few Clang tests) were XFAILed on Windows because of false negatives when comparing paths. First, we default CaseSenstive to false on Windows. This allows drive letters like "D:" to match "d:". Windows filesystems are, by default, case insensitive, so this makes sense even beyond the drive letter. Second, we allow slashes to match backslashes when they're used as the root component of a path. Both of these changes are limited to RedirectingFileSystems, so there's little chance of affecting other path handling. These changes allow eleven of the VFS tests to pass on Windows as well as three other Clang tests, so they have re-enabled. This solves the majority of PR43272. Additional VFS test failures will be fixed in separate patches. Differential Revision: https://reviews.llvm.org/D69958

Switch "windows" to "system-windows" in some XFAILs

2019-09-12T11:19:12+00:00

The test failure mode appears to be due to the host machine rather than the target. The PS4 buildbots are windows-hosted targeting x86_64-scei-ps4, and are currently reporting these as unexpected failures: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/28114 llvm-svn: 371726

Start porting ivfsoverlay tests to Windows

2019-09-11T20:56:25+00:00

Part of PR43272, the changes are: 1. Use @ as the sed pattern delimiter instead of : so that the drive letter in lit substitutions isn't an issue. 2. Use the %/t and %/S substitutions to get paths with forward slashes to work around string quoting issues in the yaml file. 3. Replace REQUIRES:shell with XFAIL:windows. These tests should pass on Windows, but do not for reasons that are not yet understood. We would like to know if they pass unexpectedly. I was able to remove the XFAILs from two tests, since they already pass with my sed fix: clang/test/VFS/module_missing_vfs.m clang/test/VFS/test_nonmodular.c Reviewers: amccarth Differential Revision: https://reviews.llvm.org/D67454 llvm-svn: 371663

Introduce FileEntryRef and use it when handling includes to report correct dependencies

2019-08-22T18:15:50+00:00

when the FileManager is reused across invocations This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns a reference to the FileEntry, and the name that was used to access the file. In the case of a VFS with 'use-external-names', the FileEntyRef contains the external name of the file, not the filename that was used to access it. The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations. Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits. Differential Revision: https://reviews.llvm.org/D65907 llvm-svn: 369680

[VFS] Implement `RedirectingFileSystem::getRealPath`.

2018-11-16T01:18:04+00:00

It fixes the case when Objective-C framework is added as a subframework through a symlink. When parent framework infers a module map and fails to detect a symlink, it would add a subframework as a submodule. And when we parse module map for the subframework, we would encounter an error like > error: umbrella for module 'WithSubframework.Foo' already covers this directory By implementing `getRealPath` "an egregious but useful hack" in `ModuleMap::inferFrameworkModule` works as expected. LLVM commit is r347009. rdar://problem/45821279 Reviewers: bruno, benlangmuir, erik.pilkington Reviewed By: bruno Subscribers: hiraditya, dexonsmith, JDevlieghere, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D54245 llvm-svn: 347012