Inner Subtype Constraints

[Nicceboy]

Hi,

I have been playing on inner subtype constraints on rasn side, that is something compiler likely wants to have also in some point. These constraints are very complex and compiler would need to maintain the whole dependency graph of the constraint context to have the understanding of all the types.

Without compiler, I think there is no other way but introduce additional DSL that adds type information manually.

Something like this

#[derive(AsnType, Debug, Decode, Encode, PartialEq, InnerSubtypeConstraint)]
#[inner_subtype_constraint(
    content => {
        kind = "choice:Ieee1609Dot2Content",
        signedData => {
            kind = "sequence:SignedData", // not necessary since sequence can be unpacked without knowing the type
            tbsData => {
                headerInfo => {
                    generationTime => present,
                    p2pcdLearningRequest => absent,
                    missingCrlIdentifier => absent
                }
            },
            signer => {
                certificate => (EtsiTs103097Certificate, size(1))
            }
        },
        encryptedData => {
            recipients => {
                pskRecipInfo => absent,
                symmRecipInfo=> absent,
                rekRecipInfo => absent
            }
        },
        signedCertificateRequest => absent
    },
)]
pub struct EtsiTs103097Data(Ieee1609Dot2Data);

Proc-macros can then use this DSL to generate constraint checks. At some level it already works, but only with subset of features and it can be difficult to maintain and support everything.

I was kinda wondering what is the state of these constraints in the compiler side and does it make sense for compiler to generate this DSL or just generate the validation functions/ additional constraints directly and bypass it completely? Compiler likely can handle this much better, but would we like to support usage without compiler as well?

[6d7a]

The compiler has a complete intermediate representation for inner subtyping, if I recall correctly. Currently, it does not generate any output for these kinds of constraints, but it's definitely doable. The macro example for 1609.2 is pretty impressive, but for the compiler, it makes things a lot harder, because it needs to handle not only the complexity of inner subtyping in ASN.1 but also the new meta language we would use in our rasn macros. Same goes for the rasn user. I've mostly seen inner subtyping being used in large specifications, and I wouldn't expect a user to hand-craft bindings from scratch in these cases.

[Nicceboy]

it makes things a lot harder, because it needs to handle not only the complexity of inner subtyping in ASN.1 but also the new meta language we would use in our rasn macros.

That is definitely true. Maybe this just stays as personal experiment.

There is one valid usecase for expressing the logic between constraints (unions, intersections), and for that, some presentation language is required, unless compiler also calculates the outcoming result directly and intermediate constraints are not described anywhere.

If I go further with this, maybe the code that actually generates the constraint checks is useful on the compiler side. It seems to be rather difficult to note the all the variations in a way that produced code is correct in overall.