The copyright was a historical remnant of diameter's roots prior to its
inclusion in OTP.

Thanks to Anatolie Golovco.

By replacing literal diameter_gen_relay atoms in forms extracted from
that module by the name of the module in question. This has been wrong
for some time, but only became noticable when the parent commit started
using ?MODULE as more than a process dictionary key or tag to match on.
In particular, the function dict/1 in diameter_gen.hrl (included by
every dictionary module) can now return ?MODULE, which is (not
surprisingly) expected to be the name of the dictionary module in
question. It wasn't in the case of a module compiled from forms: it was
diameter_gen_relay, since that's the module the forms were extracted
from.

The fix only affects dictionaries compiled from forms, as returned by
diameter_make:codec/2. In particular, dictionaries compiled from Erlang
source returned by this function, or by diameterc(1), are unaffected.

Instead of detecting the error, code generation failed when attempting
to lookup the type of an undefined AVP.

* anders/diameter/unicode_path/OTP-11655:
  Fix unicode path failure in diameter_make:codec/2

This is an encoding that didn't exist at the time of the previous
commit, but which was added in commit 83b6daef. Use it to restrict
stringification to lists containing printable ascii.

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.)