private member name mangling breaks in unchecked mode

[efortuna]

The CL here: https://chromiumcodereview.appspot.com/9621001

unfortunately does not behave quite as expected in unchecked mode. Try running:

tools/test.py -m release -c frogium client/samples/smoketest

The test will fail. We're not seeing this breakage on the buildbots because we're running all of them in checked mode! (I'll change that once this is fixed) If you run the same test with the "--checked" flag, the test will pass.

All of my performance tests on all browsers are broken until the change is fixed. :-(

It looks like in this test, DoubleLinkedQueueEntry has a field called _element, which gets "renamed" to the unique name _dart_coreimpl_element, but the new name doesn't propagate to later references to the field in other methods.

[rakudrama]

I understand the problem.
Concrete classes and their members are created on demand during codegen.

1. add corelib DoubleLinkedQueueEntry._element
2. add otherlib XXX._element, rename to _otherlib_element
   codegen:
3. generate code using DoubleLinkedQueueEntry._element --- the cat is out of the bag
4. generate demand for DoubleLinkedQueueEntry<Foo>
5. add corelib DoubleLinkedQueueEntry<Foo>._element, rename to _dart_corelib_element

The process of renaming incrementally is somewhat unpredictable. Given libA.ClassX._foo and libB.ClassY._foo, one or both could be renamed depending on the order in which the private members are added to the libraries.

I see three ways out of this:

1. A global flag that disables the renaming during codegen. Hacky.
2. Rename the current field in all the libraries, not just the current one. This has the disadvantage that no library gets the short version of the name.
3. Write a small pass to do the renaming just before codegen (or analysis?)

I think #­3 is the best option, and probably not much more code than the current code, just in a different place.
The libraries can be visited in priority order, giving the first library with the name the short version, extending the names only in subsequent libraries with a clash. I would prioritize the main library so we don't mess with the user's main program.
Doing it all in one small pass will also let us prevent clashes between private fields that look too much like renamed fields. There is currently no check that the prefixed name is not also user defined field name.

[rakudrama]

Fix available: https://chromiumcodereview.appspot.com/9656003

Kasper, I have to go home now. Can you land this or something like it to unblock us?

[kasperl]

Thanks, Stephen. Fix landed in r5217.

---

Added Fixed label.