Loosen dependency contraints

[n8henrie]

Loosen dependency contraints to allow API-compatible dependency updates, update
Cargo.lock accordingly

[n8henrie]

There are several stragglers I can add to this PR as well, assuming the tests pass (locally was hanging on tests::ipc_multiple_clients).

[AucaCoyan]

Great! This looks promising. I merged the clippy fixes and skipped that test it's causing you problems. In my machine took longer than a couple of minutes (4-5?), so probably something is going south when cargo tries to run that specific test.
Try merging dev again and see if you have better results 💯

[n8henrie]

I should have mentioned but I am able to recreate Cargo.lock without any trouble here (#1953). Just rm Cargo.lock, cargo clean, then cargo build and Bob's your uncle.

[AucaCoyan]

Oh (click soud) nice!
CI is acting weird, I think every machine is downloading different versions of the crates, and that collides with the code we were using (chrono, for example).
Is it possible to you to make the CI green? Watch out this line. You can delete that if it's causing trouble, and then we re-add it (compile times lasts aeons)

[AucaCoyan]

Hi! Just as another comment, you can check my pr trying this same steps of updating chrono and the like here #1872

[n8henrie]

Looks like most of the failures were just a clippy lint. Not sure what's up with Windows though.

[AucaCoyan]

...
 Compiling espanso v2.2.1 (D:\a\espanso\espanso\espanso)
error: linking with `link.exe` failed: exit code: 1169
  |
  = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.39.33519\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" 
...
   = note: wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdipAlloc already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdipCloneImage already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdipCreateBitmapFromFile already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdipCreateBitmapFromFileICM already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdipCreateHBITMAPFromBitmap already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdipDisposeImage already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdipFree already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdiplusShutdown already defined in windows.0.52.0.lib(gdiplus.dll)
          wxmsw31u_core.lib(corelib_gdiplus.obj) : error LNK2005: GdiplusStartup already defined in windows.0.52.0.lib(gdiplus.dll)
          D:\a\espanso\espanso\target\debug\deps\espanso.exe : fatal error LNK1169: one or more multiply defined symbols found
          

error: could not compile `espanso` (bin "espanso") due to 1 previous error

Oh damn. I hitted this error many times, and I don't have any idea why it happens. The log says that it can't link the librearies, or it doesn't find the linker (link.exe). I mildly assume that is something related to the C++ code, in which I have totally null experience 😢
I asked Federico once, and he didn't had a solution for this error

[n8henrie]

The find_tool function from the cc crate doesn't seem to be working in CI / GitHub Actions, at least on newer versions.

• use in espanso:

  espanso/espanso-modulo/build.rs

  Line 60 in e959572

  let tool = cc::windows_registry::find_tool("msvc", "devenv")

  
  fn find_tool definition: https://github.com/rust-lang/cc-rs/blob/61b81c8b4c1a2d589dcf3982c992e98859bed131/src/windows/find_tools.rs#L58
• Minimal example crate: https://github.com/n8henrie/find-msvc/actions
  • It takes several clicks to go through, but you can pick through https://github.com/n8henrie/find-msvc/actions to see versions that return a toolchain and those that don't
  • I used git log -G'^cc = "' -p to find commits that changed the cc version dependency; so far it looks like 1.0.66 works while the more recent ones fail to find the toolchain (using the windows-latest / windows-2022 GitHub Actions image)

[n8henrie]

cc >= 1.0.84 requires a full target (including arch): rust-lang/cc-rs#1071

[n8henrie]

I hitted this error many times, and I don't have any idea why it happens.

@AucaCoyan It looks like @federico-terzi may have used the avoid-gdi to work around this issue:

$ git log --grep gdiplus
commit 04720212e571e7f1e22a4f9587a1bb9fd3d73e3a
Author: Federico Terzi <federico-terzi@users.noreply.github.com>
Date:   Fri May 21 22:00:02 2021 +0200

    feat(ui): add feature to avoid double linking gdiplus

commit ccb3e11d9329d17583a3d30b1849b9675d11f995
Author: Federico Terzi <federico-terzi@users.noreply.github.com>
Date:   Fri May 21 21:59:29 2021 +0200

    feat(clipboard): add feature to avoid double linking gdiplus

[AucaCoyan]

It had never occurred to me we could grep the issue in git history. Thank you for that TIL!
I'm on the phone now, but later I would like to what changes introduced those 2 commits and if they are necessary again in these new deps.

Great work here!

[n8henrie]

Just checking in -- still have this on my mind, but still unclear on how to fix the windows gdiplus linking issues.

[n8henrie]

Even prior to this PR, we've known that some dependency is breaking windows if we run cargo update (even without bumping any version number in Cargo.toml: #1953

To try to flesh this out, I ran the script below, which starts from a working Cargo.lock and then:

1. runs cargo update --dry-run and filters for any dependencies that would have been updated
2. updates each of the deps individually (cargo update depname)
3. makes a commit including the name of the updated dependency
4. pushes to GitHub to try to build for windows in CI
5. resets back to the working Cargo.lock
6. continues with the next dependency

#!/usr/bin/env bash

set -x

main() {
  while read -r dep; do
    git reset --hard c25d419d8fd233751dfa6f97d4385afe78febb98
    cargo update "${dep}"
    git add Cargo.lock
    git commit -m "Update ${dep}"
    git push --force-with-lease
  done < <(cargo update --dry-run |& awk '/Updating/ && /->/ { print $2 }')
}
main "$@"

You can see my pages of results at: https://github.com/n8henrie/espanso/actions/workflows/ci.yml

Unfortunately it's not immediately obvious how to tie a specific workflow run back to the culprit commit, but some work with the (authenticated) gh CLI tool helps:

$ gh api --paginate  -H "Accept: application/vnd.github+json"   -H "X-GitHub-Api-Version: 2022-11-28"   /repos/n8henrie/espanso/actions/workflows/ci.yml/runs

I'll need to jq through this a bit to see if I can tease apart which ones succeeded and which broke, but hopefully will have a little more info soon.

[AucaCoyan]

Thanks for the thorough explanation!