Errors compiling SGP22/SGP32/PKIX asn1 files

sorry that the issue is AI generated, but the errors and trying to figure out how to make rasn work with my ASN1 was not AI generated, just the issue, sorry if this is a bit odd, thanks.

the ASN1 files were taken from osmocom at - https://gitea.osmocom.org/ttcn3/osmo-ttcn3-hacks/src/branch/master/library/euicc
though they are public domain at itu/3gpp/gsma sources but are usually embedded in PDF files, so easier to just copy from osmocom.

I did manage to compile everything with [asn1c](https://github.com/vlm/asn1c)
and ended up just binding ffi using [bindgen](https://github.com/rust-lang/rust-bindgen).
It's not a great solution, but it works...

-----

This document outlines issues encountered when using `rasn-compiler` v0.14.3 with `rasn` v0.28.1 to compile SGP32 ASN.1 definitions.

## Environment

- **rasn-compiler**: 0.14.3
- **rasn**: 0.28.1
- **ASN.1 source**: SGP32 (GSMA specification) with dependencies on PKIX1Explicit88, PKIX1Implicit88, RSPDefinitions (SGP22), PEDefinitions
- **Encoding**: DER

## Issue 1: Missing ASN.1 Type Support

### Description
Several standard ASN.1 types are not supported by rasn-compiler, causing "cannot find type" errors during compilation.

### Affected Types
1. `T61String` (TeletexString) - Used in PKIX X.509 definitions
2. `UniversalString` - Used in various PKIX structures
3. `ANY` type - Used for extensible type definitions
4. `DirectoryString` - X.509 name component type
5. `PolicyQualifierId` - PKIX certificate policy type

### Example Error
```
error[E0412]: cannot find type `T61String` in this scope
    --> src/generated.rs:4049:41
     |
4049 |             generation_qualifier: Option<T61String>,
     |                                         ^^^^^^^^^ not found in this scope
```

### Workaround Applied
We manually added type aliases in the root module:
```rust
pub type T61String = rasn::types::Utf8String;
pub type ANY = rasn::types::Any;
pub type DirectoryString = rasn::types::Utf8String;
pub type PolicyQualifierId = rasn::types::ObjectIdentifier;
```

### Expected Behavior
The compiler should either:
- Generate these types automatically, or
- Provide clear documentation on required type aliases
- Map these to appropriate `rasn::types` equivalents

---

## Issue 2: Incorrect Default Value Type Generation

### Description
Generated default value functions return incorrect types that don't match the field types they're meant to initialize.

### Example 1: UInt8 Default Value

**Generated Code:**
```rust
fn anonymous_key_object_key_compontents_mac_length_default() -> UInt8 {
    8  // ERROR: returns integer, not UInt8
}
```

**Error:**
```
error[E0308]: mismatched types
   --> src/generated.rs:460
    |
460 |         8
    |         ^ expected `UInt8`, found integer
```

**Required Fix:**
```rust
fn anonymous_key_object_key_compontents_mac_length_default() -> UInt8 {
    UInt8(8)  // Wrap in UInt8 newtype
}
```

### Example 2: Complex Type Default Value

**Generated Code:**
```rust
fn peakaparameter_sqn_init_default() -> SequenceOf<OctetString> {
    alloc::vec![
        <OctetString as From<&'static [u8]>>::from(&[0, 0, 0, 0, 0, 0]),
        // ... 31 more entries
    ]
}
```

**Actual Field Type:**
```rust
pub sqn_init: PEAKAParameterSqnInit  // Wrapper around SequenceOf<AnonymousPEAKAParameterSqnInit>
```

**Error:**
```
error[E0308]: mismatched types
    |
    = note: expected struct `PEAKAParameterSqnInit`
               found struct `Vec<rasn::types::OctetString>`
```

**Required Fix:**
```rust
fn peakaparameter_sqn_init_default() -> PEAKAParameterSqnInit {
    PEAKAParameterSqnInit(alloc::vec![
        AnonymousPEAKAParameterSqnInit(FixedOctetString::<6>::new([0, 0, 0, 0, 0, 0])),
        // ... properly wrapped entries
    ])
}
```

---

## Issue 3: Module Scoping and Import Problems

### Description
Types defined at the root level or in sibling modules cannot be imported properly in generated submodules.

### Example Error
```
error[E0432]: unresolved imports `super::T61String`, `super::ANY`
  --> src/generated.rs:15:17
   |
15 |     use super::{T61String, ANY};
   |                 ^^^^^^^^^  ^^^ no `ANY` in `generated`
   |                 |
   |                 no `T61String` in `generated`
```

### Context
When the compiler generates:
```rust
// In generated.rs
pub type T61String = rasn::types::Utf8String;

pub mod pedefinitions {
    use super::{T61String, ANY};  // ERROR: Cannot find these
    // ...
}
```

### Workaround Applied
Move type aliases to `lib.rs` and use crate-level imports:
```rust
// In lib.rs
pub type T61String = rasn::types::Utf8String;
pub type ANY = rasn::types::Any;

pub mod generated;

// In generated.rs modules
pub mod pedefinitions {
    use crate::{T61String, ANY};  // Works with crate-level import
    // ...
}
```

### Expected Behavior
The compiler should generate imports that correctly reference types based on their actual location in the module hierarchy.

---

## Issue 4: Forward References and Circular Dependencies

### Description
Modules with circular dependencies fail to compile because types are referenced before they're defined.

### Example Structure
```
rspdefinitions module references:
  - CancelSessionResponse (defined in sgp32_definitions)
  - PrepareDownloadResponse (defined in sgp32_definitions)
  
sgp32_definitions module references:
  - AuthenticateServerRequest (defined in rspdefinitions)
  - HandleNotification (defined in rspdefinitions)
```

### Error
```
error[E0412]: cannot find type `CancelSessionResponse` in this scope
    --> src/generated.rs:5667:32
     |
5667 |         pub cancel_session_response: CancelSessionResponse,
     |                                      ^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
```

### Workaround Applied
Manually add cross-module imports:
```rust
pub mod rspdefinitions {
    use super::sgp32_definitions::{
        CancelSessionResponse,
        PrepareDownloadResponse,
        // ...
    };
}

pub mod sgp32_definitions {
    use super::rspdefinitions::{
        AuthenticateServerRequest,
        HandleNotification,
        // ...
    };
}
```

This only partially works due to the nature of circular dependencies.

### Expected Behavior
The compiler should:
- Detect circular dependencies and reorder definitions appropriately
- Use forward declarations where necessary
- Generate proper import statements that resolve the dependency cycle

---

## Issue 5: Malformed Generated Code - Syntax Errors

### Description
The compiler occasionally generates syntactically invalid Rust code.

### Example Error
```
error: unexpected closing delimiter: `}`
    --> src/generated.rs:9283:1
     |
6775 | pub mod sgp32_definitions {
     |                           - this delimiter might not be properly closed...
...
6799 |     };
     |     - ...as it matches this but it has different indentation
...
9283 | }
     | ^ unexpected closing delimiter
```

### Context
This error appeared after applying manual fixes to imports, suggesting the compiler may have issues with:
- Proper brace matching in complex module structures
- Handling of multi-line use statements
- Module closure when imports are modified

---

## Reproduction Steps

### 1. Setup
```bash
# Create new Rust project
cargo new rasn_sonnetz --lib
cd rasn_sonnetz

# Add dependencies to Cargo.toml
[dependencies]
rasn = "0.28"

[build-dependencies]
rasn-compiler = "0.14"
```

### 2. Create build.rs
```rust
use rasn_compiler::prelude::*;
use std::path::PathBuf;

fn main() {
    let output_file = PathBuf::from("src/generated.rs");
    
    Compiler::<RasnBackend, _>::new()
        .add_asn_by_path("asn1_files/PKIX1Explicit88.asn1".into())
        .unwrap()
        .add_asn_by_path("asn1_files/PKIX1Implicit88.asn1".into())
        .unwrap()
        .add_asn_by_path("asn1_files/PEDefinitions.asn1".into())
        .unwrap()
        .add_asn_by_path("asn1_files/RSPDefinitions.asn1".into())
        .unwrap()
        .add_asn_by_path("asn1_files/SGP32Definitions.asn".into())
        .unwrap()
        .set_output_path(output_file)
        .compile_to_string()
        .unwrap();
}
```

### 3. Run Compilation
```bash
cargo build
```

### 4. Observe Errors
All the issues documented above will appear during compilation.

---

## Summary

The main categories of issues are:

1. **Type Coverage**: Missing support for standard ASN.1 types
2. **Type Correctness**: Generated default values have wrong types
3. **Module System**: Scoping and import generation problems
4. **Dependency Resolution**: Circular dependency handling
5. **Code Generation**: Occasional syntax errors in output

These issues prevent successful compilation of complex, real-world ASN.1 specifications like SGP32 without extensive manual intervention.


Errors compiling SGP22/SGP32/PKIX asn1 files #167

Description

Environment

Issue 1: Missing ASN.1 Type Support

Description

Affected Types

Example Error

Workaround Applied

Expected Behavior

Issue 2: Incorrect Default Value Type Generation

Description

Example 1: UInt8 Default Value

Example 2: Complex Type Default Value

Issue 3: Module Scoping and Import Problems

Description

Example Error

Context

Workaround Applied

Expected Behavior

Issue 4: Forward References and Circular Dependencies

Description

Example Structure

Error

Workaround Applied

Expected Behavior

Issue 5: Malformed Generated Code - Syntax Errors

Description

Example Error

Context

Reproduction Steps

1. Setup

2. Create build.rs

3. Run Compilation

4. Observe Errors

Summary

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions