Background: Not every storedType int is the same if they come from different modules or so?

Background: Otherwise they will throw Exceptions because the class definitions are there but not the type infos

Background: We only checked public nondefault, that matched for public statics as well.
Now checks for public nodefault abstract

Also TODO: Functional Type may not be part of functional Method's signature

Background: If the return type was a generic parameter, that early it wouldn't have been populated yet, and why load the return type as first thing in a method anyways?

Background: Approximate member choosing is based only on the types, so an overridden method would match twice, but with different priority. Fixes this by including a priority check before deciding whether or not to throw an error

Background: For some classes the TypeId does not have the super class but the definition has. Now checking both

Background: Javac creates an ACC_BRIDGE method to deal with the signature change (either a covariant parameter or contravariant return type change).
Hence there are two declared methods, one that is the old one, one that is new. For Signatures where only the return type changed this caused both to be registered and an ambiguity later where ZC could not determine which to choose

Required for Type assertion, else a 'Object is not assignable to X' will follow

Required for lambdas

.. Unless they have 'nope' in their name

This time for nonexpansions.
The method signatures should be calculated correctly now, though they are still only filled with nulls

Was an instance field all along, but always set to null

Now it doesn't select the first nondefault method but the first public nondefault method

Reason behind this is to prevent NoClassDefFoundErrors for working with Sided classes in MCF

Fixed functions not working properly

Let's see if putting them all into one TypeVariableContext works..?

Also, a lambda that returns void cannot conclude the generic header. How should we deal with this?

Before it they would simply return false, even if a type would match the bounds

They used the signature instead of the description, so there was an AIOOB when the compiler tried to cast a 'TT;' as that only exists in signatures, not in descriptions

Is there any reason why not to?

This commit at least fixes that some classes have the same name, e.g. the name of an expansion class and the name of the script block part within the file.

WIP since it still needs more doing and a way to properly store already generated names.

Who would've thought that a 'this' can be a non-object :thinking-face:

Reason: Some iterators use the generated USizeRange which would throw a ClassCastException