the bug here has been for long time already, 
sometimes SDM woks, sometimes not and yo have to rebuild with temp-clean
this is not C++ compiler

суббота, 17 декабря 2016 г., 4:24:31 UTC+3 пользователь Nándor Előd Fekete 
написал:
>
> Well, yes, of course, I can always start from scratch, but that's around 
> 3+ minutes (it's a bigger project), which is worse than what I currently 
> do, "touching" the Java source file that the compiler is having problem 
> generating correct code for. The biggest problem is that it's breaking my 
> workflow, and I'd rather spend some time finding a probable bug in the 
> compiler itself and give back to the community by fixing it than constantly 
> working around the issue.
>
> On Saturday, December 17, 2016 at 2:11:09 AM UTC+1, Kirill Prazdnikov 
> wrote:
>>
>> mvn clean and clean temp folder before compile will help
>>
>>
>>  суббота, 17 декабря 2016 г., 0:49:30 UTC+3 пользователь Nándor Előd 
>> Fekete написал:
>>>
>>> Hi!
>>>
>>> I have this strange problem in SDM, where a method in the generated 
>>> output JS gets defined under a name, but gets referenced under another name.
>>>
>>> I'll try to show it through actual compiled JS code vs original code.
>>>
>>> function *getBoundingClientRect_3_g$*(this$static_0_g$, 
>>> withinOffsetParent_0_g$){
>>>   $clinit_ElementOverlayMixin_0_g$();
>>>   var deltaX_0_g$, deltaY_0_g$, offsetParent_0_g$, parentBCR_0_g$;
>>>   offsetParent_0_g$ = $getOffsetParent_0_g$(this$static_0_g$);
>>>   if (is_4_g$(offsetParent_0_g$)) {
>>>     parentBCR_0_g$ = 
>>> *$getBoundingClientRect_2_g$*(as_58_g$(offsetParent_0_g$), 
>>> true);
>>>     deltaY_0_g$ = $getScrollTop_0_g$(offsetParent_0_g$) - 
>>> parentBCR_0_g$.getTop_15_g$();
>>>     deltaX_0_g$ = $getScrollLeft_0_g$(offsetParent_0_g$) - 
>>> parentBCR_0_g$.getLeft_16_g$();
>>>   }
>>>    else {
>>>     deltaY_0_g$ = getScrollTop_4_g$();
>>>     deltaX_0_g$ = getScrollLeft_6_g$();
>>>   }
>>>   return 
>>> withinOffsetParent_0_g$?$getBoundingClientRect_1_g$(this$static_0_g$).translated_1_g$(deltaX_0_g$,
>>>  
>>> deltaY_0_g$):$getBoundingClientRect_1_g$(this$static_0_g$);
>>> }
>>> getBoundingClientRect_3_g$.displayName = 
>>> 'ElementOverlayMixin.$getBoundingClientRect';
>>>
>>>
>>> This is the original Java source of the method:
>>>
>>> public final ClientRect *getBoundingClientRect*(boolean 
>>> withinOffsetParent) {
>>> float deltaY;
>>> float deltaX;
>>> Element offsetParent = getOffsetParent();
>>> if (Element.is(offsetParent)) {
>>> ClientRect parentBCR = ElementOverlayMixin.as(offsetParent).
>>> *getBoundingClientRect*(true);
>>> deltaY = offsetParent.getScrollTop() - parentBCR.getTop();
>>> deltaX = offsetParent.getScrollLeft() - parentBCR.getLeft();
>>> } else {
>>> deltaY = Window.getScrollTop();
>>> deltaX = Window.getScrollLeft();
>>> }
>>> return withinOffsetParent ? getBoundingClientRect().translated(deltaX, 
>>> deltaY) : getBoundingClientRect();
>>> }
>>>
>>> I've highlighted the important parts with bold+red/green. Note that it's 
>>> a recursive method invoking itself on another object. In the generated 
>>> output, the name of the function in the function declaration and the name 
>>> used while referring to the same function is different.
>>>
>>> After a "touch" on the source code file, the compiler now generates the 
>>> correct JS output:
>>>
>>> function *$getBoundingClientRect_2_g$*(this$static_0_g$, 
>>> withinOffsetParent_0_g$){
>>>   $clinit_ElementOverlayMixin_0_g$();
>>>   var deltaX_0_g$, deltaY_0_g$, offsetParent_0_g$, parentBCR_0_g$;
>>>   offsetParent_0_g$ = $getOffsetParent_0_g$(this$static_0_g$);
>>>   if (is_4_g$(offsetParent_0_g$)) {
>>>     parentBCR_0_g$ = 
>>> *$getBoundingClientRect_2_g$*(as_58_g$(offsetParent_0_g$), 
>>> true);
>>>     deltaY_0_g$ = $getScrollTop_0_g$(offsetParent_0_g$) - 
>>> parentBCR_0_g$.getTop_15_g$();
>>>     deltaX_0_g$ = $getScrollLeft_0_g$(offsetParent_0_g$) - 
>>> parentBCR_0_g$.getLeft_16_g$();
>>>   }
>>>    else {
>>>     deltaY_0_g$ = getScrollTop_4_g$();
>>>     deltaX_0_g$ = getScrollLeft_6_g$();
>>>   }
>>>   return 
>>> withinOffsetParent_0_g$?$getBoundingClientRect_1_g$(this$static_0_g$).translated_1_g$(deltaX_0_g$,
>>>  
>>> deltaY_0_g$):$getBoundingClientRect_1_g$(this$static_0_g$);
>>> }
>>>
>>> $getBoundingClientRect_2_g$.displayName = 
>>> 'ElementOverlayMixin.$getBoundingClientRect';
>>>
>>> I'm using incremental mode, but I think it happened on the first 
>>> compilation too with all previous compilation caches cleared.
>>>
>>> Do you guys have any tips on where to look in the compiler code where 
>>> the method name handling / mangling happens?
>>>
>>> Many thanks!
>>>
>>> Nandi.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to