FAQ
Hi,

I was under the impression that this used to fail to compile:

http://play.golang.org/p/rHD7hUQcZd

Am I mistaken or was something changed in the go compiler?

Go complains if you don't use variables or imports, so it should complain
if there is dead code around in the form of private functions that are not
called in the package and CAN'T be accessed (cause are private) from other
packages.

Was this changed? If so... why?

In the meantime, how can I detect dead code like this, for instance private
functions not called in the package?

Thanks in advance,

Jose

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jan Mercl at Mar 13, 2013 at 12:14 pm

    On Wed, Mar 13, 2013 at 1:06 PM, josvazg wrote:
    Hi,

    I was under the impression that this used to fail to compile:

    http://play.golang.org/p/rHD7hUQcZd

    Am I mistaken or was something changed in the go compiler?
    It's the same for as long as I can remember. IMO, this is permitted,
    in contrast to an unused import or variable, because it _may_ become
    used when referenced/called from other file of the same package, which
    may be included in the build only conditionally. Either through build
    tags of by any other means, including for example naming it explicitly
    in the compiler's command line.
    In the meantime, how can I detect dead code like this, for instance private
    functions not called in the package?
    Probably only using go/{build,parse,ast,types,...}.

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nate Finch at Mar 13, 2013 at 12:15 pm
    This is expected behavior. It has been discussed somewhat recently,
    here: https://groups.google.com/forum/#!searchin/golang-nuts/unreachable/golang-nuts/D-mmT10VBEA/nZqQu2Q7qb4J

    One of the most common reasons for this kind of code to occur "legally" is
    if you're compiling for a specific platform and you have a
    platform-specific function, but don't want to split it out into a whole
    separate conditionally compiled file.

    I'm not sure how easy it would be for the compiler to distinguish between a
    function that is never called and a function that is only conditionally
    called. Someone else might be able to answer that better than me.

    As for finding these things, it definitely should be possible to write a
    tool to parse the code and look for functions that are not exported and are
    not used.... even if the tool gave false positives for conditionally used
    functions, it would still be useful.
    On Wednesday, March 13, 2013 8:06:23 AM UTC-4, josvazg wrote:

    Hi,

    I was under the impression that this used to fail to compile:

    http://play.golang.org/p/rHD7hUQcZd

    Am I mistaken or was something changed in the go compiler?

    Go complains if you don't use variables or imports, so it should complain
    if there is dead code around in the form of private functions that are not
    called in the package and CAN'T be accessed (cause are private) from other
    packages.

    Was this changed? If so... why?

    In the meantime, how can I detect dead code like this, for instance
    private functions not called in the package?

    Thanks in advance,

    Jose
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josvazg at Mar 13, 2013 at 12:50 pm
    Ok thanks!

    Now I understand.

    But, if the compiler can't complain... Shouldn't "go vet" complain instead?

    I mean...
    1) If you run "go vet" with no files or restrictions on a package and...
    2) There is a private function and...
    3) No body calls it in ANY of the FILES in the package...
    Shouldn't go vet say something like:
    # go vet
    somefile.go:32:8: func unused() defined and not used in package localpkg...
    is it dead code?

    (Since if the file is conditionally used, then there is SOME file in which
    it is called.)

    Jose

    El miércoles, 13 de marzo de 2013 13:15:10 UTC+1, Nate Finch escribió:
    This is expected behavior. It has been discussed somewhat recently, here:
    https://groups.google.com/forum/#!searchin/golang-nuts/unreachable/golang-nuts/D-mmT10VBEA/nZqQu2Q7qb4J

    One of the most common reasons for this kind of code to occur "legally" is
    if you're compiling for a specific platform and you have a
    platform-specific function, but don't want to split it out into a whole
    separate conditionally compiled file.

    I'm not sure how easy it would be for the compiler to distinguish between
    a function that is never called and a function that is only conditionally
    called. Someone else might be able to answer that better than me.

    As for finding these things, it definitely should be possible to write a
    tool to parse the code and look for functions that are not exported and are
    not used.... even if the tool gave false positives for conditionally used
    functions, it would still be useful.
    On Wednesday, March 13, 2013 8:06:23 AM UTC-4, josvazg wrote:

    Hi,

    I was under the impression that this used to fail to compile:

    http://play.golang.org/p/rHD7hUQcZd

    Am I mistaken or was something changed in the go compiler?

    Go complains if you don't use variables or imports, so it should complain
    if there is dead code around in the form of private functions that are not
    called in the package and CAN'T be accessed (cause are private) from other
    packages.

    Was this changed? If so... why?

    In the meantime, how can I detect dead code like this, for instance
    private functions not called in the package?

    Thanks in advance,

    Jose
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josvazg at Mar 13, 2013 at 1:02 pm
    I mean this would be very useful cause, when changing package behaviour,
    some auxiliary functions may get unused and you may forget or don't notice
    it.

    It would be a good practice then to do a go vet to clean-up those
    functions, if you may.

    Jose

    El miércoles, 13 de marzo de 2013 13:50:12 UTC+1, josvazg escribió:
    Ok thanks!

    Now I understand.

    But, if the compiler can't complain... Shouldn't "go vet" complain instead?

    I mean...
    1) If you run "go vet" with no files or restrictions on a package and...
    2) There is a private function and...
    3) No body calls it in ANY of the FILES in the package...
    Shouldn't go vet say something like:
    # go vet
    somefile.go:32:8: func unused() defined and not used in package
    localpkg... is it dead code?

    (Since if the file is conditionally used, then there is SOME file in which
    it is called.)

    Jose

    El miércoles, 13 de marzo de 2013 13:15:10 UTC+1, Nate Finch escribió:
    This is expected behavior. It has been discussed somewhat recently,
    here:
    https://groups.google.com/forum/#!searchin/golang-nuts/unreachable/golang-nuts/D-mmT10VBEA/nZqQu2Q7qb4J

    One of the most common reasons for this kind of code to occur "legally"
    is if you're compiling for a specific platform and you have a
    platform-specific function, but don't want to split it out into a whole
    separate conditionally compiled file.

    I'm not sure how easy it would be for the compiler to distinguish between
    a function that is never called and a function that is only conditionally
    called. Someone else might be able to answer that better than me.

    As for finding these things, it definitely should be possible to write a
    tool to parse the code and look for functions that are not exported and are
    not used.... even if the tool gave false positives for conditionally used
    functions, it would still be useful.
    On Wednesday, March 13, 2013 8:06:23 AM UTC-4, josvazg wrote:

    Hi,

    I was under the impression that this used to fail to compile:

    http://play.golang.org/p/rHD7hUQcZd

    Am I mistaken or was something changed in the go compiler?

    Go complains if you don't use variables or imports, so it should
    complain if there is dead code around in the form of private functions that
    are not called in the package and CAN'T be accessed (cause are private)
    from other packages.

    Was this changed? If so... why?

    In the meantime, how can I detect dead code like this, for instance
    private functions not called in the package?

    Thanks in advance,

    Jose
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Damian Gryski at Mar 13, 2013 at 2:04 pm
    Remy has an implementation of this functionality, although it's not in go
    vet:

    https://github.com/remyoudompheng/go-misc/tree/master/deadcod<https://github.com/remyoudompheng/go-misc/tree/master/deadcode>
    e

    Damian

    Le mercredi 13 mars 2013 13:50:12 UTC+1, josvazg a écrit :
    Ok thanks!

    Now I understand.

    But, if the compiler can't complain... Shouldn't "go vet" complain instead?

    I mean...
    1) If you run "go vet" with no files or restrictions on a package and...
    2) There is a private function and...
    3) No body calls it in ANY of the FILES in the package...
    Shouldn't go vet say something like:
    # go vet
    somefile.go:32:8: func unused() defined and not used in package
    localpkg... is it dead code?

    (Since if the file is conditionally used, then there is SOME file in which
    it is called.)

    Jose

    El miércoles, 13 de marzo de 2013 13:15:10 UTC+1, Nate Finch escribió:
    This is expected behavior. It has been discussed somewhat recently,
    here:
    https://groups.google.com/forum/#!searchin/golang-nuts/unreachable/golang-nuts/D-mmT10VBEA/nZqQu2Q7qb4J

    One of the most common reasons for this kind of code to occur "legally"
    is if you're compiling for a specific platform and you have a
    platform-specific function, but don't want to split it out into a whole
    separate conditionally compiled file.

    I'm not sure how easy it would be for the compiler to distinguish between
    a function that is never called and a function that is only conditionally
    called. Someone else might be able to answer that better than me.

    As for finding these things, it definitely should be possible to write a
    tool to parse the code and look for functions that are not exported and are
    not used.... even if the tool gave false positives for conditionally used
    functions, it would still be useful.
    On Wednesday, March 13, 2013 8:06:23 AM UTC-4, josvazg wrote:

    Hi,

    I was under the impression that this used to fail to compile:

    http://play.golang.org/p/rHD7hUQcZd

    Am I mistaken or was something changed in the go compiler?

    Go complains if you don't use variables or imports, so it should
    complain if there is dead code around in the form of private functions that
    are not called in the package and CAN'T be accessed (cause are private)
    from other packages.

    Was this changed? If so... why?

    In the meantime, how can I detect dead code like this, for instance
    private functions not called in the package?

    Thanks in advance,

    Jose
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Mar 13, 2013 at 4:29 pm
    It's issue 4827.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 13, '13 at 12:06p
activeMar 13, '13 at 4:29p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase