Make E0599's label more clear for field which is used like a method.

[surechen]

fixes #127178

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
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

[compiler-errors]

I think rewording "field, not method" to be a bit more detailed is useful (though I think the "in scope" part is redundant imo), but this doesn't fix the issue linked, which is expressing confusion about why something is being called a field when it's a method -- just because it's a method that's out of scope.

[lolbinarycat]

additionally, the most confusing part of issue is the help messages getting interleaved, which is completely unaddressed.

[surechen]

additionally, the most confusing part of issue is the help messages getting interleaved, which is completely unaddressed.

Thanks for the additional explanation.
In my opinion, the suggestions here are not getting interleaved, because first of all, it is a field, so it is recommended that the user remove the surrounding brackets first, and then try to find traits that can provide this method. The user will only be prompted after finding some satisfied traits.
I initially thought that what might cause user confusion was that field, not a method was too simple, especially when it was not known whether the user wanted a field or a method.
I feel that there is no need to move the probe logic in fn suggest_traits_to_import to the time when the message field, not a method is issued, because it does not seem to make much sense to know it in advance. I prefer to simply improve the information field, not a method here.
Hope to get your reply, thank you. @compiler-errors @lolbinarycat

[lolbinarycat]

In my opinion, the suggestions here are not getting interleaved

the three help messages that get printed appear in this order:

1. help: items from traits can only be used if the trait is implemented and in scope
2. help: remove the arguments
3. help: trait GetX which provides x is implemented but not in scope; perhaps you want to import it

1 and 3 deal with the fact that you could fix the error by importing a trait, while 2 deals with the fact you could fix the error by turning a method call into a field access. the similar fixes should be grouped together.

[surechen]

In my opinion, the suggestions here are not getting interleaved

the three help messages that get printed appear in this order:

1. help: items from traits can only be used if the trait is implemented and in scope
2. help: remove the arguments
3. help: trait GetX which provides x is implemented but not in scope; perhaps you want to import it

1 and 3 deal with the fact that you could fix the error by importing a trait, while 2 deals with the fact you could fix the error by turning a method call into a field access. the similar fixes should be grouped together.

Thank you for your reply. I will take some time to process it as soon as possible

[compiler-errors]

@rustbot author

[surechen]

The original help message "items from traits can only be used if the trait is implemented and in scope" may not be displayed in the order of the code due to the diagnostic's mechanism, so here I try to use span_help to make the help message sorting comply with the order of the code.
Please help review again. Thank you. @compiler-errors

[compiler-errors]

Please revert this. I don't think this improves the quality of the error message.

[surechen]

Please revert this. I don't think this improves the quality of the error message.

Done. Thank you.

[bors]

☔ The latest upstream changes (presumably #128786) made this pull request unmergeable. Please resolve the merge conflicts.