Skip to content

Compilation error with url 2.5.3 / idna 1.0.3 with Rust < 1.81 and edition 2021 (resolver 2) when sqlx-core < 0.8.3 is in the dependency graph #992

Closed

Description

@TotalKrill

Edited by @hsivonen to put resolution options at the top for folks who come here:

To resolve this compilation error, update SQLx to 0.8.3 and/or update Rust to 1.81 or later.

This compilation error is due to a combination of:

  1. SQLx unnecessarily turning off the default features of url, and from a proc macro context specifically. (Request for SQLx not to do that: Please do not turn off default features for url transact-rs/sqlx#3589)
  2. url 2.5.3 (and idna 1.0.3) conditionally raising MSRV to 1.81 when default features are off (from no_std support for the url crate #831). Conditionally raising MSRV to 1.81 is not a semver break, because raising MSRV isn't a semver break.
  3. resolver = "2", which is implied by edition = "2021" performing feature resolution for proc macro dependencies separately from normal dependencies, so a normal dependency on url with default features enabled does not cause default features to be enabled for the proc macro case.

Original report follows:

  • Note that this crate implements the URL Standard not RFC 1738 or RFC 3986

Describe the bug

After update to v1.0.3 wich is picked up automatically since its a patch upgrade, our code no longer compiles the same.

rust versions tested:

  • rustc 1.80.1
  • rustc 1.81.0
   Compiling idna v1.0.3
error[E0658]: use of unstable library feature 'error_in_core'
  --> /home/krille/.cargo/registry/src/index.crates.io-6f17d22bba15001f/idna-1.0.3/src/lib.rs:78:6
   |
78 | impl core::error::Error for Errors {}
   |      ^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #103765 <https://github.com/rust-lang/rust/issues/103765> for more information

Activity

  1. changed the title [-]Compilation error with update to 1.0.3[/-] [+]Compilation error with update to idna 1.0.3[/+] on Nov 4, 2024
  2. valenting commented on Nov 4, 2024

    @valenting
    Collaborator

    @TotalKrill
    Is your crate depending on idna directly with default-features = false.
    Or is the issue url failing to propagate the std feature to idna?

  3. TotalKrill commented on Nov 4, 2024

    @TotalKrill
    Author

    We are depending on url, not idna directly

  4. TotalKrill commented on Nov 4, 2024

    @TotalKrill
    Author

    @valenting seems i was wrong about 1.81.0, seems to work there...

  5. hsivonen commented on Nov 4, 2024

    @hsivonen
    Collaborator

    Are you depending on url with default-features = false?

    I tried to repro on 1.80.1, and the following compiles:

    rustup default 1.80
    cargo new --bin testurl
    cd testurl
    cargo add url
    cargo build
  6. TotalKrill commented on Nov 4, 2024

    @TotalKrill
    Author

    we have a workspace, but we only depend on url like this: url = "2.5.0"

  7. TotalKrill commented on Nov 4, 2024

    @TotalKrill
    Author

    running cargo tree -i url -f "{p} {f}"

    this is what our tree ends up including, with two different versions of URL included, probably by one of our other deps.

    • url v2.5.3 default,serde,std
    • url v2.5.3

    Edit: I meant version 2.5.3, 2.5.0 is the version that compiles

  8. hsivonen commented on Nov 4, 2024

    @hsivonen
    Collaborator

    url 2.5.0 and url 2.5.2 depended on idna 0.5. url 2.5.1 depended on idna 1.0.

    The introduction of no_std support to url in 2.5.3 and the introduction of core::error::Error to idna in 1.0.3 was intended not to change MSRV to 1.81 with default features but was expected to change MSRV to 1.81 for default-features = false users.

    Do you somehow have url 2.5.1 in your dependency graph? Can you force Cargo to take url 2.5.3 in its place?

  9. TotalKrill commented on Nov 4, 2024

    @TotalKrill
    Author

    Oh sorry, I am currently forcing our software to take 2.5.0, since 2.5.3 does not compile. Updated the previous comment to show that the cargo tree command showed 2.5.3

  10. hsivonen commented on Nov 4, 2024

    @hsivonen
    Collaborator

    So if you have url 2.5.3 without features and url 2.5.3 with the feature std, Cargo should unify those to one copy of url with the feature std. Are you sure the edited comment about cargo tree is correct?

    Aside: This isn't specific to idna. If I use Rust 1.80.1 with:

    [dependencies]
    url = { version = "2.5.3", default-features = false }
    idna = "1"

    ...idna compiles and the compilation of url fails with a complaint about impl core::error::Error for ParseError {} in url.

  11. TotalKrill commented on Nov 4, 2024

    @TotalKrill
    Author

    yep, my edited comment stands. But with what you say, something else might be changing to default-features = false

  12. hsivonen commented on Nov 4, 2024

    @hsivonen
    Collaborator

    As long as something in your dependency graph depends on url without setting default-features = false, something else setting default-features = false shouldn't matter.

    @Twixes, GitHub autolinks a couple of your changesets referencing this issue. Do you have minimized steps to reproduce?

  13. valenting commented on Nov 4, 2024

    @valenting
    Collaborator

    I think cargo tree -e features might explain if there's such a dependency conflict.

  14. 25 remaining items

  15. changed the title [-]Compilation error with url 2.5.3 / idna 1.0.3 with Rust < 1.81 and edition 2021 (resolver 2) when sqlx-core is in the dependency graph[/-] [+]Compilation error with url 2.5.3 / idna 1.0.3 with Rust < 1.81 and edition 2021 (resolver 2) when sqlx-core < 0.8.3 is in the dependency graph[/+] on Jan 7, 2025
  16. hsivonen commented on Jan 7, 2025

    @hsivonen
    Collaborator

    I edited the guidance at the top of this issue page to suggest updating SQLx to 0.8.3.

    SQLx 0.8.3 was released only 4 days ago, so I'm leaving this issue open for a while so that people whose projects are affected are more likely to find it. Perhaps a couple of weeks is enough and then we can close this.

  17. hsivonen commented on Feb 12, 2025

    @hsivonen
    Collaborator

    Perhaps a couple of weeks is enough and then we can close this.

    It's been more than a couple of weeks.

  18. added a commit that references this issue on Mar 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions