[Bug translator/16097] improve error message on array type mismatch

["jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16097

--- Comment #2 from Jonathan Lebon <jlebon at redhat dot com> ---
OK, I made a bit more research into this. I think I understand the reason we do
not get the right tokens printed.

Here is the summary of it:

- In the simple example in comment 1, the global 'array' is inferred type
pe_long, while 'array[1]' is inferred as type pe_string. There's a conflict and
resolve_2types() calls mismatch() with array[1] as the offending token (and
user is happy).
- In the original example in the description, the global 'array' is inferred
type pe_long, then the function call 'str_ret_type()' is inferred the type
pe_string. resolve_2types() reports a conflict between the expected type t
(which is pe_string) and the global 'array' (which is pe_long) BEFORE
'array[1]' ever gets the chance of being resolved. So we print the global
declaration as the offending token (and user is confused).

And here is the longer answer:

Let's look at the simple example in comment 1:

global array

probe begin {            
   array[0] = 1
   array[1] = "string" 
}

Note that 1 and "string" are literals and will already have their types set to
pe_long/pe_string before even the first iteration of the main loop in
semantic_pass_types().

Here is the order of 'interesting' things that happen:
- On the first iteration, the left side of the first assignment (i.e.
'array[0]') is inferred type pe_long, since the right side is a literal number.
- Still on the first iteration, the left side of the second assignment (i.e.
'array[1]') is inferred type pe_string, since the right side is a literal
string.
- On the second iteration, the referent of array[0] (i.e. the global
declaration 'array') is inferred type pe_long, since 'array[0]' is of type
pe_long.
- Still on the second iteration,  upon visiting the left side of the second
assignment (i.e. 'array[1]'), resolve_2types() detects the mismatch between
referrer type ('array[1]' is pe_string) and referent (global 'array' is
pe_long) and calls mismatch
- Thus, we will get the right token ('array[1]') printed out

Now consider the original example in the description:

global array

function str_ret_type() {
   return "hi"
}

probe begin {
   array[0] = 1
   array[1] = str_ret_type()
}

Here is the order of events:

- On the first iteration, the function str_ret_type() is visited and is
inferred type pe_string from the return statement.
- Still the first iteration, the left side of the first assignment (i.e.
'array[0]') is inferred type pe_long, since the right side is a literal number.
This is the same as in the previous example.
- Still on the first iteration, the left side of the second assignment (i.e.
'array[1]') cannot be inferred a type, because the right side (i.e. the
str_ret_type() call) hasn't been visited yet and still has type pe_unknown.
- Still on the first iteration, the right side (i.e. the str_ret_type() call)
gets visited AFTER the left side and is resolved to type pe_string, since the
referent (the function declaration) is type pe_string.
- On the second iteration, the referent of array[0] (i.e. the global
declaration 'array') is inferred type pe_long, since 'array[0]' is of type
pe_long. This is the same as in the previous example.
- Still on the second iteration,  upon visiting the left side of the second
assignment (i.e. 'array[1]'), resolve_2types() detects the mismatch between the
REFERENT (the global declaration 'array' is pe_long) and the expected type (t
is pe_string) and calls mismatch
- Thus, we will get the token of the referent (i.e. the global definition)
printed out rather than 'array[1]', which has never been resolved.

So the key difference between the two examples is that in the first simpler
one, the right side of the second assignment ("string") doesn't need to be
resolved (since it's a literal) and is thus used right away on the first
iteration to resolve the left side. On the other hand, in the second example,
the right side (the str_ret_type() function call) needs to be resolved first on
the first pass and thus misses the chance of being used to resolve the left
side. On subsequent iterations, resolve_2types() is already focused on that
mismatch and never gives the chance for the left side to get resolved.

Proposed patches in upcoming comment.

-- 
You are receiving this mail because:
You are the assignee for the bug.