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

Move more things into codegen-core #1762

Merged
merged 21 commits into from
Sep 27, 2022

Conversation

david-perez
Copy link
Contributor

This moves most things from codegen-client that should be in
codegen-core into codegen-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.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link
Collaborator

@jdisanti jdisanti left a 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
Copy link
Collaborator

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.

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 was surprised too. I've opened #1764; once that's merged, I'll keep the transformer in codegen-client in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

#1764 was merged; I've moved RemoveEventStreamOperations back to the client in 67dc987.

* SPDX-License-Identifier: Apache-2.0
*/

package software.amazon.smithy.rust.codegen.core.smithy.protocols
Copy link
Collaborator

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -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
Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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.

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 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.

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 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) {
Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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.

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 agree with this sentiment in the general case, but:

  1. Untangling the branching on CodegenTarget is diffcult; and
  2. 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 of CodegenTarget 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.

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 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
Copy link
Collaborator

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

david-perez added a commit that referenced this pull request Sep 23, 2022
…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)
@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

david-perez added a commit that referenced this pull request Sep 23, 2022
…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).
@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@david-perez david-perez merged commit 5b7aa7b into main Sep 27, 2022
@david-perez david-perez deleted the davidpz/move-more-things-into-codegen-core branch September 27, 2022 12:33
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.

3 participants