Hmm, this could present quite a huge problem, with this in place, dozens of tests in Weld TS fail - basically anything that requires a subclass and a proxy (intercepted/decorated normal scoped beans) will crash.

The generation of subclasses doesn't take into consideration this information at all as it was never present until now.

Funny thing is, the exception you are seeing is a result of a call on a generated method (in subclass), where Method.getGenericReturnType() returns null, which according to javadoc shouldn't happen.

For instance this method (added into proxies) is with CFW 1.2.4 represented as

public Object weld_getTargetInstance()

with no signature attached.

Whereas with CFW 1.2.5 (snapshot) this translates to

public T weld_getTargetInstance()

and the signature is (from bytecode) Signature: #240 // ()TT;.

With some debugging during creation of the aforementioned method with CFW 1.2.5, I can see that the method added has return type Ljava/lang/Object; but after creating it, you now set it the signature of the previous method which conflicts in the return type. Later on, when using reflections to getGenericReturnType(), it checks for signature and because that is found, it tries to do return getGenericInfo().getReturnType(); however CFW never sets that information, hence it blows up.
Tomasz Adamski are you sure the fix you did on CFW side is enough to add signatures into methods properly? I am certainly not an expert on this but not being able to read the generated method via reflections smells a bit fishy.