Skip to content
New issue

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

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

Already on GitHub? # to your account

Make it impossible to create an invalid BuildSettingCondition #4131

Merged

Conversation

sjavora
Copy link
Contributor

@sjavora sjavora commented Feb 12, 2022

Instead of a single when method that takes two optional values, use multiple methods so that it is impossible for both to be nil.

///
/// - Parameters:
/// - platforms: The applicable platforms for this build setting condition.
public static func when(platforms: [Platform]) -> BuildSettingCondition {
BuildSettingCondition(platforms: platforms, config: nil)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: use .none instead of nil to make it more semantically clear

precondition(!(platforms == nil && configuration == nil))
return BuildSettingCondition(platforms: platforms, config: configuration)
public static func when(configuration: BuildConfiguration) -> BuildSettingCondition {
BuildSettingCondition(platforms: nil, config: configuration)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: use .none instead of nil to make it more semantically clear

@tomerd
Copy link
Contributor

tomerd commented Feb 12, 2022

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Feb 12, 2022

thanks @sjavora

@sjavora sjavora force-pushed the disallowImpossibleBuildSettingCondition branch from 23756a4 to fbe0d7a Compare February 12, 2022 20:09
@sjavora
Copy link
Contributor Author

sjavora commented Feb 12, 2022

@tomerd Updated to use .none 👍

In the meantime I also found https://github.com/apple/swift-package-manager/blob/2ea136b5703039b5a596c8a61d090e4dc300ee98/Sources/PackageDescription/PackageDescriptionSerialization.swift#L354

...which seems like it got copy/pasted as there is just one optional parameter. Should I remove that as well? TargetDependencyCondition is Encodable so I'm not 100% sure removing the optionality won't break something...

@tomerd
Copy link
Contributor

tomerd commented Feb 12, 2022

thanks @sjavora

PackageDescriptionSerialization is a bit more sensitive since it drives the manifest parsing. this does need to be improved, but maybe a topic for a separate PR

@tomerd
Copy link
Contributor

tomerd commented Feb 12, 2022

@swift-ci please smoke test

@tomerd tomerd added the ready Author believes the PR is ready to be merged & any feedback has been addressed label Feb 12, 2022
@SDGGiesbrecht
Copy link
Contributor

This is a public, source‐breaking change to the PackageDescription module. (For example, .when(platforms: [.macOS], configuration: nil) will break.) Does the old method need to be retained with tools version constraints and/or deprecation notices?

@tomerd
Copy link
Contributor

tomerd commented Feb 13, 2022

This is a public, source‐breaking change to the PackageDescription module. (For example, .when(platforms: [.macOS], configuration: nil) will break.) Does the old method need to be retained with tools version constraints and/or deprecation notices?

good catch @SDGGiesbrecht did not notice this was in PackageDescription. @sjavora please lets restore the previous API but mark as deprecated, and add availability notation on the new APIs as well e.g..

@available(_PackageDescription, deprecated: 999.0)
public static func when(
         platforms: [Platform]? = nil,
         configuration: BuildConfiguration? = nil
     ) -> BuildSettingCondition

@available(_PackageDescription, introduced: 999.0)
public static func when(
         platforms: [Platform]
     ) -> BuildSettingCondition

we will update 999.0 to 5.7 when we add that version identifier

@sjavora sjavora force-pushed the disallowImpossibleBuildSettingCondition branch from fbe0d7a to a2bc957 Compare February 13, 2022 10:11
Instead of a single method that takes two optional values, use multiple methods so that it is impossible for both to be `nil`.
@sjavora sjavora force-pushed the disallowImpossibleBuildSettingCondition branch from a2bc957 to 60f0253 Compare February 13, 2022 10:13
@sjavora
Copy link
Contributor Author

sjavora commented Feb 13, 2022

Oops! I didn't even think about that 🤦

Thank you for noticing - put back the original method and added @availability.

@tomerd
Copy link
Contributor

tomerd commented Feb 14, 2022

thanks @sjavora this looks good now imo. @SDGGiesbrecht wdyt?

one last ask, since this is user facing API change in the manifest could you please add an entry in the change log, e.g. #4137 (can be done in a separate PR if you prefer)

@SDGGiesbrecht
Copy link
Contributor

👍 Looks good now.

@tomerd
Copy link
Contributor

tomerd commented Feb 14, 2022

@swift-ci please smoke test

@shahmishal
Copy link
Member

@swift-ci please smoke test

4 similar comments
@tomerd
Copy link
Contributor

tomerd commented Feb 14, 2022

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Feb 14, 2022

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Feb 14, 2022

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Feb 15, 2022

@swift-ci please smoke test

@shahmishal
Copy link
Member

@swift-ci please smoke test

1 similar comment
@tomerd
Copy link
Contributor

tomerd commented Feb 15, 2022

@swift-ci please smoke test

@tomerd tomerd merged commit 645fe16 into swiftlang:main Feb 15, 2022
tomerd added a commit that referenced this pull request Feb 15, 2022
motivation: keep change log up to date

changes: document changes from #4131
@tomerd tomerd mentioned this pull request Feb 15, 2022
@sjavora sjavora deleted the disallowImpossibleBuildSettingCondition branch February 15, 2022 08:11
tomerd added a commit that referenced this pull request Feb 15, 2022
motivation: keep change log up to date

changes: document changes from #4131
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
add to change log ready Author believes the PR is ready to be merged & any feedback has been addressed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants