Re: [PR] fix(XmlUtil): escapeControlCharacters off-by-one bug [groovy]

2023-10-26 Thread via GitHub


paulk-asert merged PR #1973:
URL: https://github.com/apache/groovy/pull/1973


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (GROOVY-10714) STC: Callable, Runnable, Serializable overload preference for functional argument (closure, lambda, etc.)

2023-10-26 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780034#comment-17780034
 ] 

Eric Milles commented on GROOVY-10714:
--

I have experimented with computing SAM-type distance first for {{Callable}}, 
{{GroovyCallable}} and {{Runnable}}.  Thus their distance would increase to 12 
or 13.  Doing so in the presence of {{Cloneable}}, {{Serializable}}, 
{{GroovyObject}} or {{GroovyObjectSupport}} overloads would be a change in 
selection.  And the current preference of {{Runnable}} over {{Callable}} would 
break without some further adjustment.

This applies equally to closures, lambdas, method pointers and method 
references.  STC treats them all as {{Closure}} in terms of argument type 
during method selection.

> STC: Callable, Runnable, Serializable overload preference for functional 
> argument (closure, lambda, etc.)
> -
>
> Key: GROOVY-10714
> URL: https://issues.apache.org/jira/browse/GROOVY-10714
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 4.0.4
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Minor
>
> This appears to be similar to GROOVY-9881, but it's specifically in the 
> method-overload procedure. Given a functional value type with two method 
> overloads:
> {code}
> interface Try {
>   Try andThenTry(Consumer)
>   Try andThenTry(Runnable)
> }
> {code}
> When this code is invoked from static code, the STC errors out on an 
> ambiguous method reference even if the method type isn't:
> {code}
> // AWS SDK 2 DynamoDbTable
> class DynamoDbTable {
>   void putItem(PutItemRequest)
>   void putItem(Consumer)
>   void putItem(T)
> }
> @CompileStatic
> class MyServiceClass {
>   void doThing() {
> Try.success(putItemRequest())
>   .andThenTry(table::putItem) // T for Try is PutItemRequest
>   }
> }
> {code}
> produces
> {code}
> [Static type checking] - Reference to method is ambiguous. Cannot choose 
> between [Try Try#andThenTry(Consumer), Try 
> Try#andThenTry(Runnable)]
> {code}
> I think this may have something to do with the relaxed SAM matching that is 
> used to bridge ambiguous closure syntax, but when a plain method reference is 
> used, there's no ambiguity available.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-10714) STC: Callable, Runnable, Serializable overload preference for functional argument (closure, lambda, etc.)

2023-10-26 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780030#comment-17780030
 ] 

Eric Milles commented on GROOVY-10714:
--

GROOVY-6189 links to GEP-12, which specifically mentions that types implemented 
by {{Closure}} represent a coercion-free match and so are preferred over 
SAM-type overloads.

For reference, the distance computed between {{Closure}} and several 
interesting types are currently as follows:
||Type||Argument-Parameter Distance||
|Closure|0|
|Cloneable|1|
|Serializable|1|
|GroovyCallable|1|
|Callable|2|
|Runnable|1|
|GroovyObject|1|
|GroovyObjectSupport|4|
|Object|14|
|SAM-type|13 or 12 (if param count helps)|

> STC: Callable, Runnable, Serializable overload preference for functional 
> argument (closure, lambda, etc.)
> -
>
> Key: GROOVY-10714
> URL: https://issues.apache.org/jira/browse/GROOVY-10714
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 4.0.4
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Minor
>
> This appears to be similar to GROOVY-9881, but it's specifically in the 
> method-overload procedure. Given a functional value type with two method 
> overloads:
> {code}
> interface Try {
>   Try andThenTry(Consumer)
>   Try andThenTry(Runnable)
> }
> {code}
> When this code is invoked from static code, the STC errors out on an 
> ambiguous method reference even if the method type isn't:
> {code}
> // AWS SDK 2 DynamoDbTable
> class DynamoDbTable {
>   void putItem(PutItemRequest)
>   void putItem(Consumer)
>   void putItem(T)
> }
> @CompileStatic
> class MyServiceClass {
>   void doThing() {
> Try.success(putItemRequest())
>   .andThenTry(table::putItem) // T for Try is PutItemRequest
>   }
> }
> {code}
> produces
> {code}
> [Static type checking] - Reference to method is ambiguous. Cannot choose 
> between [Try Try#andThenTry(Consumer), Try 
> Try#andThenTry(Runnable)]
> {code}
> I think this may have something to do with the relaxed SAM matching that is 
> used to bridge ambiguous closure syntax, but when a plain method reference is 
> used, there's no ambiguity available.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (GROOVY-11208) No parse error for interface method with default value

2023-10-26 Thread Eric Milles (Jira)
Eric Milles created GROOVY-11208:


 Summary: No parse error for interface method with default value
 Key: GROOVY-11208
 URL: https://issues.apache.org/jira/browse/GROOVY-11208
 Project: Groovy
  Issue Type: Bug
  Components: parser-antlr4
Reporter: Eric Milles


I noticed this syntax mentioned here: https://groovy.apache.org/wiki/GEP-12.html

Is this supposed to be valid for some case or is it defunct?
{code:groovy}
interface I {
  def m() default { 1 }
}
{code}

It does not produce any parser or compiler errors.  But I don't think the 
default value saved in {{MethodNode}} is used for anything.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-6189) basic SAM conversion

2023-10-26 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-6189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780026#comment-17780026
 ] 

Eric Milles commented on GROOVY-6189:
-

Doc is now here: https://groovy.apache.org/wiki/GEP-12.html

> basic SAM conversion
> 
>
> Key: GROOVY-6189
> URL: https://issues.apache.org/jira/browse/GROOVY-6189
> Project: Groovy
>  Issue Type: Sub-task
>Reporter: Jochen Theodorou
>Assignee: Jochen Theodorou
>Priority: Major
> Fix For: 2.2.0-beta-1
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: [PR] fix(XmlUtil): escapeControlCharacters off-by-one bug [groovy]

2023-10-26 Thread via GitHub


pinicarus commented on PR #1973:
URL: https://github.com/apache/groovy/pull/1973#issuecomment-1780972154

   > It would be better if you could provide the related test as well.
   
   I added the range bounds to the existing test


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org