[jira] [Created] (GROOVY-7719) Generic type incompatibility not detected for method called on field
Frank Pavageau created GROOVY-7719:
--
Summary: Generic type incompatibility not detected for method
called on field
Key: GROOVY-7719
URL: https://issues.apache.org/jira/browse/GROOVY-7719
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 2.4.5
Reporter: Frank Pavageau
Assignee: Cédric Champeau
While reading the test case for GROOVY-5839, I noticed it did not actually
match the reported problem, which is about a method-level generic type
shadowing a class-level generic type. However, the real problem is that the
code compiles even without the shadowing of the generic type of the class by
the method:
{code}
class GoodCodeRed {
Collection attached = []
public void attach(GoodCodeRed toAttach) {
attached.add(toAttach)
}
}
def g1 = new GoodCodeRed()
def g2 = new GoodCodeRed()
g1.attach(g2)
{code}
{{T}} and {{U}} are unrelated, the {{attached.add(toAttach)}} call should not
compile.
Once that is fixed, we can see if the shadowing of the type is also an issue,
simply by renaming {{U}} to {{T}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (GROOVY-4249) Create "AspectG" to provide first class integration with AspectJ
[ https://issues.apache.org/jira/browse/GROOVY-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed GROOVY-4249. - Resolution: Won't Fix As there was no discussion of or work done on this issue in over 5 years, I'm closing it. > Create "AspectG" to provide first class integration with AspectJ > > > Key: GROOVY-4249 > URL: https://issues.apache.org/jira/browse/GROOVY-4249 > Project: Groovy > Issue Type: New Feature >Reporter: Matthew T. Adams > > See discussions at > http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg12186.html > and > http://groovy.329449.n5.nabble.com/AspectG-tp396059p396059.html > * Support aspects woven via ajc at compile time to Groovy classes compiled > via groovyc (may already be supported) > * Enhance Groovy's MOP to be aware of applicable AspectJ aspects in order to > support aspects dynamically at run time > This issue is related to the AspectJ issue > https://bugs.eclipse.org/bugs/show_bug.cgi?id=317060 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7454) [Static type checking] - Reference to method is ambiguous
[
https://issues.apache.org/jira/browse/GROOVY-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15069635#comment-15069635
]
Pascal Schumacher edited comment on GROOVY-7454 at 12/23/15 1:52 PM:
-
Thanks Frank and everybody else who contributed. :)
was (Author: pascalschumacher):
Thanks to everybody who contributed. :)
> [Static type checking] - Reference to method is ambiguous
> -
>
> Key: GROOVY-7454
> URL: https://issues.apache.org/jira/browse/GROOVY-7454
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.3
>Reporter: Christopher Smith
>
> This issue has a number of seeming duplicates marked as "fixed", but I'm
> reliably seeing it in 2.4.3 when calling `findAll()` on any Spring
> `CrudRepository`:
> {code}
> Groovy:[Static type checking] - Reference to method is ambiguous. Cannot
> choose between [java.util.List
> org.springframework.data.mongodb.repository.MongoRepository#findAll(),
> java.util.List
> org.springframework.data.mongodb.repository.MongoRepository#findAll()]
> {code}
> No idea whether this is triggered in particular by the name of the method,
> which Groovy defines on {{Object}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (GROOVY-5506) Saving the current script under the MacOS X console triggers a new window
[ https://issues.apache.org/jira/browse/GROOVY-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed GROOVY-5506. - Resolution: Incomplete I'm closing this for now. Please reopen if still relevant. Thanks! > Saving the current script under the MacOS X console triggers a new window > - > > Key: GROOVY-5506 > URL: https://issues.apache.org/jira/browse/GROOVY-5506 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 2.0-rc-2 >Reporter: Guillaume Balaine > > On Mac OS X using the JDK 7 Applet plugin, saving a script file triggers a > new save as popup window instead of updating the already saved script file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (GROOVY-3963) GroovyConsole windows should be their own process
[ https://issues.apache.org/jira/browse/GROOVY-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed GROOVY-3963. - Resolution: Won't Fix I'm closing this after Johns comment. > GroovyConsole windows should be their own process > - > > Key: GROOVY-3963 > URL: https://issues.apache.org/jira/browse/GROOVY-3963 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 1.7.0 > Environment: Tested on Windows XP >Reporter: Keegan Witt >Priority: Minor > > The output is shared between GroovyConsole windows created from the same > process, since requesting a new window doesn't create a new process. > Steps to reproduce: > 1. Open a new console window (ctrl + shift + n) > 2. Cause some output to be generated > 3. Observe output in original window > The output of that script will be displayed on all console windows created in > the (ctrl + shift + n) way but not when it is launched as a new process. I > believe the latter behavior to be preferable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7454) [Static type checking] - Reference to method is ambiguous
[
https://issues.apache.org/jira/browse/GROOVY-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15069503#comment-15069503
]
Frank Pavageau commented on GROOVY-7454:
This issue should be resolved, since it's the same as GROOVY-7420 for which the
fix has been merged.
> [Static type checking] - Reference to method is ambiguous
> -
>
> Key: GROOVY-7454
> URL: https://issues.apache.org/jira/browse/GROOVY-7454
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.3
>Reporter: Christopher Smith
>Assignee: Cédric Champeau
>
> This issue has a number of seeming duplicates marked as "fixed", but I'm
> reliably seeing it in 2.4.3 when calling `findAll()` on any Spring
> `CrudRepository`:
> {code}
> Groovy:[Static type checking] - Reference to method is ambiguous. Cannot
> choose between [java.util.List
> org.springframework.data.mongodb.repository.MongoRepository#findAll(),
> java.util.List
> org.springframework.data.mongodb.repository.MongoRepository#findAll()]
> {code}
> No idea whether this is triggered in particular by the name of the method,
> which Groovy defines on {{Object}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GROOVY-7720) Type incompatibility of generic placeholders not detected on assignment
Frank Pavageau created GROOVY-7720:
--
Summary: Type incompatibility of generic placeholders not detected
on assignment
Key: GROOVY-7720
URL: https://issues.apache.org/jira/browse/GROOVY-7720
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 2.4.5, 2.4.0
Reporter: Frank Pavageau
Assignee: Cédric Champeau
It looks like the issue in GROOVY-7719 can be generalized, because the
following compiles:
{code}
class Foo {
public void set(U value) {
T localValue = value
}
}
def foo = new Foo()
foo.set(new Object())
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7719) Type incompatibility of generic placeholders not detected for method called on field
[
https://issues.apache.org/jira/browse/GROOVY-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Pavageau updated GROOVY-7719:
---
Summary: Type incompatibility of generic placeholders not detected for
method called on field (was: Generic type incompatibility not detected for
method called on field)
> Type incompatibility of generic placeholders not detected for method called
> on field
>
>
> Key: GROOVY-7719
> URL: https://issues.apache.org/jira/browse/GROOVY-7719
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.5
>Reporter: Frank Pavageau
>Assignee: Cédric Champeau
>
> While reading the test case for GROOVY-5839, I noticed it did not actually
> match the reported problem, which is about a method-level generic type
> shadowing a class-level generic type. However, the real problem is that the
> code compiles even without the shadowing of the generic type of the class by
> the method:
> {code}
> class GoodCodeRed {
> Collection attached = []
> public void attach(GoodCodeRed toAttach) {
> attached.add(toAttach)
> }
> }
> def g1 = new GoodCodeRed()
> def g2 = new GoodCodeRed()
> g1.attach(g2)
> {code}
> {{T}} and {{U}} are unrelated, the {{attached.add(toAttach)}} call should not
> compile.
> Once that is fixed, we can see if the shadowing of the type is also an issue,
> simply by renaming {{U}} to {{T}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7720) Type incompatibility of generic placeholders not detected on assignment
[
https://issues.apache.org/jira/browse/GROOVY-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15069515#comment-15069515
]
Frank Pavageau commented on GROOVY-7720:
Here's a fun variant as well:
{code}
class Converter {
public U convert(T value) {
value
}
}
def converter = new Converter()
Integer i = converter.convert(new Object())
{code}
It compiles, but fails at runtime:
{noformat}
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
object 'java.lang.Object@337d44e4' with class 'java.lang.Object' to class
'java.lang.Integer'
{noformat}
> Type incompatibility of generic placeholders not detected on assignment
> ---
>
> Key: GROOVY-7720
> URL: https://issues.apache.org/jira/browse/GROOVY-7720
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.0, 2.4.5
>Reporter: Frank Pavageau
>Assignee: Cédric Champeau
>
> It looks like the issue in GROOVY-7719 can be generalized, because the
> following compiles:
> {code}
> class Foo {
> public void set(U value) {
> T localValue = value
> }
> }
> def foo = new Foo()
> foo.set(new Object())
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request: GROOVY-6787 Compare arguments with the generi...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/221 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-6787) type checker does not check generics bounds of wildcards properly
[
https://issues.apache.org/jira/browse/GROOVY-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15069401#comment-15069401
]
ASF GitHub Bot commented on GROOVY-6787:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/221
> type checker does not check generics bounds of wildcards properly
> -
>
> Key: GROOVY-6787
> URL: https://issues.apache.org/jira/browse/GROOVY-6787
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.2.2, 2.3.0, 2.4.0-rc-1
>Reporter: Jochen Theodorou
>
> {code:Java}
> public > void bar(T a){}
> bar([new Object()])
> {code}
> This should not compile because Object is no CharSequence, but it does,
> because the type checker will simply ignore the bound and set T to
> LinkedList
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-6787) type checker does not check generics bounds of wildcards properly
[
https://issues.apache.org/jira/browse/GROOVY-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved GROOVY-6787.
---
Resolution: Fixed
Assignee: Pascal Schumacher
Fix Version/s: 2.4.6
Pull request merged. Thanks!
> type checker does not check generics bounds of wildcards properly
> -
>
> Key: GROOVY-6787
> URL: https://issues.apache.org/jira/browse/GROOVY-6787
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.2.2, 2.3.0, 2.4.0-rc-1
>Reporter: Jochen Theodorou
>Assignee: Pascal Schumacher
> Fix For: 2.4.6
>
>
> {code:Java}
> public > void bar(T a){}
> bar([new Object()])
> {code}
> This should not compile because Object is no CharSequence, but it does,
> because the type checker will simply ignore the bound and set T to
> LinkedList
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
