u/shepmaster

I can't have #[snafu::report] proc macro accept a return type of Result<(), Box<dyn std::error::Error>>

That's because Box<dyn std::error::Error>> doesn't actually implement core::error::Error, which is always a surprising thing for people to find out! snafu::report only works with error types that implement Error.

this would require me to have some sort of all errors enum, which is definitely not something I'd want to do.

This is what I'd suggest doing, so I'd want to delve into why you don't want to do it. If you have nothing useful to add and just want to agglomerate errors, maybe transparent would be useful (untested code):

fn main() -> Result<(), AppError> {
    let config = config::load()?;
    let result = process::data(config)?;
    network::notify(result)?;

    Ok(())
}

#[derive(Debug, Snafu)]
enum AppError {
    #[snafu(transparent)]
    Config { source: config::LoadError },

    #[snafu(transparent)]
    Process { source: process::Error },

    #[snafu(transparent)]
    Network { source: network::ConnectionError },
}

I am a big fan of SNAFU! I've found the maintainer to be very thoughtful about all of my feature requests, even if it takes a while for them to implement anything. I use SNAFU in just about every project, except for a handful of projects where I really want to avoid dependencies or procedural macros.

I like that SNAFU has a sliding scale of "how much do I want to care about errors right here and now". It works well in no-std cases: I've used it for some embedded work and know of some people that have used it for things like Windows kernel drivers.

What are the major benefits of this over a "one error enum per crate" pattern?

The biggest immediate benefit comes in code that cares about recovering from certain types of errors. With smaller-scoped errors, you have fewer cases to reason about.

The harder benefit (but totally worth it, IMO!) is to go all the way down the rabbit hole and never construct any specific error in more than one spot. By doing this, your error longer needs to have the concept of a stack trace or a location: the causal chain of errors tells you exactly where in your code the failure occurred! In a way, I think of stack traces as "dynamic" and the causal chain as "static" (it's not literally, but if you squint a bit...)

Other than 1 lib, my other libs are internal to my workspace (i.e. not going to publish them).

I'll point out that we often neglect to think of our errors as a public API, one which is subject to SemVer concerns. The common pattern of an enum with public variants and fields is actually really brittle with regards to SemVer. SNAFU recommends using opaque errors to help with this case.

Of course, I know I don't have to follow their philosophy.

Absolutely correct. It's heartening to me that you are at all worried about handling errors and then exposing them in a thoughtful manner to your users.

And while I am at it, any tips on error handling in snafu or in general?

A key thing to do is every time you have to think or investigate why / how an error occurred, try to improve the error: give it more content, rewrite the message, introduce more error variants, etc.

Ah, I understand more, thank you!

Just to clarify, you mean that there could be a way for a specific type to opt-in to the same behavior as a CustomPtr (changing which group a type was in), but not some way of creating user-defined groups, right?

I also think that there'd only be the possibility of moving CustomPtr to the same group as & — the user couldn't add an attribute to &T and it doesn't make sense to change which group a named lifetime would belong in.

Can you explain more, or provide an example?

What kind of "grouping" would you be looking for?

Can you explain more?

• Box is a smart pointer and it's not affected by this change.
• Cow is a smart pointer from the standard library and it's as affected by this change as any similar type a user could create.
• Any type with a reference inside of it, whether or not it's a smart pointer, whether or not it's in the standard library or user code, is affected by this change.

Perhaps there's some disagreement on terminology?

I have my own issues to complain to Kia Corporate about (specifically for #1 Cochran). Can you share how you contacted corporate?

Amusingly, I filed the issue for the same reason as the OP: a student in training noticed the new (at the time) warning about fields unused except in Debug in structs with named fields. To prove a point, I attempted to show how the same warming would occur for tuple structs, only to find it didn’t.

That led me to discover that tuple structs had never supported dead field warnings of any kind and thus open the issue.

This issue is being tracked at https://github.com/rust-lang/rust-playground/issues/910

I agree with this sentiment.

https://github.com/rust-console/gba

I had three wisdom teeth extracted in October 2021 at Pittsburgh Oral Surgery. I went in once for an exam and X-ray and then again for the extraction. Going by my HSA transactions, the exam was around $90 and the extraction was a hair under $1000. The exam was billed as "dental" and the extraction as "medical".

They were pretty good about talking to me about costs after the exam, which is why I'd guess they are vague on the phone. Without seeing your specific case, the work required could be wildly different.

I also elected to get the full anesthesia, which costs a bit more.

Overall, I liked them and my mouth was a lot happier after the surgery.

(Playground author/maintainer here)

As other people have mentioned, the Docker image is not created at code submission time. Instead, each of the six images are built each night and uploaded to Docker Hub. During the build, we do some trickery to compile all of the dependencies so that they are ready to go later on. The playground machines try to pull these containers every so often (30 minutes, IIRC).

A new Docker container is created for each code submission to provide isolation from any other concurrent requests, but the work those do is minimal — compiling the user's code, linking everything, and executing it (or running Clippy, Rustfmt, etc.).

If so, how is so fast?

Glad to hear you think so, but I still wish it were faster! Ideally, compiling and running "hello world" should take < 1 second of real time. Counting the time aloud, it takes about 4 seconds right now.

Part of the problem is that the machine is a bit overloaded, but I'm sure there's also architecture changes that could be made.

It's great to have multi-cursor support

Ace has multi cursor support as well.

On Mac, Option-Control-{Left/Right} multiselects the next matching phrase. Option-Control-{Up/Down} adds a multi cursor in that direction.

It looks like this is a reasonable guide to the available functionality

Yes, all procedural macros are inherently unhygienic. This has even bitten us once before.

SNAFU (and thiserror/anyhow, AFAIK) implement this functionally ourselves. That means you can use SNAFU 0.7 with this formatting string functionality back to Rust 1.34 (my MSRV).

Another way of writing that .map would be:

*<Box<[i32; 5]>>::try_from(vec.into_boxed_slice()).expect("Array wasn't 5 elements")

The page most of us are looking for: new emoji in Unicode 14.

I thought about using Bevy-ECS for an XML DOM library, but I don't think it was a great fit. However, I am using ECS-related concepts like allocating all nodes of a specific type in their own arena, leading to good data locality. It can also help with some XPath queries ("find all elements with the name X").

You have to specify that you want to install the x86-64 compiler instead of defaulting to aarch64.

Nothing, really. You can install the equivalent x86-64 toolchain and use it via Rosetta.

You need to use 11 as the SDK, but you don’t need to compile on 11. You can cross compile to 11 from 10.15.

While technically Arm processors allow big endian, most usages (including M1 and other Apple chips) keep it as little endian.

Rust cannot make macOS Arm support tier 1 until there is a CI provider that allows running tests on the M1 hardware. No CI providers have established a timeline for any such support.

How would you propose solving it?

if they want people to rewrite all their C libraries in Rust.

Can you provide some citation that this is a goal of the Rust project? Otherwise it seems like you are parroting things that overly enthusiastic (or trolling) people on the internet have said.

backtickopt6