[ABANDONED] 'Go To Declaration' won't work from a definition

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] 'Go To Declaration' won't work from a definition

    Nordic are very fond of this kind of thing:

    C Source Code

    1. /** @brief Macro for forwarding the new implementation. */
    2. #define nrf_drv_gpiote_init nrfx_gpiote_init
    3. /** @brief Macro for forwarding the new implementation. */
    4. #define nrf_drv_gpiote_is_init nrfx_gpiote_is_init
    5. /** @brief Macro for forwarding the new implementation. */
    6. #define nrf_drv_gpiote_uninit nrfx_gpiote_uninit
    7. /** @brief Macro for forwarding the new implementation. */
    8. #define nrf_drv_gpiote_out_init nrfx_gpiote_out_init
    9. /** @brief Macro for forwarding the new implementation. */
    10. #define nrf_drv_gpiote_out_uninit nrfx_gpiote_out_uninit
    11. /** @brief Macro for forwarding the new implementation. */
    12. #define nrf_drv_gpiote_out_set nrfx_gpiote_out_set
    Display All
    ie, renaming functions via #defines.

    So, for example, in my code I might call nrf_drv_gpiote_init:

    C Source Code

    1. err_code = nrf_drv_gpiote_init();
    2. APP_ERROR_CHECK(err_code);

    If I do either 'Go To Definition' or 'Go To Declaration' on that call, they both end up at the #define



    C Source Code

    1. /** @brief Macro for forwarding the new implementation. */
    2. #define nrf_drv_gpiote_in_init nrfx_gpiote_in_init
    Which is all fine and correct.


    But, if I select nrfx_gpiote_in_init on that #define line, then 'Go To Declaration' will go to the definition - not the declaration:

    C Source Code

    1. nrfx_err_t nrfx_gpiote_in_init(nrfx_gpiote_pin_t pin,
    2. nrfx_gpiote_in_config_t const * p_config,
    3. nrfx_gpiote_evt_handler_t evt_handler)
    4. {
    5. NRFX_ASSERT(pin < NUMBER_OF_PINS);
    6. nrfx_err_t err_code = NRFX_SUCCESS;
    7. :
    8. :

    This is WRONG!


    And 'Go To Declaration' at that point does nothing.

    Why is this important?

    Because, as is common practice, the documentation is with the declaration - not the definition:

    C Source Code

    1. /**
    2. * @brief Function for initializing a GPIOTE input pin.
    3. * @details The input pin can act in two ways:
    4. * - lower accuracy but low power (high frequency clock not needed)
    5. * - higher accuracy (high frequency clock required)
    6. *
    7. * The initial configuration specifies which mode is used.
    8. * If high-accuracy mode is used, the driver attempts to allocate one
    9. * of the available GPIOTE channels. If no channel is
    10. * available, an error is returned.
    11. * In low accuracy mode SENSE feature is used. In this case only one active pin
    12. * can be detected at a time. It can be worked around by setting all of the used
    13. * low accuracy pins to toggle mode.
    14. * For more information about SENSE functionality, refer to Product Specification.
    15. *
    16. * @param[in] pin Pin.
    17. * @param[in] p_config Initial configuration.
    18. * @param[in] evt_handler User function to be called when the configured transition occurs.
    19. *
    20. * @retval NRFX_SUCCESS If initialization was successful.
    21. * @retval NRFX_ERROR_INVALID_STATE If the driver is not initialized or the pin is already used.
    22. * @retval NRFX_ERROR_NO_MEM If no GPIOTE channel is available.
    23. */
    24. nrfx_err_t nrfx_gpiote_in_init(nrfx_gpiote_pin_t pin,
    25. nrfx_gpiote_in_config_t const * p_config,
    26. nrfx_gpiote_evt_handler_t evt_handler);
    Display All

  • Hello,

    Thank you for your inquiry.
    We tried to reproduce the issue but it was not possible with our simplified examples.
    Could you point me to the correct Nordic SDK source for reference?
    Which Embedded Studio version are you using? Does the behaviour change when using the latest version?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Actually, it's not limited to just the definitions redirected via macros as described.

    I frequently find that 'Got To Declaration' won't even work on a "simple", un-obfuscated definition.

    The behaviour doesn't seem to be entirely consistent: sometimes it does work, often it doesn't.

    I've not been able to spot any pattern in when it does & doesn't work (other than with the macro stuff).

    I get a similar problem with header file names: usually, after selecting a header file name in a #include, 'Go To Definition' will open that header. Except when it doesn't.

    I have seen this behaviour ever since I start using SES with the Nordic nRF52 SDK v15.0.0, and now on v15.3.0

    SES version is:

    SES wrote:

    SEGGER Embedded Studio for ARM
    Release 3.40 Build 2018052200.36079
    Windows x64


    © 2014-2018 SEGGER Microcontroller GmbH
    © 1997-2018 Rowley Associates Ltd.


    GCC/BINUTILS: Built using the GNU ARM Embedded Toolchain version 7-2017-q4-major source distribution


    Clang/LLVM: Built using the version 6.0.0 source distribution
    Using a later version of SES with the Nordic SDK caused too much grief last time I tried it ...

    Is it possible to have 2 different versions of SES installed at the same time on the same PC?

    EDIT

    I see that the Nordic SDK v15.3.0 now recommends SES v4.12 - so I could give that a go. But the question about multiple SES versions on the same PC still stands ...

    The post was edited 1 time, last by awneil: updated information ().