Errors reported for modifier overloading should outright say that overloading is not allowed

[cameel]

Error messages reported when you try to overload a modifier say that you cannot use the same name but do not say why. I think they should outright say that the cause of the error is that modifier overloading is not allowed. At least until we actually implement it (#72).

Example 1: straightforward overloading

contract C {
    modifier m(uint x) { _; }
    modifier m() { _; }
}

Error: Identifier already declared.
 --> test.sol:3:5:
  |
3 |     modifier m() { _; }
  |     ^^^^^^^^^^^^^^^^^^^
Note: The previous declaration is here:
 --> test.sol:2:5:
  |
2 |     modifier m(uint x) { _; }
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^

Example 2: overloading by inheriting from two bases

contract A {
    modifier m() { _; }
}
contract B {
    modifier m(uint x) { _; }
}
contract C is B, A {}

This case is especially misleading because the message suggests that you should override the modifiers in the derived class but they aren't even virtual.

Error: Derived contract must override modifier "m". Two or more base classes define modifier with same name.
 --> test.sol:7:1:
  |
7 | contract C is B, A {
  | ^ (Relevant source part starts here and spans across multiple lines).
Note: Definition in "A":
 --> test.sol:2:5:
  |
2 |     modifier m() { _; }
  |     ^^^^^^^^^^^^^^^^^^^
Note: Definition in "B":
 --> test.sol:5:5:
  |
5 |     modifier m(uint x) { _; }
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[cameel]

Bad error messages are an annoyance that I'd really like to see fixed. Maybe we should create a catch-all issue for this but until then, I'm going to keep this one open.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.