log icon indicating copy to clipboard operation
log copied to clipboard

Consider emitting a diagnostic message when multiple incompatible log level features are used

Open CattleProdigy opened this issue 3 years ago • 3 comments

So today I learned the hard way that crate features are additive. If a program directly or indirectly through other dependencies, depends on a crate of the same version multiples times with different features, it will use the union of features. It does not introduce multiple copies of the crate like what happens with a version mismatch. This is pretty logical behavior I suppose, but it's a bit annoying when you have features that are mutually incompatible (like static max output level in logs).

In my specific case, I had some far flung dependency setting release_max_level_info, when I was trying to do trace level logging.

The real problem here was a dependency library setting log level features. I'll sort that out with that library, but when I was trying to figure out what was going on, I hadn't considered that multiple features were active simultaneously until I did a bunch of digging (verbose builds, grepping through .cargo etc.). I could see legitimate use cases for multiple log levels perhaps, so I wouldn't make this an error. A compiler warning or message saying something to the effect of "hey you've got both release_max_level_info and release_max_level_trace, we're going to go with info" (but obviously more generic than that) could be very helpful.

CattleProdigy avatar Jan 24 '22 16:01 CattleProdigy

Cargo suppresses all warnings produced by dependencies, so even if we emitted a warning you wouldn't be able to see it in normal compilation contexts.

sfackler avatar Jan 24 '22 16:01 sfackler

How about a compile error then, instead? I mean multiple max_level_* features set, suggests misuse, doesn't it?

dekellum avatar Jan 31 '22 20:01 dekellum

It is a bit of an unfortunate (mis)use of Cargo features, isn't it. Ideally I'd like to get away from the max_level_* features altogether in favor of an environment variable that we read through our build.rs.

KodrAus avatar Feb 11 '22 10:02 KodrAus