PR# 10471 expanded conformance to any broken in TUPLE.valid_type_for_index

According to the new semantics, LINKED_LIST [INTEGER] conforms to LINKED_LIST [ANY]. This works in the most recent version of ISE Eiffel (5.7.59914 GPL) as demonstrated below by the first assignment statement.

Correspondingly TUPLE [INTEGER] conforms to TUPLE [STRING]. This also works as demonstrated below by the second assignment statement.

What does not work is to ask a TUPLE [LINKED_LIST [ANY]] whether one can put a LINKED_LIST [INTEGER] as its first element. (One obviousy should). The check instruction below fails though.

My guess is that eif_gen_conf needs to be adapted to the new semantics, but I never looked at the function yet, so I could be terribly wrong (;

many thanks in advance,
Andreas
PS: Btw, I have it the priority Critical, because for me (AutoTest, Erl-G) it is a show stopper.

	execute is
		local
			ll_int: LINKED_LIST [INTEGER]
			ll_any: LINKED_LIST [ANY]
			t_ll_any: TUPLE [LINKED_LIST [ANY]]
			t_ll_int: TUPLE [LINKED_LIST [INTEGER]]
		do
			create ll_int.make
			ll_any := ll_int
			t_ll_any := [ll_int]
			create t_ll_any
			check
				t_ll_any.valid_type_for_index (ll_int, 1)
			end
		end

This is not going to be fixed in the 5.7 release as it requires a lot of work for little benefit for our users. But we will implement it as part of our work on the ECMA conformance.

Ah, I see. Do you plan to fix this for 5.7 or is this going to be part of a later release?

many thanks in advance,
Andreas

Reattachment of an object of a generic type with an expanded parameter to a variable of a generic type with a reference parameter is not supported, but this is not caught at run-time at the moment.

I just checked the content of eif_gen_conf in gen_conf.c from  SVN head and it contains the following code:


if (EIF_IS_EXPANDED_TYPE(System(eif_cid_map[ttype]))) {
		/* Expanded target no conformance because types are different */
		return 0;
	}

Which is probably the source of the problem.