Change:
This help message seems weird. I'd expect the help to be more like: Consider adding if you want to silent the lint on the unused import Consider removing the unused import Suggesting to add to the module is the least expected option, and it seems too assertive in its current wording. No response Perhaps the detection for triggering on the module could be smarter and only consider a module as a potential test module if it contains at least one annotated function? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How can i proceed to solve this any suggestions on how can it be done changes to which file will make it happen since i am new to this repo
Hi thank you for your interest. For now, I think making the help message less assertive would be sufficient. Here are some tips to get you started: will need to find where this help message is emitted. You can identify where this help message is coming from by grepping the repo, i.e. this case, it might be as simple as changing this string to make it sound less assertive. can reformat your changes via . the UI test suite to make sure at least one test fails -- this means at least one test is actually testing this diagnostic. you're happy with the stderr output from your change, re-bless the UI test suite and now make sure the UI test suite passes. to make sure tidy checks passes locally. a PR and wait for review. Your reviewer will discuss with you to see if any further changes are desirable. <https://rustc-dev- the more in-depth reference. If you are stuck, feel free to ask here, or make a new thread in .
claim
(Unless already submitted a change and I didn't find it, I should be able to create a PR soon)

Discussion:
if let Some(span) = in_test_module { db.span_help( sess.source_map().guess_head_span(span), <del> "consider adding a `#[cfg(test)]` to the containing module", </del> <ins> "if this is a test module, consider adding a `#[cfg(test)]` to the containing module", </ins> ); } }

LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:8:1 | LL | mod test {

LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:18:1 | LL | mod tests {

LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:28:1 | LL | mod test_a {

LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:38:1 | LL | mod a_test {

LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:48:1 | LL | mod tests_a {

LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:58:1 | LL | mod a_tests {