made in gimp, with <3

Context for actual rust programmers

I was having massive beef with the rust compiler yesterday, every cargo check takes 20 seconds.

And then look at the three functions below, only one of them are Send, if you know why, please let me know.

(Note: value that is not Send cannot be held across an await point, and Box<dyn Error> is not Send)

async fn one() {
    let res: Result<(), Box<dyn Error>> = do_stuff();
    if let Err(err) = res {
        let content = err.to_string();
        let _ = do_stuff(content).await;
    }
}

async fn two() {
    let res: Result<(), Box<dyn Error>> = do_stuff();
    let content = if let Err(err) = res {
        Some(err.to_string())
    } else {
        None
    };
    drop(res);
    if let Some(content) = content {
        let _ = do_stuff(content).await;
    }
}

async fn three() {
    let content = {
        let res: Result<(), Box<dyn Error>> = do_stuff();
        if let Err(err) = res {
            Some(err.to_string())
        } else {
            None
        }
    };
    if let Some(content) = content {
        let _ = do_stuff(content).await;
    }
}
  • Ephera@lemmy.mlEnglish
    1·
    11 hours ago

    Hmm, that sounds exactly like my setup. Weird.

    I did have the file created, with {} inside (empty Nix expression). If I git add it, it works as well:

    And yeah, I understand that it’s supposed to be a stacktrace, but other error messages look similarly horrendous and I can often only try to guess what’s wrong by reading the stacktrace top-to-bottom, so I’ve somewhat gotten used to doing that.

    But good to know that these terrible error messages might be a problem with my system. Thanks!

    • bobo@lemmy.ml
      1·
      10 hours ago

      I think we’re doing different things, that’s why it’s giving us completely different errors.

      I just added files to imports in configuration.nix

      I’m guessing you’ve got some manual error checking implemented with assertions?

      error:
       … while calling the 'seq' builtin
         at «github:nixos/nixpkgs/4bd9165a9165d7b5e33ae57f3eecbcb28fb231c9?narHash=sha256-l/iNYDZ4bGOAFQY2q8y5OAfBBtrDAaPuRQqWaFHVRXM%3D»/lib/modules.nix:402:18:
          401|         options = checked options;
          402|         config = checked (removeAttrs config [ "_module" ]);
             |                  ^
          403|         _module = checked (config._module);

       … while evaluating a branch condition
         at «github:nixos/nixpkgs/4bd9165a9165d7b5e33ae57f3eecbcb28fb231c9?narHash=sha256-l/iNYDZ4bGOAFQY2q8y5OAfBBtrDAaPuRQqWaFHVRXM%3D»/lib/modules.nix:305:9:
          304|       checkUnmatched =
          305|         if config._module.check && config._module.freeformType == null && merged.unmatchedDefns != [ ] then
             |         ^
          306|           let

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: Path 'nix/bobo/test.nix' does not exist in Git repository "/home/bobo/dotfiles".
Command 'nix --extra-experimental-features 'nix-command flakes' build --print-out-paths '/home/bobo/dotfiles/nix#nixosConfigurations."bobo".config.system.build.nixos-rebuild' --no-link' returned non-zero exit status 1.

      I can often only try to guess what’s wrong by reading the stacktrace top-to-bottom, so I’ve somewhat gotten used to doing that.

      I’m yet to see any nix error be more readable top to bottom. And I think it’s intentionally designed that way so you don’t need to scroll up.