dependencies "contain code that will be rejected by a future version of Rust"

[MightyPork]

I'm getting this warning when built using latest rustc:

warning: the following packages contain code that will be rejected by a future version of Rust: buf_redux v0.8.4, multipart v0.18.0

multipart is abandoned and buf_redux is its abandoned dependency. The cleanest fix would be to switch to something else providing multipart encoding.

I made local forks of the affected crates and fixed it, also upgraded them to 2021 edition. The fix was trivial, mostly just adding dyn and removing some semicolons in macros.

Here's the patches needed to do that:

buf_redux:

5514df91edd41543afa8b51c51fd3824b66e8b67.diff.txt

multipart:

f56611df6a528ab3141c1f9a047401f2140fb69a.diff.txt

[bradfier]

Thanks for the report @MightyPork - I tend to agree that switching to a maintained provider of Content-Encoding: multipart/* is probably the better solution than carrying around vendored or patched versions of old crates.

I'd accept a PR to do that, otherwise I will look at it myself when I have time.

[bradfier]

This is, unfortunately, more trouble than it initially seemed.

Multipart and buf_redux are direct dependencies and thus fairly easy to swap out, indeed someone already maintains an updated version of buf_redux so I only had to publish an updated crate for the former.

The spanner in the works comes from traitobject which is even more unmaintained than the other two - this gets pulled in by our old-ish version of Hyper so we can't replace it with a fork as easily.

Rouille can't be the only place these new deprecation warnings are showing up so I'll see if there is any information elsewhere about what the suggested migration plan is.

[ravenexp]

Is it possible to make multipart an optional feature instead? Not everyone needs Content-Encoding: multipart/* for their applications.

[bradfier]

Is it possible to make multipart an optional feature instead? Not everyone needs Content-Encoding: multipart/* for their applications.

Yes, but doing so is a breaking change and requires a 4.0 to do so - and I don't really think it's worthwhile for that.

Regardless you'd still be caught out by the hit on traitobject as it's via Hyper, a mandatory dep.

[ravenexp]

Regardless you'd still be caught out by the hit on traitobject as it's via Hyper, a mandatory dep.

I don't have either of these in my dependency tree:

├── rouille v3.6.2
│   ├── base64 v0.13.1
│   ├── chrono v0.4.26
│   │   ├── iana-time-zone v0.1.57
│   │   └── num-traits v0.2.15
│   │       [build-dependencies]
│   │       └── autocfg v1.1.0
│   ├── filetime v0.2.21
│   │   ├── cfg-if v1.0.0
│   │   └── libc v0.2.147
│   ├── multipart v0.18.0
│   │   ├── buf_redux v0.8.4
│   │   │   ├── memchr v2.5.0
│   │   │   └── safemem v0.3.3
│   │   ├── httparse v1.8.0
│   │   ├── log v0.4.19
│   │   ├── mime v0.3.17
│   │   ├── mime_guess v2.0.4
│   │   │   ├── mime v0.3.17
│   │   │   └── unicase v2.6.0
│   │   │       [build-dependencies]
│   │   │       └── version_check v0.9.4
│   │   │   [build-dependencies]
│   │   │   └── unicase v2.6.0 (*)
│   │   ├── quick-error v1.2.3
│   │   ├── rand v0.8.5
│   │   │   ├── libc v0.2.147
│   │   │   ├── rand_chacha v0.3.1
│   │   │   │   ├── ppv-lite86 v0.2.17
│   │   │   │   └── rand_core v0.6.4
│   │   │   │       └── getrandom v0.2.10
│   │   │   │           ├── cfg-if v1.0.0
│   │   │   │           └── libc v0.2.147
│   │   │   └── rand_core v0.6.4 (*)
│   │   ├── safemem v0.3.3
│   │   ├── tempfile v3.6.0
│   │   │   ├── cfg-if v1.0.0
│   │   │   ├── fastrand v1.9.0
│   │   │   └── rustix v0.37.21
│   │   │       ├── bitflags v1.3.2
│   │   │       ├── io-lifetimes v1.0.11
│   │   │       │   └── libc v0.2.147
│   │   │       ├── libc v0.2.147
│   │   │       └── linux-raw-sys v0.3.8
│   │   │   [build-dependencies]
│   │   │   └── autocfg v1.1.0
│   │   └── twoway v0.1.8
│   │       └── memchr v2.5.0
│   ├── percent-encoding v2.3.0
│   ├── rand v0.8.5 (*)
│   ├── serde v1.0.164
│   ├── serde_derive v1.0.164 (proc-macro)
│   │   ├── proc-macro2 v1.0.63
│   │   │   └── unicode-ident v1.0.9
│   │   ├── quote v1.0.29
│   │   │   └── proc-macro2 v1.0.63 (*)
│   │   └── syn v2.0.22
│   │       ├── proc-macro2 v1.0.63 (*)
│   │       ├── quote v1.0.29 (*)
│   │       └── unicode-ident v1.0.9
│   ├── serde_json v1.0.99
│   │   ├── itoa v1.0.6
│   │   ├── ryu v1.0.13
│   │   └── serde v1.0.164
│   ├── sha1_smol v1.0.0
│   ├── threadpool v1.8.1
│   │   └── num_cpus v1.16.0
│   │       └── libc v0.2.147
│   ├── time v0.3.22
│   │   ├── libc v0.2.147
│   │   ├── num_threads v0.1.6
│   │   └── time-core v0.1.1
│   ├── tiny_http v0.12.0
│   │   ├── ascii v1.1.0
│   │   ├── chunked_transfer v1.4.1
│   │   ├── httpdate v1.0.2
│   │   └── log v0.4.19
│   └── url v2.4.0
│       ├── form_urlencoded v1.2.0
│       │   └── percent-encoding v2.3.0
│       ├── idna v0.4.0
│       │   ├── unicode-bidi v0.3.13
│       │   └── unicode-normalization v0.1.22
│       │       └── tinyvec v1.6.0
│       │           └── tinyvec_macros v0.1.1
│       └── percent-encoding v2.3.0

[tgross35]

What is the path forward here?

There is now a somewhat recent RUSTSEC advisory for multipart that is starting to show up wherever Rouille is used. Low severity only, but would be nice to avoid.

[golddranks]

How are Hyper and traitobject relevant here? They don't seem to be dependencies of Rouille.