2018: fix lint on unused dependencies #57274

mark-i-m · 2019-01-02T18:25:18Z

Previously warn(unused_extern_crates) was a way to detect unused dependencies. How can I:

declare dependencies in the root module

be warned when those dependencies are not used

As it is now, cargo builds all dependencies and does not warn if they are unused.

The text was updated successfully, but these errors were encountered:

cramertj · 2019-01-02T18:41:53Z

IMO it should be based on the --extern args provided to rustc, and should not ignore "for-side-effects-only" imports now that we can do use some_crate as _;

mark-i-m · 2019-01-02T22:25:10Z

So as far as I can tell, the set of unused crates is computed here:

rust/src/librustc_typeck/check_unused.rs

Line 74 in ec19464

fn unused_crates_lint<'tcx>(tcx: TyCtxt<'_, 'tcx, 'tcx>) {

and then passed around through the tcx. Is this the code that needs to be updated?

Nemo157 · 2019-01-03T10:56:26Z

This might have issues with adding dependencies-of-dependencies to force specific versions (I'm not sure how common that pattern is, and I guess they could be treated as "for-side-effects-only" imports as @cramertj mentions above).

dekellum · 2019-01-03T18:52:00Z

In a project, I was just adding such (originally-)transitive dependencies to get a -Z minimal-versions build working. At least before "unused_extern_crates" is changed to default to "warn", perhaps an allow=unused flag could be supported on the Cargo.toml dependency itself, like the #[allow(some_lint)] attribute in code?

cramertj · 2019-01-03T18:57:12Z

@dekellum Is there a reason you want to allow it in Cargo.toml rather than use <cratename> as _; as I suggested above?

dekellum · 2019-01-03T19:47:23Z

I agree both that use some_crate as _; should not trigger the unused_extern_crate lint (should not be treated as unused) and with the concern for the use-case raised by @Nemo157. Needing to add use some_crate as _; for each of these originally-transitive dependencies is more cumbersome, when just wanting to guide cargo's dependency resolution, where nothing really needs to be imported as far as rustc is concerned. Note also in my case, using the [patch] section of Cargo.toml didn't work for the such resolution adjustment.

jonhoo · 2019-01-16T18:19:49Z

We'd also have to make sure that if you have, say, two binaries in a crate, and Cargo.toml lists a dependency that is only used by one of them, compiling the other shouldn't generate a warning.

cramertj · 2019-01-16T18:28:22Z

@jonhoo IMO that's a bug in cargo that it doesn't allow specifying per-build-target dependencies (or maybe it does, in which case users should do that).

jonhoo · 2019-01-16T18:46:39Z

@cramertj yeah, I agree, the real solution would be to have per-target dependencies, but sadly that's not something we have yet. There's some discussion in rust-lang/cargo#1982 on how we may add support for dependencies for binary targets, which would go a long way, but that has been open for a while. Until we get support for that though, we'd have to make sure that the lint doesn't erroneously give a warning in those cases.

cramertj · 2019-01-16T18:55:04Z

@jonhoo It seems fine to me to silence those cases using use X as _;. They are unused external crates, and it's wrong for them to be passed in via --extern but not used in the crate. It so happens that there isn't a "correct" way to fix it right now aside from silencing the warning with use X as _;, but rustc is correct to warn in that case IMO.

What to do about this case practically is just sort of unfortunate, since rustc doesn't have enough information at any point to determine that this is just waiting on a missing cargo feature. The only clear options to me are to trigger this warning and require that users manually silence it (which is undoubtedly annoying) or not display the warning at all until the requisite feature is added to cargo (which seems similarly annoying).

A more complex but complete solution would be to have some way of telling rustc about all the targets you intend to compile in the future that should be considered in determining whether a crate is "used" without actually fully compiling each of those targets. Actually making this work well is a bit outside the reach of my imagination at the moment, and it seems of little value once we get cargo build-target-specific dependencies working.

jonhoo · 2019-01-16T19:02:44Z

Sounds like the best thing would be to push the effort to allow per-target depenencies in cargo forward. Sadly that's a process that's been slow going since 2015. There has been some recent effort from @pwoolcoc to write up an RFC recently though (helped by @alexreg), so maybe there's hope!

elichai · 2019-05-14T17:27:37Z

I think that having a lint for unnecessary dependencies in Cargo.toml is a very important and useful thing

est31 · 2019-08-24T14:04:10Z

See also rust-lang/rust-clippy#4341

est31 · 2019-08-30T18:39:41Z

FYI, while I'd like to have it implemented in upstream tools as well, I have released an independent tool that does such an unused crates lint.

jsgf · 2020-05-06T18:48:08Z

What's the current state of this?

From the look of it, the code at

rust/src/librustc_typeck/check_unused.rs

Line 68 in 339f574

fn unused_crates_lint(tcx: TyCtxt<'_>) {

which by its name should be responsible for this is actually making extern crate -> use suggestions, but doesn't warn about unused crates?

Is that code still the right starting point for addressing this issue?

ehuss · 2020-05-06T19:18:07Z

I don't think the compiler will be able to implement this without false positives. @Aaron1011 attempted in #69203, which is sort of the straightforward approach to add a lint. However, when used with Cargo, Cargo unconditionally passes every dependency to every target. This means if you have a dev-dependency that is used in tests/foo.rs, but not in src/lib.rs, then you would get an unused warning in lib.rs.

It's hard to think of an approach that could work solely in rustc. If we want the lint to work with Cargo, then a higher level tool is needed. That is exactly what cargo-udeps is, though I haven't used it much.

It may be possible that Cargo will gain per-target dependencies (rust-lang/rfcs#2887), but that might be a long ways off, and may not completely address the problem.

We could add the lint as allow-by-default, and let non-Cargo users, or adventurous souls to turn it on manually.

It may also be possible to build this into Cargo itself. It could use binary-dep-depinfo (#63012) to glean what is used. I haven't thought about it too much. I think cargo-udeps now has experimental support for that.

Those are the approaches I can think of offhand.

petrochenkov · 2020-05-06T19:31:06Z

I still think #69203 is useful even if it is allow-by-default.
At least it worked on the rustc repo pretty well.

Resurrecting it is on my todo list, but I have no idea how soon I'll get to it.
It would be great if someone else could do that sooner.

jsgf · 2020-05-07T00:10:53Z

@ehuss Thanks for the update. I'm primarily concerned with Buck builds where every target should have precisely defined dependencies, so the Cargo limitation doesn't apply.

Thanks for the pointer to #69203; I'll give it a closer look.

jsgf · 2020-05-18T01:23:24Z

@petrochenkov I have a draft implementation of this in https://github.com/jsgf/rust/tree/warn-unused-deps, following your advice of doing most of the logic in rustc_metadata::postprocess. The logic looks sound, but the problem I'm running into is how to report the diagnostics and handle the lint allow/deny flags and attributes without a tcx or a real Span corresponding to the lint.

Suggestions?

@petrochenkov

This will print a diagnostic for crates which are mentioned as `--extern` arguments on the command line, but are never referenced from the source. This diagnostic is controlled by `-Wunused-crate-dependencies` or `#![warn(unused_crate_dependencies)]` and is "allow" by default. There are cases where certain crates need to be linked in but are not directly referenced - for example if they are providing symbols for C linkage. In this case the warning can be suppressed with `use needed_crate as _;`. Thanks to @petrochenkov for simplified core. Resolves issue rust-lang#57274

Warn about unused crate deps Implements rust-lang#57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = "bar" }` in `Cargo.toml`), then it will warn about each unused alias. This does not consider crate added by some other means than `--extern`, including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](rust-lang#57274 (comment)) as it will over-specify crates, causing spurious warnings. As a result, this lint is "allow" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.

@petrochenkov

This will print a diagnostic for crates which are mentioned as `--extern` arguments on the command line, but are never referenced from the source. This diagnostic is controlled by `-Wunused-crate-dependencies` or `#![warn(unused_crate_dependencies)]` and is "allow" by default. There are cases where certain crates need to be linked in but are not directly referenced - for example if they are providing symbols for C linkage. In this case the warning can be suppressed with `use needed_crate as _;`. Thanks to @petrochenkov for simplified core. Resolves issue rust-lang#57274

Implement `--extern-location` This PR implements `--extern-location` as a followup to rust-lang#72342 as part of the implementation of rust-lang#57274. The goal of this PR is to allow rustc, in coordination with the build system, to present a useful diagnostic about how to remove an unnecessary dependency from a dependency specification file (eg Cargo.toml). EDIT: Updated to current PR state. The location is specified for each named crate - that is, for a given `--extern foo[=path]` there can also be `--extern-location foo=<location>`. It supports ~~three~~ two styles of location: ~~1. `--extern-location foo=file:<path>:<line>` - a file path and line specification 1. `--extern-location foo=span:<path>:<start>:<end>` - a span specified as a file and start and end byte offsets~~ 1. `--extern-location foo=raw:<anything>` - a raw string which is included in the output 1. `--extern-location foo=json:<anything>` - an arbitrary Json structure which is emitted via Json diagnostics in a `tool_metadata` field. ~~1 & 2 are turned into an internal `Span`, so long as the path exists and is readable, and the location is meaningful (within the file, etc). This is used as the `Span` for a fix suggestion which is reported like other fix suggestions.~~ `raw` and `json` are for the case where the location isn't best expressed as a file and location within that file. For example, it could be a rule name and the name of a dependency within that rule. `rustc` makes no attempt to parse the raw string, and simply includes it in the output diagnostic text. `json` is only included in json diagnostics. `raw` is emitted as text and also as a json string in `tool_metadata`. If no `--extern-location` option is specified then it will emit a default json structure consisting of `{"name": name, "path": path}` corresponding to the name and path in `--extern name=path`. This is a prototype/RFC to make some of the earlier conversations more concrete. It doesn't stand on its own - it's only useful if implemented by Cargo and other build systems. There's also a ton of implementation details which I'd appreciate a second eye on as well. ~~**NOTE** The first commit in this PR is rust-lang#72342 and should be ignored for the purposes of review. The first commit is a very simplistic implementation which is basically raw-only, presented as a MVP. The second implements the full thing, and subsequent commits are incremental fixes.~~ cc `@ehuss` `@est31` `@petrochenkov` `@estebank`

…crum Add an unstable --json=unused-externs flag to print unused externs This adds an unstable flag to print a list of the extern names not used by cargo. This PR will enable cargo to collect unused dependencies from all units and provide warnings. The companion PR to cargo is: rust-lang/cargo#8437 The goal is eventual stabilization of this flag in rustc as well as in cargo. Discussion of this feature is mostly contained inside these threads: rust-lang#57274 rust-lang#72342 rust-lang#72603 The feature builds upon the internal datastructures added by rust-lang#72342 Externs are uniquely identified by name and the information is sufficient for cargo. If the mode is enabled, rustc will print json messages like: ``` {"unused_extern_names":["byteorder","openssl","webpki"]} ``` For a crate that got passed byteorder, openssl and webpki dependencies but needed none of them. ### Q: Why not pass -Wunused-crate-dependencies? A: See [ehuss's comment here](rust-lang#57274 (comment)) TLDR: it's cleaner. Rust's warning system wasn't built to be filtered or edited by cargo. Even a basic implementation of the feature would have to change the "n warnings emitted" line that rustc prints at the end. Cargo ideally wants to synthesize its own warnings anyways. For example, it would be hard for rustc to emit warnings like "dependency foo is only used by dev targets", suggesting to make it a dev-dependency instead. ### Q: Make rustc emit used or unused externs? A: Emitting used externs has the advantage that it simplifies cargo's collection job. However, emitting unused externs creates less data to be communicated between rustc and cargo. Often you want to paste a cargo command obtained from `cargo build -vv` for doing something completely unrelated. The message is emitted always, even if no warning or error is emitted. At that point, even this tiny difference in "noise" matters. That's why I went with emitting unused externs. ### Q: One json msg per extern or a collective json msg? A: Same as above, the data format should be concise. Having 30 lines for the 30 crates a crate uses would be disturbing to readers. Also it helps the cargo implementation to know that there aren't more unused deps coming. ### Q: Why use names of externs instead of e.g. paths? A: Names are both sufficient as well as neccessary to uniquely identify a passed `--extern` arg. Names are sufficient because you *must* pass a name when passing an `--extern` arg. Passing a path is optional on the other hand so rustc might also figure out a crate's location from the file system. You can also put multiple paths for the same extern name, via e.g. `--extern hello=/usr/lib/hello.rmeta --extern hello=/usr/local/lib/hello.rmeta`, but rustc will only ever use one of those paths. Also, paths don't identify a dependency uniquely as it is possible to have multiple different extern names point to the same path. So paths are ill-suited for identification. ### Q: What about 2015 edition crates? A: They are fully supported. Even on the 2015 edition, an explicit `--extern` flag is is required to enable `extern crate foo;` to work (outside of sysroot crates, which this flag doesn't warn about anyways). So the lint would still fire on 2015 edition crates if you haven't included a dependency specified in Cargo.toml using `extern crate foo;` or similar. The lint won't fire if your sole use in the crate is through a `extern crate foo;` statement, but that's not its job. For detecting unused `extern crate foo` statements, there is the `unused_extern_crates` lint which can be enabled by `#![warn(unused_extern_crates)]` or similar. cc `@jsgf` `@ehuss` `@petrochenkov` `@estebank`

…crum Add an unstable --json=unused-externs flag to print unused externs This adds an unstable flag to print a list of the extern names not used by cargo. This PR will enable cargo to collect unused dependencies from all units and provide warnings. The companion PR to cargo is: rust-lang/cargo#8437 The goal is eventual stabilization of this flag in rustc as well as in cargo. Discussion of this feature is mostly contained inside these threads: rust-lang#57274 rust-lang#72342 rust-lang#72603 The feature builds upon the internal datastructures added by rust-lang#72342 Externs are uniquely identified by name and the information is sufficient for cargo. If the mode is enabled, rustc will print json messages like: ``` {"unused_extern_names":["byteorder","openssl","webpki"]} ``` For a crate that got passed byteorder, openssl and webpki dependencies but needed none of them. ### Q: Why not pass -Wunused-crate-dependencies? A: See [ehuss's comment here](rust-lang#57274 (comment)) TLDR: it's cleaner. Rust's warning system wasn't built to be filtered or edited by cargo. Even a basic implementation of the feature would have to change the "n warnings emitted" line that rustc prints at the end. Cargo ideally wants to synthesize its own warnings anyways. For example, it would be hard for rustc to emit warnings like "dependency foo is only used by dev targets", suggesting to make it a dev-dependency instead. ### Q: Make rustc emit used or unused externs? A: Emitting used externs has the advantage that it simplifies cargo's collection job. However, emitting unused externs creates less data to be communicated between rustc and cargo. Often you want to paste a cargo command obtained from `cargo build -vv` for doing something completely unrelated. The message is emitted always, even if no warning or error is emitted. At that point, even this tiny difference in "noise" matters. That's why I went with emitting unused externs. ### Q: One json msg per extern or a collective json msg? A: Same as above, the data format should be concise. Having 30 lines for the 30 crates a crate uses would be disturbing to readers. Also it helps the cargo implementation to know that there aren't more unused deps coming. ### Q: Why use names of externs instead of e.g. paths? A: Names are both sufficient as well as neccessary to uniquely identify a passed `--extern` arg. Names are sufficient because you *must* pass a name when passing an `--extern` arg. Passing a path is optional on the other hand so rustc might also figure out a crate's location from the file system. You can also put multiple paths for the same extern name, via e.g. `--extern hello=/usr/lib/hello.rmeta --extern hello=/usr/local/lib/hello.rmeta`, but rustc will only ever use one of those paths. Also, paths don't identify a dependency uniquely as it is possible to have multiple different extern names point to the same path. So paths are ill-suited for identification. ### Q: What about 2015 edition crates? A: They are fully supported. Even on the 2015 edition, an explicit `--extern` flag is is required to enable `extern crate foo;` to work (outside of sysroot crates, which this flag doesn't warn about anyways). So the lint would still fire on 2015 edition crates if you haven't included a dependency specified in Cargo.toml using `extern crate foo;` or similar. The lint won't fire if your sole use in the crate is through a `extern crate foo;` statement, but that's not its job. For detecting unused `extern crate foo` statements, there is the `unused_extern_crates` lint which can be enabled by `#![warn(unused_extern_crates)]` or similar. cc ``@jsgf`` ``@ehuss`` ``@petrochenkov`` ``@estebank``

…crum Add an unstable --json=unused-externs flag to print unused externs This adds an unstable flag to print a list of the extern names not used by cargo. This PR will enable cargo to collect unused dependencies from all units and provide warnings. The companion PR to cargo is: rust-lang/cargo#8437 The goal is eventual stabilization of this flag in rustc as well as in cargo. Discussion of this feature is mostly contained inside these threads: rust-lang#57274 rust-lang#72342 rust-lang#72603 The feature builds upon the internal datastructures added by rust-lang#72342 Externs are uniquely identified by name and the information is sufficient for cargo. If the mode is enabled, rustc will print json messages like: ``` {"unused_extern_names":["byteorder","openssl","webpki"]} ``` For a crate that got passed byteorder, openssl and webpki dependencies but needed none of them. ### Q: Why not pass -Wunused-crate-dependencies? A: See [ehuss's comment here](rust-lang#57274 (comment)) TLDR: it's cleaner. Rust's warning system wasn't built to be filtered or edited by cargo. Even a basic implementation of the feature would have to change the "n warnings emitted" line that rustc prints at the end. Cargo ideally wants to synthesize its own warnings anyways. For example, it would be hard for rustc to emit warnings like "dependency foo is only used by dev targets", suggesting to make it a dev-dependency instead. ### Q: Make rustc emit used or unused externs? A: Emitting used externs has the advantage that it simplifies cargo's collection job. However, emitting unused externs creates less data to be communicated between rustc and cargo. Often you want to paste a cargo command obtained from `cargo build -vv` for doing something completely unrelated. The message is emitted always, even if no warning or error is emitted. At that point, even this tiny difference in "noise" matters. That's why I went with emitting unused externs. ### Q: One json msg per extern or a collective json msg? A: Same as above, the data format should be concise. Having 30 lines for the 30 crates a crate uses would be disturbing to readers. Also it helps the cargo implementation to know that there aren't more unused deps coming. ### Q: Why use names of externs instead of e.g. paths? A: Names are both sufficient as well as neccessary to uniquely identify a passed `--extern` arg. Names are sufficient because you *must* pass a name when passing an `--extern` arg. Passing a path is optional on the other hand so rustc might also figure out a crate's location from the file system. You can also put multiple paths for the same extern name, via e.g. `--extern hello=/usr/lib/hello.rmeta --extern hello=/usr/local/lib/hello.rmeta`, but rustc will only ever use one of those paths. Also, paths don't identify a dependency uniquely as it is possible to have multiple different extern names point to the same path. So paths are ill-suited for identification. ### Q: What about 2015 edition crates? A: They are fully supported. Even on the 2015 edition, an explicit `--extern` flag is is required to enable `extern crate foo;` to work (outside of sysroot crates, which this flag doesn't warn about anyways). So the lint would still fire on 2015 edition crates if you haven't included a dependency specified in Cargo.toml using `extern crate foo;` or similar. The lint won't fire if your sole use in the crate is through a `extern crate foo;` statement, but that's not its job. For detecting unused `extern crate foo` statements, there is the `unused_extern_crates` lint which can be enabled by `#![warn(unused_extern_crates)]` or similar. cc ```@jsgf``` ```@ehuss``` ```@petrochenkov``` ```@estebank```

deepink-mas · 2023-02-14T13:12:14Z

While this is still open is there a quick check that can be performed that will confirm whether a dependency is still necessary or not?

For example if I comment or remove a dep from Cargo.toml and run "cargo check --all-targets", will I always get an error if the dep is still needed, and conversely does the absence of any errors indicate that the dep is unused?

est31 · 2023-02-14T20:26:48Z

@deepink-mas The lint is in rustc mostly to support non-cargo build systems. For cargo there needs to be cargo level comparison between multiple units, which isn't implemented in cargo right now.

Furthermore, there is no single cargo command that builds all units, see rust-lang/cargo#8437 (comment)

…itives `unused_crate_dependencies` is complaining about the `rand` dev-dependency, which is used by integ tests. This is a known problem with this lint: rust-lang/rust#57274

This lint doesn't work with multiple targets (in the case of prepare-worker, the bench-only dependencies were messing it up). See: - rust-lang/rust#95513 - rust-lang/rust#57274 (comment)

mark-i-m mentioned this issue Jan 2, 2019

(Modules) Tracking issue for (use) crate_name:: paths without extern crate #53128

Closed

3 tasks

jonhoo mentioned this issue Jan 18, 2019

Write a tool that reports unnecessary crate dependencies servo/servo#9256

Closed

jonas-schievink added the A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. label Jan 26, 2019

petrochenkov mentioned this issue Mar 30, 2019

[WIP] UNUSED_EXTERN_CRATES -> Deny #59483

Closed

Mark-Simulacrum mentioned this issue Jun 21, 2019

Tidy doesn't check for unused extern crates #62036

Open

pawanjay176 mentioned this issue Jul 26, 2019

Remove unused dependencies sigp/lighthouse#456

Merged

est31 mentioned this issue Aug 24, 2019

lint for unused crates rust-lang/rust-clippy#4341

Open

repi mentioned this issue Aug 27, 2019

Get warning on unused crates in Cargo.toml EmbarkStudios/rust-ecosystem#16

Open

2 tasks

nagisa mentioned this issue Jan 21, 2020

rustc doesn't complain if extern rlib is missing #68417

Closed

Aaron1011 mentioned this issue Feb 16, 2020

Implement unused crate lint for 2018 edition #69203

Closed

jsgf mentioned this issue May 26, 2020

Implement --extern-location #72603

Merged

est31 mentioned this issue May 28, 2020

rustc_lint: Remove unused_crate_dependencies from the unused group #72702

Merged

This was referenced Jul 2, 2020

Add an unstable --json=unused-externs flag to print unused externs #73945

Merged

[WIP] Add flag to warn about unused dependencies rust-lang/cargo#8437

Closed

ordian mentioned this issue Oct 26, 2020

introduce errors with info paritytech/polkadot#1834

Merged

teenjuna mentioned this issue Jul 9, 2021

Val err details teenjuna/prae#12

Merged

avitex mentioned this issue Dec 28, 2021

Tracking issue for warning for rust_2018_idioms by default #54910

Open

11 tasks

ehuss mentioned this issue Mar 31, 2022

unused_crate_dependencies false-positives in crates with muliple (lib/bin) targets #95513

Open

tv42 mentioned this issue Sep 8, 2023

False positives for dev-dependencies with unused_crate_dependencies lint #72686

Closed

Dentosal mentioned this issue Sep 20, 2023

no_std support for fuel-tx and fuel-vm FuelLabs/fuel-vm#582

Merged

weihanglo mentioned this issue Oct 19, 2023

unused-crate-dependencies conflicts in lib and bin crates rust-lang/cargo#12854

Closed

ehuss mentioned this issue Jan 2, 2024

Proposal: Adding a prune command/flag to the cargo CLI rust-lang/cargo#13234

Open

tombh mentioned this issue Aug 20, 2024

Add a note about why Clippy doesn't do this? Boshen/cargo-shear#78

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

2018: fix lint on unused dependencies #57274

2018: fix lint on unused dependencies #57274

mark-i-m commented Jan 2, 2019

cramertj commented Jan 2, 2019

mark-i-m commented Jan 2, 2019

Nemo157 commented Jan 3, 2019

dekellum commented Jan 3, 2019

cramertj commented Jan 3, 2019

dekellum commented Jan 3, 2019

jonhoo commented Jan 16, 2019

cramertj commented Jan 16, 2019 •

edited

Loading

jonhoo commented Jan 16, 2019

cramertj commented Jan 16, 2019 •

edited

Loading

jonhoo commented Jan 16, 2019

elichai commented May 14, 2019

est31 commented Aug 24, 2019

est31 commented Aug 30, 2019

jsgf commented May 6, 2020

ehuss commented May 6, 2020

petrochenkov commented May 6, 2020

jsgf commented May 7, 2020 •

edited

Loading

jsgf commented May 18, 2020

deepink-mas commented Feb 14, 2023

est31 commented Feb 14, 2023

2018: fix lint on unused dependencies #57274

2018: fix lint on unused dependencies #57274

Comments

mark-i-m commented Jan 2, 2019

cramertj commented Jan 2, 2019

mark-i-m commented Jan 2, 2019

Nemo157 commented Jan 3, 2019

dekellum commented Jan 3, 2019

cramertj commented Jan 3, 2019

dekellum commented Jan 3, 2019

jonhoo commented Jan 16, 2019

cramertj commented Jan 16, 2019 • edited Loading

jonhoo commented Jan 16, 2019

cramertj commented Jan 16, 2019 • edited Loading

jonhoo commented Jan 16, 2019

elichai commented May 14, 2019

est31 commented Aug 24, 2019

est31 commented Aug 30, 2019

jsgf commented May 6, 2020

ehuss commented May 6, 2020

petrochenkov commented May 6, 2020

jsgf commented May 7, 2020 • edited Loading

jsgf commented May 18, 2020

deepink-mas commented Feb 14, 2023

est31 commented Feb 14, 2023

cramertj commented Jan 16, 2019 •

edited

Loading

cramertj commented Jan 16, 2019 •

edited

Loading

jsgf commented May 7, 2020 •

edited

Loading