PropertySetterFactory: don't cache property setters globally as this leads to problems in the transformer

[tbosch]

Old (see comments below):
Was: Transformers: Don't set reflector.reflectionCapabilities over an async gap

In generator.dart we first set reflector.reflectionCapabilities, then wait for the compiler to compile and then reset the state. Although the caller of this particular method sequences calls, the call sites of generator.dart don't do this.

This yields to adding setters/getters to the wrong ng_deps.dart files.

Solution:

1. change DomRenderCompiler to have a new method compileSync, which takes a ViewDefinition and a template string. The normal compile method can delegate to this one internally.
2. change generator.dart to first load the template, then set a temporal reflector.reflectionCapabilities, call compiler.compileSync and reset the temporal reflector.reflectionCapabilities.

[tbosch]

@naomiblack I think we should to a patch release for this one, as otherwise transformers are not really usable in Google3...

[kegluneq]

Is it true that getChangeDetectorDefinitions makes the same requests to ReflectionCapabilities as compile does?

This is what this block of asserts was meant to test and so far it's come back clean.

If so, we can use the RecordingReflectionCapabilities in that area to generate our getters, setters, & methods instead, avoiding the async gap.

[tbosch]

I don't think so: The compiler parses expressions and requests getters/setters/methods from the reflector. Also, it requests getters/setters for property bindings. @vsavkin what do you think?

[kegluneq]

A quick test confirms that this strategy won't work.

Another potential option is to use the data structures in the ProtoViewDto returned by compile to figure out which getters, setters, and methods we need to register. This seems a bit more error-prone than actually pulling them out of the ReflectionCapabilities after compile, but avoids playing with global state, which just smells bad.

[tbosch]

After talking to @kegluneq we should do the following:

Don't create a new method on the DomCompiler but use CompilePipeline directly. The long term plan would be switching back to using the DomCompiler and only relying on its result instead of listening to the calls to the reflector.

[tbosch]

The reason for this issue was that in some cases the transpiler did not generate all of the property setters when a ngFor directive was used. It turns out, that the transpiler code is correct (although the code passage in this issue seemed suspicious). I could verify this via print statements that I added into the transformer when it replaces the ReflectionCapabilities.

The real problem is in the property_setter_factory.ts: This is caching property setters in a module global variable. Because of this, even though the transpiler recreated the compiler for every template it only got property setters for e.g. ngForOf only once accross all compiled files of all entry points. Not caching these property setters leads to correctly generated setters for every template by the transpiler (I checked the .ng_deps.dart files).