`term::emit`'s `writer` argument does not behave additively wrt features.

[cwfitzgerald]

Originally reported as gfx-rs/wgpu#7915
Connected to #374
cc @bushrat011899

Hello! The writer argument to term::emit can cause compilation to fail when additional features are added. https://github.com/brendanzab/codespan/blob/master/codespan-reporting/src/term.rs#L28-L30 when there are no features enabled, you can pass in a String and it will compile. But enable the termcolor feature, a string will no longer be allowed. Similarly you can put a fmt::Write type which does not impl io::Write into the slot, which will cause a compilation failure when the std feature is added by another crate.

[kaleidawave]

Yes, termcolor::WriteColor is not a superset of std::io::Write (and also different to core::fmt::Write) and so it can break when mixed.

Apologies that this has landed in the latest release. Will have a think about how to fix. May require an intermediate trait.

[kaleidawave]

I believe that this area is changed by #387. So maybe worth making merging that change first rather than trying to add a hack-fix for this now

[npetrangelo]

I ran into this as well. Do you recommend using a 25.x.x version of wgpu until this is fixed?

[citizinf]

@npetrangelo I looked into wgpu#7915 and wgpu#7968 and also played around with the small toy wgpu project I'm working on. It seems this compile error doesn't happen when the dependency tree only includes wgpu 26. Things were compiling fine for me until I added a dependency on glyphon 0.9.0 which is using wgpu 25. I was able to "fix" the compile error by just bumping up the versions of wgpu (dependencies and dev-dependencies) of glyphon in my local .cargo/registry folder.

Perhaps that won't last past the next time cargo updates the registry. I didn't try downgrading my project to wgpu 25 but I would guess that should work since that version doesn't appear to enable the termcolor feature (https://github.com/gfx-rs/wgpu/blob/f35cf942af1a3bb6f48aa9185f4d2bcee809f814/wgpu/Cargo.toml#L156) and that was also what fixed it in wgpu#7968 (see comment).

[cwfitzgerald]

Can wgpu help push this along in any way? Happy to make any PRs needed to get this resolved, as this seems like a blocker to upgrading wgpu.