BaldDemian opened a new pull request, #3658:
URL: https://github.com/apache/fory/pull/3658

   <!--
   **Thanks for contributing to Apache Fory™.**
   
   **If this is your first time opening a PR on fory, you can refer to 
[CONTRIBUTING.md](https://github.com/apache/fory/blob/main/CONTRIBUTING.md).**
   
   Contribution Checklist
   
       - The **Apache Fory™** community has requirements on the naming of pr 
titles. You can also find instructions in 
[CONTRIBUTING.md](https://github.com/apache/fory/blob/main/CONTRIBUTING.md).
   
       - Apache Fory™ has a strong focus on performance. If the PR you submit 
will have an impact on performance, please benchmark it first and provide the 
benchmark result here.
   -->
   
   ## Why?
   
   Identifiers colliding with Rust keywords should be escaped to prevent 
compiling errors.
   
   ## What does this PR do?
   
   The current implementation broadly follows the approach used by prost-build. 
It first normalizes identifiers from the IDL according to Rust naming 
conventions, e.g. converting struct names to UpperCamelCase and field names to 
snake_case. It then checks whether the normalized identifiers are Rust keywords 
and escapes them when necessary.
   
   
   
   This process is not trivial as I first expected. For example, we need to 
cache the escaped name of each identifier to make sure the definition site and 
all use sites refer to the same name consistently.
   
   
   
   Although I have tested the implementation against many corner cases, this 
handling is still **incomplete**, much like prost itself. It may still generate 
Rust code that fails to compile for valid (but rare, I suppose 🤔) IDL. In most 
cases, this happens because an identifier from the IDL conflicts with an 
identifier already used by the Rust code generated by Fory. 
   
   
   
   Example 1:
   
   IDL:
   
   ```protobuf
   package demo;
   message Fory {
     string value = 1;
   }
   ```
   
   Generated Rust code:
   
   ```rust
   use fory::Fory;
   pub struct Fory {
       pub value: String,
   }
   pub fn register_types(fory: &mut Fory) -> Result<(), fory::Error> {
       fory.register::<Fory>(...)?;
       Ok(())
   }
   ```
   
   Compiling errors:
   
   ```
   error[E0255]: the name `Fory` is defined multiple times
   error[E0117]: derive/impl resolves to the external `fory::Fory` type
   ```
   
   ----
   
   Example 2:
   
   IDL:
   
   ```protobuf
   package demo;
   message HashMap {
     string value = 1;
   }
   message Holder {
     map<string, string> values = 1;
     HashMap item = 2;
   }
   ```
   
   Generated Rust code:
   
   ```rust
   use std::collections::HashMap;
   pub struct HashMap {
       pub value: String,
   }
   pub struct Holder {
       pub values: HashMap<String, String>,
       pub item: HashMap,
   }
   ```
   
   Compiling errors:
   
   ```
   error[E0255]: the name `HashMap` is defined multiple times
   error[E0107]: missing generics for struct `std::collections::HashMap`
   ```
   
   However, I think IDL like the above are rare in real practice. The resulting 
compiling errors are clear and straightforward and the user can handle the 
conflicting names easily in the IDL.
   
   ## Related issues
   
   <!--
   Is there any related issue? If this PR closes them you say say fix/closes:
   
   - #xxxx0
   - #xxxx1
   - Fixes #xxxx2
   -->
   
   Close https://github.com/apache/fory/issues/3544.
   
   ## AI Contribution Checklist
   
   <!-- Full requirements and disclosure template:
   
https://github.com/apache/fory/blob/main/AI_POLICY.md#9-contributor-checklist-for-ai-assisted-prs
 -->
   
   - [ ] Substantial AI assistance was used in this PR: no
   - [ ] If `yes`, I included a completed [AI Contribution 
Checklist](https://github.com/apache/fory/blob/main/AI_POLICY.md#9-contributor-checklist-for-ai-assisted-prs)
 in this PR description and the required `AI Usage Disclosure`.
   - [ ] If `yes`, my PR description includes the required `ai_review` summary 
and screenshot evidence of the final clean AI review results from both fresh 
reviewers on the current PR diff or current HEAD after the latest code changes.
   
   <!-- If substantial AI assistance = `yes`, paste the completed checklist and 
disclosure block here, including the final ai_review summary and screenshot 
evidence from both fresh reviewers on the current PR diff or current HEAD after 
the latest code changes. -->
   
   ## Does this PR introduce any user-facing change?
   
   <!--
   If any user-facing interface changes, please [open an 
issue](https://github.com/apache/fory/issues/new/choose) describing the need to 
do so and update the document if necessary.
   
   Delete section if not applicable.
   -->
   
   - [ ] Does this PR introduce any public API change?
   - [ ] Does this PR introduce any binary protocol compatibility change?
   
   ## Benchmark
   
   <!--
   When the PR has an impact on performance (if you don't know whether the PR 
will have an impact on performance, you can submit the PR first, and if it will 
have impact on performance, the code reviewer will explain it), be sure to 
attach a benchmark data here.
   
   Delete section if not applicable.
   -->
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to