Beautification when instantiation in block issue

[sverrham]

The beautifiaction breaks when I have a block and instantiate an entity inside it. so the provided example is beautified differently if the instantiation is commented out: ` b_something : block is begin i_ent : entity some_lib.dev generic map ( g_fpga_family => g_fpga_family, g_something => true) port map ( clk => clk, data => data); end block;

p_some : process(clk) begin if rising_edge(clk) then something <= '0'; end if; end process;`

[Remillard]

I'll take a look and see what I can do!

[Remillard]

Actually there's maybe a larger issue in that block is not even scoping with syntax support, so that's weird. I don't usually use them myself, but I was pretty sure I had an issue a few months back where someone asked for block support.

In any event, I'll try to get both of these solved.

[Remillard]

Aha, it's scoped if and only if you use a label. I must have really only put in some basic support. According to my quick and dirty language spec, the is and the ending label are optional. The preceding label is not optional.

[Remillard]

Found my prior work in issue #133. While is is technically optional, I need it due to the fact you can have a guard expression for blocks. The syntax rules are different in the guard expression, so I use the is as a delimiter for guard expression rules and then the statement declaration rules and the two should really not be mixed. However the ending label is easy to make optional (and I just did it.)

Onto beautification issues now.

[Remillard]

Okay. I think I've figured out what's going on under beautification and it's going to be a tricky one. block has a lot of options, among which is not only its own port generics and ports, but its own generic maps and port maps! Thus this is the only place in the language that breaks syntax on generic map. Usually a generic map clause is ended by a single parenthesis because it is followed by the mandatory port map which ends in a );. That's the formal end of the instantiation.

However, the rule breaks in blocks. It is perfectly legal to have a generic map ( ) ; statement in the declarative region! How I made this work was by making the beautification engine ignore generic map and instead trigger on generic alone which DOES have a general rule that it ends in );. However this clearly fouled up when you put not just an instantiation, but an instantiation WITH A GENERIC MAP into the block.

The beautification engine is not as sophisticated as Sublime's own lexical parsing engine, nor does it need to be in general. I do have some limited branching support though, so I will see if I can't keep generic ignored in the declarative region, and then branch to a concurrent statement region and remove the ignoring.

[Remillard]

Alright, I think this works. Your code block above beautifies to:

    b_something : block is
    begin
        i_ent : entity some_lib.dev
            generic map (
                g_fpga_family => g_fpga_family,
                g_something   => true)
            port map (
                clk  => clk,
                data => data);
    end block;

    p_some : process(clk)
    begin
        if rising_edge(clk) then
            something <= '0';
        end if;
    end process; `

I don't see any reason this ought to have knock on effects as it was just a rule change so I'll push out a quick release.