Skip to content

Fix nested generic typerefs applying generic params at the wrong level #59262

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 1 commit into from
Jun 30, 2022

Conversation

augusto2112
Copy link
Contributor

@augusto2112 augusto2112 commented Jun 3, 2022

Generic params of typerefs are supposed to be "attached" on the level
they belong, not as a flat list, unlike other parts of the system. Fix
the application of bound generic params by checking how many were
already applied in the hierarchy and ignoring those already attached.

@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

if (auto parentDescriptor = readParentContextDescriptor(descriptor))
if (parentDescriptor->isResolved())
if (auto resolvedParent = parentDescriptor->getResolved())
parent = readNominalTypeFromDescriptor(metadata, resolvedParent);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure if this is ok, I'm passing the metadata of the current descriptor, not the parent.

@augusto2112 augusto2112 force-pushed the nested-generic-typeref branch from e95c3b3 to 868feb7 Compare June 3, 2022 22:46
@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

@augusto2112 augusto2112 requested a review from mikeash June 3, 2022 22:51
@augusto2112 augusto2112 force-pushed the nested-generic-typeref branch from 868feb7 to 50a9f04 Compare June 4, 2022 00:12
@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

Copy link
Contributor

@mikeash mikeash left a comment

Choose a reason for hiding this comment

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

One minor request, LGTM.

if (Parent)
GenericParams.erase(GenericParams.begin(),
GenericParams.begin() +
GetNumberOfGenericParametersInHierarchy(Parent));
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a bounds check here to fail gracefully if GetNumberOfGenericParametersInHierarchy(Parent) > GenericParams.size()? We sometimes get weird values due to corrupt or misidentified data in the target process.

Copy link
Contributor

@adrian-prantl adrian-prantl left a comment

Choose a reason for hiding this comment

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

Nice!

@@ -283,6 +283,24 @@ class NominalTypeRef final : public TypeRef, public NominalTypeTrait {
class BoundGenericTypeRef final : public TypeRef, public NominalTypeTrait {
std::vector<const TypeRef *> GenericParams;

static uint64_t
Copy link
Contributor

Choose a reason for hiding this comment

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

Doxygen comment?

Copy link
Contributor

Choose a reason for hiding this comment

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

(What's not obvious from the name is that this counts the generic parameters in the parent only.)

@augusto2112 augusto2112 force-pushed the nested-generic-typeref branch from 50a9f04 to acae3d2 Compare June 7, 2022 22:53
@augusto2112 augusto2112 requested a review from rjmccall June 7, 2022 22:54
@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

/// single flat array.
template <typename T = BuilderType,
std::enable_if_t<std::is_same<T, reflection::TypeRefBuilder>::value,
bool> = true>
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of hardcoding TypeRefBuilder here, it might be cleaner to look for a new trait on BuilderType, so we can do enable_if_t<BuilderType::needsToPrecomputeParentGenericContextShapes> or something like that.

@augusto2112 augusto2112 force-pushed the nested-generic-typeref branch 2 times, most recently from 1bbc169 to 07eaa56 Compare June 16, 2022 22:55
@augusto2112
Copy link
Contributor Author

@swift-ci test

@augusto2112
Copy link
Contributor Author

@jckarter updated

@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

@@ -64,6 +64,8 @@ class ASTBuilder {
using BuiltRequirement = swift::Requirement;
using BuiltSubstitutionMap = swift::SubstitutionMap;

static constexpr bool needsToPrecomputeParentGenericContextShapes = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we Doxygen-document what this parameter means?

auto node = buildContextMangling(descriptor, dem);
if (!node || node->getKind() != Node::Kind::Type)
return BuiltTypeDecl();
std::vector<size_t> paramsPerLevel;
Copy link
Contributor

Choose a reason for hiding this comment

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

llvm::SmallVector<size_t, 4> ?

return BuiltTypeDecl();
std::vector<size_t> paramsPerLevel;
size_t runningCount = 0;
std::function<void(ContextDescriptorRef current, size_t &)> countLevels =
Copy link
Contributor

Choose a reason for hiding this comment

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

Comment what the lambda does?

@augusto2112 augusto2112 requested a review from jckarter June 21, 2022 19:52
@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

Generic params of typerefs are supposed to be "attached" on the level
they belong, not as a flat list, unlike other parts of the system. Fix
the application of bound generic params by checking how many were
already applied in the hierarchy and ignoring those already attached.
@augusto2112 augusto2112 force-pushed the nested-generic-typeref branch from 07eaa56 to 6a82edd Compare June 22, 2022 23:33
@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

@augusto2112
Copy link
Contributor Author

Seems like this is failing for some other reason:

error: terminated(1): /Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swiftpm-macosx-x86_64/x86_64-apple-macosx/release/swiftpm-xctest-helper /Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swiftpm-macosx-x86_64/x86_64-apple-macosx/release/SwiftPMPackageTests.xctest /var/folders/pf/p5g2vb2j0yx1x6vlmxdppc700000gn/T/TemporaryFile.ke3aih output:
    error: unableToLoadBundle("/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swiftpm-macosx-x86_64/x86_64-apple-macosx/release/SwiftPMPackageTests.xctest")
    2022-06-23 00:26:01.911 swiftpm-xctest-helper[70753:3102817] Error loading /Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swiftpm-macosx-x86_64/x86_64-apple-macosx/release/SwiftPMPackageTests.xctest/Contents/MacOS/SwiftPMPackageTests:  dlopen(/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swiftpm-macosx-x86_64/x86_64-apple-macosx/release/SwiftPMPackageTests.xctest/Contents/MacOS/SwiftPMPackageTests, 265): Library not loaded: @rpath/libswift_Concurrency.dylib
      Referenced from: /Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swiftpm-macosx-x86_64/x86_64-apple-macosx/release/SwiftPMPackageTests.xctest/Contents/MacOS/SwiftPMPackageTests
      Reason: image not found

@augusto2112
Copy link
Contributor Author

@swift-ci smoke test

@augusto2112 augusto2112 merged commit 1398760 into swiftlang:main Jun 30, 2022
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.

4 participants