-
Notifications
You must be signed in to change notification settings - Fork 717
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
debug
in trace
fails to compile with log
feature enabled
#820
Comments
Agh, that's pretty bad, thanks for the report. I'll make sure to fix that right away! We'll have to double-check why the compilation checks with various feature flags enabled (including the |
Hmm. This is an interesting issue, because it's kind of in competition with the change in #806, which actually removed the import in the general case (without the I'm not sure off the top of my head what the right solution is to handle these two competing needs. IMO, the existence of the imports for @snejugal and @sirwindfield, any opinions on the best compromise here? |
In my crate the import is already explicit, so removing the internal import won't break it. But my concern is, just as yours, that there's likely code that depends on this (by mistake?) |
I've got seven published crates that got broken by this issue. Investigation has shown that I can still compile with an old This is an untenable situation. What are the options here? Irrespective of whether I could publish new versions that fix the issues in each crate, I am not willing to have all crates that I published in the past that depend on |
Perhaps they were unintentional, but I claim that nobody would ever have added explicit imports for them, because the compiler warned about unused imports (in my code!) when doing that. use tracing::trace;
use tracing::field::debug;
fn main() {
trace!(foo = debug(42));
}
So no, this is not a valid argument, in my opinion. |
@d-e-s-o this is a good point, I hadn't thought of that. The compiler warning about explicit imports of these names suggests that the use of the implicit imports is probably more widespread than I'd hoped initially. In that case, it seems like we're probably going to have to revert commit e3b3a3a and publish a new point release (possibly yanking the non-semver-compatible 0.1.16?). @sirwindfield, sorry about that — when we're preparing to release In the meantime, merging PR #790 should provide a solution for recording fields with names that collide with |
This reverts commit e3b3a3a. This change was accidentally semver-incompatible, as user code was able to use the imported `debug` and `display` functions without adding an import outside the macro. Although this was not documented, downstream code relied on these names being available, so this resulted in a breaking change in a point release. Fixes #820
This reverts commit e3b3a3a. This change was accidentally semver-incompatible, as user code was able to use the imported `debug` and `display` functions without adding an import outside the macro. Although this was not documented, downstream code relied on these names being available, so this resulted in a breaking change in a point release. Fixes #820
Ah I just say the notifications haha :) The macro should have used the fully qualified names of all imports anyway, which is good API design from an objective point of view and prevents situations like these. I didn't think about people actually "using" it so the version should have been pushed to denote a breaking change instead of just a minor. @hawkw Feel free to re-open the old PR in the case for v0.2. I'll just rebase it in that case :). |
On that note, sorry @d-e-s-o. It just didn't cross my mind that it would break builds to be honest. Should have thought about it a little bit more :( |
I think it might be possible by adding a |
@hawkw Probably worth an investigation ;) |
I tried it out. It turns out that if we import the types by name (e.g. This approach would work fine, provided that we ensure the module containing the deprecated functions only contains the functions we intend to deprecate. |
I mean, it's up to the maintainers anyway, but as it seems it's something that we both didn't expect to happen. It either has to be documented properly or removed in v0.2 (which I would favor for). |
No worries. I am just happy that we rolled back without push back. On that note: thanks @hawkw for the quick fix! (haven't tested yet or checked whether a new released has been cut already, but I am sure it will come eventually)
I have no problem with requiring an import for used functionality, conceptually. I.e., I absolutely could live with having to use use tracing::trace;
use tracing::field::debug;
fn main() {
trace!(foo = debug(42));
} My problem is solely with breakages of code (that abides to Rust's semver rules) published in the past. I.e., e3b3a3a is bad because it breaks code published that earlier was building fine. I feel very strongly that once published it should continue building (well, and working). |
Wait a minute...I just took another look at look at the git history, and I don't actually think yanking 0.1.16 is necessary. It looks like @sirwindfield's commit e3b3a3a only merged after 0.1.16 was released. We did need to revert that commit, as it would cause a breaking change if published, but it wasn't part of the 0.1.16 release. Instead, this specific issue is caused by an interaction with the It turns out this is not, in fact, an accidental breaking change in 0.1.16, but a long-standing bug that has existed since commit 76b5e80, which predates However, the issue only exists when the So, while we did need to revert e3b3a3a, we don't need to yank 0.1.16, and we need to make an additional change to fix this in the case where the |
Fixes #820 (for real, this time!) Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Ah, good to hear that it wasn't me who broke it haha :) I do have to say though, I like my short hash 👌 |
## Motivation When the `log` feature is enabled, the expressions provided for field values are passed into two separate macros: one which prepares the `tracing` structured value set that is used to construct the `tracing` event, and another which formats a textual message to send to `log`, if emitting a `log` record for the event is enabled. The issue is that the macro that generates the `tracing` value set generates a block containing an import for `tracing::field::debug` and `tracing::field::display`, while the block generated by the `log` message formatting macro does not import those functions. Therefore, the block where the `log` message is formatted fails to compile, since the functions are not present in the scope it expands to. It turns out this is not, in fact, an accidental breaking change in 0.1.16 as was suspected, but a long-standing bug that has existed since commit 76b5e80, which predates `tracing` 0.1.0. This issue existed as far back as when the library was still called `tokio-trace`! However, the issue only exists when the `log` feature flag is enabled --- and it's disabled by default. The bug hadn't caused any issues in the past, since use of the `log` feature flag was not widespread enough to be coincident with an instance of someone relying on the implicitly-imported function names. The breakage happened specifically because `hyper` 0.13.7 enables `tracing`'s `log` feature by default, so _everyone_ depending on `hyper` suddenly had that feature enabled --- now, the set of people enabling the `log` feature is suddenly _much_ larger! ## Solution This branch adds the missing imports in the `__tracing_mk_format_args!` helper macro, which generates the `log` format args. I've also added uses of `debug` and `display` without imports to the tests for the `log` feature flag, which don't compile prior to the fix. Fixes #820 (for real, this time!)
Okay, published |
Bug Report
Version
Platform
Description
This is the minimal reproducible example:
When
tracing
is compiled with default features, this code compiled. However, iftracing
is compiled with thelog
feature, it fails to compile:This happens because
tracing
emits a use fortracing::field::debug
when logging through itself, but it doesn't when logging throughlog
:expanded code
This actually broke my crate
tbot
, for which today I had to release a new version adding the neededuse
. It compiled just fine untilhyper
andh2
, whichtbot
depends on, switched fromlog
totracing
with thelog
feature enabled in their latest releases.The text was updated successfully, but these errors were encountered: