New metadata format

[eliascxstro]

The current metadata format being used is present within a .expect file. For example, for if.expect the metadata is given as: metadata #{ 0: let x: ubit<32> = 4; 1: let y: ubit<32> = 5; }# where each line lists the group name and the line number the group is on respective to the corresponding if.fuse file. While useful and intuitive, it would be better to make the metadata more streamlined and not hardcoded.

With the new format, these mappings would be within a field called ids for the adapter. This field is essentially a HashMap where the keys are the group names within the program, represented as Strings, and the values are what line the group starts on, represented as integers.

Whenever any type of step is made, the interpreter would return the following struct:

pub struct ProgramStatus {  

  status: HashSet<Id>, // all groups currently running  

  done: bool,          // states whether the program has finished  
}

With this, we can easily use one of the groups that are running, look up the line the group is on in ids, and then display that line in the debugger. If done is ever true, then we automatically terminate the debugger.

This raises the question of what group to display should 2 groups of the same name be running or even two groups in general. For simplicity, it might be best to just display the first group in the HashSet given to us. In the future, it could be possible to give certain groups priority over others, or even allow one to choose which group to display.

The harder decision to be made is how the parser for the metadata is going to be made. When intializing the debug adapter, ideally ids should contain all groups and their respective lines for the .futil file being debugged. For this, it would be best to start discussing a high level overview of the parser and how it should work before doing anything else.

[EclecticGriffin]

so to concretely propose what a new metadata format might look like for calyx to calyx mappings:

metadata #{
     group1: /path/to/file LINE_NUMBER
     group2: /path/to/file LINE_NUMBER
}#

We could consider eliding the path for cases where the file is the one the metadata is attached to, but we could just as easily not for the sake of uniformity. Regardless, this implies a Calyx pass which adds the metadata table to the file for a standard Calyx file. Alternatively, we could consider instead making it a separate tool if we don't want to introduce the metadata format to the compiler directly since as far as the compiler is concerned the existing metadata structure is an opaque and unparsed string.

Curious if @sampsyo has any thoughts on this

[EclecticGriffin]

Caveat that my proposed example would probably run into issues for paths with spaces and would probably either need to explicitly escape them or just otherwise wrap such paths in quotation marks