Bugfix: ZLS download using incorrect target

[mirror-shades]

Fixes: #67

Bug:

In certain conditions Anyzig would target the wrong link when trying to download the Zig Language Server.

Problem:

There were two conditions found that would cause this error:

1. Using a version of Zig which doesn't map to a ZLS release. Because ZLS doesn't keep the same versioning as Zig, using the compiler version directly can fail.
   FIX: Zigtools offers a tool to match Zig version to ZLS version.

2. Zigtools has swapped the placement of OS and ARCH on the name of their latest binary release. This means the current target parsing is broken on the latest ZLS version.
   FIX: Prefer ARCH-OS key, fallback to OS-ARCH.

Changes:

Created a function to call the ZLS version matching tool and do the fallback logic if the OS/ARCH are suspected to be swapped. The only change to existing code is calling this function rather than trying the download directly.

Previous behavior:

anyzig: zig version '0.15.1' pulled from 'C:\dev\zig\doxa\build.zig.zon'
anyzig: appdata 'C:\Users\User\AppData\Local\anyzig'
anyzig: downloading 'https://builds.zigtools.org/zls-windows-x86_64-0.15.1.zip'...
error: bad HTTP response code: '404 Not Found'

New behavior:

anyzig: zig version '0.15.1' pulled from 'C:\dev\zig\doxa\build.zig.zon'       
anyzig: appdata 'C:\Users\User\AppData\Local\anyzig'
anyzig: debug: zls tarball 'https://builds.zigtools.org/zls-x86_64-windows-0.15.0.zip'
anyzig: downloading 'https://builds.zigtools.org/zls-x86_64-windows-0.15.0.zip'...
anyzig: downloaded zls-0.15.1 to 'C:\Users\User\AppData\Local\zig\p\N-V-__8AAKcO5QDO6ePs_xjItIpKxJA3ITHFlY-JbPNLpTAB'
ZLS - A non-official language server for Zig

Commands:
  help, --help,             Print this help and exit
  version, --version        Print version number and exit
  env                       Print config path, log path and version

General Options:
  --config-path [path]      Set path to the 'zls.json' configuration file      
  --log-file [path]         Set path to the 'zls.log' log file
  --log-level [enum]        The Log Level to be used.
                              Supported Values:
                                err
                                warn
                                info (default)
                                debug

Advanced Options:
  --enable-stderr-logs      Write log message to stderr
  --disable-lsp-logs        Disable LSP 'window/logMessage' messages

[neurocyte]

anyzig: downloaded zls-0.15.1 to

This should be zls-0.15.0 right?

[marler8997]

I think we already do this exact same thing when downloading a mach version. We should share that code which also includes a cache and skips any network requests if we can already find the version in our local cache.

[marler8997]

question...do we really need an index for ZLS URLs? is there not a way to just generate the URL from the version? It just seems a bit silly that what we need is to get a download URL, and the way we get that is to generate a download URL that gets us the real download URL? We ultimately have to generate one anyway, why the extra steps?

[mirror-shades]

anyzig: downloaded zls-0.15.1 to

This should be zls-0.15.0 right?

I don't think so. Hashstores indicate the zig compiler version and point to the Zig fetch cache, e.g, zls-0.15.1 and zls-0.15.2 hashstores will point to the same cache for the ZLS 0.15.0 binary. Marking the compiler version directly prevents the need to check which versions are compatible at runtime. The naming convention is a bit confusing but I think the intent is correct.

[mirror-shades]

question...do we really need an index for ZLS URLs? is there not a way to just generate the URL from the version? It just seems a bit silly that what we need is to get a download URL, and the way we get that is to generate a download URL that gets us the real download URL? We ultimately have to generate one anyway, why the extra steps?

The only reason is because, for whatever reason, ZLS doesn't match their version numbers to Zig's, so the url cannot be constructed from the compiler version number alone. I am using 0.15.1 but there is no ZLS-0.15.1 so the download fails.

Edit:
Assuming the minor versions are the same we could decrement the patch version from until we find the latest version? so 0.15.2 would try 0.15.2, then 0.15.1, finally finding the target on 0.15.0. That would prevent the need for checking the index.

[marler8997]

I'm double checking with ZLS folks if it has to be this way or not. If so, then I made a small commit that has the first part of this change which just puts the logic we're already using for mach in a function: b073c02

So if you want to have it ready, you could just start from that commit and add your function to extract the version for ZLS.