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

[Feature request] Code fix to add unsafe block #25926

Open
Neme12 opened this issue Apr 4, 2018 · 4 comments
Open

[Feature request] Code fix to add unsafe block #25926

Neme12 opened this issue Apr 4, 2018 · 4 comments
Labels
Milestone

Comments

@Neme12
Copy link
Contributor

Neme12 commented Apr 4, 2018

class C
{
    void M()
    {
        int* p;
    }
}

We could provide a code fix to either:

  1. Wrap the code in a new unsafe block
  2. Make the containing member/local function unsafe
  3. Make the containing type unsafe

Possibly all 3 options.

related to #25722 We could potentially extend this if unsafe is disallowed in the project to offer both in one fix (Add unsafe block and allow unsafe in this project) but given that unsafe code is not very common and we don't really encourage it either, I'm actually OK with this being a 2-step fix (Add unsafe block + Allow unsafe code in this project on the added block) and having these features completely unrelated.

Tagging @jcouv @CyrusNajmabadi

@CyrusNajmabadi
Copy link
Member

Seems reasonable. I would separate out the fixes that change the project vs the fixes that update the source code.

@jcouv jcouv added the Area-IDE label Apr 5, 2018
@Neme12
Copy link
Contributor Author

Neme12 commented Apr 6, 2018

BTW, I don't ever use unsafe so I don't actually see myself using this... @jcouv @CyrusNajmabadi is this something you would find useful?

@CyrusNajmabadi
Copy link
Member

In the rare cases i use unsafe... sure :)

But there's probably several dozen more compiler errors that i would benefit from fixes more than this :)

@jcouv
Copy link
Member

jcouv commented Apr 6, 2018

I agree with Cyrus. The unsafe project fixer makes sense to me because the pain of going into project settings is high.
On the other hand, the fixer to add unsafe keyword or block in the current method isn't nearly as valuable, in my opinion.

@jinujoseph jinujoseph added this to the Unknown milestone Apr 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants