maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/VFS/external-names.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

51 lines
2.3 KiB
C
Raw Normal View History

Fix `sed -e s@FOO@%/S@` and similar when there's @'s in the working directory 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`
2019-12-04 07:22:30 +08:00
// RUN: sed -e "s@INPUT_DIR@%{/S:regex_replacement}/Inputs@g" -e "s@OUT_DIR@%{/t:regex_replacement}@g" -e "s@EXTERNAL_NAMES@true@" %S/Inputs/use-external-names.yaml > %t.external.yaml
// RUN: sed -e "s@INPUT_DIR@%{/S:regex_replacement}/Inputs@g" -e "s@OUT_DIR@%{/t:regex_replacement}@g" -e "s@EXTERNAL_NAMES@false@" %S/Inputs/use-external-names.yaml > %t.yaml
Start porting ivfsoverlay tests to Windows 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
2019-09-12 04:56:25 +08:00
Reapply fixed "Honour 'use-external-names' in FileManager" Was r202442 There were two issues with the original patch that have now been fixed. 1. We were memset'ing over a FileEntry in a test case. After adding a std::string to FileEntry, this still happened to not break for me. 2. I didn't pass the FileManager into the new compiler instance in compileModule. This was hidden in some cases by the fact I didn't clear the module cache in the test. Also, I changed the copy constructor for FileEntry, which was memcpy'ing in a (now) unsafe way. llvm-svn: 202539
2014-03-01 05:16:07 +08:00
#include "external-names.h"
Introduce FileEntryRef and use it when handling includes to report correct dependencies 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
2019-08-23 02:15:50 +08:00
#ifdef REINCLUDE
#include "external-names.h"
#endif
Reapply fixed "Honour 'use-external-names' in FileManager" Was r202442 There were two issues with the original patch that have now been fixed. 1. We were memset'ing over a FileEntry in a test case. After adding a std::string to FileEntry, this still happened to not break for me. 2. I didn't pass the FileManager into the new compiler instance in compileModule. This was hidden in some cases by the fact I didn't clear the module cache in the test. Also, I changed the copy constructor for FileEntry, which was memcpy'ing in a (now) unsafe way. llvm-svn: 202539
2014-03-01 05:16:07 +08:00
////
// Preprocessor (__FILE__ macro and # directives):
// RUN: %clang_cc1 -I %t -ivfsoverlay %t.external.yaml -E %s | FileCheck -check-prefix=CHECK-PP-EXTERNAL %s
[VFS] More consistent support for Windows Removed some #ifdefs specific to Windows handling of VFS paths. This eliminates most of the differences between the Windows and non-Windows code paths. Making this work required some changes to account for the fact that VFS file paths can be Posix style or Windows style, so you cannot just assume that they use the host's native path style. In one case, this means implementing our own version of make_absolute, since the filesystem code in Support doesn't have styles in the sense that the path code does. Differential Review: https://reviews.llvm.org/D71092
2020-01-22 08:45:51 +08:00
// CHECK-PP-EXTERNAL: # {{[0-9]*}} "[[NAME:.*Inputs(/|\\\\)external-names.h]]"
Reapply fixed "Honour 'use-external-names' in FileManager" Was r202442 There were two issues with the original patch that have now been fixed. 1. We were memset'ing over a FileEntry in a test case. After adding a std::string to FileEntry, this still happened to not break for me. 2. I didn't pass the FileManager into the new compiler instance in compileModule. This was hidden in some cases by the fact I didn't clear the module cache in the test. Also, I changed the copy constructor for FileEntry, which was memcpy'ing in a (now) unsafe way. llvm-svn: 202539
2014-03-01 05:16:07 +08:00
// CHECK-PP-EXTERNAL-NEXT: void foo(char **c) {
// CHECK-PP-EXTERNAL-NEXT: *c = "[[NAME]]";
// RUN: %clang_cc1 -I %t -ivfsoverlay %t.yaml -E %s | FileCheck -check-prefix=CHECK-PP %s
// CHECK-PP-NOT: Inputs
////
// Diagnostics:
// RUN: %clang_cc1 -I %t -ivfsoverlay %t.external.yaml -fsyntax-only %s 2>&1 | FileCheck -check-prefix=CHECK-DIAG-EXTERNAL %s
Fix external-names.c test when separator is \\ 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" ^ [...] <stdin>: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
2019-12-30 16:21:42 +08:00
// CHECK-DIAG-EXTERNAL: {{.*}}Inputs{{..?}}external-names.h:{{[0-9]*:[0-9]*}}: warning: incompatible pointer
Reapply fixed "Honour 'use-external-names' in FileManager" Was r202442 There were two issues with the original patch that have now been fixed. 1. We were memset'ing over a FileEntry in a test case. After adding a std::string to FileEntry, this still happened to not break for me. 2. I didn't pass the FileManager into the new compiler instance in compileModule. This was hidden in some cases by the fact I didn't clear the module cache in the test. Also, I changed the copy constructor for FileEntry, which was memcpy'ing in a (now) unsafe way. llvm-svn: 202539
2014-03-01 05:16:07 +08:00
// RUN: %clang_cc1 -I %t -ivfsoverlay %t.yaml -fsyntax-only %s 2>&1 | FileCheck -check-prefix=CHECK-DIAG %s
// CHECK-DIAG-NOT: Inputs
////
// Debug info
Stop messing with the 'g' group of options in CompilerInvocation. With this change, most 'g' options are rejected by CompilerInvocation. They remain only as Driver options. The new way to request debug info from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}" and "-dwarf-version={2|3|4}". In the absence of a command-line option to specify Dwarf version, the Toolchain decides it, rather than placing Toolchain-specific logic in CompilerInvocation. Also fix a bug in the Windows compatibility argument parsing in which the "rightmost argument wins" principle failed. Differential Revision: http://reviews.llvm.org/D13221 llvm-svn: 249655
2015-10-08 12:24:12 +08:00
// RUN: %clang_cc1 -I %t -ivfsoverlay %t.external.yaml -triple %itanium_abi_triple -debug-info-kind=limited -emit-llvm %s -o - | FileCheck -check-prefix=CHECK-DEBUG-EXTERNAL %s
DebugInfo: Metadata constructs now start with DI* LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now that the `DIDescriptor` hierarchy has been gone for about a week. This commit was generated using the rename-md-di-nodes.sh upgrade script attached to PR23080, followed by running clang-format-diff.py on the `lib/` portion of the patch. llvm-svn: 236121
2015-04-30 00:40:08 +08:00
// CHECK-DEBUG-EXTERNAL: !DISubprogram({{.*}}file: ![[Num:[0-9]+]]
Fix external-names.c test when separator is \\ 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" ^ [...] <stdin>: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
2019-12-30 16:21:42 +08:00
// CHECK-DEBUG-EXTERNAL: ![[Num]] = !DIFile(filename: "{{[^"]*}}Inputs{{..?}}external-names.h"
Reapply fixed "Honour 'use-external-names' in FileManager" Was r202442 There were two issues with the original patch that have now been fixed. 1. We were memset'ing over a FileEntry in a test case. After adding a std::string to FileEntry, this still happened to not break for me. 2. I didn't pass the FileManager into the new compiler instance in compileModule. This was hidden in some cases by the fact I didn't clear the module cache in the test. Also, I changed the copy constructor for FileEntry, which was memcpy'ing in a (now) unsafe way. llvm-svn: 202539
2014-03-01 05:16:07 +08:00
Stop messing with the 'g' group of options in CompilerInvocation. With this change, most 'g' options are rejected by CompilerInvocation. They remain only as Driver options. The new way to request debug info from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}" and "-dwarf-version={2|3|4}". In the absence of a command-line option to specify Dwarf version, the Toolchain decides it, rather than placing Toolchain-specific logic in CompilerInvocation. Also fix a bug in the Windows compatibility argument parsing in which the "rightmost argument wins" principle failed. Differential Revision: http://reviews.llvm.org/D13221 llvm-svn: 249655
2015-10-08 12:24:12 +08:00
// RUN: %clang_cc1 -I %t -ivfsoverlay %t.yaml -triple %itanium_abi_triple -debug-info-kind=limited -emit-llvm %s -o - | FileCheck -check-prefix=CHECK-DEBUG %s
Reapply fixed "Honour 'use-external-names' in FileManager" Was r202442 There were two issues with the original patch that have now been fixed. 1. We were memset'ing over a FileEntry in a test case. After adding a std::string to FileEntry, this still happened to not break for me. 2. I didn't pass the FileManager into the new compiler instance in compileModule. This was hidden in some cases by the fact I didn't clear the module cache in the test. Also, I changed the copy constructor for FileEntry, which was memcpy'ing in a (now) unsafe way. llvm-svn: 202539
2014-03-01 05:16:07 +08:00
// CHECK-DEBUG-NOT: Inputs
Introduce FileEntryRef and use it when handling includes to report correct dependencies 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
2019-08-23 02:15:50 +08:00
////
// Dependency file
// RUN: %clang_cc1 -D REINCLUDE -I %t -ivfsoverlay %t.external.yaml -Eonly %s -MTfoo -dependency-file %t.external.dep
// RUN: echo "EOF" >> %t.external.dep
// RUN: cat %t.external.dep | FileCheck --check-prefix=CHECK-DEP-EXTERNAL %s
Fix external-names.c test when separator is \\ 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" ^ [...] <stdin>: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
2019-12-30 16:21:42 +08:00
// CHECK-DEP-EXTERNAL: Inputs{{..?}}external-names.h
Introduce FileEntryRef and use it when handling includes to report correct dependencies 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
2019-08-23 02:15:50 +08:00
// CHECK-DEP-EXTERNAL-NEXT: EOF
// RUN: %clang_cc1 -D REINCLUDE -I %t -ivfsoverlay %t.yaml -Eonly %s -MTfoo -dependency-file %t.dep
// RUN: cat %t.dep | FileCheck --check-prefix=CHECK-DEP %s
// CHECK-DEP-NOT: Inputs