[nem-en] patch for matching compiler

[Marcin Grzeskowiak]

Kamil Skalski <kamil.skalski at gmail.com> napisał(a) :

> Ok, now it boots and tests are running well. There is one regression
> in location of reported warning in new-matching-null.n
> without -new-matching the location is
> positive/new-matching-null.n:97:7:97:12: warning: matching is not
> exhaustive, example unmatched value: V.A (a = V.A, b = B)
> 
> and with it
> positive/new-matching-null.n:96:5:96:8: warning: matching is not
> exhaustive, example unmatched value: V.A (a = V.A, b = B)
> 

I don't know yet how to fix this but the problem is caused by
the fact that when -new-matching option is specified 
the DecisionTreeBuilder.CheckMatching function (responsible for
warnings) is invoked later in the compilation process than when
compiler is run without the option.
In the first case it is called by DecisionTreeCompiler just before
it compiles the matching while in the second case it is called from
typing/Typer.n some time before MatchingCompiler.Run ().
It seems that when `match' is embedded in a `try' block 
the Location_stack looks different at the time CheckMatching () is
called in these two cases resulting in different warnings from
Message.Warning ().
Actually this behavior can be also observed without -new-matching. For
example:

 1: public module M
 2: {
 3:   public Main () : void
 4:   {
 5:     try {
 6:       match (false) {
 7:         | false => {}
 8:         | false => {}
 9:         | true => {}
10:       }
11:     } catch {
12:       | _ => {}
13:     }
14:   }
15: }

`ncc warn_test.n` says:
warn_test.n:8:11:8:16: warning: this match clause is unused
warn_test.n:5:5:5:8: warning: unreachable pattern in matching

The first warning is from DTB.CheckMatching () and the second
(redundant) warning is from MatchingCompiler.cg_match_over_booleans ()
and it shows wrong location as -new-matching would do.

This is not critical but I found another problem in my patch which
is related to the way DecisionTreeBuilder treats enums. If the enum
declaration has [System.Flags] attribute its span is -1 ("infinite")
which means that it can be assigned any value that is correct for
the underlying int type. Without [System.Flags] however the span of
enum type is equal to the number of named constants in enum. This
is generally not correct but works nice for CheckMatching () (resulting
in better warning messages) and unfortunately breaks my patch.
For example:

//[System.Flags]
public enum E
{ 
 | Red = 1
 | Green = 2
 | Blue = 4
}
public module M
{
  public goo (e : E) : void // this is for warnings only
  {
    | Red => {}
    | Green => {}
  }
  foo (e : E) : string
  {
    | Red => "Red"
    | Green => "Green"
    | Blue => "Blue"
  }
  public Main () : void
  {
    System.Console.WriteLine (foo (E.Red | E.Blue))
  }
}

During compilation there is a warning for goo:
'matching is not exhaustive, example unmatched value: Red'
and when you run the program
1) without -new-matching: Main is interrupted with MatchFailureException
2) with -new-matching: program prints "Blue"

This is because the span of E is 3 and the Decision.Failure node is
missing in decision tree for foo () (without -new-matching it doesn't
matter because decision tree isn't used to generate code).

When [System.Flags] is uncommented the situation is different - both with
and without -new-matching the execution is interrupted by exception
(span == -1 and there is Failure node in tree).
But now there are two warnings:
for goo: 
'matching is not exhaustive, example unmatched value: 
 (anything except [(1 :> E), (2 :> E)])'
and for foo:
' ... (anything except [(1 :> E), (2 :> E), (4 :> e)]'

I don't know yet what to do to have span == -1 for both types and enums
but different warnings.

Seems that these problems (esp. the second one) block my patch for now :-(
I will try to fix them during the weekend.

Marcin


*************************************************
    Śląski Pasaż Handlowy - wpadnij na zakupy
            http://pasaz.silesianet.pl
*************************************************