Add suggestions for std_instead_of_core

[tom-anders]

changelog: [`std_instead_of_core`]: add suggestions

Fixes #11446

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Manishearth (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[Jarcho]

This needs tests for the more fun cases with mixed imports. e.g.

use std::fmt::{Result, format};
use std::{collections::HashMap, fs, str};

Should end up as (if there's going to be a suggestion for them)

use core::fmt::Result;
use alloc::fmt::format;
use alloc::collections::HashMap;
use std::fs;
use core::str;

I don't remember how those get picked up by the lint.

[Manishearth]

overall looks good but i want to discuss the exact text a bit, and i agree with @Jarcho that more examples would be great!

[Manishearth]

hm, not a fan of how this looks where "core" gets repeated. it sounds confusing but it makes sense if you understand how the span arrows work.

thoughts on better ways to present this? perhaps "consider importing the item using: core"?

unsure if that's better, open to opinions!

[cathaysia]

Is this turned off by default? I mean, will this have any impact on no_std programs. Or is it automatically disabled if no_std is found?

[Manishearth]

No, these are restriction lints

(and this PR is not adding them, it is improving the existing ones. We've had them for a while)

[tom-anders]

This needs tests for the more fun cases with mixed imports. e.g.

use std::fmt::{Result, format};
use std::{collections::HashMap, fs, str};

Should end up as (if there's going to be a suggestion for them)

use core::fmt::Result;
use alloc::fmt::format;
use alloc::collections::HashMap;
use std::fs;
use core::str;

I don't remember how those get picked up by the lint.

Currently this fails with failed to apply suggestions for tests/ui/std_instead_of_core.rs with rustfix: Cannot replace slice of data that was already replaced.

Getting the replacement right here seems complicated - If you can give me some starting points on how to handle this, I can have a go though.

Otherwise, maybe let's just detect this case and not offer any suggestions for now? We could open a new issue for handling these kinds of replacements.

[Manishearth]

Yeah that sounds fine. We should also file an issue on rustfix for that.

(ideally take the JSON-format rust output and the file and include them in the issue)

[Manishearth]

@bors r+

[bors]

📌 Commit e0014af has been approved by Manishearth

It is now in the queue for this repository.

[bors]

⌛ Testing commit e0014af with merge 27165ac...

[tom-anders]

Yeah that sounds fine. We should also file an issue on rustfix for that.

(ideally take the JSON-format rust output and the file and include them in the issue)

Is it really a rustfix issue though? Currently our lint will first try to replace "std" with with core (for Result import) and then the same "std" with alloc (for the format import). Do you think rustfix should simply apply the second suggestion in this case?

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: Manishearth
Pushing 27165ac to master...