Skip to content

Codegen: allow synth properties of non-synth classes #13258

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

Merged
merged 9 commits into from
Jun 7, 2023

Conversation

redsun82
Copy link
Contributor

@redsun82 redsun82 commented May 23, 2023

This can serve as a basis for #13240.

@redsun82 redsun82 requested review from MathiasVP and d10c May 23, 2023 14:05
@redsun82 redsun82 requested a review from a team as a code owner May 23, 2023 14:05
@github-actions github-actions bot added the Swift label May 23, 2023
@redsun82 redsun82 changed the title Codegen+Swift: allow synth properties of non-synth classes Codegen: allow synth properties of non-synth classes May 24, 2023
@github-actions github-actions bot removed the Swift label May 24, 2023
@redsun82 redsun82 changed the base branch from codeql-cli-2.13.3 to main May 25, 2023 14:03
@redsun82 redsun82 requested review from a team as code owners May 25, 2023 14:03
@redsun82 redsun82 force-pushed the redsun82/swift-synth-properties branch from addae60 to cc271d6 Compare May 25, 2023 14:05
@redsun82 redsun82 removed request for a team May 25, 2023 14:05
Copy link
Contributor

@d10c d10c left a comment

Choose a reason for hiding this comment

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

Looks good! Left a minor comment. Do you think DCA is warranted for this PR?

}


def test_stub_on_class_with_ipa_on_arguments(generate_classes):
assert generate_classes([
schema.Class("MyObject", ipa=schema.IpaInfo(on_arguments={"base": "A", "index": "int", "label": "string"})),
schema.Class("MyObject", ipa=schema.IpaInfo(on_arguments={"base": "A", "index": "int", "label": "string"}),
properties=[schema.SingleProperty("foo", "bar")]),
Copy link
Contributor

Choose a reason for hiding this comment

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

Am I reading this correctly that when you add a simple foo: bar property, it becomes synth=True by default? Or is it because this class is declared as inheriting from class "A" and its foo: bar | synth property on line 575 of test_dbschemegen.py? Basically, I'm finding it hard to follow how the fixtures for this test are set up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea is that all properties of synth classes are synth by default, without needing to explicitly mark it. It might be a bit confusing that synth actually translates to the ipa attribute internally (for historicaly reasons mainly). Would it be clearer if we wrote

    assert generate_classes([
        schema.Class("MyObject", synth=schema.SynthInfo(on_arguments={"base": "A", "index": "int", "label": "string"}),
                     properties=[schema.SingleProperty("foo", "bar")]),
        ]) ==

(that is, substitute all ipa mentions with synth)?

Also, these test files are completely independent, and each tests each python module in isolation. So there's no need to look at test_dbschemegen.py for this test. The *gen.py tests are mostly built around testing that a certain input to the generation (typically a list of schema.Class instances) gives a certain output that is actually fed to the renderer. The tests themselves can be written quite simply, but there is indeed complexity in the generate_classes pytest fixture, which is built to feed the input in the generator under test by intercepting and mocking the loaders, and then intercept the relevant output data fed to the Renderer in the actual code.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, right, I didn't realize that that's what ipa= was doing. Doing that renaming would indeed be clearer, yes. I thought that this PR did the complete renaming, but apparently it's backwards-compatible with ipa, so it's probably also fine as it is.

@MathiasVP
Copy link
Contributor

Looks good! Left a minor comment. Do you think DCA is warranted for this PR?

I don't think this is necessary when no actual .ql or .cpp was changed.

@d10c
Copy link
Contributor

d10c commented Jun 6, 2023

Hi @redsun82, can we resolve the conflicts and merge this soon-ish? I intend to build #13240 on top of this PR, which would obviate the need for a dbscheme change.

@redsun82
Copy link
Contributor Author

redsun82 commented Jun 7, 2023

sorry about the delay @d10c! I've done the renaming (which was just a matter of s/Ipa/Synth/g and s/ipa/synth/g, plus the renaming of two templates). Thank you for the merge and the fix commits! This can be merged now as far as I'm concerned.

Copy link
Contributor

@d10c d10c left a comment

Choose a reason for hiding this comment

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

LGTM! (Though I think someone else also has to approve?)

@redsun82
Copy link
Contributor Author

redsun82 commented Jun 7, 2023

I think it's ok to merge it with your approval. This PR in itself introduces no changes in actually generated code, so it's 0 risk. If when using this feature you'll find issues, we can come back to it with follow up changes.

@redsun82 redsun82 merged commit 357542a into main Jun 7, 2023
@redsun82 redsun82 deleted the redsun82/swift-synth-properties branch June 7, 2023 08:31
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