-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[stdlib] Add consuming/owned annotations to Collection implementations #19360
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
@swift-ci please smoke benchmark |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: Swift libraries
How to read the dataThe 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
|
@swift-ci please smoke test compiler performance |
@swift-ci please smoke test |
0459317
to
55eaf41
Compare
@swift-ci please smoke benchmark |
@swift-ci please smoke test |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: Swift libraries
How to read the dataThe 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
|
55eaf41
to
c753163
Compare
@swift-ci please test |
Build failed |
@@ -64,22 +64,22 @@ class Myclass2 { | |||
|
|||
arr1.append(1) | |||
// FIXME: missing append() | |||
// CHECK: dref: FAILURE for 'append' usr=s:Sa6appendyyxF | |||
// CHECK: type: (inout Array<Int>) -> (Int) -> () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nkcsgexi @benlangmuir not entirely sure what this was testing so the fix here was just to make it match the new output... Array.append(_:)
now takes its argument owned so the mangled name changed but not sure about the following line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The type change from (inout Array<Int>) -> (Int) -> ()
to (inout Array<Int>) -> () -> ()
is bogus. I assume that means we aren't handling owned et. al. correctly in type reconstruction. @slavapestov what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So would it be better to XFAIL this one for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can go ahead and XFAIL it, please do file a radar though.
Build failed |
// CHECK-NEXT: strong_retain %1 : $Hello | ||
// CHECK-NEXT: [[STACK:%.*]] = alloc_stack $Hello | ||
// CHECK-NEXT: store %1 to [[STACK]] | ||
// CHECK-NEXT: apply [[AEFUN]]<Hello>([[STACK]], %0) | ||
// CHECK-NEXT: dealloc_stack [[STACK]] | ||
// CHECK-NEXT: strong_release %1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eeckstein this was the only non-mangled-name change that was needed
Oops missed an assert-build-only optimizer test... |
@swift-ci please test |
Build failed |
Build failed |
c73c99e
to
24f7304
Compare
@swift-ci please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
swiftlang#19360) * Add consuming/owned annotations to Collection implementations * Update SILOptimizer tests * Fix access_marker_verify test * XFAIL reconstruct_type_from_mangled_name
swiftlang#19360) * Add consuming/owned annotations to Collection implementations * Update SILOptimizer tests * Fix access_marker_verify test * XFAIL reconstruct_type_from_mangled_name
swiftlang#19360) * Add consuming/owned annotations to Collection implementations * Update SILOptimizer tests * Fix access_marker_verify test * XFAIL reconstruct_type_from_mangled_name
swiftlang#19360) * Add consuming/owned annotations to Collection implementations * Update SILOptimizer tests * Fix access_marker_verify test * XFAIL reconstruct_type_from_mangled_name
swiftlang#19360) * Add consuming/owned annotations to Collection implementations * Update SILOptimizer tests * Fix access_marker_verify test * XFAIL reconstruct_type_from_mangled_name
swiftlang#19360) * Add consuming/owned annotations to Collection implementations * Update SILOptimizer tests * Fix access_marker_verify test * XFAIL reconstruct_type_from_mangled_name
Mostly following the protocols, various ownership annotations on collection types:
__consuming
__owned
__consuming
Most changes are in now. I'm leaving
Set
andDictionary
for later as they're in-flux elsewhere.