Renaming is too simple

[CohenArthur]

Trying to use types defined in a previously included source result in incorrect renaming.

// option.jk
type Option(...);

// iter.jk
func next(i: Iter) -> option::Option {
    ...
}

// lib.jk
incl option
incl iter

After renaming, iter.jk will have the following source

// iter.jk
func iter::next(i: iter::Iter) -> iter::option::Option {
    ...
}

Which is invalid since the Option type is not defined in the iter source, but in a previously included one. The code produced by the renaming is therefore invalid since iter::option::Option does not exist

[CohenArthur]

A solution could be to prefix all names using a root namespace, and rename accordingly. Then, all items would become named relative to root, and it shouldn't be an issue anymore

[CohenArthur]

This does not work either because the Renamer does not currently have any knowledge of names already existing. We should maybe keep a map of existing names to see if we need to rename something or not

|‾‾‾‾‾‾‾‾‾‾‾|
|           |
|  main.jk  |=> uses std::option::Option, std::iter::Iter
|           |
|___________|

incl std/

|‾‾‾‾‾‾‾‾‾‾‾|
|           |
|   lib.jk  |
|           |
|___________|

incl option
incl iter

|‾‾‾‾‾‾‾‾‾‾‾|        |‾‾‾‾‾‾‾‾‾‾‾|
|           |        |           |
| option.jk |        |  iter.jk  |=> uses option::Option
|           |        |           |
|___________|        |___________|
     |                     |
     -> creates Option     -> creates Iter