aboutsummaryrefslogtreecommitdiffstats
path: root/lib/asn1/src/asn1ct_parser2.erl
AgeCommit message (Collapse)Author
2015-06-18Change license text to APLv2Bruce Yinhe
2015-01-12asn1ct_parser2: Remove expensive lookahead_assignment/1 functionBjörn Gustavsson
In the parsing of a value assignment, such as: value INTEGER ::= 42 there is call to a function called lookahead_assignment/1 that will ensure that the sequence of tokens that follows the value is a valid assignment. The problem is that if the next assignment is a value assignment, that too will look ahead to the next assignment. That means that the complexity will be quadratic if there are many value assignments following each other. The reason for the test in the first place is unclear; my guess is that it was an attempt to provide better error reporting.
2015-01-12asn1ct_parser2: Clean up error handling and reportingBjörn Gustavsson
Errors were reported using a throw like this: throw({asn1_error,{get_line(hd(Tokens)),get(asn1_module), [got,get_token(hd(Tokens)),expected,typereference]}}). The attempt to tell the user what was expected was often mis-leading. It is time-consuming and non-trival to provide correct information of what is expected. Therefore, we will not even try. Instead we will spend more effort to report the token where the error was discovered. We will replace each throw with a function call: parse_error(Tokens). Also add the syntax_SUITE test suite to test error reporting and to cover all error reporting code. Remove the old c_syntax/1 test case. Also remove all out-commented code.
2015-01-12asn1ct, asn1ct_parser2: Refactor the upper levels of error handlingBjörn Gustavsson
Responsibilities for parse error handling were split between asn1ct and asn1ct_parser2 in a confusing way. Let asn1ct_parser2 return structured_error tuples in the same way as the check pass.
2015-01-12asn1ct_parser2: Eliminate all uses of old-style 'catch'Björn Gustavsson
Most uses of 'catch' are not necessary. For example, parse_or/2 is typically called like this: case catch parse_or(Tokens, Flist) of {'EXIT',Reason} -> exit(Reason); {asn1_error,_}=AsnErr -> throw(AsnErr); Result -> Result end. Since {asn1_error,_} is always thrown (never returned) and a successful is always returned (never thrown), the 'case' and the 'catch' are not necessary. The code can be simplified too: parse_or(Tokens, Flist) In a few cases, we will need to replace the 'catch' with 'try'...'catch'.
2015-01-12asn1ct_parser2: Clean up parse_or/3 and parse_or_tag/3Björn Gustavsson
Use try...catch instead of catch.
2015-01-12asn1ct_parser2: Correct extraction of line number from tokenBjörn Gustavsson
The first position in a token tuple is always an atom, the second the line number. The code tested the third position.
2015-01-12asn1ct_parser2: Throw an {asn1_error,...} for *all* parse errorsBjörn Gustavsson
In a future commit, we want to tighten what we catch. Therefore, legitimate parsing errors should always throw a controlled exception, instead of arbitrarily crashing.
2015-01-12asn1ct_parser2: Simplify parse_Type/1Björn Gustavsson
The parse_Type/1 calls various type parse functions. Most of those functions return a #type record, but not all of them. If a #type{} record is not returned, parse_Type/1 will wrap the return value in a We can simplify the code in parse_Type/1 if we make sure that the type parsing functions called by parse_Type/1 always return a #type{} record.
2015-01-12asn1ct_parser2: Remove unsuccessful parsing of ValueSetFromObjectsBjörn Gustavsson
The TypeFromObject and ValueSetFromObjects grammar productions cannot be distinguished by the parser without the help of type information (which the parser does not have). Since the parser attempts to parse TypeFromObject before ValueSetFromObjects, the parsing of ValueSetFromObjects will always fail.
2015-01-12Move checking of UNIQUE & DEFAULT error to asn1ct_checkBjörn Gustavsson
To keep the error reporting code in asn1ct_parser2 simple, we only want to handle pure syntactic errors. Therefore, move the check that UNIQUE and DEFAULT are not applied to the same field to asn1ct_check.
2015-01-12Rewrite constraint handlingBjörn Gustavsson
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}
2015-01-12Clean up checking of object setsBjörn Gustavsson
2015-01-12Remove special case in parserBjörn Gustavsson
The parser handled the builtin ABSTRACT-SYNTAX and TYPE-IDENTIFIER classes specially, which caused problems. It turns out that there is no longer any need to handle those classes specially.
2014-09-01Remove unused code for ABSTRACT-SYNTAX and TYPE-IDENTIFIERBjörn Gustavsson
Before classes were fully implemented, there was support for ABSTRACT-SYNTAX and TYPE-IDENTIFIER. Some of that code is still there and is no longer used. Get rid of it and correct comments.
2014-09-01Add the module name to the #classdef{} recordBjörn Gustavsson
If we want construct an #'Externaltypereference'{} from a #classdef{} record, we will need the module name.
2014-09-01Eliminate the use of #identifier{} outside the tokeniser and parserBjörn Gustavsson
The only remaining use of #identifier{} in asn1ct_check was in a temporary packaging of a value that would be ultimately be put into #valuedef{}. Therefore we can eliminate that last usage but putting the value directly into a #valuedef{} and we can move the record definition into asn1ct_parser2.
2014-09-01Fix problem with object identifiers in external modulesBjörn Gustavsson
When parsing ASN.1, certain constructs can only be understood in the full context of the entire ASN.1 module. For instance, the value following ID in this simplified excerpt from MTSAbstractService88: administration-88 PORT ::= { ID {id-pt-administration 88} } the value following "ID" can be interpreted either as value for: SEQUENCE { id-pt-administration INTEGER } or as an OBJECT IDENTIFIER. Our ASN.1 parser assumes that a SEQUENCE is meant, and if that later turns out to be wrong, the SEQUENCE value is rewritten to an OBJECT IDENTIFIER. The problem is that at the time of the rewrite, we no longer know in which ASN.1 module id-pt-administration was defined in, and we have to use the module name in the state{} record. Unfortunately, the module name in the state{} record may not always be correct. While there are attempts in the code to keep the module name up-to-date when checking imported types, it is not done consistently, and it seems to be a difficult and error-prone task to attempt to make it consistent. A safer and less error-prone approach is to make sure that we don't lose the module name while parsing. To make it clear what we are doing, we will introduce a new #seqtag{} record that are used for tags in SEQUENCE values. The name is based on its primary use. The record also contains the module in case it happens to be an OBJECT IDENTIFIER.
2014-09-01Teach the ASN.1 compiler to understand "EXPORTS ALL"Björn Gustavsson
EXPORTS ALL is the same as leaving out the EXPORTS statement.
2013-09-18asn1ct_parser2: Clean the process dictionary after parsingBjörn Gustavsson
Apart from cleanliness, the test suite runs many tests cases in parallel, so it never hurts to reduce the memory pressure.
2013-06-12Update copyright yearsBjörn-Egil Dahlberg
2013-05-31Eliminate use of #constraint{} outside of the parserBjörn Gustavsson
The record #constraint{} is almost unused outside of the parser except for two places in asn1ct_check. The only correct usage of the record is in instance_of_constraints/2. Eliminate that usage by updating the parser to pass that constraint in the same way as all other constraints. In check_integer_range/2, the record is used incorrectly. A constraint for an integer will never be a list of #constraint{} records. Therefore, the list comprehension will always produce an empty list, and check_constr/2 will not actually check anything (which is kind of lucky, since the 'ValueRange' range constraint is incorrectly written - the lower and upper bounds should be in a tuple). For now, we will not attempt to actually start validating integer ranges. Firstly (obviously) we will need to be sure that we correctly handles all forms of constraints, and secondly we will need to consider whether we need to produce a warning rather than an error for compatibility reasons.
2013-05-31Eliminate general use of #typereference{}Björn Gustavsson
The record #typereference{} is only used internally within the asn1ct_parser2 module (the parser translates it to an #'Externaltypereference{} record).
2012-12-18asn1ct_parser2: Let synonyms share parsing codeBjörn Gustavsson
UNION and "|" are synonyms, as are INTERSECTION and "^". Use the same parsing code for the synonyms.
2012-05-04Add support for multiple ExtensionAdditionGroupsKenneth Lundin
2012-02-28[asn1] Make tables and processes unnamedAdam Lindberg
- Refactor and clean up asn1_db process - Remove unused stop function in asn1ct.erl - Remove infinite loop possibilites in asn1ct_check.erl - test/1,2,3 now run in separate process - Update documentation for new test options
2010-08-25Add support for Extension addition groupKenneth Lundin
2010-02-19OTP-8463 Support for EXTENSIBILITY IMPLIED and SET/SEQ OF NamedType isKenneth Lundin
added.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP