ok, taking a look
On Tue, Jun 9, 2015 at 11:38 AM, 'Roberto Lublinerman' via GWT Contributors
wrote:
> I tweaked the code a bit and now it should never output duplicated class
> literals. @Ray, Could you review the patch?
>
> On Tue, Jun 9, 2015 at 10:31 AM, 'Ray Cromwell' via GWT Contributors
I tweaked the code a bit and now it should never output duplicated class
literals. @Ray, Could you review the patch?
On Tue, Jun 9, 2015 at 10:31 AM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> I don't think it's an issue that blocks since peop
I don't think it's an issue that blocks since people are most likely to use
SDM in uncompiled mode, and the 'error' can always be suppressed and turned
into a warning. At best, it might inhibit a const optimization in Closure
where it sees the same variable declared/assigned twice I think.
On Tue
SDM expects that classes/interfaces get generated as a whole either all of
it or none. As you know, class literals are not really part of the class
but they are field in a separate synthetic class). Even SDM (with all
optimizations off, no pruning at UnifyAST) if a reference to the class
literal is
I have uploaded the real fix for review at
https://gwt-review.googlesource.com/#/c/12920.
It should fix your situation but could you verify?
On Tue, Jun 9, 2015 at 10:08 AM, 'Chris DiGiano' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> Roberto, if it's any hi
Roberto, if it's any hint to the underlying problem: you're right that that
the class is not reference anywhere else—it is used solely for the purpose
of type coercion.
Chris
On Tue, Jun 9, 2015 at 10:48 AM 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wr
Chris,
My change actually fixed a bug which may have obscured a problem. There
were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closur
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend we
proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried restarting
the code server and clearing the cache. This did not fix t
This might be due to the way we handle class literals. Class literals for
interfaces if not referenced during the initial compile might cause that
error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and st
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell wrote:
> Try rolling back this CL and see if it fixes it (
> https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/sv
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano wrote:
> I'm having trouble re
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement("dialog", PolymerDialog.class).open();
Unfort
12 matches
Mail list logo
