maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Modules/crash-vfs-path-traversal.m

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

67 lines
2.8 KiB
Mathematica
Raw Normal View History

Replace lit feature keyword 'non-ms-sdk' with 'ms-sdk'; eliminate 'non-ps4-sdk' and use just 'ps4'. llvm-svn: 360425
2019-05-10 21:40:17 +08:00
// REQUIRES: crash-recovery, shell
// UNSUPPORTED: ms-sdk, ps4
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// FIXME: Canonicalizing paths to remove relative traversal components
// currenty fails a unittest on windows and is disable by default.
// FIXME: This XFAIL is cargo-culted from crash-report.c. Do we need it?
[CMake] Use normalized Windows target triples Changes the default Windows target triple returned by GetHostTriple.cmake from the old environment names (which we wanted to move away from) to newer, normalized ones. This also requires updating all tests to use the new systems names in constraints. Differential Revision: https://reviews.llvm.org/D47381 llvm-svn: 339307
2018-08-09 10:16:18 +08:00
// XFAIL: windows-gnu
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// RUN: rm -rf %t
// RUN: mkdir -p %t/i %t/m %t
Prefer 'env not' over 'not env' in tests. That way, lit's builtin 'env' command can be used for the 'env' bit. Also it's clearer that way that the 'not' shouldn't cover 'env' failures. llvm-svn: 374749
2019-10-14 09:41:56 +08:00
// RUN: env FORCE_CLANG_DIAGNOSTICS_CRASH= TMPDIR=%t TEMP=%t TMP=%t \
// RUN: not %clang -fsyntax-only %s -I %S/Inputs/crash-recovery -isysroot %/t/i/ \
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// RUN: -fmodules -fmodules-cache-path=%t/m/ 2>&1 | FileCheck %s
// RUN: FileCheck --check-prefix=CHECKSRC %s -input-file %t/crash-vfs-*.m
// RUN: FileCheck --check-prefix=CHECKSH %s -input-file %t/crash-vfs-*.sh
// RUN: FileCheck --check-prefix=CHECKYAML %s -input-file \
// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml
// RUN: find %t/crash-vfs-*.cache/vfs | \
Use a simpler set of mock headers for the vfs+modules crash recovery tests. The System/ mock is large and too complex for this test. It can cause the tests to fail in mysterious ways as it depends on the resource dir being present, which is not really supported for driver tests (using %clang instead of %clang_cc1). Copy the tree and trim out all the %unnecessary fat. llvm-svn: 263718
2016-03-18 00:19:51 +08:00
// RUN: grep "Inputs/crash-recovery/usr/include/stdio.h" | count 1
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
#include "usr/././//////include/../include/./././../include/stdio.h"
// CHECK: Preprocessed source(s) and associated run script(s) are located at:
// CHECK-NEXT: note: diagnostic msg: {{.*}}.m
// CHECK-NEXT: note: diagnostic msg: {{.*}}.cache
Add pragma to perform module import and use it in -E output. Many of our supported configurations support modules but do not have any first-class syntax to perform a module import. This leaves us with a problem: there is no way to represent the expansion of a #include that imports a module in the -E output for such languages. (We don't want to just leave it as a #include because that requires the consumer of the preprocessed source to have the same file system layout and include paths as the creator.) This patch adds a new pragma: #pragma clang module import MODULE.NAME.HERE that imports a module, and changes -E and -frewrite-includes to use it when rewriting a #include that maps to a module import. We don't make any attempt to use a native language syntax import if one exists, to get more consistent output. (If in the future, @import and #include have different semantics in some way, the pragma will track the #include semantics.) llvm-svn: 301725
2017-04-29 08:34:47 +08:00
// CHECKSRC: #pragma clang module import cstd.stdio
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// CHECKSH: # Crash reproducer
// CHECKSH-NEXT: # Driver args: "-fsyntax-only"
// CHECKSH-NEXT: # Original command: {{.*$}}
// CHECKSH-NEXT: "-cc1"
// CHECKSH: "-isysroot" "{{[^"]*}}/i/"
// CHECKSH-NOT: "-fmodules-cache-path="
// CHECKSH: "crash-vfs-{{[^ ]*}}.m"
// CHECKSH: "-ivfsoverlay" "crash-vfs-{{[^ ]*}}.cache/vfs/vfs.yaml"
[CrashReproducer] Provide a clean dir path for -fmodules-cache-path The most common workflow with module reproducers involves deleting the module cache before running the script. This happens because leftovers from the crash are present in the cache and could trigger unrelated and confusing errors, misleading from the initial reproduction intent. Change this to point to a clean path but leave the leftovers untouched. rdar://problem/28655070 llvm-svn: 289176
2016-12-09 11:11:48 +08:00
// CHECKSH: "-fmodules-cache-path=crash-vfs-{{[^ ]*}}.cache/repro-modules"
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
[CrashReproducer] Setup 'use-external-names' in YAML files. Hide the real paths when rebuilding from VFS by setting up the crash reproducer to use 'use-external-names' = false. This way we avoid module redifinition errors and consistently use the same paths against all modules. With this change on Darwin we are able to simulate a crash for a simple application using "Foundation/Foundation.h" (which relies on a bunch of different frameworks and headers) and successfully rebuild all the modules by relying solely at the VFS overlay. llvm-svn: 266234
2016-04-14 03:28:21 +08:00
// CHECKYAML: 'case-sensitive':
// CHECKYAML-NEXT: 'use-external-names': 'false',
// CHECKYAML-NEXT: 'overlay-relative': 'true',
Reapply [2] [VFS] Add 'overlay-relative' field to YAML files This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263893
2016-03-20 10:08:48 +08:00
// CHECKYAML: 'type': 'directory'
// CHECKYAML: 'name': "/[[PATH:.*]]/Inputs/crash-recovery/usr/include",
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// CHECKYAML-NEXT: 'contents': [
// CHECKYAML-NEXT: {
// CHECKYAML-NEXT: 'type': 'file',
// CHECKYAML-NEXT: 'name': "module.map",
Reapply [2] [VFS] Add 'overlay-relative' field to YAML files This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263893
2016-03-20 10:08:48 +08:00
// CHECKYAML-NEXT: 'external-contents': "/[[PATH]]/Inputs/crash-recovery/usr/include/module.map"
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// CHECKYAML-NEXT: },
// Replace the paths in the YAML files with relative ".." traversals
// and fed into clang to test whether we're correctly representing them
// in the VFS overlay.
// RUN: sed -e "s@usr/include@usr/include/../include@g" \
// RUN: %t/crash-vfs-*.cache/vfs/vfs.yaml > %t/vfs.yaml
Reapply [2] [VFS] Add 'overlay-relative' field to YAML files This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263893
2016-03-20 10:08:48 +08:00
// RUN: cp %t/vfs.yaml %t/crash-vfs-*.cache/vfs/vfs.yaml
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// RUN: unset FORCE_CLANG_DIAGNOSTICS_CRASH
Revert "Reapply [VFS] Add 'overlay-relative' field to YAML files" Tests failing on http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/46102 This reverts commit a1683cd6c9e07359c09f86e98a4db6b4e1bc51fc. llvm-svn: 263750
2016-03-18 05:30:55 +08:00
// RUN: %clang -E %s -I %S/Inputs/crash-recovery -isysroot %/t/i/ \
Reapply [2] [VFS] Add 'overlay-relative' field to YAML files This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263893
2016-03-20 10:08:48 +08:00
// RUN: -ivfsoverlay %t/crash-vfs-*.cache/vfs/vfs.yaml -fmodules \
Reapply [2]: [VFS] Add support for handling path traversals This was applied twice r261551 and 263617 and later reverted because: (1) Windows bot failing on unittests. Change the current behavior to do not handle path traversals on windows. (2) Windows bot failed to include llvm/Config/config.h in order to use HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp. Handle ".", ".." and "./" with trailing slashes while collecting files to be dumped into the vfs overlay directory. Include the support for symlinks into components. Given the path: /install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin" component is a symlink, it's not safe to use `path::remove_dots` here, and `realpath` is used to get the right answer. Since `realpath` is expensive, we only do it at collecting time (which only happens during the crash reproducer) and cache the base directory for fast lookups. Overall, this makes the input to the VFS YAML file to be canonicalized to never contain traversal components. Differential Revision: http://reviews.llvm.org/D17104 rdar://problem/24499339 llvm-svn: 263686
2016-03-17 10:20:43 +08:00
// RUN: -fmodules-cache-path=%t/m/ 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECKOVERLAY
Add pragma to perform module import and use it in -E output. Many of our supported configurations support modules but do not have any first-class syntax to perform a module import. This leaves us with a problem: there is no way to represent the expansion of a #include that imports a module in the -E output for such languages. (We don't want to just leave it as a #include because that requires the consumer of the preprocessed source to have the same file system layout and include paths as the creator.) This patch adds a new pragma: #pragma clang module import MODULE.NAME.HERE that imports a module, and changes -E and -frewrite-includes to use it when rewriting a #include that maps to a module import. We don't make any attempt to use a native language syntax import if one exists, to get more consistent output. (If in the future, @import and #include have different semantics in some way, the pragma will track the #include semantics.) llvm-svn: 301725
2017-04-29 08:34:47 +08:00
// CHECKOVERLAY: #pragma clang module import cstd.stdio /* clang -E: implicit import