Introduce #[diagnostic::on_move(message)]

[rperier]

cc #149862

This is a first proposal. I have deliberately kept it simpler than diagnostic::on_unimplemented.

Few questions/remarks:

• Do I need to move the OnMoveDirective logic into a dedicated module perhaps ? let's say into compiler/rustc_borrowck/src/diagnostics/on_move.rs
• No problems to depend on crates like rustc_ast from the borrowck ?
• Notes are not supported yet. While message and label are very static , in the sense that they are emitted in the same way from the same place in the borrowck, it is not the case for the notes. It would make the code more complex. But, I can add support for notes if it does make sense.

Suggestions are welcomed !

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

[rustbot]

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rperier]

r? @estebank

[fmease]

The attribute parsing shouldn't happen here. That's also why you had to make borrowck depend on the AST, right?

Attribute parsing should generally always happen in rustc_attr_parsing. However, it seems that diagnostic attr parsing still happens elsewhere judging by the fact that its validation steps occur in rustc_passes::check_attr (that'll change in the future most likely as part of the ongoing attribute rewrite). Moreover, there used to be a specific module dedicated to diagnostic attrs, I don't know if that still exists or not. In any case, please move all the parsing (incl. validation) bits out of this crate.

No problems to depend on crates like rustc_ast from the borrowck ?

It means that anybody modifying rustc_ast also has to rebuild rustc_borrowck (that might already be the case or not if it's a transitive dependency, I can't check rn) hurting compile-edit cycles.

[rperier]

Yes, that's what I was afraid of, I was not sure that all the logic should happen here :)

I am going to do all the required changes, no problems, however currently, that's quiet confusing, diagnostic::on_unimplemented is checked by rustc_passes::check_attr to be sure that it's applied onto a trait definition (same for ::on_const). Then all the attribute parsing is done in compiler/rustc_trait_selection/src/error_reporting/traits/on_unimplemented.rs (same for diagnostic::on_const it seems, right ?).

[mejrs]

diagnostic::on_unimplemented is checked by rustc_passes::check_attr

Many of the ported attributes still have a pass in check_attr, your pass should stay there.

Then all the attribute parsing is done in compiler/rustc_trait_selection/src/error_reporting/traits/on_unimplemented.rs (same for diagnostic::on_const it seems, right ?).

I'm currently working on porting the parsing for diagnostic attributes, that code won't stay there for long.

[mejrs]

I'm currently working on migrating the existing diagnostic attribute infrastructure, can you do this PR after that? It's going to be quite a mess to resolve that conflict.

Is this meant to be only used by the standard library or also by users? If only by std, I think you should forego the attribute and instead check whether T implements UseCloned and recommend a clone (or .use if on nightly).

[rperier]

Yeah I can completly wait until you finished your work and do my PR after that, It was my intention to be honest . Resolving conflicts or rebasing is not an issue for me.