Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Semantic token tests on Windows don’t report stdlib declarations as defaultLibrary #1770

Open
ahoppen opened this issue Oct 18, 2024 · 1 comment · May be fixed by swiftlang/swift#77120 or #1773
Open

Semantic token tests on Windows don’t report stdlib declarations as defaultLibrary #1770

ahoppen opened this issue Oct 18, 2024 · 1 comment · May be fixed by swiftlang/swift#77120 or #1773

Comments

@ahoppen
Copy link
Member

ahoppen commented Oct 18, 2024

I needed to disable quite a few SemanticTokenTests because stdlib symbols are not correctly reported as defaultLibrary on Windows. Investigate why.
@ahoppen
Copy link
Member Author

ahoppen commented Oct 18, 2024

Synced to Apple’s issue tracker as rdar://138210224

ahoppen added a commit to ahoppen/swift that referenced this issue Oct 19, 2024
@ahoppen
[SourceKit] Check if the realpath of a module is inside the SDK to de…
413d31d 
…cide if it's system

On Windows, we run into the following situation when running SourceKit-LSP tests:
- The SDK is located at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk` with `S:` being a substitution drive
- We find `Swift.swiftmodule` at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule`
- Now, to check if `Swift.swiftmodule` is a system module, we take the realpath of the SDK, which resolves the substitution drive an results in something like `C:\Users\alex\src\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk`
- Since we don’t take the realpath of `Swift.swiftmodule`, we will assume that it’s not in the SDK, because the SDK’s path is on `C:` while `Swift.swiftmodule` lives on `S:`

To fix this, we also need to check if a module’s real path is inside the SDK.

Fixes swiftlang/sourcekit-lsp#1770
rdar://138210224
@ahoppen ahoppen linked a pull request Oct 19, 2024 that will close this issue
Open
ahoppen added a commit to ahoppen/swift that referenced this issue Oct 19, 2024
@ahoppen
[SourceKit] Check if the realpath of a module is inside the SDK to de…
4cb6425 
…cide if it's system

On Windows, we run into the following situation when running SourceKit-LSP tests:
- The SDK is located at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk` with `S:` being a substitution drive
- We find `Swift.swiftmodule` at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule`
- Now, to check if `Swift.swiftmodule` is a system module, we take the realpath of the SDK, which resolves the substitution drive an results in something like `C:\Users\alex\src\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk`
- Since we don’t take the realpath of `Swift.swiftmodule`, we will assume that it’s not in the SDK, because the SDK’s path is on `C:` while `Swift.swiftmodule` lives on `S:`

To fix this, we also need to check if a module’s real path is inside the SDK.

Fixes swiftlang/sourcekit-lsp#1770
rdar://138210224
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this issue Oct 19, 2024
@ahoppen
Re-enable SemanticTokenTests and SwiftInterfaceTests on Windows
fba4a79 
The underlying issue was fixed by swiftlang/swift#77120

Fixes swiftlang#1770
Fixes swiftlang#1771
rdar://138210224
rdar://138210215
@ahoppen ahoppen linked a pull request Oct 19, 2024 that will close this issue
Open
ahoppen added a commit to ahoppen/swift that referenced this issue Oct 19, 2024
@ahoppen
[SourceKit] Check if the realpath of a module is inside the SDK to de…
50ae6c6 
…cide if it's system

On Windows, we run into the following situation when running SourceKit-LSP tests:
- The SDK is located at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk` with `S:` being a substitution drive
- We find `Swift.swiftmodule` at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule`
- Now, to check if `Swift.swiftmodule` is a system module, we take the realpath of the SDK, which resolves the substitution drive an results in something like `C:\Users\alex\src\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk`
- Since we don’t take the realpath of `Swift.swiftmodule`, we will assume that it’s not in the SDK, because the SDK’s path is on `C:` while `Swift.swiftmodule` lives on `S:`

To fix this, we also need to check if a module’s real path is inside the SDK.

Fixes swiftlang/sourcekit-lsp#1770
rdar://138210224
ahoppen added a commit to ahoppen/swift that referenced this issue Oct 19, 2024
@ahoppen
[SourceKit] Check if the realpath of a module is inside the SDK to de…
a287e2a 
…cide if it's system

On Windows, we run into the following situation when running SourceKit-LSP tests:
- The SDK is located at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk` with `S:` being a substitution drive
- We find `Swift.swiftmodule` at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule`
- Now, to check if `Swift.swiftmodule` is a system module, we take the realpath of the SDK, which resolves the substitution drive an results in something like `C:\Users\alex\src\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk`
- Since we don’t take the realpath of `Swift.swiftmodule`, we will assume that it’s not in the SDK, because the SDK’s path is on `C:` while `Swift.swiftmodule` lives on `S:`

To fix this, we also need to check if a module’s real path is inside the SDK.

Fixes swiftlang/sourcekit-lsp#1770
rdar://138210224
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@ahoppen