-
Notifications
You must be signed in to change notification settings - Fork 196
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
Move more things into codegen-core
#1762
Move more things into codegen-core
#1762
Conversation
…hings-into-codegen-core
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Love seeing this happen.
It looks like none of the unit tests were moved? Most of them require testutil
to move, which is not so easy. But it looks like you have enough critical mass of classes moved that testutil
should actually move over successfully now. I would definitely prefer the tests move along with the core classes.
@@ -3,13 +3,13 @@ | |||
* SPDX-License-Identifier: Apache-2.0 | |||
*/ | |||
|
|||
package software.amazon.smithy.rust.codegen.client.smithy.transformers | |||
package software.amazon.smithy.rust.codegen.core.smithy.transformers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised to see RemoveEventStreamOperations
used by the server. Was this intentional? It requires allow listing service module names through the smithy-build.json
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was surprised too. I've opened #1764; once that's merged, I'll keep the transformer in codegen-client
in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
||
package software.amazon.smithy.rust.codegen.core.smithy.protocols |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file should be renamed to ProtocolLoader.kt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Done in Rename protocol loader in codegen-core from ClientProtocolLoader ….
@@ -3,12 +3,12 @@ | |||
* SPDX-License-Identifier: Apache-2.0 | |||
*/ | |||
|
|||
package software.amazon.smithy.rust.codegen.client.smithy.generators | |||
package software.amazon.smithy.rust.codegen.core.smithy.generators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this class belongs in rustlang
with the code that uses it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in Move GenericsGenerator into rustlang and rename it to RustGenerics. I also renamed it to RustGenerics
.
@@ -3,7 +3,7 @@ | |||
* SPDX-License-Identifier: Apache-2.0 | |||
*/ | |||
|
|||
package software.amazon.smithy.rust.codegen.client.rustlang | |||
package software.amazon.smithy.rust.codegen.core.rustlang |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think RustReservedWords
should stay in client for now. It needs to be broken up into multiple composed classes since right now it has client-specific logic in it to handle the Unknown
enum variants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we should refactor that bit out. However, I can't keep it in codegen-client
, since BuilderGenerator
, that is codegen-core
depends on it, and we can't have core
depending on client
. We should eventually put BuilderGenerator
in codegen-client
anyway, since in #1342 the server project has its own builder generators. However, if I do so now in this PR, several things break, because the extension functions defined in BuilderGenerator.kt
(StructureShape.builderSymbol
, RuntimeConfig.operationBuildError()
, MemberShape.setterName()
...) are ingrained throughout codegen-core
. Untangling all these is related to the CodegenTarget
and reducing branching cleanup, that we should tackle separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened #1766 to track this.
import software.amazon.smithy.rust.codegen.core.rustlang.rustBlock | ||
import software.amazon.smithy.rust.codegen.core.smithy.CodegenTarget | ||
import software.amazon.smithy.rust.codegen.core.smithy.expectRustMetadata | ||
import software.amazon.smithy.rust.codegen.core.smithy.renamedFrom | ||
import software.amazon.smithy.rust.codegen.core.util.toSnakeCase | ||
|
||
fun CodegenTarget.renderUnknownVariant() = when (this) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function shouldn't get copied into core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my comment here #1762 (comment).
@@ -3,7 +3,7 @@ | |||
* SPDX-License-Identifier: Apache-2.0 | |||
*/ | |||
|
|||
package software.amazon.smithy.rust.codegen.client.smithy.generators | |||
package software.amazon.smithy.rust.codegen.core.smithy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think core should have the concept of CodegenTarget
. Anything that depends on should be kept in client so that it can be individually refactored into core with the target if/else cases removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this sentiment in the general case, but:
- Untangling the branching on
CodegenTarget
is diffcult; and - I'm actually not sure that removing the branching entirely is beneficial. In certain particular core generators, all you need is a quick and dirty
if (target == ...)
to get the job done. In some cases I think that introducing inheritance/composition/customization injections to get rid of the notion ofCodegenTarget
can be detrimental to code maintainability.
CodegenTarget
is used by > 14 generators that this PR places in codegen-core
. Keeping them in codegen-client
entails bringing more things back. It's too ingrained. I think putting CodegenTarget
in codegen-core
is the sweet spot here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened #1765 to track this.
@@ -3,12 +3,11 @@ | |||
* SPDX-License-Identifier: Apache-2.0 | |||
*/ | |||
|
|||
package software.amazon.smithy.rust.codegen.client.smithy | |||
package software.amazon.smithy.rust.codegen.core.smithy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should rename the Core-
prefix out of these now that they're in the actual core module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…degenVisitor` This is a holdover from when the server subproject was started. We've never utilized this model transformer, nor will we have any use for it now, since event stream operations are supported in the server since #1479. See #1762 (comment)
…to `ProtocolLoader`
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
…degenVisitor` (#1764) This is a holdover from when the server subproject was started. We've never utilized this model transformer, nor will we have any use for it now, since event stream operations are supported in the server since #1479. See #1762 (comment).
…hings-into-codegen-core
A new generated diff is ready to view.
A new doc preview is ready to view. |
…hings-into-codegen-core
A new generated diff is ready to view.
A new doc preview is ready to view. |
This moves most things from
codegen-client
that should be incodegen-core
intocodegen-core
.This is a continuation of the efforts started in #1697, #1730.
Testing
No generated diff should be observed.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.