On 9/8/18, 10:05 AM, "Harbs" <harbs.li...@gmail.com> wrote:
I should have included a full explanation in my email.
I tried {…*} but I got the same error as with {…}.
{*} is not technically right as the arguments after the first is not
declared, but I tested trace with multiple arguments with the change and the
closure compiler did not complain. It’s the closest annotation I could come up
with that does not cause the error. (i.e. the first argument is required) I
can’t think of any downsides of leaving the rest of the arguments out. Can you
think of an issue with it?
If Closure Compiler did not notice that there were extra arguments, some day
they might fix it so it does notice. We should annotate our code correctly.
Maybe a better fix is to update the closure compiler? Not sure…
IIRC, you recently added some code to the compiler to clean out empty CSS
selectors in release mode. I wonder if there is a way to special case trace
and rewrite it in a way that Closure Compiler will know to remove it. Like
remove every line of code or every line of code after the rest handling.
I just wanted to fix the build in the meantime.
I do not wish to see us release with the wrong annotations. But feel free to
hack the final output code.
Suggestions?
Harbs
> On Sep 7, 2018, at 7:14 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> The fix does not look right to me. Here are a link that indicates that
variable number of arguments should be using "...".
>
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=jY1qMvlQPbXRJqTXanp6WLVxi9v5AvP%2BTUF38HiqDA8%3D&reserved=0>
>
> This link indicates that the annotation for trace should be {...*}
>
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F25474311%2Fannotating-zero-or-more-parameters-with-any-type-for-google-closure-compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F25474311%2Fannotating-zero-or-more-parameters-with-any-type-for-google-closure-compiler&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=heE3Aayf8LufbLIJwBJGXXDewL2J%2FquKX6R9wTGHPEg%3D&reserved=0>
>
> What document led you to believe you could just use {*}, which indicates
only one parameter.
>
> Thanks,
> -Alex
>
> On 9/7/18, 1:55 AM, "Harbs" <harbs.li...@gmail.com
<mailto:harbs.li...@gmail.com>> wrote:
>
> I just committed a fix for this.
>
> We can discuss further, but at least the build should work…
>
>> On Sep 7, 2018, at 10:55 AM, Carlos Rovira <carlosrov...@apache.org>
wrote:
>>
>> Right, I'm seeing as well JewelExample failing on compile
>>
>> thanks
>>
>> El vie., 7 sept. 2018 a las 9:13, Harbs (<harbs.li...@gmail.com>)
escribió:
>>
>>> I’m saying that a param defined as {…} confuses the closure compiler
when
>>> you have the rest redefined as an array anywhere but the first line of
the
>>> function. It seems like a bug in the closure compiler.
>>>
>>> Changing:
>>> rest = Array.prototype.slice.call(arguments, 0);
>>> to:
>>> var rest = Array.prototype.slice.call(arguments, 0);
>>>
>>> also makes the error go away, but we do get a reassignment warning.
>>>
>>> I’m not sure what declaring a @param as {…} actually accomplishes in
terms
>>> of type checking.
>>>
>>>> On Sep 7, 2018, at 10:02 AM, Alex Harui <aha...@adobe.com.INVALID>
>>> wrote:
>>>>
>>>> Are you saying some recent change to the compiler is now generating:
>>>> @param {...} rest
>>>>
>>>> If so, what changed caused that output? If not, why did it not fail
>>> before?
>>>>
>>>> We should be generating whatever Google says we should generate for
rest
>>> parameters. Although I did ponder the impact of having Royale's trace
not
>>> take extra parameters. Then folks would have to concat strings before
>>> calling trace.
>>>>
>>>> -Alex
>>>>
>>>> On 9/6/18, 11:58 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>
>>>> It looks like the problem is caused by:
>>>> * @param {...} rest
>>>>
>>>> What would happen if we remove the @param or change it to @param {*=}
>>> rest?
>>>>
>>>> Both of those work.
>>>>
>>>>> On Sep 7, 2018, at 8:35 AM, Alex Harui <aha...@adobe.com.INVALID>
>>> wrote:
>>>>>
>>>>> But first, I'm not sure your idea is going to work in all cases. See
>>> if you get the same problem in JewelExample.
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3049de2a8d7c4cfdfd6d08d615ad5849%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636720231590608291&sdata=rbbJA1WE6kM51gJyvUiMRF8%2FNm41wtUo7URuae9jKqE%3D&reserved=0>
