You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The Swift extension currently resolves the Swift toolchain LLDB dylib used by CodeLLDB by following the symbolic link, if any, from other toolchain binaries to the toolchain install location and relative paths from there to the standard location. However, in some environments the symlink may not point to the toolchain. It can be a shell script, or some kind of proxy instead, which would mean that the dylib cannot be located in this way.
Describe the solution you'd like
Since the Swift extension has knowledge of swiftly already, such as the presence of the config.json file, it can use the toolchain location under swiftly to find the symbolic link.
Note that the proposal above includes a possible mechanism to invoke swiftly itself to find a toolchain location that could be another avenue for finding the physical location of a toolchain managed by swiftly. Currently, it looks something like this, but could change before it is released:
swiftly use --print-location
Describe alternatives you've considered
An alternative to this is to use the LLDB-DAP, which doesn't require the use of specific files within a toolchain for debugging.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The Swift extension currently resolves the Swift toolchain LLDB dylib used by CodeLLDB by following the symbolic link, if any, from other toolchain binaries to the toolchain install location and relative paths from there to the standard location. However, in some environments the symlink may not point to the toolchain. It can be a shell script, or some kind of proxy instead, which would mean that the dylib cannot be located in this way.
See the swiftly proxy proposal as an example.
Describe the solution you'd like
Since the Swift extension has knowledge of swiftly already, such as the presence of the
config.json
file, it can use the toolchain location under swiftly to find the symbolic link.Note that the proposal above includes a possible mechanism to invoke swiftly itself to find a toolchain location that could be another avenue for finding the physical location of a toolchain managed by swiftly. Currently, it looks something like this, but could change before it is released:
Describe alternatives you've considered
An alternative to this is to use the LLDB-DAP, which doesn't require the use of specific files within a toolchain for debugging.
Additional context
N/A
The text was updated successfully, but these errors were encountered: