# Limitations
This document describes what synta-codegen does not support, and where applicable
provides workarounds.
---
## ASN.1 syntax not parsed
The following constructs cause a parse error if they appear in an input file.
### Multiple modules per file
synta-codegen accepts exactly one module per input file. A file containing two or
more `MODULE DEFINITIONS ... END` blocks will fail to parse after the first `END`
is encountered.
**Workaround**: split multi-module files into one file per module before passing
them to the tool. This is the recommended practice for ASN.1 schemas regardless.
### Parameterized types
```asn1
Container { T } ::= SEQUENCE { item T }
```
The braced parameter list is not parsed.
**Workaround**: expand parameterized types manually into concrete definitions.
### Information object classes (CLASS / WITH SYNTAX)
```asn1
CONTENT-TYPE ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type
} WITH SYNTAX { &Type IDENTIFIED BY &id }
```
Neither `CLASS` nor `WITH SYNTAX` are parsed.
### Object set assignments
```asn1
SupportedTypes CONTENT-TYPE ::= { ... }
```
Not parsed. Behavior: parse error.
### INSTANCE OF
Not parsed. Behavior: parse error.
---
## Constructs parsed but not code-generated
The following constructs are parsed and recorded in the AST but produce no output
in the generated code. They do not cause errors.
### Table constraints (ComponentRelation)
The surrounding type definition is still emitted. Only the constraint annotation
is dropped.
### User-defined constraints (CONSTRAINED BY)
Silently dropped from generated code.
### PermittedAlphabet constraints (FROM) -- C backend
The Rust backend validates permitted alphabets in the `new()` constructor. The C
backend does not emit alphabet validation; the constraint is dropped for C output.
### Pattern constraints (PATTERN) -- C backend
Rust output optionally validates patterns (enable `regex` feature). The C backend
drops PATTERN constraints from generated code.
### ContainedSubtype (CONTAINING) -- C backend
Rust output optionally validates CONTAINING constraints (enable
`validate_containing` feature). The C backend drops CONTAINING constraints.
### EXPLICIT tag on anonymous inline structural type -- C backend only
An anonymous SEQUENCE, SET, or CHOICE written inline inside an EXPLICIT tag,
without a preceding named type definition, is not fully supported by the C code
generator.
Example (not supported in C output):
```asn1
Wrapper ::= SEQUENCE {
item [0] EXPLICIT SEQUENCE { a INTEGER, b INTEGER }
}
```
The parse succeeds. The Rust backend handles this case correctly. The C backend
emits the outer SEQUENCE but silently omits the EXPLICIT wrapper encoding around
the anonymous inner type.
**Workaround**: extract the inner type to a named definition and reference it by
name.
```asn1
Inner ::= SEQUENCE { a INTEGER, b INTEGER }
Wrapper ::= SEQUENCE {
item [0] EXPLICIT Inner
}
```
---
## Circular dependency detection
Circular module import cycles are detected. Use `--check-imports` to verify a set
of ASN.1 files before generating code:
```bash
synta-codegen a.asn1 b.asn1 --check-imports
```
If a cycle exists, the tool reports it and exits with an error. Code generation
is not attempted.
ASN.1 circular dependencies cannot be resolved automatically. Refactor the schemas
to eliminate the cycle.
---
## Out of scope
The following are intentionally not generated by synta-codegen.
### BER/CER encoding logic
The synta library's derive macros handle BER/DER/CER encoding at compile time.
synta-codegen generates type definitions and struct layouts; it does not inline
encoding logic.
### Serde derive attributes
Not generated. If Serde integration is needed, add it to the generated types
manually or through a wrapper crate.
### Additional trait implementations
synta-codegen derives `Debug`, `Clone`, and `PartialEq` on generated types. Other
traits (Hash, Ord, Display, etc.) must be added manually.
### Information object class semantics
Table constraints are parsed (see above) but the code generator does not model
or enforce information object class semantics.