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

Refactor property validation and simplify generation #26

Merged
merged 9 commits into from
Jan 19, 2024

Conversation

dfed
Copy link
Owner

@dfed dfed commented Jan 19, 2024

This PR is best reviewed commit by commit, in split view, with whitespace ignored

There's a lot going on here, but the high level is that we are refactoring how we store and generate dependencies to remove a ton of potential issues.

We had a ton of little bugs because we were:

  1. Storing associated information as optional properties away from associated enum cases
  2. Validating our dependency tree twice – once in the dependency tree generator and once during code generation

We fix both of these architectural issues in this PR (in separate commits), as well as a few other minor bugs that I found along the way.

Because we have updated the Dependency.Source – which SafeDITool may persist – this PR is a breaking change and we will need to roll to a 0.3.0 when this merges.

@dfed dfed self-assigned this Jan 19, 2024
@@ -68,13 +68,10 @@ jobs:
linux:
name: Build and Test on Linux
runs-on: ubuntu-latest
container: swift:5.9
Copy link
Owner Author

Choose a reason for hiding this comment

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

following the advice here to avoid this kind of CI failure

case .ifConfigDecl:
return false
}
element.instantiableMacro != nil
Copy link
Owner Author

Choose a reason for hiding this comment

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

I simplified our macro access while I was adding associated types to the Dependency.Source enum in order to share this code.

@@ -35,7 +35,7 @@ public enum FixableInstantiableError: DiagnosticError {
public var description: String {
switch self {
case .dependencyHasTooManyAttributes:
"Dependency can have at most one of @\(Dependency.Source.instantiated), @\(Dependency.Source.received), or @\(Dependency.Source.forwarded) attached macro"
"Dependency can have at most one of @\(Dependency.Source.instantiatedRawValue), @\(Dependency.Source.receivedRawValue), or @\(Dependency.Source.forwardedRawValue) attached macro"
Copy link
Owner Author

Choose a reason for hiding this comment

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

Dependency.Source is no longer a String-backed enum, so we need to use constants for these raw values now.

Copy link

codecov bot commented Jan 19, 2024

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (e488c86) 99.27% compared to head (4e8dd1a) 99.36%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main      #26      +/-   ##
==========================================
+ Coverage   99.27%   99.36%   +0.09%     
==========================================
  Files          39       40       +1     
  Lines        8166     8888     +722     
==========================================
+ Hits         8107     8832     +725     
+ Misses         59       56       -3     
Files Coverage Δ
...s/SafeDICore/Errors/FixableInstantiableError.swift 92.40% <100.00%> (ø)
...ore/Extensions/AttributeListSyntaxExtensions.swift 97.29% <100.00%> (+5.63%) ⬆️
Sources/SafeDICore/Models/Dependency.swift 100.00% <100.00%> (ø)
Sources/SafeDICore/Models/Initializer.swift 98.94% <100.00%> (-0.03%) ⬇️
Sources/SafeDICore/Models/Instantiable.swift 100.00% <ø> (ø)
Sources/SafeDICore/Models/Scope.swift 100.00% <100.00%> (ø)
...rces/SafeDICore/Visitors/InstantiableVisitor.swift 98.08% <100.00%> (-0.12%) ⬇️
Tests/SafeDICoreTests/FileVisitorTests.swift 100.00% <100.00%> (ø)
Tests/SafeDICoreTests/InitializerTests.swift 100.00% <100.00%> (ø)
Tests/SafeDIMacrosTests/InjectableMacroTests.swift 100.00% <100.00%> (ø)
... and 5 more

@@ -2521,7 +3172,7 @@ final class SafeDIToolTests: XCTestCase {
}
}

func test_run_onCodeWithUnfulfillableRenamedReceivedPropertyType_throwsError() async {
Copy link
Owner Author

Choose a reason for hiding this comment

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

I made the tests refer to Aliased rather than Renamed for consistency. We still talk about renaming in the README, but that's fine.

I'm also open to feedback that the case should be case renamed rather than case alias

)
}

func test_run_writesConvenienceExtensionOnRootOfTree_whenReceivedPropertyIsAliasedWasALevelBelowWhereItWasForwarded() async throws {
Copy link
Owner Author

Choose a reason for hiding this comment

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

This test did already succeed, but it still seemed worth having this coverage.

@dfed dfed marked this pull request as ready for review January 19, 2024 20:17
@dfed dfed requested a review from MrAdamBoyd January 19, 2024 20:18
@dfed dfed force-pushed the dfed--refactor-property-resolution branch from 18dc6e5 to 842e32d Compare January 19, 2024 20:27
@dfed dfed force-pushed the dfed--refactor-property-resolution branch from 842e32d to 41f8875 Compare January 19, 2024 20:30
instantiable: instantiable,
scope: instantiatedScope,
type: type
))
}
scope.propertiesToInstantiate.append(contentsOf: additionalPropertiesToInstantiate)
Copy link
Owner Author

Choose a reason for hiding this comment

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

propertiesToInstantiate might not be the best name. propertiesToGenerate?

Copy link
Owner Author

Choose a reason for hiding this comment

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

indeed. 346e1da

return !propertyStack.contains($0.property) && $0.property != property
case .received:
return false
}
}
.map(\.property)
).subtracting(
Copy link
Owner Author

Choose a reason for hiding this comment

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

do we need receivedProperties calculated for both cases? could simplify maybe

Copy link
Owner Author

Choose a reason for hiding this comment

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

ah we got rid of this anyways

Copy link
Collaborator

@MrAdamBoyd MrAdamBoyd left a comment

Choose a reason for hiding this comment

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

Thank you for the walkthrough, approved

@dfed dfed merged commit a2d9db4 into main Jan 19, 2024
10 checks passed
@dfed dfed deleted the dfed--refactor-property-resolution branch January 19, 2024 23:03
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.

2 participants