Change:
format!("{}: {}", item_ident, ty), Applicability::MachineApplicable, ) <del> .emit(); </del> <ins> .emit_unless(ty.references_error()); </ins> } None => { let mut diag = bad_placeholder_type(tcx, vec![span]); <del> if !matches!(ty.kind(), ty::Error(_)) { </del> <ins> if !ty.references_error() { </ins> diag.span_suggestion( span, "replace `_` with the correct type",

Discussion:
I think the suggestion is trying to suggest a type, but gets a due to the type error in the body of the . Ideally we would just not suggest a type, but there are probably a lot of other places that this issue occurs. () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Fix instructions: the place where the suggestion is emitted the suggestion from being created if the suggested type is ( gives that) possibly other variants of
Hi i am interesting in tackling this issue! This would be my first time contributing.
Cool! You can mark yourself as workin on this issue by writing in it. Feel free to ask away with anything that is unclear. Or actually, just anything ^^ If you prefer chat over github messages, you can also reach out in by opening a new thread.
claim
The error is emitted here: within fn inferplaceholdertype, but I am confused by what is happening when matches with none, since it emits a different error. If it is unrelated to this issue, should I check for ty::Err and it variants from within Some(mut err)? I was thinking of matching on like so:
I've managed to block the second error: I used err.delayasbug() because I was getting an internal compiler error for an unused error. I saw which does the same thing and seems more appropriate, but is the fn that I should use? Using emit_unless(bool):
I like the variant more. Though I think we should add an method that takes a , which we get from the . What do you think
Shouldn't it also be , same order as in the code?
claim reclaiming this issue with a new account
The order is indeed odd, but at least grammatically correct. If you have , you are adding to . This along with another order swap around being for an and meaning an operation . I think we could have an entire design meeting just around how to get all of that into a diagnostic without causing more confusion than the status quo. If you want you can open an issue about just the order confusion, I'll add the appropriate tags.
I'm concerned about the possibility of there being a case where is generated without any other error (but that shouldn't happen).

The emitunless`:
I don't know enough about the language design space to be opening up meaningful issues. I was just making a comment. I don't know whether it's an issue or not and I certainly don't want to create issues that will be closed immediately.
That shouldn't stop you. Some times there are things that the team hasn't yet noticed and it is a good idea to rise the point. Other times tickets are duplicated but that is also a useful signal that can be a proxy for urgency. We treat these kind of issues seriously. We rarely immediately close tickets around here unless they are a duplicate (where we close with a link) or completely off-topic (where we point of more reasonable venues). If you still feel this comment isn't worth a new ticket but still want to have a conversation around it, feel free to visit and start a new thread. IIRC, I am the one that wrote that message and I went back and forth between a sentence that made grammatical sense and one that looked like the provided code, and landed in the current message and a main label in the order of the code. Since the output has changed slightly and the later has been "lost". As the "culprit" of the current state, I welcome any conversation around this. That's how we improve :)
claim is open :)