Changes

update to mwe(2) 1.11.0/2.17.0 M0

Signed-off-by: Christian Dietrich <christian.dietrich.opensource@gmail.com>

switch to  Xtext M0 for bootstrapping

Signed-off-by: Christian Dietrich <christian.dietrich.opensource@gmail.com>

use workaround also in latest

Signed-off-by: Christian Dietrich <christian.dietrich.opensource@gmail.com>

added generator as a source folder

emf.codegen.ecore dependency

Otherwise the "Generator" class cannot be found.

added MWE2 file

added DirectoryCleaner

renaming

regenerated classes

only a white space difference

removed old Java generator

restored GenerateXbase

regenerated classes

only a white space difference

removed generator from src.excludes

bin.excludes of generator folder in Xbase

Revert "removed old Java generator"

This reverts commit f8b3fd3a6f08d3cab73f77ef658e503504294a81.

renamed Java generator

removed MWE2 file

bin.excludes of generator folder in Common Types

Xtend: fixed strange error message for `void` as a field type

Xtend PerformanceTest in Java

Harden bundle constraints between Xtext bundles (#2892)

* Harden constraints between Xtext bundles

Since we don't do any semantic versioning in Xtext, it's safest to
assume that all bundles always require the latest version of their
peers.

* Export all packages as versioned packages

This should allow clients to use import-package instead of
require-bundle for their Xtext dependencies

* Bump bogus version number of xtext.logging fragment
* Fixes to MergableManifest, added Java-based update script

Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>

Remove redundant bundle requirements that are already fulfilled due to re-exports (#2893)

* Reduced number of Guava bundle requirements to guide the OSGI resolver
* Removed redundant require-bundle entries for xtext.util

It's re-exported from org.eclipse.xtext and thus the additional
bundle requirement makes it harder for the OSGI resolver to find
solutions (as counter-intuitive as it sounds)

* Marked xtend.lib as non-optional in xtext.core

In fact it wasn't optional at all since it brought the xbase libraries
into the class path which are used throughout the entire bundle code.

Also xtext.util has already a mandatory dependency on xtend.lib so it
does no harm to require it from xtext.

* Removed redundant bundle requirements to com.google.inject

It's re-exported from xtext.util and thereby transitively by xtext

Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>

Keep the filter-chain consistent when using the LoggingTester

Manipulating the next-pointer of the linked list is error-prone
and corrupted the filter chain. It's safer to re-create the filter chain
from scratch by calling addFilter again.

Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>

don't retrieve the ImportManager by reflection

Since we already assume that the import manager is part of the
appendable, which is a TreeAppendable, I think it's better to do the
case and expose getImportManager in TreeAppendable than to call that
method with two reflective calls.
This would also allow clients to provide a custom TreeAppendable; with
the reflective call this latter use-case would not be supported

Removed cyclic dependency to mwe2.launch (#2897)

Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>

Fixed type common super type computation when type params are involved (#2894)

Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>

simplified appendConstructedTypeName

use getNamedType instead of manually retrieving the last element of
supertypes

canCompileToJavaAnonymousClass

check isAnonymousClassConstructorCall

Xtend uses canCompileToJavaAnonymousClass

simplified isVariableDeclarationRequired

simplified isVariableDeclarationRequired 2

isVariableDeclarationRequired for constructor in Xbase

removed duplication by constructorCallToJavaExpression

instead of redefining _toJavaStatement we redefine
constructorCallToJavaExpression and we call it also in other parts

reduced visibility of some methods

when redefining them it's useless to make them public; when used
internally, make them private

private -> protected (restored visibility)

Added an Xtend validator test for cycles in internal types

also verify the error's position for hierarchy cycles

also verify error's position for INTERFACE_EXPECTED

also verify error's position for OVERRIDDEN_FINAL

also verify error's position for CLASS_EXPECTED

also verify error's position for field INVALID_USE_OF_TYPE

also verify error's position for parameter INVALID_USE_OF_TYPE

fixed verify error's position for parameter INVALID_USE_OF_TYPE

also verify error's position for DUPLICATE_PARAMETER_NAME

also verify error's position for duplicates

also verify error's position for duplicate methods

also verify error's message parts for duplicate methods

added missing tests for doCheckOverriddenMethods

also verify error position for CONFLICTING_DEFAULT_METHODS

also verify error position for CLASS_MUST_BE_ABSTRACT

also verify error position for ANONYMOUS_CLASS_MISSING_MEMBERS

also verify error position for anonymous class override final class

added test with anonymous class not implementing abstract methods

also verify error position for constructors' errors

also verify error position for anonymous class' members