Skip to content

[OSLog] Update compiler stubs and tests #34100

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
Oct 2, 2020
Merged

[OSLog] Update compiler stubs and tests #34100

merged 1 commit into from
Oct 2, 2020

Conversation

guitard0g
Copy link

@guitard0g guitard0g commented Sep 28, 2020

The compiler stubs for testing the OSLog implementation are in need of an update. This change updates the stubs to be consistent with the current OSLog implementation, updates the existing tests, and adds new tests for String and metatype interpolations.

rdar://69719729

@guitard0g
Copy link
Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 058b013ea301732e5823dac4ac854cc426658530

@guitard0g
Copy link
Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - bd36608337a6f1f98e62de952bca871e9e9434be

@guitard0g
Copy link
Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 824edecd8bed9dc92bde31782e5bd9b982e27cc0

@guitard0g
Copy link
Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - f291ddeac2eceebe84a24abdde2f842d3ce478e4

@guitard0g
Copy link
Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 0912810efb3d9106d01469cf0f1d2cd5d2d3f3bc

Copy link
Contributor

@ravikandhadai ravikandhadai left a comment

Choose a reason for hiding this comment

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

Thanks Josh. It is looking great. I have just left a few minor comments.

public static var sensitive: OSLogPrivacy {
OSLogPrivacy(privacy: .sensitive, mask: .none)
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can remove the sensitive options. This property declaration and the following static function declaration: sensitive(mask:) and all references to it.


@_semantics("test_driver")
func intValueWithPrivacyTest() -> OSLogMessage {
return "An integer value \(10, privacy: .sensitive(mask: .hash))"
Copy link
Contributor

Choose a reason for hiding this comment

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

This test is good to have. Thanks for adding it. We can change .sensitive here by .private.

@@ -157,18 +154,30 @@ func testNSObjectInterpolation(nsArray: NSArray) {
// CHECK-NEXT: [[OFFSET3:%.+]] = getelementptr inbounds i8, i8* [[BUFFER]], i{{.*}} 3
// CHECK-64-NEXT: store i8 8, i8* [[OFFSET3]], align 1
// CHECK-32-NEXT: store i8 4, i8* [[OFFSET3]], align 1
// CHECK-NEXT: tail call void @llvm.objc.release
// DOESN'T HAPPEN: tail call void @llvm.objc.release
Copy link
Contributor

Choose a reason for hiding this comment

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

Feel free to delete the "Doesn't happen" line


// CHECK-64-NEXT: tail call swiftcc void @"${{.*}}_os_log_impl_test{{.*}}"({{.*}}, {{.*}}, {{.*}}, {{.*}}, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @{{.*}}, i64 0, i64 0), i8* {{(nonnull )?}}[[BUFFER]], i32 12)
// CHECK-32-NEXT: tail call swiftcc void @"${{.*}}_os_log_impl_test{{.*}}"({{.*}}, {{.*}}, {{.*}}, {{.*}}, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @{{.*}}, i32 0, i32 0), i8* {{(nonnull )?}}[[BUFFER]], i32 8)
// CHECK-NEXT: [[BITCASTED_OBJ_STORAGE:%.+]] = bitcast i8* [[OBJ_STORAGE]] to %swift.opaque*
// CHECK-NEXT: tail call void @swift_arrayDestroy(%swift.opaque* [[BITCASTED_OBJ_STORAGE]], i64 1
Copy link
Contributor

@ravikandhadai ravikandhadai Sep 29, 2020

Choose a reason for hiding this comment

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

Does this SIL instruction use i64 even on 32 bit platforms? You can omit the i64 and the rest if that is not the case.

// CHECK-32: [[BUFFER:%.+]] = tail call noalias i8* @swift_slowAlloc(i{{.*}} 8
// CHECK-64-NEXT: [[STR_STORAGE:%.+]] = tail call noalias i8* @swift_slowAlloc(i{{.*}} 32
// CHECK-32-NEXT: [[STR_STORAGE:%.+]] = tail call noalias i8* @swift_slowAlloc(i{{.*}} 16
// CHECK: call void @llvm.lifetime.start{{.*}}({{.*}}, i8* {{(nonnull )?}}[[STR_STORAGE_PTR:%.*]]
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder what STR_STORAGE_PTR corresponds to. It doesn't quite correspond to the unsafe storage buffers we are creating. Is this SILValue derived from the input argument %0 in the actual SIL?

Copy link
Author

Choose a reason for hiding this comment

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

I believe it corresponds to the unsafe storage buffer but the SIL there is a little bit complicated so I may be interpreting it incorrectly. It goes something like:

  %2 = alloca i64, align 8
  ..
  %12 = tail call noalias i8* @swift_slowAlloc(i64 32, i64 -1) #5 // String storage buffer
  %13 = ptrtoint i8* %12 to i64
  %14 = bitcast i64* %2 to i8*
  call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %14)
  store i64 %13, i64* %2, align 8

What this looks like to me is an indirect way of tracking the lifetime of a pointer to the storage buffer.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for clarifying it.

// CHECK-NEXT: [[OFFSET3:%.+]] = getelementptr inbounds i8, i8* [[BUFFER]], i{{.*}} 3
// CHECK-NEXT: store i8 8, i8* [[OFFSET3]], align 1

// CHECK: [[STR_POINTER:%.*]] = call swiftcc i8* @"${{.*}}getNullTerminatedUTF8Pointer{{.*}}"(i{{.*}} %0, {{.*}} %1
Copy link
Contributor

Choose a reason for hiding this comment

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

It is also good to check that STR_POINTER is stored into the [[BUFFER]] at the right offset.

@guitard0g
Copy link
Author

@swift-ci please test

1 similar comment
@guitard0g
Copy link
Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 1a01fd2a882c03c0552fb3826ba2d45d709af652

@guitard0g
Copy link
Author

@swift-ci please test

@ravikandhadai ravikandhadai self-requested a review October 1, 2020 00:54
@swift-ci
Copy link
Contributor

swift-ci commented Oct 1, 2020

Build failed
Swift Test OS X Platform
Git Sha - 4a13ae96278d0a45e1af33a4f1b3059e82907e4f

Copy link
Contributor

@ravikandhadai ravikandhadai left a comment

Choose a reason for hiding this comment

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

Looks good to me. Thanks Josh!

The compiler stubs for testing the OSLog implementation are in need of an update. This change updates the stubs to be consistent with the current OSLog implementation, updates the existing tests, and adds new tests for String and metatype interpolations.

rdar://69719729
@guitard0g
Copy link
Author

@swift-ci please test

@swift-ci
Copy link
Contributor

swift-ci commented Oct 1, 2020

Build failed
Swift Test Linux Platform
Git Sha - 1fd6ef9

@ravikandhadai
Copy link
Contributor

@swift-ci please test Linux Platform

@swift-ci
Copy link
Contributor

swift-ci commented Oct 2, 2020

Build failed
Swift Test Linux Platform
Git Sha - 1fd6ef9

@ravikandhadai
Copy link
Contributor

@swift-ci Please smoke test Linux Platform

@guitard0g
Copy link
Author

@swift-ci please smoke test

@guitard0g guitard0g merged commit 4e7714b into swiftlang:main Oct 2, 2020
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