search

haskell / haskell-ide-engine

The engine for haskell ide-integration. Not an IDE
BSD 3-Clause "New" or "Revised" License
2.38k stars 210 forks source link

Add code action for hiding imports #1191

Open expipiplus1 opened 5 years ago

expipiplus1 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

fendor commented 5 years ago

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 commented 5 years ago

@fendor that sounds like a great idea!

fendor commented 5 years ago

I am implementing the feature upstream in #18

expipiplus1 commented 5 years ago

Thanks!

On Wed, 29 May 2019, 21:33 fendor, notifications@github.com 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 https://github.com/haskell/haskell-ide-engine/issues/1191?email_source=notifications&email_token=AAGRJXFQB45OCMIR36WS3RLPX3SB7A5CNFSM4HHWAJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQR5OY#issuecomment-497098427, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGRJXA7D6M6GPFZ4CEJWU3PX3SB7ANCNFSM4HHWAJOQ .

fendor commented 5 years ago

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 commented 4 years ago

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