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

WIP: Capture dep info with Spanned #9752

Closed
wants to merge 5 commits into from

Conversation

gilescope
Copy link
Contributor

Here we add Spanned info into dependencies. Nothing is done with the information, but this seems like a good first step towards line numbers.

@rust-highfive
Copy link

r? @alexcrichton

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 1, 2021
@gilescope
Copy link
Contributor Author

@est31 should I be using toml-spanned-value crate rather than the toml crate or should the toml Spanned type be enough?

I'm getting invalid type: string "registry", expected a borrowed string for key errors which I don't quite understand.

@est31
Copy link
Member

est31 commented Aug 3, 2021

toml-spanned-value helps when you were dealing with Value. Otherwise the Spanned<> type would be enough. In fact, the SpannedValue type from toml-spanned-value is just a type alias for Spanned<Value>. However, that Value is not the Value from the toml crate, but a copy with SpannedValue being used instead of Value in e.g. arrays, so that you have spans available deeply nested in the datastructure.

From what I can recall, cargo mainly does its own types and doesn't use Value, so utility of toml-spanned-value might be limited. It's been some time since I last worked with toml-spanned-value, but I remember that there had to be some hacks to get spans through serde's limited data model. Maybe your error is related to those?

[dependency.foo] <-- foo isn't a Spanned<&str>
@bors
Copy link
Contributor

bors commented Aug 19, 2021

☔ The latest upstream changes (presumably #9793) made this pull request unmergeable. Please resolve the merge conflicts.

@est31
Copy link
Member

est31 commented Aug 19, 2021

Mhh I wonder if it is good to cover everything in Spanned<_>. Maybe instead do use <path>::Spanned as S; and then do S<Thing>? Covering everything in that seems better to me.

@gilescope
Copy link
Contributor Author

gilescope commented Aug 20, 2021 via email

@est31
Copy link
Member

est31 commented Aug 20, 2021

@gilescope I meant use toml::Spanned as S;. In Rust you can rename imports. Generally I'm not a fan of it but when it greatly simplifies code, I think it's a good idea.

@gilescope
Copy link
Contributor Author

May as well go the whole hog and define something like this:
type DepMap = BTreeMap<String, Spanned<TomlDependency>>;

My main problem is that when Spanned is added, serde for some reason tries to use Serde's default &str deserialiser which is hardcoded to Err:

fn visit_str<E>(self, v: &str) -> Result<Self::Value, E> { Err(...) }

and that seems to be because of this in serde:

impl<'de: 'a, 'a> Deserialize<'de> for &'a str {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>,
    {
        deserializer.deserialize_str(StrVisitor) // <-- This visitor seems hardcoded to Err on &str.
    }
}

The interactions between serde, serde-ignored and toml-rs deserialisers are non-trivial.

@est31
Copy link
Member

est31 commented Sep 5, 2021

Oh yeah serde is really nice for the simple use cases but it has its limits. Getting spanned information through serde happens through a bunch of hacks. Maybe those fail if serde-ignored is used?

@gilescope
Copy link
Contributor Author

Yeah. Not sure what to do here. I think @dtolnay is probably the only one who could possibly pinpoint how to solve it. I've tried but my brain just can't grok what in the 3 tiers of serdes I need to change in order to fix it.

I could try taking out serde-ignored to try and simplify the problem but I'm going to have to put it back again...

@ehuss ehuss removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 1, 2022
@ehuss
Copy link
Contributor

ehuss commented Feb 1, 2022

I'm going to close this for now since cargo has switched to toml_edit.
Pending toml-rs/toml#302, this might be something we could revisit in the future.

@ehuss ehuss closed this Feb 1, 2022
@epage
Copy link
Contributor

epage commented Jan 13, 2023

FYI toml-rs/toml#435 adds span support in to toml_edit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants