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

[SR-12912] Fix crash in test targets with Bundle.module in 5.3 #2905

Merged
merged 1 commit into from
Sep 17, 2020

Conversation

MaxDesiatov
Copy link
Contributor

@MaxDesiatov MaxDesiatov commented Sep 3, 2020

Same as #2817, resolves SR-12912 in the release/5.3 branch.

Setting the path for Bundle.module fails in the case where the bundle is accessed during tests.
This uses the already derived bundlePath instead.

…iftlang#2817)

* SR-12912
Setting the path for Bundle.module fails in the case where the bundle is accessed during tests.
This uses the already derived bundlePath instead.

* Only use bundlePath when building a testTarget

* Updating this for discussion in PR. This hardcodes the test path as expected, however, when the target under test accesses Bundle.module, it fails for the same reason as before

* This prefers Bundle.main, but if it is inaccessible it falls back to the build output directory path.

* Cleaned up changes in BuildPlan.swift
Added passing integration test into TestToolTests.swift
Added failing integration test into BasicTests.swift

* Remove integration test from TestToolTests.swift

* Only instantiate Bundle for buildPath if main bundle is not found
@MaxDesiatov
Copy link
Contributor Author

@swift-ci please test

@MaxDesiatov MaxDesiatov changed the title [SR-12912] Fix crash in test targets when accessing Bundle.module in 5.3 [SR-12912] Fix crash in test targets with Bundle.module in 5.3 Sep 3, 2020
@abertelrud
Copy link
Contributor

Looks good to me, though I don't know where we are with being to get things into the SwiftPM 5.3 branch right now.

@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Sep 3, 2020

Should I ping Rick Ballard to clarify this? (He's the release manager to make the decision on whether this can be included, isn't he?)

@abertelrud
Copy link
Contributor

That sounds good; yes, @rballard is release manager for 5.3, with @tomerd for future releases.

@rballard
Copy link
Contributor

rballard commented Sep 3, 2020

I saw the PR! I'm discussing schedules with some other Swift folks and will get back to you soon.

@rballard
Copy link
Contributor

rballard commented Sep 3, 2020

While this is an important fix, at this point in the schedule we're going to hold it; but let's keep the PR open and take it at the first post-5.3 opportunity.

@ffried
Copy link
Contributor

ffried commented Sep 4, 2020

Thanks everyone!

Please correct me if I'm wrong, but this basically renders SPM resources unusable for the following use cases (in Swift 5.3.0 that is):

  • Test targets with resources.
  • Normal (library) targets with resources that have unit tests.

The former is less critical IMHO. I also found a workaround for that and posted it in the forums.

I find it rather difficult, however, to find a workaround for the latter case, since I'd like to avoid having to differentiate how resources are loaded in release vs. debug builds, just so that unit tests don't crash. Also, this would mean that the production code of loading resources is never actually tested.

@chrisballinger
Copy link

If we missed the mark for Xcode 12 GM, I would still really like to see this merged and available for an upcoming Xcode 12 point release, because otherwise it means we can't release SPM support for a popular library that includes resources (Core Data model definitions) and unit test coverage that involves those models: robbiehanson/XMPPFramework#1177

What I'm not quite sure about is if this is merged into a Swift 5.3.1 release, our Package@swift-5.3.swift will remain broken on Swift 5.3.0. Is there a way to specify Package@swift-5.3.1.swift, or will library authors with resources and test coverage need to wait for Swift 5.4 before releasing SPM support?

@3a4oT
Copy link

3a4oT commented Sep 14, 2020

Please ship it with 5.3

@rballard
Copy link
Contributor

At this point in the schedule we need to hold this fix, but I expect us to take it ASAP for the first dot release post-5.3. This is a good question @chrisballinger re: whether we need to define a new package version for compatibility here; I'll chat with @neonichu about that.

@karimhm
Copy link

karimhm commented Sep 17, 2020

Will this fix SR-13560 ?

@rballard
Copy link
Contributor

We've shipped 5.3 and should get this into the next patch release; approved to merge now. (I see @airspeedswift just beat me to it).

I chatted with @neonichu and we agreed that no new format version was needed here, as clients of a package don't run that package's tests, so clients on stock 5.3 shouldn't break when packages they use adopt resources.

@neonichu neonichu merged commit aa589c7 into swiftlang:release/5.3 Sep 17, 2020
@neonichu
Copy link
Contributor

@karimhm I just double-checked and it does not fix this, SR-13560 seems like a separate issue.

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.

10 participants