Rewrite constraint handling

The internal representation for constraints (and object sets)
as produced by the parser was awkward, making further processing
convoluted. Here follows some examples of the old representation
for INTEGER constraints.

The constraint 1..2 is represented as:

  {'ValueRange',{1,2}}

If we extend the constraint like this:

  1..2, ...,

or like this:

  1..2, ..., 3

the representation would be:

  {{'ValueRange',{1,2}},[]}

and

  {{'ValueRange',{1,2}},{'SingleValue',3}}

respectively. Note that the pattern {A,B} will match all these
constraints.

When combining constraints using set operators:

  1..2 | 3..4 ^ 5..6

the representation will no longer be a tuple but a list:

  [{'ValueRange',{1..2}} union
   {'ValueRange',{3..4}} intersection
   {'ValueRange',{5..6}}]

The parse has full knowledge of the operator precedence; unfortunately,
the following pass (asn1ct_check) must also have the same knowledge
in order to correctly evaluate the constraints.

If we would change the order of the evaulation with round brackets:

  (1..2 | 3..4) ^ 5..6

there would be a nested listed in the representation:

  [[{'ValueRange',{1..2}} union {'ValueRange',{3..4}}]
   intersection {'ValueRange',{5..6}}]

We will change the representation to make it more explicit.
At the outer level, a constraint is always represented as

  {element_set,Root,Extension}

Extension will be 'none' if there is no extension, and 'empty' if
there is an empty extension. Root may also be 'empty' in an object set
if there are no objects in the root. Thus the constraints:

  1..2
  1..2, ...
  1..2, ..., 3

will be represented as:

  {element_set,{'ValueRange',{1,2}},none}
  {element_set,{'ValueRange',{1,2}},empty}
  {element_set,{'ValueRange',{1,2}},{'SingleValue',3}}

We will change the set operators too. This constraint:

  1..2 | 3..4 ^ 5..6

will be represented as:

  {element_set,
      {union,
        {'ValueRange',{1,2}},
        {intersection,
           {'ValueRange',{3,4}},
           {'ValueRange',{5,6}}},
       none}}

which is trivial to understand and evaluate. Similarly:

  (1..2 | 3..4) ^ 5..6

will be represented as:

  {element_set,
      {intersection,
        {union,{'ValueRange',{1,2}},{'ValueRange',{3,4}}},
        {'ValueRange',{5,6}}},
      none}

1 files changed, 11 insertions, 5 deletions

diff --git a/lib/asn1/test/error_SUITE.erl b/lib/asn1/test/error_SUITE.erl
index bcb31cb3bb..d81eac7017 100644
--- a/lib/asn1/test/error_SUITE.erl
+++ b/lib/asn1/test/error_SUITE.erl
@@ -124,6 +124,7 @@ constraints(Config) ->
 	   "  II-1 ::= INTEGER (holder-1.&obj)\n"
 	   "  II-2 ::= INTEGER ('1234'H<..20)\n"
 	   "  II-3 ::= INTEGER (1..<\"abc\")\n"
+	   "  II-4 ::= INTEGER (10..1)\n"
 
 	   "  HOLDER ::= CLASS {\n"
 	   "    &obj HOLDER OPTIONAL\n"
@@ -136,7 +137,8 @@ constraints(Config) ->
      [
       {structured_error,{M,2},asn1ct_check,illegal_value},
       {structured_error,{M,3},asn1ct_check,illegal_integer_value},
-      {structured_error,{M,4},asn1ct_check,illegal_integer_value}
+      {structured_error,{M,4},asn1ct_check,illegal_integer_value},
+      {structured_error,{M,5},asn1ct_check,reversed_range}
      ]} = run(P, Config),
     ok.
 
@@ -595,13 +597,14 @@ table_constraints(Config) ->
 	   "  }\n"
 
 	   "  Seq-2 ::= SEQUENCE {\n"
-	   "    contentType INTEGER({Contents}),\n"
+	   "    contentType INTEGER,\n"
 	   "    content CONTENTS.&Type({Contents}{@contentType})\n"
 	   "  }\n"
 
+	   "  Int ::= INTEGER ({1})\n"
+
 	   "  Seq-3 ::= SEQUENCE {\n"
-	   "    contentType INTEGER,\n"
-	   "    content CONTENTS.&Type({Contents}{@contentType})\n"
+	   "    contentType CONTENTS.&id({1})\n"
 	   "  }\n"
 
 	   "Contents CONTENTS ::= {\n"
@@ -619,7 +622,10 @@ table_constraints(Config) ->
        {missing_ocft,contentType}},
       {structured_error,
        {M,10},asn1ct_check,
-       {missing_ocft,contentType}}
+       illegal_table_constraint},
+      {structured_error,
+       {M,11},asn1ct_check,
+       invalid_table_constraint}
      ]} = run(P, Config),
     ok.