Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement adjusted member conflict rules #33235
(Edit May 31st by eernstg: The member conflicts rules have been simplified considerably, which is reflected in the simpler text below. E.g., many rows in the table are now justified by the same line number in the specification.)
Cf. issue #33077, CL 54410, and commits e8bb129 and 08c893d, the Dart 2 rules for which pairs of member declarations constitute a conflict have changed slightly, and expressed in a significantly simpler form. This issue is concerned with the implementation and testing of the updated rules.
For instance, it is now an error if a class declares a setter named
The number in the third column is the line number in dartLangSpec.tex as of c6129f7 where the given situation is specified to be a conflict (that is, a compile-time error or a static warning (which is also an error in Dart 2)).
The conflicts listed above are concerned with conflicts among member declarations that are beyond the simple name clash where two declarations introduce the same name into the same scope, that is, the names may be different, and they may be in different scopes.
In particular, the above list says nothing about overriding (because overriding is always concerned with two declarations of the same kind, and the list does not mention any such case).
It may be useful to consider certain cases where there is no conflict:
This was referenced
May 25, 2018
It is breaking because it makes
Almost all combinations of methods (static or instance) with the same base name (a method/getter named
I'm not aware of a concrete presubmit experiment which would reveal the breakage more precisely.
Note that #33237 (the Fasta subtask) was closed 10 days ago, which should imply that bleeding edge based usages would already have seen the breakage.
I just noticed that issue #32613 is not closed, although #33237 is closed, and also that #33237 was closed based on a commit with message 'Check for conflicts between a static setter and a constructor or static method', which does not mention the case in #33077.
Issue #32613 is not exactly the CFE subtask for this issue, it is a broader task which is concerned with the implementation of conflict checking for members (at all, they used to be completely missing), not just the changes which were introduced as of 08c893d. At this point, however, resolving issue #32613 should imply that #33237 is also resolved, because a full implementation should include the latest updates.
My current interpretation of the situation is that #33237 was closed too early (unless the remaining cases including "declares instance setter, has instance method" have been implemented in some other commit), and also that #33237 and #32613 should be consolidated (such that they do not overlap, or at least such that the overlap is known and is being managed).