Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[csharp] Referencing standalone enum generates uncompilable enum #7657

Closed
donqstepper opened this issue Feb 14, 2018 · 1 comment
Closed

Comments

@donqstepper
Copy link

donqstepper commented Feb 14, 2018

Duplicate, please close
Description

Using the csharp generator, when generating for a swagger definition which uses a referenced type which itself references a standalone enum type, the generated enum code is malformed/does not compile.

Swagger-codegen version

2.3.1 (does not happen in 2.3.0)
Also checked it still occurs on master as of aa6b217

Swagger declaration file content or url
swagger: '2.0'
info:
  title: Enum failure reproduction
  description: "Minimal-ish reproduction of enum generation failure in swagger-codegen 2.3.1"
  version: 1
paths:
  /discussions:
    post:
      operationId: createDiscussion
      summary: Create discussion
      parameters:
        - name: discussion
          in: body
          description: Discussion to create.
          required: true
          schema:
            $ref: "#/definitions/NewDiscussion"
definitions:
  NewDiscussion:
    type: object
    properties:
      status:
        $ref: '#/definitions/DiscussionStatus'
    required:
      - status
  DiscussionStatus:
    type: string
    description: Status of the discussion.
    enum: 
      - "open"
      - "closed"
      - "review"
Command line used for generation

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i swagger.yaml -l csharp -o /tmp/broken -DpackageName=CommentingServiceClient

Steps to reproduce
  1. Run above command line
  2. Attempt to build resulting solution, or open DiscussionStatus.cs and observe:
namespace CommentingServiceClient.Model
{
    /// <summary>
    /// Status of the discussion.
    /// </summary>
    /// <value>Status of the discussion.</value>
    
    public enum DiscussionStatus
    {
        
        /// <summary>
        /// Enum Open for value: open
        /// </summary>
        
        Open = open,
        
        /// <summary>
        /// Enum Closed for value: closed
        /// </summary>
        
        Closed = closed,
        
        /// <summary>
        /// Enum Review for value: review
        /// </summary>
        
        Review = review
    }

}

As you can see, this will not compile.

Related issues/PRs

Duplicate of #7656 - please close

Suggest a fix/enhancement

This issue goes away if you inline the definition of NewDiscussion (or DiscussionStatus, but that also removes the standalone enum class). Unfortunately this is not a viable workaround if you wish to reuse the type.

@donqstepper donqstepper changed the title [csharp] Referencing standalone enum multiple times generates uncompilable enum [csharp] Referencing standalone enum generates uncompilable enum Feb 14, 2018
spanglerco added a commit to spanglerco/swagger-codegen that referenced this issue Oct 1, 2018
Depending on HashMap iteration order, the isString flag added to string
enum values can be lost due to copying a reference to the
allowableValues map to properties that reference the enum. The result is
that the code fails to compile.

This should fix swagger-api#7656, fix swagger-api#7657 (regarded as a duplicate of 7656), and
fix swagger-api#8027 (which also appears to be the same issue).
spanglerco added a commit to spanglerco/swagger-codegen that referenced this issue Oct 2, 2018
Depending on HashMap iteration order, the isString flag added to string
enum values can be lost due to copying a reference to the
allowableValues map to properties that reference the enum. The result is
that the code fails to compile.

This should fix swagger-api#7656, fix swagger-api#7657 (regarded as a duplicate of 7656), and
fix swagger-api#8027 (which also appears to be the same issue).
@frantuma
Copy link
Member

should be fixed in #9936

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants