* Add team "groups" in tools/OWNERS_<group name>.
* Add top-level OWNERS as a fallback.
* Add OWNERS for all top-level directories.
* Add OWNERS to all packages.
For additional background information see go/dart-sdk-owners.
TEST=No op until code-owners is enabled.
Bug: b/200915407
Change-Id: I7fe6116cc599c749cd50ca16151d6d6a801d99d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229147
Reviewed-by: Jonas Termansen <sortie@google.com>
Fixes#47190
TEST=None, only markdown files where edited.
Change-Id: Ife204f9c792b6bce30d0cd7bf2260ced11c8f2b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213049
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
- Fix the link to the Dart SDK changelog so that it correctly refers
to the file `CHANGELOG.md` in the root directory of the repo.
- Fix the text that must prefix a breaking change to `**Breaking
Change**` (which is what we have been doing fairly consistently in
the changelog for over a year).
Change-Id: If1226bf51be5f40c057694f4ee2e2c7a479b069e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179583
Reviewed-by: Franklin Yow <frankyow@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
A couple of feature specs did not explicitly say that they are now
background material and normative language should be found in specific
other places. This CL does that. It also makes the README.md even more
explicit in order to make the same point.
Change-Id: I79cbd86a662faf478ce41c01e09c5f32a3f03cd3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134824
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This CL is using an approach that does not rely on program
transformations (based on the idea in CL 50221 from Lasse).
I have taken the approach to make `constant list literal`, `constant
object expression` the higher level concepts, and define the notion of
a `constant context` in terms of the syntax (so it requires an actual
`\CONST{}` or a switch case in the enclosing syntax).
Doing this work, I encountered the section about postfix expressions,
and (like several times before), I noted that there was no
specification of the static analysis at all. So I cleaned up that
section, at the time where I needed to edit it already, because of
the new `constructorInvocation` syntax.
If that is helpful, I could split this CL into a pure "implicit
creation" CL and another "fix up postfix expressions" CL.
Change-Id: I669ce942f698ca2fbb47ea60c58f4f05304ae66d
Reviewed-on: https://dart-review.googlesource.com/c/93432
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Change-Id: I41e8f558fd4c3145637a7d2f09cc261815ab2161
Reviewed-on: https://dart-review.googlesource.com/c/84605
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
This CL just changes whitespace and formatting.
In particular, it replaces \syntax{`...'} by \lit{...} as much as
possible (because it's simpler and shorter, and \lit{...} works in
some situations where \syntax{...} does not).
Change-Id: Icd241a8c9d04280ff57041450aa342eb56d34589
Reviewed-on: https://dart-review.googlesource.com/c/90742
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This was needed because we had a handful of long sentences, nearly
identical, specifying that operator == must not be overridden, except
if it's in a specific built-in class.
These locations have been adjusted several times because it's tricky,
and now we have this in just one location (so we won't forget to
include bool again, somewhere).
Note that this shows a couple of facts (this was already a consequence
of the wording in the language specification, but now it's explicit):
We can `switch` on constant lists, sets, maps, and function objects,
and similarly for element expressions in constant lists and sets, and
for keys in constant maps.
Bug: https://github.com/dart-lang/language/issues/188.
Change-Id: Ie54bce573ee577654b598926b711d6dc8eab6ff1
Reviewed-on: https://dart-review.googlesource.com/c/90462
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
.. and checked that they can occur also in Dart 2; added a comment
about why this is so, on each of them. Also, got rid of the term
"run-time error": the majority of references to errors at run time
were "dynamic error", and now that is the term used everywhere.
Cf. https://github.com/dart-lang/sdk/issues/34521.
Change-Id: I7579c84a8d52199524770fb91c64804173ed533d
Reviewed-on: https://dart-review.googlesource.com/c/90243
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
little problems in the spec that we have noted over time.
Fixed a couple of LaTeX mistakes; adjusted FutureOr section
The 'Type FutureOr' section was adjusted in order to avoid duplicate
subtype rules (the ones that we have had in section 'Type FutureOr'
until now are duplicates of rules in \ref{subtypeRules}).
Also changed the name of \basetype to \futureOrBase, because the former
is too generic to be helpful for readers.
Change-Id: I8d83cf1a0af275a930fbbb94cf59a9d758066583
Reviewed-on: https://dart-review.googlesource.com/c/90061
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Change-Id: I0008f74c75da28fbf38a959e2925b72dd1dfd38f
Reviewed-on: https://dart-review.googlesource.com/c/88563
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Currently, this kind of clash is an error when there is a declaration
at which the conflict is known to be an error, but it was not an error
when it occurs because a class `implements` two other classes where one
provides the getter/setter and the other provides the method.
Note to implementors: The analyzer apparently already flags this
situation as an error, so the change should be non-breaking, and if
implementation changes are needed at all it would most likely only be
in other tools.
Bug: https://github.com/dart-lang/sdk/issues/35561
Change-Id: I7f55b8995829ad64b86ebf33045b235813fc5161
Reviewed-on: https://dart-review.googlesource.com/c/88455
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
It has implementation consequences to refer to classes that are not
declared in dart:core, and it increases the library/spec interaction surface.
This change removes all references to `LinkedHashSet` from the spec.
It changess the rule for when a `{}` is a set to be
context type is a subtype of `FutureOr^\inf(Iterable<Object>)`
and not a subtupe of `FutureOr^\inf(Map<Object,Object>)`.
That should *work* for
* `Iterable<X>`
* `Set<X>`
* `LinkedHashSet<X>`
* `HashSet<X>`
* `FutureOr<Set<X>>`
(with likely exect-type issues as usual).
Change-Id: I3074da27b36093075c8c83e9672bf2fdec135c1c
Reviewed-on: https://dart-review.googlesource.com/c/87972
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Also marked the feature specification generalized-void.md
as background material
Change-Id: I08c9b54d956208db5aa8e695540b0c1fc941e46b
Reviewed-on: https://dart-review.googlesource.com/c/86421
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Needs some iterations of sanity checks, but has the expected shape
for it all at this point.
Change-Id: Idd96efa95d65ad6bd202b694c9d1f297cf04a8b6
Reviewed-on: https://dart-review.googlesource.com/c/86660
Reviewed-by: Leaf Petersen <leafp@google.com>
Corrected instantiate-to-bound.md to (1) take the variance of the top level
type into account for each step of the algorithm, and (2) explicitly require
that the type yielded by the algorithm must be checked for well-boundedness;
finally (3) an example showing that we can indeed get a result which is not
well-bounded was added.
Also adjusted the terminology to be consistent with dartLangSpec.tex
(where we say 'generic type alias' rather than 'parameterized type
alias').
Change-Id: I4b4e4ee7988439e39b05514f172d69233b1695d7
Reviewed-on: https://dart-review.googlesource.com/c/80140
Reviewed-by: Leaf Petersen <leafp@google.com>
Also updated spec on the static and dynamic types of functions literals
and static functions along with the function objects obtained from
closurizations of them.
Introduced a separate notion of what it means to be a correct override
relation (where the old text used subtyping, which won't suffice, for
several reasons).
Introduced the notion of interfaces as a separate kind of entity that
contains method signatures (again, a new kind of entity), thus
clarifying exactly which pieces of information is available during
static analysis of member accesses, e.g., instance method invocations.
Introduced 'combined' interfaces; they are needed for `mixin`
declarations, and we will specify them soon (so it should be OK to
have them now, even though they are unused).
Change-Id: I6347df49b1aa7a81d74e25904ee75c19e8ac6930
Reviewed-on: https://dart-review.googlesource.com/c/81263
Reviewed-by: Leaf Petersen <leafp@google.com>
