Goblint-CIL aims to support OCaml >= 4.05, so things such as List.find_map that are more recent cannot be used here.

This also fixes goblint/gobview#7 (comment).

I am extremely skeptical that this indeed fixes that issue. We had identified that it was due to prune pruning the entire hashtable because of some hash issue. This seems unrelated to the issue you are fixing here.

Ok, I am sure this is a stupid question, but here it comes: Why rely on something so brittle as line numbers here at all?

I am extremely skeptical that this indeed fixes that issue. We had identified that it was due to prune pruning the entire hashtable because of some hash issue. This seems unrelated to the issue you are fixing here.

I did some more investigation:
The test case from the semantic search issue actually works in GobView also without the proposed changes from this (and the related) PRs. My fixes are necessary only for other test cases (such as the one described in #146, also with semantic queries) that contain pseudo-return nodes or where the computation with the line numbers is unlucky. I am however not able to reconstruct the false behavior of GobView anymore (no matter which of the current versions), where no results are found for the semantic query. This is confusing, because I am convinced that I did observe this unexpected behavior earlier.

Ok, I am sure this is a stupid question, but here it comes: Why rely on something so brittle as line numbers here at all?

CIL renames duplicate variable names in its so-called alpha-conversion. These renamings are stored in a hash table that maps variable names from the c source code to (possibly several) tuples of varinfo (which possibly has a different name) and location (where the varinfo with the new name was created). The function find_uses_in_fun_var tries to find all variable occurrences in a specific function body and for this looks up all (across the complete project) possible renamings of the searched variable in the hashtable. Because those renamings are not restricted to occurrences in the relevant functions, they are filtered with this location comparison.

Here is an example:

1 void f(int i) {
2   int i = 0; // renamed to i___0
3   int i___1 = 0;
4   i++;
5   return;
5 }

int main() {
  int i = 0;
  int i = 0; // renamed to i___0;
  int i = 1; // renamed to i___1
  f(i);
  return 0;
}

Querying for variables of name i in the body of function named f should lead to finding occurrences in lines 2 and 4. Without the line number check, the additional renaming i -> i___1 in main is retrieved from the map and the additional occurrence in line 3 is wrongfully found.

I was wondering if one could avoid this check by searching for the varinfo, instead of just its name, but I think this would need some more extensive refactoring.

Thanks for the clarification! I feel like I knew this at some point, but have forgotten it since then.

@stilscher what is blocking this?