Update the changelog and upgrading guide in preparation for 0.8

[shepmaster]

No description provided.

[netlify]

✅ Deploy Preview for shepmaster-snafu ready!

Name	Link
🔨 Latest commit	1dc3d95
🔍 Latest deploy log	https://app.netlify.com/sites/shepmaster-snafu/deploys/658c92cb9c104400083f5273
😎 Deploy Preview	https://deploy-preview-428--shepmaster-snafu.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[shepmaster]

I've run my mini-crater tool using the main branch. There were 170 crates (a) on crates.io (b) that use SNAFU (c) that I could build. 100% of those worked with the new version.

I've also tested with upgrading some of my binary projects and asked some friends to test with their private projects that use SNAFU. The biggest issue there was the change of location to no longer be automatically treated as implicit.

Anything else we should check before 0.8?

[Enet4]

Do we have plans to change anything in light of #425? If not, I think we are ready to launch the release rocket.

[shepmaster]

I went ahead and added those deprecation attributes as it was easy. So... good to go then?

[Enet4]

I found an unexpected problem in DICOM-rs when trying to migrate the code which depends on whatever_context. It cannot infer the type parameters, whereas it had no issues in snafu 0.7. I put it in branch wip/snafu_0.8, might be worth taking a look before release.

error[E0284]: type annotations needed
  --> transfer-syntax-registry/src/adapters/jpeg.rs:75:18
   |
75 |                 .with_whatever_context(|_| format!("JPEG decoding failure on frame {}", i))?;
   |                  ^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `E2` declared on the method `with_whatever_context`
   |
   = note: cannot satisfy `<_ as FromString>::Source == _`
help: consider specifying the generic arguments
   |
75 |                 .with_whatever_context::<_, String, E2>(|_| format!("JPEG decoding failure on frame {}", i))?;
   |                                       +++++++++++++++++

error[E0283]: type annotations needed
  --> transfer-syntax-registry/src/adapters/jpeg.rs:75:18
   |
75 |                 .with_whatever_context(|_| format!("JPEG decoding failure on frame {}", i))?;
   |                  ^^^^^^^^^^^^^^^^^^^^^                                                     - type must be known at this point
   |                  |
   |                  cannot infer type of the type parameter `E2` declared on the method `with_whatever_context`
   |
   = note: multiple `impl`s satisfying `DecodeError: From<_>` found in the following crates: `core`, `dicom_encoding`:
           - impl From<NotEncapsulatedSnafu> for DecodeError;
           - impl From<dicom_encoding::adapters::decode_error::FrameRangeOutOfBoundsSnafu> for DecodeError;
           - impl<T> From<!> for T;
           - impl<T> From<T> for T;
           - impl<__T0> From<dicom_encoding::adapters::decode_error::MissingAttributeSnafu<__T0>> for DecodeError
             where __T0: Into<&'static str>;
   = note: required for `Result<(), DecodeError>` to implement `FromResidual<Result<Infallible, _>>`
help: consider specifying the generic arguments
   |
75 |                 .with_whatever_context::<_, String, E2>(|_| format!("JPEG decoding failure on frame {}", i))?;
   |                                       +++++++++++++++++

error[E0282]: type annotations needed
   --> transfer-syntax-registry/src/adapters/jpeg.rs:165:14
    |
165 |             .whatever_context("Expected to have raw pixel data available")?;
    |              ^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `E` declared on the method `whatever_context`
    |
help: consider specifying the generic arguments
    |
165 |             .whatever_context::<&str, E>("Expected to have raw pixel data available")?;
    |                              +++++++++++

• inline comment

[Enet4]

We're now using backtraces from the standard library by default, right?

[shepmaster]

Oops. Fixed.

[shepmaster]

I found an unexpected problem in DICOM-rs when trying to migrate the code which depends on whatever_context. It cannot infer the type parameters, whereas it had no issues in snafu 0.7.

Odd; I can't immediately reason out why it should / would have worked before. There's a lot of type inference going on with whatevers... Bisecting leads to d826e6a, which does add more From implementations.

The problem, if I get it correctly, is that whatever_context has some type S ("string") and then some E ("error") that can be constructed from the string. However, the ? operator then tries to convert that E into another error type via From / Into. With the new From impls, I guess it becomes too complicated for the type system to figure out what concrete type E should be. Before, I guess there was only ever the one type and that was solvable?

I think there's still only one concrete type that satisfies all the requirements, but maybe I'm missing something.

Annoyingly, you don't even really want the type conversion provided by ? here and if it were missing then this would all compile.

---

Some choices I see...

1. Put those additional From implementations behind a feature flag, but that could easily cause crate A which uses the feature to break crate B which does not use the feature.

2. Remove the new implementations. They aren't essential to any current functionality, but allow experimenting with do yeet.

3. Live with the new type inference problems and make people add annotations. If we went down this path, we could potentially change the signature to use impl trait to make turbofishing easier:

   fn whatever_context<S, E>(self, context: Into<String>) -> Result<T, E>
   where
       E: FromString,

[Enet4]

All that it took to hit this edge case was calling whatever_context in a function returning a Result<_, SpecificCustomError>. As such, I would be inclined with option 2, because the loss of ergonomics is overwhelming, especially against the given benefits of allowing experimentation with a feature which is not even stabilized. We might come up with better alternatives in the meantime.

[shepmaster]

Alright; reverted and removed from the changelog. Anything else?

[Enet4]

So yes, the type inference errors are gone!

For curiosity sake, I noticed that one of my error types AccessError, increased in size upon this update, from 48 bytes to 56. Any idea why? Is it because Backtrace from std can be larger?

[shepmaster]

Is it because Backtrace from std can be larger?

Looks like it...

use snafu::prelude::*;

#[derive(Debug, Snafu)]
struct Error {
    backtrace: snafu::Backtrace,
}

fn main() {
    dbg!(std::mem::size_of::<Error>());
}

version	features	size
0.7.5		0
0.7.5	backtraces	32
0.7.5	backtraces-impl-std	48
0.7.5	backtraces-impl-backtrace-crate	32
master		48
master	backtraces-impl-backtrace-crate	32

[Enet4]

👍