[BUG] [RUST] Empty field structs generated when name conflict between path parameter and response object field of same name using anyOf

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

An anyOf field in a response body named the same as a request parameter causes the Rust generator to generate an empty struct.

This occurs whether anyOf has one variant or two -- the repro below is identical for these two inputs:

  "anyOf": [
    {
      "type": "string"
    },
    {
      "type": "null"
    }
  ]

and

  "anyOf": [
    {
      "type": "string"
    }
  ]

openapi-generator version

v7.16.0

OpenAPI declaration file content or url

{
  "openapi": "3.1.0",
  "info": {
    "version": "0.1",
    "title": "test case"
  },
  "paths": {
    "/api/get/{field_name}": {
      "get": {
        "parameters": [
          {
            "name": "field_name",
            "in": "path",
            "required": true,
            "schema": {
              "type": "string"
            }
          }
        ],
        "operationId": "getter",
        "responses": {
          "200": {
            "description": "description",
            "content": {
              "application/json": {
                "schema": {
                  "properties": {
                    "field_name": {
                      "anyOf": [
                        {
                          "type": "string"
                        }
                      ]
                    }
                  },
                  "additionalProperties": false,
                  "type": "object"
                }
              }
            }
          }
        }
      }
    }
  }
}

Generation Details

$ docker run --rm -v "${PWD}:/local" openapitools/openapi-generator-cli:v7.16.0 generate \
      -i /local/minimal.json \
      -g rust \
      -o /local/openapi-minimal \
      --global-property debugModels,debugOpenAPI

Actual Output

Produces an empty struct for the field:

// getter_200_response.rs
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Getter200Response {
    #[serde(rename = "field_name", skip_serializing_if = "Option::is_none")]
    pub field_name: Option<Box<models::Getter200ResponseFieldName>>,
}

impl Getter200Response {
    pub fn new() -> Getter200Response {
        Getter200Response {
            field_name: None,
        }
    }
}


// getter_200_response_field_name.rs
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Getter200ResponseFieldName {
}

impl Getter200ResponseFieldName {
    pub fn new() -> Getter200ResponseFieldName {
        Getter200ResponseFieldName {
        }
    }
}

Expected Output

1. For this input, I would expect the same as if the "anyOf" was simplified to a simple type: string output:

// getter_200_response.rs
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Getter200Response {
    #[serde(rename = "field_name", skip_serializing_if = "Option::is_none")]
    pub field_name: Option<String>,
}

impl Getter200Response {
    pub fn new() -> Getter200Response {
        Getter200Response {
            field_name: None,
        }
    }
}

2. For the anyOf with two variants, I would expect the standard Rust enum variant behavior.

Related issues/PRs

#21896

Start with the minimal.json reproduction and run the documented Docker command using the Rust generator. Compare the generated getter_200_response.rs and getter_200_response_field_name.rs files with the expected String output, then investigate how the Rust generator handles anyOf fields when their name conflicts with a path parameter. Done means the one-variant case produces the expected field type and the multi-variant case produces standard enum behavior.