Add code action for hiding imports

[expipiplus1]

It would be nice if there was a code action for hiding imports which are unused and being shadowed by local declarations.

This is complicated because it requires some detailed information on the provenance of these names in order to hide them (for example if they are record fields).

An example:

Given the following warning:

triangle/Main.hs:83:26: warning: [-Wname-shadowing]
    This binding for ‘window’ shadows the existing bindings
      imported from ‘Graphics.Vulkan’ at triangle/Main.hs:(29,1)-(45,59)
      (and originally defined in ‘Graphics.Vulkan.Extensions.VK_NN_vi_surface’)
      imported from ‘Graphics.Vulkan’ at triangle/Main.hs:(29,1)-(45,59)
      (and originally defined in ‘Graphics.Vulkan.Extensions.VK_KHR_xlib_surface’)
      imported from ‘Graphics.Vulkan’ at triangle/Main.hs:(29,1)-(45,59)
      (and originally defined in ‘Graphics.Vulkan.Extensions.VK_KHR_xcb_surface’)
      imported from ‘Graphics.Vulkan’ at triangle/Main.hs:(29,1)-(45,59)
      (and originally defined in ‘Graphics.Vulkan.Extensions.VK_KHR_android_surface’)

To the hiding list of Graphics.Vulkan add

  XlibSurfaceCreateInfoKHR(window)
, XcbSurfaceCreateInfoKHR(window)
, ViSurfaceCreateInfoNN(window)
, AndroidSurfaceCreateInfoKHR(window)

At the moment this is a pain, as one has to visit each of those modules and find out which record is exposing that name.

[lorenzo]

An alternate code action could be to make the shadowed function come from a qualified module instead. I often choose to fully qualify things when getting name conflicts

[fendor]

Is there a tool to do it already? E.g. could hsimport do that?

[fendor]

Hsimport does not seem to be able to do that, maybe we can add that to hsimport? It seems at least to be a feature they might want.

[lorenzo]

@fendor that sounds like a great idea!

[fendor]

I am implementing the feature upstream in #18

[expipiplus1]

Thanks!

…

On Wed, 29 May 2019, 21:33 fendor, ***@***.***> wrote: I am implementing the feature upstream in #18 <https://github.com/dan-t/hsimport/pull/18> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1191?email_source=notifications&email_token=AAGRJXFQB45OCMIR36WS3RLPX3SB7A5CNFSM4HHWAJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQR5OY#issuecomment-497098427>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGRJXA7D6M6GPFZ4CEJWU3PX3SB7ANCNFSM4HHWAJOQ> .

[fendor]

Not yet done! For a more complete implementation, the issue #19 needs to be implemented as discussed with the author. However, I wont be able to do it before august.
Afterwards, diagnostics must be parsed to offer the right Code Action. However, the general concept is already implemented in HIE, so as soon as upstream support is implemented and published.

[fendor]

This can be implemented now, since we have implemented the required features upstream in hsimport!