Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for Provider API #96024

Open
3 tasks
yaahc opened this issue Apr 13, 2022 · 13 comments
Open
3 tasks

Tracking Issue for Provider API #96024

yaahc opened this issue Apr 13, 2022 · 13 comments
Labels
B-RFC-approved Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@yaahc
Copy link
Member

yaahc commented Apr 13, 2022

Feature gate: #![feature(provide_any)]

This is a tracking issue for RFC 3192

This RFC proposes extending the any module of the core library with a generic API for objects to provide type-based access to data. (In contrast to the existing APIs which provides type-driven downcasting, the proposed extension integrates downcasting into data access to provide a safer and more ergonomic API).

The initial motivating use case for this API is to provide the necessary functionality to add generic member access to the Error trait to generalize extracting context like Backtrace and to make it possible to move the Error trait into core while leaving Backtrace in std.

Public API

TODO: Update this section once the implementation PR is merged

Steps / History

Unresolved Questions

  • None yet.
@yaahc yaahc added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. B-RFC-approved Approved by a merged RFC but not yet implemented. labels Apr 13, 2022
@yaahc
Copy link
Member Author

yaahc commented Jul 8, 2022

#98912 updates the request_* functions to have an APIT (arg position impl trait) parameter instead of a standard generic parameter to remove unnecessary inferred parameters while turbofishing.

Callers change:

let obj: Box<dyn Provider> = Box::new(SomeConcreteType { some_string: "hello".to_owned() });

// From
assert_eq!(&**request_ref::<String, _>(&*obj).unwrap(), "hello");

// To
assert_eq!(&**request_ref::<String>(&*obj).unwrap(), "hello");

@dtolnay
Copy link
Member

dtolnay commented Aug 31, 2022

One minor thing that weirds me out about this API is this impl:

impl<E> Provider for E
where
E: Error + ?Sized,

Since this is a blanket impl (Self type is a generic parameter), it is the one blanket impl that Provider is ever going to be able to have, at least absent some far-future negative impls feature in the language. Any other blanket impl would be considered overlapping and violate coherence.

But it's a blanket impl of core::any::Provider, which is envisioned as being as general-purpose as the Any trait, for types which implement core::error::Error, which is a much narrower use case. In some sense this relationship is saying that "Errors are the one true canonical/privileged implementers of the Provider trait; any other application of Provider is second-class".

I am wondering which one of the following would be feasible:

  1. Yes, errors are the one privileged application of Provider, and while Provider may be useful for some other things sometimes, all of those are second-class.

    a. Maybe move Provider to core::error to double down on this view?

  2. Remove the blanket impl. What are the things that make the blanket impl necessary for usability of this API, and can those be mitigated a different way?

@yaahc
Copy link
Member Author

yaahc commented Aug 31, 2022

We could go back to what we had before we move Error into core which was a provide impl just on dyn Error which caused some other paper cuts but I can't remember exactly what those issues were.

@thomcc
Copy link
Member

thomcc commented Aug 31, 2022

Another issue for the provider API that matters for non-error cases is the lack of support for &mut.

I think the initial proposal did support this, at some cost to complexity. While I don't know that we need to support it out of the gate (I've wanted it multiple times when playing around with the API), it would be good to be sure we know it would look like, so that if we want to add it in the future, that we have not painted ourselves into a corner where we cannot do so.

@yaahc
Copy link
Member Author

yaahc commented Aug 31, 2022

@thomcc I believe all we have to do is expose the tag APIs to support those cases. We didn't change the impl, only the exposed API.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 1, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? `@yaahc`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 1, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? ``@yaahc``
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 1, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? ```@yaahc```
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 1, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? ````@yaahc````
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 1, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? `````@yaahc`````
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 1, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? ``````@yaahc``````
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 2, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? `@yaahc`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 2, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? ``@yaahc``
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 2, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? ```@yaahc```
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Sep 2, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? ````@yaahc````
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Sep 2, 2022
Add additional methods to the Demand type

This adds on to the original tracking issue rust-lang#96024

r? `````@yaahc`````
dbanty pushed a commit to knope-dev/knope that referenced this issue Sep 4, 2022
[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [thiserror](https://togithub.com/dtolnay/thiserror) | dependencies | patch | `1.0.32` -> `1.0.33` |

---

### Release Notes

<details>
<summary>dtolnay/thiserror</summary>

### [`v1.0.33`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.33)

[Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.32...1.0.33)

-   Expose backtraces via the new "generic member access" API on the Error trait ([rust-lang/rust#99301, [rust-lang/rust#96024)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

 **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://app.renovatebot.com/dashboard#github/knope-dev/knope).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzMi4xODQuMiIsInVwZGF0ZWRJblZlciI6IjMyLjE4NC4yIn0=-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@jakobhellermann
Copy link
Contributor

Another issue for the provider API that matters for non-error cases is the lack of support for &mut.

I believe all we have to do is expose the tag APIs to support those cases. We didn't change the impl, only the exposed API.

Is this something that just hasn't been implemented yet or was there an active decision to not expose &mut references for now?
I'm thinking we could just add

pub fn request_ref<'a, T>(provider: &'a (impl Provider + ?Sized)) -> Option<&'a T>
where
    T: 'static + ?Sized,
{
    request_by_type_tag::<'a, tags::Ref<tags::MaybeSizedValue<T>>>(provider)
}

+pub fn request_ref_mut<'a, T>(provider: &'a (impl Provider + ?Sized)) -> Option<&'a mut T>
+where
+    T: 'static + ?Sized,
+{
+    request_by_type_tag::<'a, tags::RefMut<tags::MaybeSizedValue<T>>>(provider)
+}

mod tags {
     pub struct Ref<I>(PhantomData<I>);
 
     impl<'a, I: MaybeSizedType<'a>> Type<'a> for Ref<I> {
         type Reified = &'a I::Reified;
     }
+    
+    pub struct RefMut<I>(PhantomData<I>);
+
+    impl<'a, I: MaybeSizedType<'a>> Type<'a> for RefMut<I> {
+        type Reified = &'a mut I::Reified;
+    }
}

but maybe I'm missing something.

@JonasJebing
Copy link

JonasJebing commented Oct 23, 2022

We could go back to what we had before we move Error into core which was a provide impl just on dyn Error which caused some other paper cuts but I can't remember exactly what those issues were.

Here's the discussion that lead to impl<E: Error + ?Sized> Provider for E: #98072 (comment)
So, the paper cut without the blanket impl is, that it's not possible to call core::any::request_* or <dyn Error>::request_* on a concrete error type like std::io::Error.

Personally, I feel like there are a lot of possible workarounds for that paper cut:

  1. The concrete error type could allow public access to its fields or getter functions;
  2. The concrete error type could impl Provider for SomeConcreteError
  3. A user can always create an adapter/newtype that implements Provider using Error::provide on the conrete error type.

So, I am leaning towards impl Provider for dyn Error instead of the blanket impl.

@JonasJebing
Copy link

JonasJebing commented Oct 23, 2022

@jakobhellermann you're missing that Provider::provide just has a shared reference &self.
So, a fn provide_mut<'a>(&'a mut self, _req: &mut Demand<'a>) {} needs to be added to the Provider trait, too.

@yaahc, @thomcc the Provider support for &mut was addressed in the RFC under "Future Possibilities".
The linked repository even includes an API for providing different &mut types to the same field or struct:

    fn provide_mut<'a>(&'a mut self, req: &mut Demand<'a>) {
        req.with(self)
            .provide_mut::<String>(|this| &mut this.string)
            .provide_mut::<str>(|this| &mut *this.string);
    }

bors bot pushed a commit to stackabletech/operator-rs that referenced this issue Nov 4, 2022
[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [Swatinem/rust-cache](https://togithub.com/Swatinem/rust-cache) | action | patch | `v2.0.0` -> `v2.0.2` |
| [clap](https://togithub.com/clap-rs/clap) | dependencies | patch | `3.2.17` -> `3.2.23` |
| [const_format](https://togithub.com/rodrimati1992/const_format_crates) | dependencies | patch | `0.2.26` -> `0.2.30` |
| [darling](https://togithub.com/TedDriggs/darling) | dependencies | patch | `0.14.1` -> `0.14.2` |
| [futures](https://rust-lang.github.io/futures-rs) ([source](https://togithub.com/rust-lang/futures-rs)) | dependencies | patch | `0.3.23` -> `0.3.25` |
| [proc-macro2](https://togithub.com/dtolnay/proc-macro2) | dependencies | patch | `1.0.43` -> `1.0.47` |
| [serde](https://serde.rs) ([source](https://togithub.com/serde-rs/serde)) | dependencies | patch | `1.0.144` -> `1.0.147` |
| [serde_json](https://togithub.com/serde-rs/json) | dependencies | patch | `1.0.85` -> `1.0.87` |
| [serde_yaml](https://togithub.com/dtolnay/serde-yaml) | dependencies | patch | `0.9.10` -> `0.9.14` |
| [snafu](https://togithub.com/shepmaster/snafu) | dependencies | patch | `0.7.1` -> `0.7.3` |
| [syn](https://togithub.com/dtolnay/syn) | dependencies | patch | `1.0.99` -> `1.0.103` |
| [thiserror](https://togithub.com/dtolnay/thiserror) | dependencies | patch | `1.0.32` -> `1.0.37` |
| [tokio](https://tokio.rs) ([source](https://togithub.com/tokio-rs/tokio)) | dependencies | patch | `1.21.1` -> `1.21.2` |
| [tracing](https://tokio.rs) ([source](https://togithub.com/tokio-rs/tracing)) | dependencies | patch | `0.1.36` -> `0.1.37` |
| [tracing-subscriber](https://tokio.rs) ([source](https://togithub.com/tokio-rs/tracing)) | dependencies | patch | `0.3.15` -> `0.3.16` |

---

### Release Notes

<details>
<summary>Swatinem/rust-cache</summary>

### [`v2.0.2`](https://togithub.com/Swatinem/rust-cache/releases/tag/v2.0.2)

[Compare Source](https://togithub.com/Swatinem/rust-cache/compare/v2.0.1...v2.0.2)

-   Avoid calling cargo metadata on pre-cleanup.

### [`v2.0.1`](https://togithub.com/Swatinem/rust-cache/releases/tag/v2.0.1)

[Compare Source](https://togithub.com/Swatinem/rust-cache/compare/v2.0.0...v2.0.1)

-   Primarily just updating dependencies to fix GitHub deprecation notices.

</details>

<details>
<summary>clap-rs/clap</summary>

### [`v3.2.23`](https://togithub.com/clap-rs/clap/releases/tag/v3.2.23)

[Compare Source](https://togithub.com/clap-rs/clap/compare/v3.2.22...v3.2.23)

#### \[3.2.23] - 2022-10-24

##### Fixes

-   Upgrade to `textwrap` 0.16

### [`v3.2.22`](https://togithub.com/clap-rs/clap/releases/tag/v3.2.22)

[Compare Source](https://togithub.com/clap-rs/clap/compare/v3.2.21...v3.2.22)

##### \[3.2.22] - 2022-09-16

##### Fixes

-   Unify dependencies on `terminal_size` to the 0.2 release

### [`v3.2.21`](https://togithub.com/clap-rs/clap/releases/tag/v3.2.21)

[Compare Source](https://togithub.com/clap-rs/clap/compare/v3.2.20...v3.2.21)

#### \[3.2.21] - 2022-09-12

##### Features

-   `TypedValueParser::map` to allow reusing existing value parsers for other purposes

### [`v3.2.20`](https://togithub.com/clap-rs/clap/releases/tag/v3.2.20)

[Compare Source](https://togithub.com/clap-rs/clap/compare/v3.2.19...v3.2.20)

#### \[3.2.20] - 2022-09-02

##### Features

-   `ArgMatches::get_count` help for `ArgAction::Count`
-   `ArgMatches::get_flag` help for `ArgAction::SetTrue` / `ArgAction::SetFalse`

### [`v3.2.19`](https://togithub.com/clap-rs/clap/releases/tag/v3.2.19)

[Compare Source](https://togithub.com/clap-rs/clap/compare/v3.2.18...v3.2.19)

#### \[3.2.19] - 2022-08-30

##### Fixes

-   *(help)* Ensure required arguments for parent commands aren't shown in their subcommands when using `args_conflicts_with_subcommand`

### [`v3.2.18`](https://togithub.com/clap-rs/clap/blob/HEAD/CHANGELOG.md#&#8203;3218---2022-08-29)

[Compare Source](https://togithub.com/clap-rs/clap/compare/v3.2.17...v3.2.18)

##### Fixes

-   *(help)* `Command::print_help` now respects `Command::colored_help`
-   *(derive)* Improved error messages

</details>

<details>
<summary>rodrimati1992/const_format_crates</summary>

### [`v0.2.29`](https://togithub.com/rodrimati1992/const_format_crates/blob/HEAD/Changelog.md#&#8203;0229)

Added lowercase hexadecimal formatting support.

Breaking: to add lowercase hexadecimal formatting, this crate changed the uppercase hexadecimal formatter from `{:x}` to `{:X}`

### [`v0.2.27`](https://togithub.com/rodrimati1992/const_format_crates/blob/HEAD/Changelog.md#&#8203;0227)

Replacing existing features with these:

-   `"rust_1_64"`: superceeding the soft-deprecated `"more_str_macros"` feature.
-   `"rust_1_51"`: superceeding the soft-deprecated `"const_generics"` feature.
    The new features are enabled by the feature they superceede.

Now the `"fmt"` feature enables the `"rust_1_64"` feature.

</details>

<details>
<summary>TedDriggs/darling</summary>

### [`v0.14.2`](https://togithub.com/TedDriggs/darling/blob/HEAD/CHANGELOG.md#v0142-October-26-2022)

[Compare Source](https://togithub.com/TedDriggs/darling/compare/v0.14.1...v0.14.2)

-   Derived impls of `FromMeta` will now error on literals, rather than silently ignoring them. [#&#8203;193](https://togithub.com/TedDriggs/darling/pull/193)
-   Don't include property paths in compile errors when spans are available. [#&#8203;203](https://togithub.com/TedDriggs/darling/pull/203)

</details>

<details>
<summary>rust-lang/futures-rs</summary>

### [`v0.3.25`](https://togithub.com/rust-lang/futures-rs/blob/HEAD/CHANGELOG.md#&#8203;0325---2022-10-20)

[Compare Source](https://togithub.com/rust-lang/futures-rs/compare/0.3.24...0.3.25)

-   Fix soundness issue in `join!` and `try_join!` macros ([#&#8203;2649](https://togithub.com/rust-lang/futures-rs/issues/2649))
-   Implement `Clone` for `sink::Drain` ([#&#8203;2650](https://togithub.com/rust-lang/futures-rs/issues/2650))

### [`v0.3.24`](https://togithub.com/rust-lang/futures-rs/blob/HEAD/CHANGELOG.md#&#8203;0324---2022-08-29)

[Compare Source](https://togithub.com/rust-lang/futures-rs/compare/0.3.23...0.3.24)

-   Fix incorrect termination of `select_with_strategy` streams ([#&#8203;2635](https://togithub.com/rust-lang/futures-rs/issues/2635))

</details>

<details>
<summary>dtolnay/proc-macro2</summary>

### [`v1.0.47`](https://togithub.com/dtolnay/proc-macro2/releases/tag/1.0.47)

[Compare Source](https://togithub.com/dtolnay/proc-macro2/compare/1.0.46...1.0.47)

-   Fix integer overflow when nesting depth of nested comments exceeds 4 billion ([#&#8203;357](https://togithub.com/dtolnay/proc-macro2/issues/357))

### [`v1.0.46`](https://togithub.com/dtolnay/proc-macro2/releases/tag/1.0.46)

[Compare Source](https://togithub.com/dtolnay/proc-macro2/compare/1.0.45...1.0.46)

-   Make proc_macro2::TokenStream's `FromStr` impl consistent with proc_macro::TokenStream's on strings that begin with a byte order mark `\u{feff}` ([#&#8203;353](https://togithub.com/dtolnay/proc-macro2/issues/353))

### [`v1.0.45`](https://togithub.com/dtolnay/proc-macro2/releases/tag/1.0.45)

[Compare Source](https://togithub.com/dtolnay/proc-macro2/compare/1.0.44...1.0.45)

-   Fix panic on parsing disallowed raw identifiers such as `r#self` ([#&#8203;351](https://togithub.com/dtolnay/proc-macro2/issues/351))

### [`v1.0.44`](https://togithub.com/dtolnay/proc-macro2/releases/tag/1.0.44)

[Compare Source](https://togithub.com/dtolnay/proc-macro2/compare/1.0.43...1.0.44)

-   Expose `span.before()` and `span.after()` to access an empty `Span` located immediately before or after the input span ([#&#8203;348](https://togithub.com/dtolnay/proc-macro2/issues/348), upstream tracking issue: [rust-lang/rust#87552)

</details>

<details>
<summary>serde-rs/serde</summary>

### [`v1.0.147`](https://togithub.com/serde-rs/serde/releases/tag/v1.0.147)

[Compare Source](https://togithub.com/serde-rs/serde/compare/v1.0.146...v1.0.147)

-   Add `serde:🇩🇪:value::EnumAccessDeserializer` which transforms an `EnumAccess` into a `Deserializer` ([#&#8203;2305](https://togithub.com/serde-rs/serde/issues/2305))

### [`v1.0.146`](https://togithub.com/serde-rs/serde/releases/tag/v1.0.146)

[Compare Source](https://togithub.com/serde-rs/serde/compare/v1.0.145...v1.0.146)

-   Allow internally tagged newtype variant to contain unit ([#&#8203;2303](https://togithub.com/serde-rs/serde/issues/2303), thanks [@&#8203;tage64](https://togithub.com/tage64))

### [`v1.0.145`](https://togithub.com/serde-rs/serde/releases/tag/v1.0.145)

[Compare Source](https://togithub.com/serde-rs/serde/compare/v1.0.144...v1.0.145)

-   Allow RefCell\<T>, Mutex\<T>, and RwLock\<T> to be serialized regardless of whether T is `Sized` ([#&#8203;2282](https://togithub.com/serde-rs/serde/issues/2282), thanks [@&#8203;ChayimFriedman2](https://togithub.com/ChayimFriedman2))

</details>

<details>
<summary>serde-rs/json</summary>

### [`v1.0.87`](https://togithub.com/serde-rs/json/releases/tag/v1.0.87)

[Compare Source](https://togithub.com/serde-rs/json/compare/v1.0.86...v1.0.87)

-   Add `write_i128` and `write_u128` methods to `serde_json::Formatter` to control the formatting of 128-bit integers ([#&#8203;940](https://togithub.com/serde-rs/json/issues/940), thanks [@&#8203;Lucretiel](https://togithub.com/Lucretiel))

### [`v1.0.86`](https://togithub.com/serde-rs/json/releases/tag/v1.0.86)

[Compare Source](https://togithub.com/serde-rs/json/compare/v1.0.85...v1.0.86)

-   Support `arbitrary_precision` feature even in no-std mode ([#&#8203;928](https://togithub.com/serde-rs/json/issues/928), thanks [@&#8203;kvinwang](https://togithub.com/kvinwang))

</details>

<details>
<summary>dtolnay/serde-yaml</summary>

### [`v0.9.14`](https://togithub.com/dtolnay/serde-yaml/releases/tag/0.9.14)

[Compare Source](https://togithub.com/dtolnay/serde-yaml/compare/0.9.13...0.9.14)

-   Implement `Deserializer` for `TaggedValue` and `&TaggedValue` ([#&#8203;339](https://togithub.com/dtolnay/serde-yaml/issues/339))

### [`v0.9.13`](https://togithub.com/dtolnay/serde-yaml/releases/tag/0.9.13)

[Compare Source](https://togithub.com/dtolnay/serde-yaml/compare/0.9.12...0.9.13)

-   Recognize `True`, `TRUE`, `False`, `FALSE` as booleans, `Null`, `NULL` as null ([#&#8203;330](https://togithub.com/dtolnay/serde-yaml/issues/330))

### [`v0.9.12`](https://togithub.com/dtolnay/serde-yaml/releases/tag/0.9.12)

[Compare Source](https://togithub.com/dtolnay/serde-yaml/compare/0.9.11...0.9.12)

-   Support deserializing tagged literal scalar into primitive ([#&#8203;327](https://togithub.com/dtolnay/serde-yaml/issues/327))

    ```yaml
    "foo": !!int |-
      7200
    ```

### [`v0.9.11`](https://togithub.com/dtolnay/serde-yaml/releases/tag/0.9.11)

[Compare Source](https://togithub.com/dtolnay/serde-yaml/compare/0.9.10...0.9.11)

-   Serialize strings on a single line when they do not already contain a newline character, regardless of string length ([#&#8203;321](https://togithub.com/dtolnay/serde-yaml/issues/321), [#&#8203;322](https://togithub.com/dtolnay/serde-yaml/issues/322))

</details>

<details>
<summary>shepmaster/snafu</summary>

### [`v0.7.3`](https://togithub.com/shepmaster/snafu/blob/HEAD/CHANGELOG.md#&#8203;073---2022-10-20)

[Compare Source](https://togithub.com/shepmaster/snafu/compare/0.7.2...0.7.3)

##### Fixed

-   The macro no longer generates invalid code when implicitly-generated
    types (such as backtraces) were used in conjunction with
    `#[snafu(source(from))]` and the type before transformation does not
    implement `std::error::Error`.

[0.7.3]: https://togithub.com/shepmaster/snafu/releases/tag/0.7.3

### [`v0.7.2`](https://togithub.com/shepmaster/snafu/blob/HEAD/CHANGELOG.md#&#8203;072---2022-10-09)

[Compare Source](https://togithub.com/shepmaster/snafu/compare/0.7.1...0.7.2)

##### Added

-   `Report` can be returned from `main` or test functions to provide a
    user-friendly display of errors.

-   A cheat sheet for the most common `#[snafu(...)]` attribute usages
    has been added to the `Snafu` macro's documentation.

-   Optional support for using the standard library's
    `std::backtrace::Backtrace` type via the `backtraces-impl-std`
    feature flag.

-   Optional support for implementing the Provider API using the
    `std::error::Error::provide` method via the `unstable-provider-api`
    feature flag.

-   Optional support for implementing the `core::error::Error` trait
    instead of `std::error::Error` via the `unstable-core-error` feature
    flag.

-   `GenerateImplicitData` has a new method `generate_with_source`.

##### Changed

-   `ErrorCompat::iter_chain` and `ChainCompat` are now available in
    no_std environments.

-   `ChainCompat` now implements `Clone`.

-   The `Debug` implementation for `Location` no longer shows some
    irrelevant internal details.

[0.7.2]: https://togithub.com/shepmaster/snafu/releases/tag/0.7.2

</details>

<details>
<summary>dtolnay/syn</summary>

### [`v1.0.103`](https://togithub.com/dtolnay/syn/releases/tag/1.0.103)

[Compare Source](https://togithub.com/dtolnay/syn/compare/1.0.102...1.0.103)

-   Implement `PartialOrd` for `Cursor` ([#&#8203;1236](https://togithub.com/dtolnay/syn/issues/1236), [#&#8203;1237](https://togithub.com/dtolnay/syn/issues/1237), thanks [@&#8203;CAD97](https://togithub.com/CAD97))

### [`v1.0.102`](https://togithub.com/dtolnay/syn/releases/tag/1.0.102)

[Compare Source](https://togithub.com/dtolnay/syn/compare/1.0.101...1.0.102)

-   More efficient internal representation for `TokenBuffer` ([#&#8203;1223](https://togithub.com/dtolnay/syn/issues/1223), thanks [@&#8203;CAD97](https://togithub.com/CAD97))
-   Fix parsing of a left shift after macro metavariable in type position ([#&#8203;1229](https://togithub.com/dtolnay/syn/issues/1229))

### [`v1.0.101`](https://togithub.com/dtolnay/syn/releases/tag/1.0.101)

[Compare Source](https://togithub.com/dtolnay/syn/compare/1.0.100...1.0.101)

-   Eliminate a bunch of redundant work done by LitStr::parse ([#&#8203;1221](https://togithub.com/dtolnay/syn/issues/1221))

### [`v1.0.100`](https://togithub.com/dtolnay/syn/releases/tag/1.0.100)

[Compare Source](https://togithub.com/dtolnay/syn/compare/1.0.99...1.0.100)

-   Parse closures with explicit empty lifetime parameter list `for<> || -> T {…}` ([#&#8203;1212](https://togithub.com/dtolnay/syn/issues/1212), [rust-lang/rust#97362)
-   Parse `dyn*` provisional syntax ([#&#8203;1213](https://togithub.com/dtolnay/syn/issues/1213), [rust-lang/rust#91611)
-   Parse attributes on the "rest" pattern of a struct in pattern position, `Struct { #[attr] .. }` ([#&#8203;1214](https://togithub.com/dtolnay/syn/issues/1214))
-   Parse `static async` and `static async move` closures ([#&#8203;1215](https://togithub.com/dtolnay/syn/issues/1215), [rust-lang/rust#62290)

</details>

<details>
<summary>dtolnay/thiserror</summary>

### [`v1.0.37`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.37)

[Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.36...1.0.37)

-   Documentation improvements

### [`v1.0.36`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.36)

[Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.35...1.0.36)

-   Documentation improvements ([#&#8203;195](https://togithub.com/dtolnay/thiserror/issues/195), thanks [@&#8203;matklad](https://togithub.com/matklad))

### [`v1.0.35`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.35)

[Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.34...1.0.35)

-   More work on integrating [std::any::Provider](https://doc.rust-lang.org/std/any/trait.Provider.html) for backtrace support
-   Fix *"Multiple applicable `provide` methods in scope"* error when the caller has both std::error::Error and std::any::Provide traits in scope ([#&#8203;185](https://togithub.com/dtolnay/thiserror/issues/185))

### [`v1.0.34`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.34)

[Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.33...1.0.34)

-   Tweak "generic member access" based Backtrace implementation ([#&#8203;184](https://togithub.com/dtolnay/thiserror/issues/184))

### [`v1.0.33`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.33)

[Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.32...1.0.33)

-   Expose backtraces via the new "generic member access" API on the Error trait ([rust-lang/rust#99301, [rust-lang/rust#96024)

</details>

<details>
<summary>tokio-rs/tokio</summary>

### [`v1.21.2`](https://togithub.com/tokio-rs/tokio/releases/tag/tokio-1.21.2)

[Compare Source](https://togithub.com/tokio-rs/tokio/compare/tokio-1.21.1...tokio-1.21.2)

### 1.21.2 (September 27, 2022)

This release removes the dependency on the `once_cell` crate to restore the MSRV of 1.21.x, which is the latest minor version at the time of release. ([#&#8203;5048])

[#&#8203;5048]: https://togithub.com/tokio-rs/tokio/pull/5048

</details>

<details>
<summary>tokio-rs/tracing</summary>

### [`v0.1.37`](https://togithub.com/tokio-rs/tracing/releases/tag/tracing-0.1.37)

[Compare Source](https://togithub.com/tokio-rs/tracing/compare/tracing-0.1.36...tracing-0.1.37)

This release of `tracing` incorporates changes from `tracing-core`
[v0.1.30][core-0.1.30] and `tracing-attributes` [v0.1.23][attrs-0.1.23],
including the new `Subscriber::on_register_dispatch` method for performing late
initialization after a `Subscriber` is registered as a `Dispatch`, and bugfixes
for the `#[instrument]` attribute. Additionally, it fixes instances of the
`bare_trait_objects` lint, which is now a warning on `tracing`'s MSRV and will
become an error in the next edition.

##### Fixed

-   **attributes**: Incorrect handling of inner attributes in `#[instrument]`ed
    functions ([#&#8203;2307])
-   **attributes**: Incorrect location of compiler diagnostic spans generated for
    type errors in `#[instrument]`ed `async fn`s ([#&#8203;2270])
-   **attributes**: Updated `syn` dependency to fix compilation with `-Z
    minimal-versions` ([#&#8203;2246])
-   `bare_trait_objects` warning in `valueset!` macro expansion ([#&#8203;2308])

##### Added

-   **core**: `Subscriber::on_register_dispatch` method ([#&#8203;2269])
-   **core**: `WeakDispatch` type and `Dispatch::downgrade()` function ([#&#8203;2293])

##### Changed

-   `tracing-core`: updated to [0.1.30][core-0.1.30]
-   `tracing-attributes`: updated to [0.1.23][attrs-0.1.23]

##### Documented

-   Added [`tracing-web`][tracing-web] and [`reqwest-tracing`][reqwest-tracing] to related crates ([#&#8203;2283],
    [#&#8203;2331])

Thanks to new contributors [@&#8203;compiler-errors](https://togithub.com/compiler-errors), [@&#8203;e-nomem](https://togithub.com/e-nomem), [@&#8203;WorldSEnder](https://togithub.com/WorldSEnder), [@&#8203;Xiami2012](https://togithub.com/Xiami2012),
and [@&#8203;tl-rodrigo-gryzinski](https://togithub.com/tl-rodrigo-gryzinski), as well as [@&#8203;jswrenn](https://togithub.com/jswrenn) and [@&#8203;CAD97](https://togithub.com/CAD97), for contributing to
this release!

[core-0.1.30]: https://togithub.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.30

[attrs-0.1.23]: https://togithub.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.23

[`tracing-web`]: https://crates.io/crates/tracing-web/

[`reqwest-tracing`]: https://crates.io/crates/reqwest-tracing/

[#&#8203;2246]: https://togithub.com/tokio-rs/tracing/pull/2246

[#&#8203;2269]: https://togithub.com/tokio-rs/tracing/pull/2269

[#&#8203;2283]: https://togithub.com/tokio-rs/tracing/pull/2283

[#&#8203;2270]: https://togithub.com/tokio-rs/tracing/pull/2270

[#&#8203;2293]: https://togithub.com/tokio-rs/tracing/pull/2293

[#&#8203;2307]: https://togithub.com/tokio-rs/tracing/pull/2307

[#&#8203;2308]: https://togithub.com/tokio-rs/tracing/pull/2308

[#&#8203;2331]: https://togithub.com/tokio-rs/tracing/pull/2331

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 5:00 and before 6:00 every weekday" in timezone Europe/Berlin, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

 **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://app.renovatebot.com/dashboard#github/stackabletech/operator-rs).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzMi4yMTcuMCIsInVwZGF0ZWRJblZlciI6IjM0LjE0LjAifQ==-->
@Kixunil
Copy link
Contributor

Kixunil commented Nov 11, 2022

First of all, I think this idea is really great so big thanks to all people participating on the design and implementation!

One thing that's puzzling me is the limitation of T: 'static. I don't see any reason for it besides possible compatibility with Any. (Could there be simply another method enforcing static?)
What I'd like to do is to provide singular value that may reference data inside the error. To be specific I'm very interested in having a common API for spanned errors that can be displayed nicely while being detached from rendering (codespan-reporting, miette...)

pub struct SpannedLabel<'a> {
    span: Span,
    label: &'a dyn fmt::Display, // maybe this should be an enum supporting `String` and `Box<fmt::Display>`
    file_id: FileId, // didn't figure out the exact type yet
}

#[derive(Copy, Clone /* ... */)]
pub struct Span {
    pub start: usize,
    pub end: usize,
}

One way to resolve this issue is to provide the values separately. This is not entirely unreasonable but I worry it'll lead to people forgetting about providing one of the two values.

Also I found this in the motivation section of the RFC:

this approach is limited by constraints on Any, we cannot return objects by value, return objects which include references (due to the 'static bound on Any),

But this still only works with 'static and is even acknowledged by the RFC:

The proposal only supports handling value types (or other types with only 'static lifetimes) and reference types.

Which sounds contradictory and I don't see it explained anywhere.

qwertz19281 added a commit to FerionVE/guion that referenced this issue Dec 4, 2022
Inspired by [queron query](https://github.com/FerionVE/guion/blob/master/src/queron/query.rs) and Rust's upcoming [Provider API](rust-lang/rust#96024).

It uses a query type with GAT response type to allow downcasting and responding with non-'static types for e.g. traitcasting.
@conradludgate
Copy link
Contributor

One thing that's puzzling me is the limitation of T: 'static

I'm not sure on the nitty gritty details of typeid and Any (and I hear there's a lot of cursed stuff to know) but T: 'a and T: 'b would definitely need to be different types (need to be very careful with subtyping etc).

Now, playing devils advocate as a non compiler engineer, I think trying to make sure that T: 'a and T: 'b have different unique typeids would be a lot of work, especially since we have troubles with that for T and U anyway

@Kixunil
Copy link
Contributor

Kixunil commented Jan 22, 2023

@conradludgate I don't see how it's relevant. AFAIK this implementation bypasses typeid and Any completely.

@conradludgate
Copy link
Contributor

AFAIK this implementation bypasses typeid and Any completely.

It bypasses Any (using a trait called Erased instead), but still uses TypeId

rust/library/core/src/any.rs

Lines 1285 to 1287 in 8e68090

if self.tag_id() == TypeId::of::<I>() {
// SAFETY: Just checked whether we're pointing to an I.
Some(unsafe { &mut *(self as *mut Self).cast::<TaggedOption<'a, I>>() })

@mstone
Copy link

mstone commented Jan 26, 2023

(With apologies if this is a bad place to ask:) while we are discussing continuing appearances of this "type_id() is lifetime-insensitive" limitation w.r.t. to type-directed programming + reflection, is there additional history or context, such as a good issue to link to, for those who would like to know more about the overall problem?

(Also, if it helps, what I've got for context so far mostly consists of, going from older to more recent:

as well as for the sub-issue that arises within some of these conversations of not breaking inference while adding generics (with defaults where necessary) to existing signatures:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants