| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Dictionary compilation fails to detect undefined AVPs in these sections.
|
|
The problem is that the change in default encoding to utf8 in 17.0, in
commit 00e42967, changes the behaviour of erl_parse:abstract/1, which is
used by the dictionary compiler to turn terms into abstract code. In
particular, it transforms the orddict representation of a parsed
dictionary to contruct the return value of a dictionary module's dict/0
function. This orddict contains various lists, one of which is a list of
tuples of the form
{Name, Code, [VendorId], [Avp]}
where Name is an ASCII string and VendorId is a non-negative integer.
Using erl_parse:abstract/2 instead allows a string encoding to be
specified but regardless of what encoding is used, the result of
transforming our tuple might not be what we really want, which is for
Name to always be represented as a string form and [VendorId] to always
be represented as a cons form: the [VendorId] will always end up as a
string form if the integers are small enough. The only way around this
is to transform the tuple bit by bit, but modifying the code to do this
is quite a lot of work, for not much gain: it would be nice to produce
more readable output but nothing stops working without it.
This commit restores the pre-17.0 conversion by explicilty specifying
latin1 as the string encoding to erl_parse:abstract/2. The utf8 encoding
broke the compilation of some dictionares since unicode strings aren't
expected when writing the generated code to file.
Note that the latin1 encoding does reasonably well in practice, although
it mangles the Ericsson Vendor Id list [193] into a "LATIN CAPITAL
LETTER A WITH ACUTE". The utf8 encoding does worse, mangling the 3GPP
Vendor Id 10415 into "DESERET CAPITAL LETTER CHEE". An ascii encoding
would do better than latin1 but doesn't yet exist. (Encoding isn't
really what the option is. It's a string predicate: if the predicate is
true then represent as a string form, otherwise a cons form.)
|
|
The case in which an AVP was defined as having type Grouped in
@avp_types without a corresponding specification in @grouped was
missing.
|
|
Instead, add diameter_make:format_error/1 to allow the caller to format
if desired, which is what applications like compiler and yecc do. Use
this to check that the expected error is the one actually generated in
the compiler suite.
|
|
An error when expecting success wasn't regarded as failure when
compiling dictionaries.
|
|
That is, preprocessed forms that can be passed to compile:forms/1,2.
|
|
To set @avp_vendor_id, @codecs and @custom_types as required for
imported avps.
|
|
In particular, make codec/2 flexible as to what's generated, the formats
(erl, hrl, parse, forms and beam) being passed in the options list and
defaulting to [erl, hrl]. The 'parse' format is the internal format to
which dictionaries are parsed, which can be manipulated by flatten/1
before being passed back to codec/2 or format/1.
Remove the (undocumented) dict/1,2 since codec/2 now subsumes it with
the 'parse' option.
|
|
It was originally written before this interface existed.
|
|
|
|
From compiler suite.
|
|
|
|
Some look to be optimistic when running in slow virtual environments.
(With bad time keeping?)
|
|
|
|
To avoid inappropriate defaults if the dictionaries are reused.
|
|
|
|
|
|
|
|
|
|
|
|
To test compilation of example dictionaries from various standards.
|
|
Compilation is slow on Solaris for one.
|
|
|
|
Didn't quite interpret '*' as RFC 3588 dictates. In particular, the
interpretation depends on what's being qualified, a required, optional
or fixed AVP.
|
|
A value is required to be the same as any specified with
@avp_vendor_id but otherwise the two locations are equivalent.
Both possibilities are allowed since @avp_vendor_id is required
for AVPs of types other than Grouped (modulo it not really needing
to exist at all: see commit 943266c9) and since the grammar parsed
in @grouped (from RFC 3588) allows it.
|
|
Check that values that should be Unsigned32 actually are.
|
|
Just use include options to add to the code path and expect that
dependent modules will either already have been loaded or will be
loaded dynamically, thereby avoiding having a module being left as
both current and old code when compiling concurrently. Not a problem
for a human user interactively compiling one module at a time
but the compiler test suite for one will compile concurrently.
In any case, leaving behind old code is probably not what someone
would expect while relying on the code path probably is.
|
|
Plus additional parsing tests.
|
|
|
