Skip to content

[ownership] When computing usesNotContainedWithinLifetime make sure the error is only a use not in lifetime error. #33618

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

Conversation

gottesmm
Copy link
Contributor

Otherwise, we can return true in cases where we do not have a proper linear
lifetime which can occur in the presence of destructures.

rdar://problem/67698939

…he error is only a use not in lifetime error.

Otherwise, we can return true in cases where we do not have a proper linear
lifetime which can occur in the presence of destructures.

<rdar://problem/67698939>
@gottesmm gottesmm requested a review from atrick August 24, 2020 21:22
// Return true if we /did/ found an error and when emitting that error, we
// If we found any error except for uses outside of our lifetime, bail.
if (error.getFoundLeak() || error.getFoundOverConsume() ||
error.getFoundUseAfterFree())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Eventually I may want to have some sort of enum here. Makes me nervous doing these sorts of exhaustive checks. But this code doesn't change too much so I think it is ok for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW, I find it easier to think about APIs that don't involve double-negative. i.e. is should be '!usesContainded', not 'usesNotContained'

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok. I am fine with changing that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am going to invert that in a follow on commit.

@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm
Copy link
Contributor Author

@swift-ci test source compatibility

@gottesmm
Copy link
Contributor Author

@swift-ci benchmark

@swift-ci
Copy link
Contributor

Performance: -O

Improvement OLD NEW DELTA RATIO
FlattenListLoop 2471 1632 -34.0% 1.51x (?)
FlattenListFlatMap 5071 4500 -11.3% 1.13x (?)
ObjectiveCBridgeStubFromNSString 876 807 -7.9% 1.09x (?)

Code size: -O

Performance: -Osize

Code size: -Osize

Performance: -Onone

Regression OLD NEW DELTA RATIO
String.data.Medium 115 129 +12.2% 0.89x (?)
String.data.LargeUnicode 124 139 +12.1% 0.89x (?)

Code size: -swiftlibs

How to read the data The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

@gottesmm gottesmm merged commit 9057123 into swiftlang:master Aug 31, 2020
@gottesmm gottesmm deleted the pr-bb7b96b4e43e9b8289ab38ff2613f251e373f0f3 branch August 31, 2020 18:17
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