Beautiful diagnostic reporting for text-based programming languages.
CyberSecurityUSC/PCDC-and-SECCDC 7
Resources for PCDC and SECCDC competitions
justinba1010/USCCodeathon-F19-Upper 4
ACM Fall 2019 240/350 Codeathon Problems
JamesPC44/USC_LowerDivision_Fall2018 2
Repository for Fall 2018 problems and solutions for 145/146 problems
human-readable binary encoding
Browser for git repositories and interactive compilation
ATO 2019 Collaborative Notes
issue closedtokio-rs/tracing
field_filter_spans intermittently fails
Bug Report
<!-- Thank you for reporting an issue.
Please fill in as much of the template below as you're able. -->
Version
Master branch (currently a8cc977e01ec4e1dce4137e37cfc1bfba7ebbed8).
Platform
I noticed the failure on MacOS, but it may appear on other platforms.
Crates
tracing and tracing-subscriber.
Description
Occasionally field_filter_spans fails with the following error:
}
[field_filter_spans] enabled -> true
thread 'field_filter_spans' panicked at '[field_filter_spans] more notifications expected: [Enter(MockSpan { metadata: Expect { name: Some("span3"), level: None, target: None } }), Event(MockEvent { fields: Some(Expect { fields: {"something": Any}, only: false }), parent: None, metadata: Expect { name: None, level: Some(Level(Debug)), target: None } }), Exit(MockSpan { metadata: Expect { name: Some("span3"), level: None, target: None } }), Nothing]', tracing-subscriber/tests/../../tracing/tests/support/subscriber.rs:528:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
See also https://github.com/tokio-rs/tracing/pull/991#issuecomment-699670469
closed time in an hour
jyn514
issue commenttokio-rs/tracing
field_filter_spans intermittently fails
Oops, this is a duplicate then.
comment created time in an hour
push eventjyn514/rust
commit sha 1bc0627607262cc60a7692b16e205f30fc88b89f
Add as_flag function to the OpenOptionsExt struct
commit sha 2c9e27b759a9e9feeb943fb855e32d7383d1dcc6
Merge branch 'convert-openoptions-cint' of github.com:FedericoPonzi/rust into convert-openoptions-cint
commit sha f9fcbbea03edb735c22311522b55d7b854bd6ac0
fixed bug
commit sha 7c1e5c1dcd25c945f619eda289f639dbe2b002da
Update OpenOptions::as_flags docs, and minor styling
commit sha ea5dc0909ea1ed4135f1bdecbaa3423051be578d
Make some Ordering methods const Constify the following methods of `core::cmp::Ordering`: - `reverse` - `then` Stabilizes these methods as const under the `const_ordering` feature. Also adds a test for these methods in a const context. Possible because of #49146 (Allow `if` and `match` in constants).
commit sha e49a29933be3bd988ccb75b053f480d9c99a7ff5
Working map_err_ignore lint
commit sha 202a80c927412a548180eca5990ee764d76ed643
Added tests for map_err, ignored map_err lint on drop_ref tests
commit sha 337729137bdec31b55665653ef0cf7dc124b0eaa
Ran cargo dev update_lints
commit sha 321b680fe66d1be04cd67fac75ff7f148fd117fe
Update docs of OpenOptions::as_flags
commit sha a80d39041e2d5cd58a846c9ef9e01ee9d691a7ed
Use inline(never) instead of cold inline(never) is better way to avoid optimizer to inline the function instead of cold.
commit sha 2387f68e437bf2ff5f117f63936257ce64052cfa
Removed map_err suggestion in lint, and updated lint documentation example
commit sha 28db5214d2c48e7a58cf79b9e272097260910a33
More implementations of Write for immutable refs Fixes #73836
commit sha 787b2707a77fa1a98f512a4905662a1a16daf13c
Move const tests for `Result` to `library\core` Part of #76268
commit sha 79d563c819483eaf6e67b6aaaef9d0ca6030337d
Move const tests for `Ordering` to `library\core` Part of #76268
commit sha b54386ab7a9da8a4f22db3a35a9ec7b0f2b98b6c
Detect overflow in proc_macro_server subspan
commit sha d98bac4e4e3cc87ec9b848c173d570ebe2aa30b6
Add tests for overflow in Vec::drain
commit sha f8cfb2f5ad847b871399dfef9b8b8ff4e84a75cb
Add tests for overflow in String / VecDeque operations using ranges
commit sha 6092828d1f432bb313818e7cfab961c0e494f69e
Add `[T; N]: TryFrom<Vec<T>>` This is very similar to the existing `Box<[T; N]>: TryFrom<Box<[T]>>`, but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice.
commit sha f8376b59d1391a5191a561c44067355f1a99c7c0
shim: monomorphic `FnPtrShim`s during construction This commit adjusts MIR shim construction so that substitutions are applied to function pointer shims during construction, rather than during codegen (as determined by `substs_for_mir_body`) - as substitutions will no longer occur during codegen, function pointer shims can now be polymorphic without incurring double substitutions. Signed-off-by: David Wood <david@davidtw.co>
commit sha 6cb671628393e292d5e68e6367f80488ace46532
Add test for checking if-let or-patterns
push time in an hour
issue openedtokio-rs/tracing
field_filter_spans intermittently fails
Bug Report
<!-- Thank you for reporting an issue.
Please fill in as much of the template below as you're able. -->
Version
<!--
List the versions of all tracing crates you are using. The easiest way to get
this information is using cargo-tree.
Master branch (currently a8cc977e01ec4e1dce4137e37cfc1bfba7ebbed8).
Platform
I noticed the failure on MacOS, but it may appear on other platforms.
Crates
tracing and tracing-subscriber.
Description
Occasionally field_filter_spans fails with the following error:
}
[field_filter_spans] enabled -> true
thread 'field_filter_spans' panicked at '[field_filter_spans] more notifications expected: [Enter(MockSpan { metadata: Expect { name: Some("span3"), level: None, target: None } }), Event(MockEvent { fields: Some(Expect { fields: {"something": Any}, only: false }), parent: None, metadata: Expect { name: None, level: Some(Level(Debug)), target: None } }), Exit(MockSpan { metadata: Expect { name: Some("span3"), level: None, target: None } }), Nothing]', tracing-subscriber/tests/../../tracing/tests/support/subscriber.rs:528:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
See also https://github.com/tokio-rs/tracing/pull/991#issuecomment-699670469
created time in an hour
pull request commenttokio-rs/tracing
The 'test macOS' job failed on https://github.com/tokio-rs/tracing/pull/991/commits/693890ee714b53c582a8a5c0aba2fcc09656918e but not on https://github.com/tokio-rs/tracing/pull/991/commits/db267aeb3b414e23c4cc0dcedc02d89a8b37eab7. I don't think running cargo fmt could have fixed it, maybe there's an intermittent failure going on? https://github.com/tokio-rs/tracing/runs/1173169110
comment created time in an hour
push eventjyn514/tracing
commit sha db267aeb3b414e23c4cc0dcedc02d89a8b37eab7
`cargo fmt`
push time in 2 hours
Pull request review commentrust-lang/rust
Link to documentation-specific guidelines.
//! # Contributing changes to the documentation //! //! Check out the rust contribution guidelines [here](-//! https://rustc-dev-guide.rust-lang.org/getting-started.html).+//! https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation). //! The source for this documentation can be found on //! [GitHub](https://github.com/rust-lang/rust).
But if this file is being viewed via https://doc.rust-lang.org/std/index.html#contributing-changes-to-the-documentation then that wording seems potentially confusing?
Hmm, that doesn't seem too confusing to me: It says the documentation for the standard library lives in the source code for the standard library. I think lib.rs is a little confusing though, maybe say library/std instead.
Both of your approaches seem fine to me, I think both are more clear than the current links.
comment created time in 2 hours
Pull request review commenttokio-rs/tracing
jobs: runs-on: ubuntu-latest strategy: matrix:- rust: [stable, 1.40.0]+ rust: [stable, 1.42.0]
Don't worry, it didn't take very long :) tracing uses the same 'minimum supported version is X' wording everywhere so I automated it:
rg 'version is 1\.40' -l | xargs sed -i 's/version is 1\.40/version is 1.42/'
comment created time in 2 hours
push eventjyn514/tracing
commit sha 693890ee714b53c582a8a5c0aba2fcc09656918e
Note that the new MSRV is 1.42 For the next person that comes along, the way to do this automatically is ```sh rg 'version is 1\.40' -l | xargs sed -i 's/version is 1\.40/version is 1.42/' ```
push time in 2 hours
pull request commenttokio-rs/tracing
Make `Level` and `LevelFilter` `Copy`
Good idea, done!
comment created time in 2 hours
push eventjyn514/tracing
commit sha 3bfd9c1f09bb94d444b90dc3c707e68e5cebe6c9
bump version number for tracing-core Since this changes crates that depend on tracing-core to remove clone calls and rely on Level and LevelFilter being Copy, those crates will no longer compile with older versions of tracing-core. This bumps the version number for `tracing-core` and sets the minimum version to the new version for all affected crates. This avoids compile errors with a cached `Cargo.lock`.
push time in 2 hours
pull request commentrust-lang/rust
Resolve `crate` in intra-doc links properly across crates
Ok, this is ready for review.
comment created time in 3 hours
issue closedrust-lang/rust-clippy
Lint on `const RUNTIME: tokio<Runtime>`
What it does
What does this lint do?
It errors on const tokio runtimes.
Categories (optional)
- Kind: Correctness
- Deny by default
What is the advantage of the recommended code over the original code
It avoids errors like the following:
Io(Custom { kind: Other, error: "reactor gone" })
const creates a new copy of the runtime every time it's used, while static uses the same runtime each time.
I was using this as RUNTIME.block_on(), which takes &mut, so possibly this could be expanded to any &mut use of a const.
Drawbacks
None.
Example
pub const RUNTIME: Lazy<Runtime> = Lazy::new(|| Runtime::new().unwrap());
should instead be
pub static RUNTIME: Lazy<Runtime> = Lazy::new(|| Runtime::new().unwrap());
closed time in 3 hours
jyn514
issue commentrust-lang/rust-clippy
Lint on `const RUNTIME: tokio<Runtime>`
Yes it would! Thank you :D https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=5329dc009d37cefba58f5acaab8d4be7
comment created time in 3 hours
push eventjyn514/rust
commit sha 406584621a4e2d3752b2444c5bed2218447f0bfe
Use relative links instead of intra-doc links Previously, `BTreeMap` tried to link to `crate::collections`, intending for the link to go to `std/collections/index.html`. But `BTreeMap` is defined in `alloc`, so after the fix in the previous commit, the links instead went to `alloc/collections/index.html`, which has almost no information. This changes it to link to `index.html`, which only works when viewing from `std::collections::BTreeMap`, the most common place to visit the docs. Fixing it to work from anywhere would require the docs for `std::collections` to be duplicated in `alloc::collections`, which in turn would require HashMap to be `alloc` for intra-doc links to work (https://github.com/rust-lang/rust/issues/74481).
push time in 4 hours
issue commentrust-lang/rust
Additional docs on pub re-exports resolve intra-doc links relative to the original module
Originally I thought this would need pulldown support, but I might be able to hack it by using the span of the
BrokenLinkpulldown returns.
It turns out pulldown already has this support in the form of into_offset_iter.
comment created time in 4 hours
issue closedraphlinus/pulldown-cmark
Include span for Events, not just BrokenLinks
Rustdoc currently has code that looks like this (yes, it's awful): https://github.com/rust-lang/rust/blob/6f2e1c65933702186cc681a3772862afa77dd632/src/librustdoc/html/markdown.rs#L1076-L1088
Originally I was hoping I could get rid of it now that BrokenLinks have spans. But the spans are only for the broken links, and rustdoc doesn't get them for [parenthesized](links). Is it possible to add that info to Event? I think that would allow removing it from BrokenLink too, but I'm not 100% sure about that.
As a side note, it looks like pulldown includes the [] in the span - is that intentional? Rustdoc only wants the URL itself, which isn't currently possible: consider [inline][link]. The - in the diff is rustdoc's hacky generated span, the + is pulldown's span.
LL | /// docs [label][with#anchor#error]
- | ^^^^^^^^^^^^^^^^^ contains invalid anchor
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^ contains invalid anchor
closed time in 4 hours
jyn514
issue commentraphlinus/pulldown-cmark
Include span for Events, not just BrokenLinks
Oh look at that! Thanks, I just didn't read the docs carefully enough :)
comment created time in 4 hours
PR opened Veykril/tlborm
pr created time in 4 hours
pull request commentrust-lang/rust
r=me with CI passing, this is definitely good enough to be on nightly
comment created time in 4 hours
issue commentrust-lang/rust
Intra-doc links don't work for associated items on re-exported primitives
Previously: https://github.com/rust-lang/rust/pull/76955, https://github.com/rust-lang/rust/issues/76693
comment created time in 4 hours
issue openedrust-lang/rust
Intra-doc links don't work for associated items on re-exported primitives
<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. -->
I tried this code:
/// [std::primitive::i32::MAX]
pub fn f() {}
I expected to see this happen: Rustdoc links to https://doc.rust-lang.org/stable/std/primitive.i32.html#associatedconstant.MAX
Instead, this happened: Rustdoc gives an error:
warning: unresolved link to `std::primitive::i32::MAX`
--> prim-assoc.rs:1:6
|
1 | /// [std::primitive::i32::MAX]
| ^^^^^^^^^^^^^^^^^^^^^^^^ the builtin type `i32` has no associated item named `MAX`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
The issue is https://github.com/rust-lang/rust/blob/71bdb8481760f7c6b8540d3dd176ed54a92c0f31/src/librustdoc/passes/collect_intra_doc_links.rs#L315 which does string comparison instead of going through resolve.
Meta
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. -->
rustdoc --version: rustdoc 1.48.0-nightly (f68e08933 2020-09-19)
created time in 4 hours
push eventjyn514/tlborm
commit sha 6b0a39c60a6bd76984842d8e54d7c49ad3eeb1cf
Fix typo
push time in 4 hours
fork jyn514/tlborm
The Little Book of Rust Macros(Updated)
https://veykril.github.io/tlborm/
fork in 4 hours
push eventjyn514/rust
commit sha 5bd814ed4eec7a886780aa524da3578eb5aa3aa3
Fix wrong comment syntax
push time in 4 hours
pull request commentrust-lang/rust
Revamp rustdoc docs about documentation using `cfg`
ping @ollie27 - does the new documentation look good to you?
comment created time in 4 hours
pull request commentrust-lang/rust
Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints
@bors r=Manishearth
comment created time in 5 hours
push eventjyn514/rust
commit sha 80ffaed809aa9bf659acf146a26d851f594c0b25
Add documentation for `private_intra_doc_links`
push time in 5 hours
pull request commentrust-lang/rust
Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints
Oh lol it tried to run the example as a doc-test.
---- /checkout/src/doc/rustdoc/src/lints.md - Lints::private_intra_doc_links (line 92) stdout ----
error: unknown start of token: `
--> /checkout/src/doc/rustdoc/src/lints.md:93:35
|
3 | warning: public documentation for `public` links to private item `private`
| ^
|
help: Unicode character '`' (Grave Accent) looks like ''' (Single Quote), but it is not
|
3 | warning: public documentation for 'public` links to private item `private`
| ^
Let me try ignoring it.
comment created time in 5 hours
push eventrust-lang/rustc-dev-guide
commit sha 35b702bf36fc9b2ff26f181f8b9145b958b9113b
Add links to documentation sources. Linking directly to the relevant/example document source locations makes it easier for potential contributors to find them.
commit sha e281cf57a6ceaa4c0834dcf70955b20a2fe6c2fb
Fix line length error. Reduced line length to <100 (as indicated by PR build error). (Also removed extra space character before link.)
commit sha 6b5c62c6f8946a1a158bb1e84e1dabe87daee820
Use implicit reference links for shorter lines (As suggested by jyn514.)
push time in 5 hours
PR merged rust-lang/rustc-dev-guide
Linking directly to the relevant/example document source locations makes it easier for potential contributors to find the sources.
The choice of the lib.rs example is somewhat arbitrary based primarily on where I first encountered the question of where the docs were located:
- https://github.com/rust-lang/rust/pull/77195#discussion_r495115432
- https://github.com/rust-lang/rust/pull/77050
pr closed time in 5 hours
pull request commentrust-lang/rust
Clean up diagnostics for arithmetic operation errors
Looks spurious:
Run src/ci/scripts/install-clang.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 424M 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
1 424M 1 6779k 0 0 4627k 0 0:01:33 0:00:01 0:01:32 4624k
3 424M 3 12.8M 0 0 6190k 0 0:01:10 0:00:02 0:01:08 6190k
curl: (56) SSLRead() return error -9806
clang+llvm-10.0.0-x86_64-apple-darwin/lib/libLLVMCore.a: Lzma library error: No progress is possible
@bors retry
comment created time in 5 hours
pull request commentrust-lang/rustc-dev-guide
Add links to documentation sources.
Yeah, that's an ongoing issue unfortunately :( https://github.com/rust-lang/rustc-dev-guide/issues/886
comment created time in 5 hours
Pull request review commentrust-lang/rust
fn drop_tag( if let Some(pos) = tags.iter().rev().position(|(t, _)| *t == tag_name) { // Because this is from a `rev` iterator, the position is reversed as well! let pos = tags.len() - 1 - pos;+ // If the tag is nested inside a "<script>", not warning should be emitted.+ let should_not_warn = tags.iter().take(pos + 1).any(|(at, _)| at == "script");
Sorry - I was using "script" as a shorthand for "any tag that introduces a syntax that's not HTML". So that includes at least style. @Manishearth might have more suggestions.
// If the tag is nested inside a "<script>", not warning should be emitted.
let should_not_warn = tags.iter().take(pos + 1).any(|(at, _)| at == "script" || at == "style");
comment created time in 5 hours
Pull request review commentrust-lang/rust
pub fn b() {} /// <h3> //~^ ERROR unclosed HTML tag `h3` pub fn c() {}++// Unclosed tags shouldn't warn if they are nested inside a script elem.+/// <script>+/// <h3><div>+/// </script>
/// <script>
/// <h3><div>
/// </script>
/// <style>
/// <h3><div>
/// </style>
comment created time in 5 hours
push eventjyn514/rust
commit sha 73ada2d40429488aaaacf37b608bababc137b910
Explicitly document the size guarantees that Option makes. Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer.
commit sha f5118a525fcf9db4102d903650331039158eff11
Clarify and add guarantee about `transmute`.
commit sha 83f47aa11bd664ed8a15ef9833063833b7b3e71c
Be clear about the reverse `transmute` guarantees.
commit sha f3d7196caec3f54e572c7389b1cef9fd9e62c1ed
Be clearer about Some/None transmute.
commit sha 8cb8955d570c76631840bfc98825ca49c0dd8eea
Change notation. Co-authored-by: Ralf Jung <post@ralfj.de>
commit sha 55802e3bf3bf6d1db5c76aea581a7912bd752890
Add Rust function pointers. Co-authored-by: Ralf Jung <post@ralfj.de>
commit sha 68209c3fe4e0f5c3758f18e98efc175af31c2e51
Rename the types for clarity.
commit sha 9bac5774d7b452b2227c9fb77a4c6de3f432ee55
Grammar tweak.
commit sha 459969f88ff95c94b7b34043a7f0e13de91de4f8
added restriction lint that prohibits the usage of unimplemented, unreachable or panic in a function of type result or option
commit sha ceab1a9167655eba9f9556f8766f8702e49dfef3
removed unnecessary comment
commit sha 8462cce96081b87eba7a5bc89130a1a09fe1f6d0
edited documentation
commit sha b2d8ca9a766703469178ea37d4d46067bb6fa926
ran cargo dev update lints
commit sha b006522393a3c3c2656e1ccdfbb0076ff1bd7e99
added lint for todo and removed option
commit sha a424a2c1676a29c147252873037e8943d54941d3
changed check_impl_item to check_fn and added a few more test cases
commit sha 73a3288282e733bfc5893e9920d29f1de5a21591
uncommented fn
commit sha 27c90b881df93b53fd3f24dcbfed116379c2fc69
initial implementation of OpenOptions to c_int
commit sha eb3906be4ad375cc6b83cd6a6e0116817db22575
Fix typo get openoptions function name Co-authored-by: Ivan Tham <pickfire@riseup.net>
commit sha d3b9ece4c0028ff7e36e34df2d2b26366f9c0648
add tests related to tuple scalar layout with ZST in last field
commit sha e5d85f917b8965a5e62513c17cbb887366b152bc
allow reordering of the last field of a MaybeUnsized struct if it's a ZST
commit sha e9bc3ddb073f2261ac46832d985efe8db863ed6a
test that we do not change the offset of ZST tuple fields when unsizing
push time in 5 hours
Pull request review commentrust-lang/rust
Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints
declare_lint! { "failures in resolving intra-doc link targets" } +declare_lint! {+ /// This is a subset of `broken_intra_doc_links` that warns when linking from+ /// a public item to a private one. This is a `rustdoc` only lint, see the+ /// documentation in the [rustdoc book].+ ///+ /// [rustdoc book]: ../../../rustdoc/lints.html#broken_intra_doc_links
Updated!
comment created time in 5 hours
push eventjyn514/rust
commit sha 73ada2d40429488aaaacf37b608bababc137b910
Explicitly document the size guarantees that Option makes. Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer.
commit sha f5118a525fcf9db4102d903650331039158eff11
Clarify and add guarantee about `transmute`.
commit sha 83f47aa11bd664ed8a15ef9833063833b7b3e71c
Be clear about the reverse `transmute` guarantees.
commit sha f3d7196caec3f54e572c7389b1cef9fd9e62c1ed
Be clearer about Some/None transmute.
commit sha 8cb8955d570c76631840bfc98825ca49c0dd8eea
Change notation. Co-authored-by: Ralf Jung <post@ralfj.de>
commit sha 55802e3bf3bf6d1db5c76aea581a7912bd752890
Add Rust function pointers. Co-authored-by: Ralf Jung <post@ralfj.de>
commit sha 68209c3fe4e0f5c3758f18e98efc175af31c2e51
Rename the types for clarity.
commit sha 9bac5774d7b452b2227c9fb77a4c6de3f432ee55
Grammar tweak.
commit sha 459969f88ff95c94b7b34043a7f0e13de91de4f8
added restriction lint that prohibits the usage of unimplemented, unreachable or panic in a function of type result or option
commit sha ceab1a9167655eba9f9556f8766f8702e49dfef3
removed unnecessary comment
commit sha 8462cce96081b87eba7a5bc89130a1a09fe1f6d0
edited documentation
commit sha b2d8ca9a766703469178ea37d4d46067bb6fa926
ran cargo dev update lints
commit sha b006522393a3c3c2656e1ccdfbb0076ff1bd7e99
added lint for todo and removed option
commit sha a424a2c1676a29c147252873037e8943d54941d3
changed check_impl_item to check_fn and added a few more test cases
commit sha 73a3288282e733bfc5893e9920d29f1de5a21591
uncommented fn
commit sha 27c90b881df93b53fd3f24dcbfed116379c2fc69
initial implementation of OpenOptions to c_int
commit sha eb3906be4ad375cc6b83cd6a6e0116817db22575
Fix typo get openoptions function name Co-authored-by: Ivan Tham <pickfire@riseup.net>
commit sha d3b9ece4c0028ff7e36e34df2d2b26366f9c0648
add tests related to tuple scalar layout with ZST in last field
commit sha e5d85f917b8965a5e62513c17cbb887366b152bc
allow reordering of the last field of a MaybeUnsized struct if it's a ZST
commit sha e9bc3ddb073f2261ac46832d985efe8db863ed6a
test that we do not change the offset of ZST tuple fields when unsizing
push time in 5 hours
issue commentrust-lang/rust
Rustdoc lints don't fire for pub re-exports
@GuillaumeGomez that's a warning for the module, not for the re-export; notice that it points to line 1 instead of line 2. Try this code instead:
#![deny(missing_doc_code_examples)]
//! ```
//! unimplemented!()
//! ```
pub use std::task::RawWakerVTable;
comment created time in 6 hours
issue commentrust-lang/rust
Additional docs on pub re-exports resolve intra-doc links relative to the original module
Another possible approach is to use the DefId of the use statement itself, but that requires fixing https://github.com/rust-lang/rust/issues/77230 first.
comment created time in 15 hours
issue commentrust-lang/rust
Additional docs on pub re-exports resolve intra-doc links relative to the original module
I'm not sure it's possible to go from a Span to the module it's defined in :/
comment created time in 15 hours
pull request commenttokio-rs/tracing
Make `Level` and `LevelFilter` `Copy`
Given that there's an explicit test for transmuting between usize and LevelFilter, I think it makes sense to add the Copy bound. Breaking Copy would also break the transmute.
comment created time in 15 hours
PR opened rust-lang/rust
This mis-highlighted the entire documentation as code.
pr created time in 15 hours
push eventjyn514/rust
push time in 15 hours
push eventjyn514/rust
commit sha 3f20adb79e946633b155da67ffa7d3a5470ac942
Fix typo in ExpnData documentation This mis-highlighted the entire documentation as code.
push time in 15 hours
pull request commentrust-lang/rust
@bors r+ rollup
I need to start using gqq more or something.
comment created time in 15 hours
push eventjyn514/rust
commit sha d4ca2eaf87e9bece8e508ad535dcbd5d9091096c
Use relative links instead of intra-doc links Previously, `BTreeMap` tried to link to `crate::collections`, intending for the link to go to `std/collections/index.html`. But `BTreeMap` is defined in `alloc`, so after the fix in the previous commit, the links instead went to `alloc/collections/index.html`, which has almost no information. This changes it to link to `index.html`, which only works when viewing from `std::collections::BTreeMap`, the most common place to visit the docs. Fixing it to work from anywhere would require the docs for `std::collections` to be duplicated in `alloc::collections`, which in turn would require HashMap to be `alloc` for intra-doc links to work (https://github.com/rust-lang/rust/issues/74481).
push time in 16 hours
push eventjyn514/rust
commit sha 45250f4bb468bb1a48f616b0b6dfca733836c2c0
Fix broken links by making them resolve in both places Previously, `BTreeMap` tried to link to `crate::collections`, intending for the link to go to `std/collections/index.html`. But `BTreeMap` is defined in `alloc`, so after the fix in the previous commit, the links instead went to `alloc/collections/index.html`, which has almost no information. This instead puts the information in both `std::collections` and `alloc::collections`. It avoids duplication by putting the docs in a separate file and using `doc(include = ...)`. As a side benefit, now that intra-doc links are being used everywhere, the exceptions in the linkchecker can be removed.
push time in 16 hours
push eventjyn514/rust
commit sha 6805188bc9330b4dfbf1fc4457c38e6d4294a60c
Fix broken links by making them resolve in both places Previously, `BTreeMap` tried to link to `crate::collections`, intending for the link to go to `std/collections/index.html`. But `BTreeMap` is defined in `alloc`, so after the fix in the previous commit, the links instead went to `alloc/collections/index.html`, which has almost no information. This instead puts the information in both `std::collections` and `alloc::collections`. It avoids duplication by putting the docs in a separate file and using `doc(include = ...)`.
push time in 16 hours
push eventjyn514/rust
commit sha 60e153c2aff92eb2fa37280052b358c56faa8222
Fix broken links by making them resolve in both places
push time in 16 hours
issue openedraphlinus/pulldown-cmark
Include span for Events, not just BrokenLinks
Rustdoc currently has code that looks like this (yes, it's awful): https://github.com/rust-lang/rust/blob/6f2e1c65933702186cc681a3772862afa77dd632/src/librustdoc/html/markdown.rs#L1076-L1088
Originally I was hoping I could get rid of it now that BrokenLinks have spans. But the spans are only for the broken links, and rustdoc doesn't get them for [parenthesized](links). Is it possible to add that info to Event? I think that would allow removing it from BrokenLink too, but I'm not 100% sure about that.
As a side note, it looks like pulldown includes the [] in the span - is that intentional? Rustdoc only wants the URL itself, which isn't currently possible: consider [inline][link]. The - in the diff is rustdoc's hacky generated span, the + is pulldown's span.
LL | /// docs [label][with#anchor#error]
- | ^^^^^^^^^^^^^^^^^ contains invalid anchor
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^ contains invalid anchor
created time in 16 hours
issue commentrust-lang/rust
Additional docs on pub re-exports resolve intra-doc links relative to the original module
Originally I thought this would need pulldown support, but I might be able to hack it by using the span of the link.
comment created time in 16 hours
issue commentraphlinus/pulldown-cmark
Reuse parser to improve performance
reusing the iterator is awkward with the current design. Since Parser itself is the Iterator and many (all?) of the standard iterator methods (map, filter, etc.) consume the iterator, it cannot be reused after using any of these
Couldn't you use for event in parser.by_ref()? https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.by_ref
comment created time in 16 hours
issue commentraphlinus/pulldown-cmark
Reuse parser to improve performance
nit about the API: I think it would be nicer to say impl IntoIterator for &mut Parser so you can keep using for event in parser {
comment created time in 17 hours
startedraphlinus/pulldown-cmark
started time in 17 hours
pull request commentrust-lang/rust
Resolve `crate` in intra-doc links properly across crates
I'll open another issue for resolving additional docs in the new scope.
https://github.com/rust-lang/rust/issues/77254
comment created time in 17 hours
issue openedrust-lang/rust
Additional docs on pub re-exports resolve intra-doc links relative to the original module
I tried this code:
/// I want to show [with_code]
pub use std::string::String;
pub fn with_code() {}
I expected to see this happen: Rustdoc links all the original documentation relative to std::string, and all the new documentation relative to the current crate, so with_code resolves properly.
Instead, this happened: Rustdoc links all the original documentation relative to std::string:
Sep 26 22:41:10.388 INFO rustdoc::passes::collect_intra_doc_links: ignoring warning from parent crate: unresolved link to `with_code`
This hits proc-macros especially hard because they're forced to be in a separate crate and can't link to anything in the main crate.
Meta
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. -->
rustdoc --version: rustdoc 1.48.0-nightly (f68e08933 2020-09-19), but also present on master (https://github.com/rust-lang/rust/commit/1ec980d225fff2346a1a631a7ffc88b37e9e18af)
created time in 17 hours
PR opened rust-lang/rust
Closes https://github.com/rust-lang/rust/issues/77193; see https://github.com/rust-lang/rust/issues/77193#issuecomment-699065946 for an explanation of what's going on here.
r? @Manishearth cc @dylni
@dylni note that this doesn't solve your original problem - now both with_code and crate::with_code will be broken links. However this will fix a lot of other broken links (in particular I think https://docs.rs/sqlx/0.4.0-beta.1/sqlx/query/struct.Query.html is because of this bug). I'll open another issue for resolving additional docs in the new scope.
pr created time in 17 hours
push eventjyn514/rust
commit sha 3fdad10d9077f0c6e7bf09723b20b68260499433
Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints This is not ideal because it means `deny(broken_intra_doc_links)` will no longer `deny(private_intra_doc_links)`. However, it can't be fixed with a new lint group, because `broken` is already in the `rustdoc` lint group; there would need to be a way to nest groups somehow. This also removes the early `return` so that the link will be generated even though it gives a warning.
push time in 17 hours
PR opened rust-lang/rust
This is not ideal because it means deny(broken_intra_doc_links) will
no longer deny(private_intra_doc_links). However, it can't be fixed
with a new lint group, because broken is already in the rustdoc lint
group; there would need to be a way to nest groups somehow.
This also removes the early return so that the link will be generated
even though it gives a warning.
r? @Manishearth cc @ecstatic-morse (https://github.com/rust-lang/rust/pull/77242#issuecomment-699565095)
pr created time in 18 hours
pull request commentrust-lang/rust
Replace `discriminant_switch_effect` with more general version
Splitting this into a separate lint sounds useful, I'll work on that. In the meantime you can add #[allow(broken_intra_doc_links)] on that exact item with a FIXME.
comment created time in 18 hours
push eventjyn514/tracing
commit sha a4ceb236df2091c7fa794b48cde3b5dbfe9353cc
Fix failing `repr` test It was comparing the pointers, not the levels themselves. This also changes transmute to explicitly specify both types to make this easier to debug in the future.
push time in 19 hours
push eventjyn514/tracing
commit sha 1950b1c318291071adac7da5eefa7e475aa0bf03
Fix failing `repr` test It was comparing the pointers, not the levels themselves. This also changes transmute to explicitly specify both types to make this easier to debug in the future.
push time in 19 hours
pull request commenttokio-rs/tracing
The CI failure looks like it's running this against the master version of workflows/CI.yml, which doesn't have the version bump. Not sure how to fix it.
comment created time in 20 hours
push eventjyn514/tracing
commit sha f1e3e00a92d0a965e9c5c6768e7f736b6e7c6187
fix nightly clippy warnings This will avoid breaking CI on new releases of clippy. It also makes the code a little easier to read. - Convert `match val { pat => true, _ => false }` to `matches!(val, pat)` - Remove unnecessary closures - Convert `self: &mut Self` to `&mut self` This bumps the MSRV to 1.42.0 for `matches!`. The latest version of rust is 1.46.0, so as per https://github.com/tokio-rs/tracing#supported-rust-versions this is not considered a breaking change. I didn't fix the following error because the fix was not trivial/needed a decision: ``` warning: you are deriving `Ord` but have implemented `PartialOrd` explicitly --> tracing-subscriber/src/filter/env/field.rs:16:32 | 16 | #[derive(Debug, Eq, PartialEq, Ord)] | ^^^ | = note: `#[warn(clippy::derive_ord_xor_partial_ord)]` on by default note: `PartialOrd` implemented here --> tracing-subscriber/src/filter/env/field.rs:98:1 | 98 | / impl PartialOrd for Match { 99 | | fn partial_cmp(&self, other: &Self) -> Option<Ordering> { 100 | | // Ordering for `Match` directives is based first on _whether_ a value 101 | | // is matched or not. This is semantically meaningful --- we would ... | 121 | | } 122 | | } | |_^ = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord ```
push time in 20 hours
pull request commenttokio-rs/tracing
Make `Level` and `LevelFilter` `Copy`
I tried this but it didn't work:
diff --git a/tracing-core/src/metadata.rs b/tracing-core/src/metadata.rs
index 8dd216f..d9ea459 100644
--- a/tracing-core/src/metadata.rs
+++ b/tracing-core/src/metadata.rs
@@ -432,7 +432,7 @@ impl LevelFilter {
// `LevelFilter`. If this is the case, converting a `usize` value into a
// `LevelFilter` (in `LevelFilter::current`) will be an identity conversion,
// rather than generating a lookup table.
- const OFF_USIZE: usize = LevelInner::Error as usize + 1;
+ const OFF_USIZE: usize = unsafe { core::mem::transmute(LevelFilter(None)) };
/// Returns a `LevelFilter` that matches the most verbose [`Level`] that any
/// currently active [`Subscriber`] will enable.
@@ -851,7 +851,7 @@ mod tests {
#[test]
fn level_filter_reprs() {
let mapping = [
- (LevelFilter::OFF, LevelInner::Error as usize + 1),
+ (LevelFilter::OFF, LevelFilter::OFF_USIZE),
(LevelFilter::ERROR, LevelInner::Error as usize),
(LevelFilter::WARN, LevelInner::Warn as usize),
(LevelFilter::INFO, LevelInner::Info as usize),
thread 'metadata::tests::level_filter_reprs' panicked at 'assertion failed: `(left == right)`
left: `5`,
right: `140381994394536`: repr changed for LevelFilter::OFF', tracing-core/src/metadata.rs:869:13
comment created time in 20 hours
pull request commenttokio-rs/tracing
Make `Level` and `LevelFilter` `Copy`
I don't know how to fix this error :(
---- metadata::tests::level_filter_reprs stdout ----
thread 'metadata::tests::level_filter_reprs' panicked at 'assertion failed: `(left == right)`
left: `5`,
right: `140704621814760`: repr changed for LevelFilter::OFF', tracing-core/src/metadata.rs:869:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
comment created time in 20 hours
push eventjyn514/tracing
commit sha 5545cae2bc8889439ea11a80001755719e172d28
fix nightly clippy warnings This will avoid breaking CI on new releases of clippy. It also makes the code a little easier to read. - Convert `match val { pat => true, _ => false }` to `matches!(val, pat)` - Remove unnecessary closures - Convert `self: &mut Self` to `&mut self` This bumps the MSRV to 1.42.0 for `matches!`. The latest version of rust is 1.46.0, so as per https://github.com/tokio-rs/tracing#supported-rust-versions this is not considered a breaking change. I didn't fix the following error because the fix was not trivial/needed a decision: ``` warning: you are deriving `Ord` but have implemented `PartialOrd` explicitly --> tracing-subscriber/src/filter/env/field.rs:16:32 | 16 | #[derive(Debug, Eq, PartialEq, Ord)] | ^^^ | = note: `#[warn(clippy::derive_ord_xor_partial_ord)]` on by default note: `PartialOrd` implemented here --> tracing-subscriber/src/filter/env/field.rs:98:1 | 98 | / impl PartialOrd for Match { 99 | | fn partial_cmp(&self, other: &Self) -> Option<Ordering> { 100 | | // Ordering for `Match` directives is based first on _whether_ a value 101 | | // is matched or not. This is semantically meaningful --- we would ... | 121 | | } 122 | | } | |_^ = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord ```
push time in 20 hours
pull request commenttokio-rs/tracing
Make `Level` and `LevelFilter` `Copy`
This is split out from https://github.com/tokio-rs/tracing/pull/990 (see https://github.com/tokio-rs/tracing/pull/990#issuecomment-699560371).
comment created time in 20 hours
PR opened tokio-rs/tracing
Motivation
This makes both structs easier to use because you no longer have to
worry about borrow errors while working with them. There's no downside
to making them Copy since both are wrappers around a usize.
Ideally, this would make Metadata::Level return Level instead of
&Level. However that's a breaking change, so I didn't make it here.
Solution
Derive Copy for both structs and fix various warnings that popped up as a result.
pr created time in 20 hours
pull request commenttokio-rs/tracing
subscriber: warn if trying to enable a statically disabled level
Originally this added a Copy impl for Level and LevelFilter, but that ran into a ton of warnings so I'm going to split it into a separate PR.
comment created time in 20 hours
push eventjyn514/tracing
commit sha e1e58cb6c4cd1d08e6b95a307891ff279695775b
subscriber: warn if trying to enable a statically disabled level This implements the warning in `tracing-subscriber` only, as mentioned in https://github.com/tokio-rs/tracing/issues/975#issuecomment-692903469. It warns whenever directives are parsed, including programmatically and through environment variables. It does not include the suggested new API which returns the filters that wouldn't be parsed. - List filters that would be ignored - Mention 'static max level' - Describe how to enable the logging Example output: ``` $ RUST_LOG=off,debug,silenced[x]=trace cargo run -q warning: some trace filter directives would enable traces that are disabled statically | `debug` would enable the DEBUG level for all targets | `silenced[x]=trace` would enable the TRACE level for the `silenced` target | the static max level is info note: to enable DEBUG logging, remove the `max_level_info` feature ``` Fixes: #975
push time in 20 hours
PR opened tokio-rs/tracing
Motivation
This will avoid breaking CI on new releases of clippy. It also makes the code a little easier to read.
Solution
- Convert
match val { pat => true, _ => false }tomatches!(val, pat) - Remove unnecessary closures
- Convert
self: &mut Selfto&mut self
matches! was stabilized in 1.42.0 and the latest version of rust is
1.46.0, so as per https://github.com/tokio-rs/tracing#supported-rust-versions
this is not considered a breaking change.
I didn't fix the following error because the fix was not trivial/needed a decision:
warning: you are deriving `Ord` but have implemented `PartialOrd` explicitly
--> tracing-subscriber/src/filter/env/field.rs:16:32
|
16 | #[derive(Debug, Eq, PartialEq, Ord)]
| ^^^
|
= note: `#[warn(clippy::derive_ord_xor_partial_ord)]` on by default
note: `PartialOrd` implemented here
--> tracing-subscriber/src/filter/env/field.rs:98:1
|
98 | / impl PartialOrd for Match {
99 | | fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
100 | | // Ordering for `Match` directives is based first on _whether_ a value
101 | | // is matched or not. This is semantically meaningful --- we would
... |
121 | | }
122 | | }
| |_^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord
As a side note, this found a bug in clippy 😆 https://github.com/rust-lang/rust-clippy/issues/6089
<!-- Thank you for your Pull Request. Please provide a description above and review the requirements below.
Bug fixes and new features should include tests.
Contributors guide: https://github.com/tokio-rs/tracing/blob/master/CONTRIBUTING.md -->
pr created time in 20 hours
push eventjyn514/tracing
commit sha 5ce2844e948396f3f9ab8fad7a203d9c6303c789
fix nightly clippy warnings This will avoid breaking CI on new releases of clippy. It also makes the code a little easier to read. - Convert `match val { pat => true, _ => false }` to `matches!(val, pat)` - Remove unnecessary closures - Convert `self: &mut Self` to `&mut self` `matches!` was stabilized in 1.42.0 and the latest version of rust is 1.46.0, so as per https://github.com/tokio-rs/tracing#supported-rust-versions this is not considered a breaking change. I didn't fix the following error because the fix was not trivial/needed a decision: ``` warning: you are deriving `Ord` but have implemented `PartialOrd` explicitly --> tracing-subscriber/src/filter/env/field.rs:16:32 | 16 | #[derive(Debug, Eq, PartialEq, Ord)] | ^^^ | = note: `#[warn(clippy::derive_ord_xor_partial_ord)]` on by default note: `PartialOrd` implemented here --> tracing-subscriber/src/filter/env/field.rs:98:1 | 98 | / impl PartialOrd for Match { 99 | | fn partial_cmp(&self, other: &Self) -> Option<Ordering> { 100 | | // Ordering for `Match` directives is based first on _whether_ a value 101 | | // is matched or not. This is semantically meaningful --- we would ... | 121 | | } 122 | | } | |_^ = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord ```
push time in 20 hours
issue openedrust-lang/rust-clippy
Clippy doesn't know how to fix `arbitrary_self_type` in some async functions
<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. -->
I tried the code from https://github.com/tokio-rs/tracing/blob/9ae4676054067dcf99b55cb76fcee3997207de6d/tracing-attributes/tests/async_fn.rs. Here is my attempt at an MCVE, but it doesn't compile:
use async_trait::async_trait;
use tracing_attributes::instrument;
#[async_trait]
pub trait Test {
async fn call();
async fn call_with_self(&self);
async fn call_with_mut_self(&mut self);
}
#[derive(Clone, Debug)]
struct TestImpl;
#[async_trait]
impl Test for TestImpl {
// instrumenting this is currently not possible, see https://github.com/tokio-rs/tracing/issues/864#issuecomment-667508801
//#[instrument(fields(Self=std::any::type_name::<Self>()))]
async fn call() {}
#[instrument(fields(Self=std::any::type_name::<Self>()))]
async fn call_with_self(&self) {}
#[instrument(fields(Self=std::any::type_name::<Self>()))]
async fn call_with_mut_self(self: &mut Self) {}
}
I expected to see this happen: cargo +nightly clippy --fix -Zunstable-options turns the code into async fn call_with_mut_self(&mut self) {}
Instead, this happened: Clippy replaces it with async fn call_with_mut_self(&'life0 mut self) {} which fails to compile.
error[E0261]: use of undeclared lifetime name `'life0`
--> tracing-attributes/tests/async_fn.rs:226:38
|
226 | async fn call_with_mut_self(&'life0 mut self) {}
| ^^^^^^ undeclared lifetime
|
= help: if you want to experiment with in-band lifetime bindings, add `#![feature(in_band_lifetimes)]` to the crate attributes
help: consider introducing lifetime `'life0` here
|
217 | impl<'life0> Test for TestImpl {
| ^^^^^^^^
help: consider introducing lifetime `'life0` here
|
216 | 'life0, #[async_trait]
| ^^^^^^^
error[E0261]: use of undeclared lifetime name `'life0`
--> tracing-attributes/tests/async_fn.rs:226:38
|
226 | async fn call_with_mut_self(&'life0 mut self) {}
| - ^^^^^^ undeclared lifetime
| |
| help: consider introducing lifetime `'life0` here: `<'life0>`
|
= help: if you want to experiment with in-band lifetime bindings, add `#![feature(in_band_lifetimes)]` to the crate attributes
error[E0195]: lifetime parameters or bounds on method `call_with_mut_self` do not match the trait declaration
--> tracing-attributes/tests/async_fn.rs:216:5
|
206 | #[async_trait]
| -------------- lifetimes in impl do not match this method in trait
...
216 | #[async_trait]
| ^^^^^^^^^^^^^^ lifetimes do not match method in trait
|
= note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)
Meta
cargo clippy -V: clippy 0.0.212 (043f6d7 2020-09-25)rustc -V: rustc 1.46.0 (04488afe3 2020-08-24)
created time in 20 hours
push eventjyn514/tracing
commit sha cca54b5995262eb13dfc73f319682a7f4d1fd801
cleanup `.clone()` now that Level is Copy Ideally, this would make `Metadata::Level` return `Level` instead of `&Level`. However that's a breaking change, so I didn't make it here.
push time in 20 hours
push eventjyn514/tracing
commit sha 7797f536457b7109d69a6c006d9000ea326bfc93
cleanup `.clone()` now that Level is Copy Ideally, this would make `Metadata::Level` return `Level` instead of `&Level`. However that's a breaking change, so I didn't make it here.
push time in 21 hours
push eventjyn514/tracing
commit sha 97348626bbaf5436b17e2b8dffe3ec034aef235b
cleanup `.clone()` now that Level is Copy Ideally, this would make `Metadata::Level` return `Level` instead of `&Level`. However that's a breaking change, so I didn't make it here.
push time in 21 hours
pull request commenttokio-rs/tracing
subscriber: warn if trying to enable a statically disabled level
I'm not sure how to add tests for this ... the existing tests in tracing-subscriber/tests use mocks and don't touch stdout. Should I add some example binary crates and run those?
comment created time in 21 hours
push eventjyn514/tracing
commit sha b745d09a18611c47f042ed6b12395335b11ec1a3
subscriber: warn if trying to enable a statically disabled level This implements the warning in `tracing-subscriber` only, as mentioned in https://github.com/tokio-rs/tracing/issues/975#issuecomment-692903469. It warns whenever directives are parsed, including programmatically and through environment variables. It does not include the suggested new API which returns the filters that wouldn't be parsed. - List filters that would be ignored - Mention 'static max level' - Describe how to enable the logging Example output: ``` $ RUST_LOG=off,debug,silenced[x]=trace cargo run -q warning: some trace filter directives would enable traces that are disabled statically | `debug` would enable the DEBUG level for all targets | `silenced[x]=trace` would enable the TRACE level for the `silenced` target | the static max level is info note: to enable DEBUG logging, remove the `max_level_info` feature ``` Fixes: #975
push time in 21 hours
PR opened tokio-rs/tracing
<!-- Thank you for your Pull Request. Please provide a description above and review the requirements below.
Bug fixes and new features should include tests.
Contributors guide: https://github.com/tokio-rs/tracing/blob/master/CONTRIBUTING.md -->
Motivation
<!-- Explain the context and why you're making that change. What is the problem you're trying to solve? If a new feature is being added, describe the intended use case that feature fulfills. -->
Fixes https://github.com/tokio-rs/tracing/issues/975.
Solution
This implements the warning in tracing-subscriber only, as mentioned in https://github.com/tokio-rs/tracing/issues/975#issuecomment-692903469. It warns whenever directives are parsed, including programmatically and through environment variables. It does not include the suggested new API which returns the filters that wouldn't be parsed.
- List filters that would be ignored
- Mention 'static max level'
- Describe how to enable the logging
Example output:
$ RUST_LOG=off,debug,silenced[x]=trace cargo run -q
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
| `silenced[x]=trace` would enable the TRACE level for the `silenced` target
| the static max level is info
note: to enable DEBUG logging, remove the `max_level_info` feature
pr created time in 21 hours
push eventjyn514/tracing
commit sha 8cb716bc22076c9d563d9578eca9828be3d59f69
subscriber: warn if trying to enable a statically disabled level This implements the warning in `tracing-subscriber` only, as mentioned in https://github.com/tokio-rs/tracing/issues/975#issuecomment-692903469. It warns whenever directives are parsed, including programmatically and through environment variables. It does not include the suggested new API which returns the filters that wouldn't be parsed. - List filters that would be ignored - Mention 'static max level' - Describe how to enable the logging Example output: ``` $ RUST_LOG=off,debug,silenced[x]=trace cargo run -q warning: some trace filter directives would enable traces that are disabled statically | `debug` would enable the DEBUG level for all targets | `silenced[x]=trace` would enable the TRACE level for the `silenced` target | the static max level is info note: to enable DEBUG logging, remove the `max_level_info` feature ``` Fixes: #975
push time in 21 hours