GROOVY-6365: avoid additional wrapping of Object[] into Object[]
GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * must be activated thanks to a type checking extension
   * makeDynamic(call) would turn an unresolved method call into a dynamic method call
   * makeDynamic(call, classNode) would turn an unresolved method call into a dynamic method call returning an object of the classNode type
   * makeDynamic(propertyExpr) would turn an unresolved property into a dynamic property lookup
   * makeDynamic(propertyExpr, classNode) would turn an unresolved property into a dynamic property lookup returning an object of the classNode type
   * makeDynamic(variableExpr) would turn an unresolved variable into a dynamic variable lookup
   * makeDynamic(variableExpr, classNode) would turn an unresolved variable into a dynamic variable lookup returning an object of the classNode type
   * makeDynamic automatically suppresses type checking errors by setting the handled=true flag to true
   * for method calls, makeDynamic returns a dummy MethodNode, allowing to suppress the type checking error

It is expected that the extension writer provided appropriate return types.
GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * make sure Foo.metaClass.bar = {...} can be handled through an extension
   * add buildListType(componentType) and buildMapType(keyType,valueType) for lists/maps (helper method)
   * add isStaticMethodCallOnClass helper method for easier detection of static method calls on a specific receiver type
GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * refactored isStaticMethodCallOnReceiver into two distinct methods
   * introduced extractStaticReceiver(methodCall) for that purpose
GROOVY-6362: Support for dynamic method calls in @CompileStatic
   * fixed dynamic method calls if made inside a closure
   * add a unit test/example on how to deal with builders
Bintray JCenter added as a first resolver in the default Ivy chain.
The resolution should be much faster now: this repo is much faster than the former first resolver (codehaus) and it contains most of the content from most of the popular Java repositories, which means most of the artifacts will be resolved without trying other repositories in the chain.
GROOVY-6379: Wrong example in the api of class Map(dropWhile)
GROOVY-6372: @Immutable fails to recognize non immutable classes (move the simple cases of matching on classname whitelist from runtime to compile time)
GROOVY-6384: add a direct method call logic for Class.forName(x)
GROOVY-6380: Improve Grapes resolution speed and stability by adding Bintray JCenter as first remote resolver in the chain

moved defaultGrapeConfig.xml for tests to correct test resource directory
Improve the grammar of a compiler error message
update copyright year
GROOVY-6357: Inner classes in Groovy should have the same access modifiers as in Java
Fix for GROOVY-6386 - groovyc task throws ZipException when it
encounters classpath resources that are not jars.
GROOVY-6357: Fix the way modifiers are updated
fix 6387: groovysh completion for maps with 'class' entry

Should now work for instances having class member neither null
nor instanceof Class, as long as getClass() returns a Class instance.

See https://jira.codehaus.org/browse/GROOVY-6387

Signed-off-by: Thibault Kruse <kruset@in.tum.de>
useless function call
more code style, using class member instead of getClass Method
GROOVY-6390: Super constructor calls are not made using direct calls but using MOP
   * introduced InvocationWriter#makeSpecialConstructorCall
   * moved code from AsmClassGenerator to InvocationWriter#makeSpecialConstructorCall
   * specialized version of makeSpecialConstructorCall in @CompileStatic mode
GROOVY-6389: groovysh: Print results using toString(), not String.valueOf

Using java.lang.String.valueOf(obj) for instances of Arrays and Maps causes
Object.toString to be used for String generation, causing ugly output in groovysh

This commit uses toString() instead which uses pretty output for collections.

As opposed to an earlier commit for Groovy 2.2, Arrays will be displayed
without their type. Avoiding the GString here because of the earlier code
comment, not sure whether there is any risk using GString here or not
(Comment was from 2007, e222d4f5cf8cc7).