@ChrisPenner This PR upgrades us to GHC 9.10 … and I think the compiler must be doing something differently somewhere, because the optchecks stuff is failing with effectively no change to unison-runtime. Maybe it just needs more of that throwIO workaround or something, but thought you might have a clue to offer.

unison-runtime:optchecks is failing, and I’m not sure why. Would love some assistance with this one.

@dolio If you might have an idea on this; possibly due to ghc version change?

That test checks that GHC is generating code that looks properly optimized. I think it basically checks that the eval function contains no mention of the Stack type.

So, the details of the optimization have changed. I guess you could try running benchmarks before and after to see if the difference actually matters. If it doesn't, then maybe we need a different test. But if it does, we need to figure out how to fix the performance. Even if it doesn't, it might be easier to tweak something to satisfy the check than to figure out a new check that's actually proper.

Here’s the Nix workflow run on my fork: https://github.com/sellout/unison/actions/runs/20785608716 (it’ll run on trunk in this repo when this PR is merged).

I think that the docs for building with cabal need to either switch back to project-file or need to otherwise give a working command (perhaps moving cabal files out of contrib or suggest adding a symlink). Otherwise this is working well for me.

I removed the commit with the Cabal doc changes. I prefer the shorter --project-dir=contrib over --project-file=contrib/cabal.project, and I like the paths to be relative to the file they’re in … but it breaks the ln -s contrib/* ./ workaround, which is nice for people who are using Cabal regularly.

NB: An annoying thing here is that because of the way the Cabal workflow works (in order to allow forks to make comments on PRs), it’s going to fail until after this is merged – it uses the workflow file from the target branch (trunk), and that means it gets the old GHC (& Cabal) version.

Ok but the current build failures aren't nix related right?
They're something weird about the optimization checks that needs to get fixed for ghc 9.10.3; so not currently mergeable.

@dolio I tried running the benchmarks, but they don’t seem to build

⚙️   Processing stanza 1 of 15.
  ❓

    An error occurred while running the following file: unison-src/transcripts-manual/benchmarks.md

    ``` ucm :hide
    > pull unison.public.base.releases.M4d base
    > pull runarorama.public.sort.data sort
    ```

    🛑

    The transcript failed due to an error in the stanza above. The error is:

    ```
    I think you want to merge unison.public.base.releases.M4d into
    the base branch, but it doesn't exist. If you want, you can
    create it with `branch.empty base`, and then `pull` again.
    ```

At first I thought I was just doing something wrong, but I’ve had the same thing happen on various releases. Granted, it’s still possibly I’m doing something wrong. I‘m now seeing if it works for me at the point the benchmarks were last updated. If not, then it’s very likely I’m doing something wrong.

Either way, the benchmarks should probably be run as part of CI. We don’t need to actually measure them in CI (GitHub is no good for that), but at least ensure they build, so then I’d immediately know what I’m doing wrong.

> pull unison.public.base.releases.M4d base

This is ancient syntax, so those aren't the right benchmarks. Those should be updated or deleted.

@dolio what are the right benchmarks that @sellout should run? Is unison-src/transcripts-manual/benchmarks.md a thing? Or, can you coordinate with them, thanks.

That test checks that GHC is generating code that looks properly optimized. I think it basically checks that the eval function contains no mention of the Stack type.

So, the details of the optimization have changed. I guess you could try running benchmarks before and after to see if the difference actually matters. If it doesn't, then maybe we need a different test. But if it does, we need to figure out how to fix the performance. Even if it doesn't, it might be easier to tweak something to satisfy the check than to figure out a new check that's actually proper.

The benchmarks are on share

https://share.unison-lang.org/@pchiusano/misc-benchmarks

run suite after pulling.

I don't actually remember what is in the benchmark transcript.

Some tests with 'continue-on-error: true' have failed:

• Cabal / smoke-test

Created by continue-on-error-comment

@aryairani This should be ready for review now.

BTW, the response I received about the inspection testing thing was that it's actually possible for the mere presence of the inspection test to change the way GHC optimizes things. So that may be what we're seeing. But I'm not sure there's a concrete solution. The actual inspection test doesn't directly refer to the thing being optimized, so it's not anything as 'simple' as that.

I'm scared but here goes

@sellout I'm seeing a new error that you might know something about. Now when I run git in this repo (with config picked up by use flake in .envrc), I get:

warning: unhandled Platform key FamilyDisplayName
error: tool 'git' not found

I still see git on my path, it's at /usr/bin/git, but running it prints these lines for some reason. I'm on macOS (Intel). Any ideas?

@mitchellwrosen Oh, yeah I encountered this last night too, this line 50 here should fix it.

95a3ec8#diff-8b67b4b0f775a1335829ea1852b4f6cd3a88983f051a2676f208ce6acd942c26

@mitchellwrosen I haven’t seen that.

@aryairani For some reason, that link doesn’t show me anything helpful (or at least not obvious enough) – can you share the line contents?

I did a bit of poking around and noticed that the other message (warning: unhandled Platform key FamilyDisplayName) is maybe due to an interaction between some Nixpkgs 25.11 revisions and the Xcode-provided git on macOS (NixOS/nixpkgs#376958) updating the flake (or your system’s Nixpkgs?) might get rid of that one.

@sellout @mitchellwrosen Sorry about that, here's the contents

I did a bit of poking around and noticed that the other message (warning: unhandled Platform key FamilyDisplayName) is maybe due to an interaction between some Nixpkgs 25.11 revisions and the Xcode-provided git on macOS (NixOS/nixpkgs#376958) updating the flake (or your system’s Nixpkgs?) might get rid of that one.

Maybe this would be better than adding it how I did (I should be able to use my system provided binaries too, IMO), but I'm not sure what it's suggesting to do about it.

Ah ha! Ok yeah, using git from nixpkgs 25.11 solved the problem. I think we want Arya's patch too so others don't hit this.

@aryairani Weird – don’t know why my browser didn’t jump to that line.

Yeah, I do like keeping my flakes as self-contained as possible. For example, adding a home-manager input when I have homeModules or homeConfigurations in the flake and Nix even itself (although that one is a bit of a catch-22). git seems a bit more outside, but I think this issue justifies its place in a consistent environment (so yeah, keep @aryairani’s patch).

Ok cool. We can always pull it later if we figure out a better solution.