Initial commit

[jakemac53]

This deviates from the design doc somewhat, differences are listed below:

1. Libraries are visited in post-order, but annotations within the libraries are not visited in text-source order. This is because the ClassMirror implementation doesn't implement the location property. The result is that method annotations execute in text-source order but class annotations are mixed in somewhat arbitrarily.
2. There are two optional arguments to run, typeFilter and customFilter, instead of just filter. The typeFilter is analogous to the filter described in the design doc, and customFilter accepts a function with this signature bool (StaticInitializer annotation).

[sigmundch]

FYI - if we change later StaticInitializer.initialize to return a future, we'd need to change this to not use =>, but return null instead.

[jakemac53]

Ya, for exactly that reason I think we should leave it as dynamic

[sigmundch]

Super cool!

[jakemac53]

ok updated everything and ran the formatter, ready for another look!

[sigmundch]

now that the queues are gone, I think we can delete this and the following comment. It's pretty self explanatory now :)

[jakemac53]

done

[sigmundch]

I just realized that we might need to move this down and make it an argument of _readLibraryDeclarations below and not a field anymore. This is for the same reason we do the caching of annotations-found for each initializer: when we process initializers in phases and someone runs init.run a second time, we should revisit all libraries to see if there were other initializers we should add.

[jakemac53]

Ya true, this isn't an issue right now because I only ever call run() on one of these crawlers once, but since the class itself doesn't enforce that it could cause bugs later on.

[jakemac53]

updated, see note about sorting libraries by uri though, we should talk at some point today about that

[sigmundch]

we should additionally filter initializers that we have previously found, otherwise we might report the message unnecessarily on an example like this:

import 'a.dart';
@init
class B extends A {}

a.dart:

@init
class A {}

[sigmundch]

(to clarify - the current check seems to be finding the super initializer, but is not excluding those that don't create a cycle)

[jakemac53]

It does cover this inside _filterMetadata

[sigmundch]

ah nice, sorry, I totally missed that. Thanks for the clarification

[sigmundch]

ok, I think I just finished the second pass :)

[jakemac53]

ok, ready for another look. I also added in the stuff we talked about with regards to ordering file imports by their relative uri to more closely match what the user typed.

[sigmundch]

after our discussion earlier, should we rename this to just Initializer? If so, should we rename initialize as run?

[jakemac53]

I think I will leave that rename for a followup cl

[sigmundch]

LGTM! Besides the comment about clustering package before file urls, I think we are good!