Skip to content

[FixCode] Add a diagnosis/fixit to help users convert void pointers. #4108

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 7 commits into from
Aug 9, 2016
Merged

[FixCode] Add a diagnosis/fixit to help users convert void pointers. #4108

merged 7 commits into from
Aug 9, 2016

Conversation

nkcsgexi
Copy link
Contributor

@nkcsgexi nkcsgexi commented Aug 8, 2016

This patch warns the usage of Unsafe[Mutable]Pointer, and fix users' code by replacing it with Unsafe[Mutable]RawPointer.

Resolved bug number: (SR-)


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
All supported platforms @swift-ci Please smoke test and merge
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library only for macOS. Simulator standard libraries and
    device standard libraries are not built.
  3. lldb is not built.
  4. The test and validation-test targets are run only for macOS. The optimized
    version of these tests are not run.

A smoke test on Linux does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library incrementally.
  3. lldb is built incrementally.
  4. The swift test and validation-test targets are run. The optimized version of these
    tests are not run.
  5. lldb is tested.

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
All supported platforms @swift-ci Please test and merge
OS X platform @swift-ci Please test OS X platform
OS X platform @swift-ci Please benchmark
Linux platform @swift-ci Please test Linux platform

Lint Testing

Language Comment
Python @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

…Pointer to Unsafe[Mutable]RawPointer. rdar://27730408

…Pointer<Void> to Unsafe[Mutable]RawPointer. rdar://27730408
@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@swift-ci smoke test OS X platform

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@jrose-apple mind reviewing this?

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@swift-ci smoke test OS X platform

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@swift-ci smoke test OS X platform

IsMutable = BGT->getDecl() == Ctx.getUnsafeMutablePointerDecl();
assert(BGT->getGenericArgs().size() == 1);
auto CanTy = BGT->getGenericArgs().front()->getCanonicalType();
return CanTy->isVoid();
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 you can skip the getCanonicalType step here.

@jrose-apple
Copy link
Contributor

I'm a little unhappy with hardcoding this in the compiler, and I'm not sure that UnsafeMutablePointer<Void> is never correct, but the implementation looks fine. @atrick, any comments?

@atrick
Copy link
Contributor

atrick commented Aug 8, 2016

Hard-coding this into the compiler is a last ditch effort to get decent diagnostics (I spent lots of time last week exploring the limits of availability annotations).

I'm not sure "deprecated" is the right language. UnsafePointer will always be a valid type in generic contexts, but people should be strongly discouraged from using it in a concrete bound generic. If they do, it will cause a number of confusing downstream errors, and the diagnostics for those errors will be better if they first rename to UnsafeRawPointer.

@atrick
Copy link
Contributor

atrick commented Aug 8, 2016

@jrose-apple UnsafePointer<Void> is a valid type (not really deprecated), but if a user is spelling that type, then they really should be using UnsafeRawPointer. I would be fine with a warning:
"Unsafe%0Pointer has been replaced by Unsafe%0RawPointer"
We do need a warning to help with code migration because the void* import type has changed and UnsafePointer conversion is restricted.

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@atrick Should the warning be "Unsafe%0Pointer has been replaced by Unsafe%0RawPointer" or "Unsafe%0Pointer has been replaced by Unsafe%0RawPointer"? I thought the later is the case we are handling here specifically.

@jrose-apple
Copy link
Contributor

:-) I think you both fell prey to Markdown's HTML embedding. "Unsafe%0Pointer" (written Unsafe%0Pointer\<Void\>).

@atrick
Copy link
Contributor

atrick commented Aug 8, 2016

I think we both didn't quote the warning string properly. I think it should be
Unsafe%0Pointer<Void> has been replaced by Unsafe%0RawPointer

#4114 has been merged.

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@jrose-apple @atrick Right, I realized what happened the moment I saw my message posting.

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@swift-ci test

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@swift-ci test

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 8, 2016

@swift-ci test

@nkcsgexi
Copy link
Contributor Author

nkcsgexi commented Aug 9, 2016

Slave went offline during the build.
@swift-ci test

@tkremenek tkremenek merged commit 03815af into swiftlang:master Aug 9, 2016
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