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

Use DirectedCodegen #548

Merged
merged 23 commits into from
Jul 1, 2022
Merged

Conversation

gosar
Copy link
Contributor

@gosar gosar commented May 24, 2022

Migrating the code generator to use Smithy's new and recommended DirectedCodegen.

This PR is dependent on related change in smithy repo - smithy-lang/smithy#1237 and smithy-lang/smithy#1289 which haven't been released yet. Once they are released, this PR can be merged into main.

Testing by regenerating based on new code

Clients

yarn generate-clients && yarn test:protocols

AWS SDKs, Generic client (under /private/aws-echo-service) and Protocol tests (under /private) regenerates without any diffs.

SSDKs

yarn generate-clients -s && yarn test:server-protocols

Generated SSDK isn't committed to main, but see the differences based on a baseline that was committed to a branch just to enable this comparison pre/post DirectedCodegen - gosar/aws-sdk-js-v3@generated-ssdk-Jun28...gosar:aws-sdk-js-v3:generated-ssdk-Jun28-directed-codegen. The base for this is generated-ssdk-Jun28 branch which is based on smithy-1.21.0 and smithy-typescript main branch. And the diff is against generated-ssdk-Jun28-directed-codegen which is based on smithy/main (unreleased) and smithy-typescript/directed-codegen branch (this PR branch).
As seen in the link, there are 2 types of changes.

  1. Some related to core differences in Smithy, like deprecating sets. I see yarn test:server-protocols is actually broken because of some changed. But this will have to be taken up separately. It does not affect the DirectedCodegen migration.
  2. And also some code location is rearranged within a file. I think the differences are ok, especially for SSDK.

Misc

I made and committed some PRs independently already to reduce the diffs in this PR.
#541
#542
#544
#545
#547
#551
#559
#564

The code has a few TODOs and refactoring that I can be taken up separately. But at this point, the generator via DirectedCodegen is functionally equivalent to before.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@gosar gosar force-pushed the directed-codegen branch from 2cd40af to 0ebc723 Compare May 24, 2022 22:38
@gosar gosar changed the title Directed codegen Use DirectedCodegen May 25, 2022
@gosar gosar force-pushed the directed-codegen branch from 0ebc723 to e16e80e Compare May 25, 2022 01:19
@gosar gosar force-pushed the directed-codegen branch 2 times, most recently from 9b76732 to de838cc Compare May 27, 2022 23:22
@gosar gosar force-pushed the directed-codegen branch 5 times, most recently from 0c166f5 to 69280b6 Compare June 7, 2022 04:32
@mtdowling
Copy link
Member

Looking good!

@gosar gosar force-pushed the directed-codegen branch 2 times, most recently from 5ec7130 to 21cd6f7 Compare June 18, 2022 08:59
@gosar gosar marked this pull request as ready for review June 18, 2022 09:05
@gosar gosar requested a review from a team as a code owner June 18, 2022 09:05
Comment on lines +401 to +405
// Write each custom file.
for (TypeScriptIntegration integration : directive.context().integrations()) {
LOGGER.finer(() -> "Calling writeAdditionalFiles on " + integration.getClass().getCanonicalName());
integration.writeAdditionalFiles(
directive.settings(),
directive.model(),
directive.symbolProvider(),
directive.context().writerDelegator()::useFileWriter);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this loop here can be removed by moving integration.writeAdditionalFiles to integration.customize which CodegenDirector will call.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be awesome if we can do it in the same customization loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think this can be done as a refactoring later.

shape.accept(this);
}
}
for (Shape shape : TopologicalIndex.of(model).getRecursiveShapes()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the generated shapes are not topo sorted. It causes a lot of import statements in the models_0.ts from models_1.ts and vise versa. It will cause the TS compliler consumes more memory than it needs. Can you add the toposort to the new directed codegen visitor? We want models_N.ts file only has import statement to its previous files.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will also make the generated diff a lot cleaner.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want models_N.ts file only has import statement to its previous files.

Hmm, I didn't understand this mattered.

Shape generation already does do topo sort.

This reordering is because CodegenDirector does generation for Service before visiting shapes. I thought this rearrangement was not a big deal other than 1 time diff. But now I'm going to evaluate to confirm if it is good to switch the order of those steps in CodegenDirector for all generators - seems reasonable to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing the order in Smithy - smithy-lang/smithy#1289. Will regenerate SDKs once approved to confirm diffs are gone.

Comment on lines 379 to 377
// TODO: do all of these parts below are before/after?
SymbolVisitor.writeModelIndex(directive.connectedShapes().values(), directive.symbolProvider(),
directive.fileManifest());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a new customization interface to modify the model or settings? If so we need to run it before generation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is not a new customization. This is just what CodegenVisitor did at here to write the models/index.ts. So this seems in the correct place. I meant to remove that TODO but forget. Removing now.

Comment on lines +401 to +405
// Write each custom file.
for (TypeScriptIntegration integration : directive.context().integrations()) {
LOGGER.finer(() -> "Calling writeAdditionalFiles on " + integration.getClass().getCanonicalName());
integration.writeAdditionalFiles(
directive.settings(),
directive.model(),
directive.symbolProvider(),
directive.context().writerDelegator()::useFileWriter);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be awesome if we can do it in the same customization loop.

gosar added 20 commits July 1, 2022 15:53
Doesn't generate everything though, but compiles and can run the generator
Generates static files, index.ts, etc.

Fixes imports that were `../` instead of `./`
Instead of DeferredWriter passes the WriterDelegator along in GenerationContext
so generateProtocolTests can create the file only if any tests need to be
written.

This is alternative to smithy-lang@09b9956
from smithy-lang#360. It is going back to
using writerDelegator like before (and picking the fileName inside the test
generation logic, instead of in DirectedTypeScriptCodegen.
The 2 SmithyBuildPlugins have duplication, which can be reduced via refactoring

Ran `yarn generate-clients -s && yarn test:server-protocols` in aws-sdk-js-v3
with this commit. Compared the generated ssdks with
https://github.com/gosar/aws-sdk-js-v3/tree/f47b48a1eb1187657f489b4e041f979e72e0134d
and found there were differences but only some moving around of code within
some files.
Given the plugins have moved to DirectedTypeScriptCodegen
The generator does not produce any .tsx files.
@gosar gosar force-pushed the directed-codegen branch from a295b49 to a398fec Compare July 1, 2022 23:23
Copy link
Contributor

@AllanZhengYP AllanZhengYP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approve the rebase

@gosar gosar merged commit be2d6ac into smithy-lang:directed-codegen Jul 1, 2022
@gosar gosar mentioned this pull request Aug 31, 2022
milesziemer added a commit to milesziemer/smithy-typescript that referenced this pull request Sep 30, 2022
The logic of `writeAdditionalFiles` was moved into `customize` as
a follow up on the discussion here:
smithy-lang#548 (comment)
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 this pull request may close these issues.

4 participants