Skip to content

🌲[lit][clang] Avoid realpath on Windows due to MAX_PATH limitations #7298

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

etcwilde
Copy link
Member

Running lit tests on Windows can fail because its use of os.path.realpath expands substitute drives, which are used to keep paths short and avoid hitting MAX_PATH limitations.

Changes lit logic to:

Use os.path.abspath on Windows, where MAX_PATH is a concern that we can work around using substitute drives, which os.path.realpath would resolve.

Use os.path.realpath on Unix, where the current directory always has symlinks resolved, so it is impossible to preserve symlinks in the presence of relative paths, and so we must make sure that all code paths use real paths.

Also updates clang's FileManager::getCanonicalName and ExtractAPI code to avoid resolving substitute drives (i.e. resolving to a path under a different root).

How tested: built with -DLLVM_ENABLE_PROJECTS=clang and built check-all on both Windows

Differential Revision: https://reviews.llvm.org/D154130
Reviewed By: @benlangmuir

Patch by Tristan Labelle [email protected]!

CC @tristanlabelle

Fixes AttributeError: module 'lit.util' has no attribute 'abs_path_preserve_drive' failure on Rebranch CI.

Running lit tests on Windows can fail because its use of
`os.path.realpath` expands substitute drives, which are used to keep
paths short and avoid hitting MAX_PATH limitations.

Changes lit logic to:

Use `os.path.abspath` on Windows, where `MAX_PATH` is a concern that we
can work around using substitute drives, which `os.path.realpath` would
resolve.

Use `os.path.realpath` on Unix, where the current directory always has
symlinks resolved, so it is impossible to preserve symlinks in the
presence of relative paths, and so we must make sure that all code paths
use real paths.

Also updates clang's `FileManager::getCanonicalName` and `ExtractAPI`
code to avoid resolving substitute drives (i.e. resolving to a path
under a different root).

How tested: built with `-DLLVM_ENABLE_PROJECTS=clang` and built `check-all` on both Windows

Differential Revision: https://reviews.llvm.org/D154130
Reviewed By: @benlangmuir

Patch by Tristan Labelle <[email protected]>!
@etcwilde etcwilde requested a review from compnerd August 22, 2023 20:04
@etcwilde
Copy link
Member Author

@swift-ci please test

@etcwilde
Copy link
Member Author

Linux failure:

/home/build-user/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swiftc: symbol lookup error: /home/build-user/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swiftc: undefined symbol: swift_getTypeByMangledNameInContext2

This is coming from building early swift syntax on Linux, which isn't quite working yet.

@etcwilde
Copy link
Member Author

macOS has made it to testing. Merging to get signal on rebranch again.

@etcwilde etcwilde merged commit 50ea21c into swiftlang:stable/20230725 Aug 22, 2023
@etcwilde etcwilde deleted the ewilde/cherry-test-changes branch August 22, 2023 22:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants