FAQ
I use kate, the KDE default editor, as my primary development environment.
It has GDB support and configurable build support (Build: go install,
Clean: go clean -i, Quick Build: go build, ...)

Until recently I thought the compiler output would not be suitable for the
error / warning tab of kate, until I ran go fmt as a taget. The output of
go fmt can be parsed into a file / lino information, yet the output of the
compilers can't.

===============
john@deneb:~$ go install github.com/the42/ogdat/...
# github.com/the42/ogdat/ogdatv21
dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76: final
function parameter must have type

john@deneb:~$ go fmt github.com/the42/ogdat/...
dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76:69:
expected type, found ')'
dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:77:2:
expected ';', found 'if'

exit status 2
john@deneb:~$
===============

The biggest difference I could spot is the omission of line offsets in the
compiler messages. Is this intentional?

Compiler: ogdatv21check.go:76:
go fmt: ogdatv21check.go:76:69:


--

Search Discussions

  • Minux at Jan 4, 2013 at 4:44 pm

    On Sat, Jan 5, 2013 at 12:05 AM, Johann Höchtl wrote:

    I use kate, the KDE default editor, as my primary development environment.
    It has GDB support and configurable build support (Build: go install,
    Clean: go clean -i, Quick Build: go build, ...)

    Until recently I thought the compiler output would not be suitable for the
    error / warning tab of kate, until I ran go fmt as a taget. The output of
    go fmt can be parsed into a file / lino information, yet the output of the
    compilers can't.

    ===============
    john@deneb:~$ go install github.com/the42/ogdat/...
    # github.com/the42/ogdat/ogdatv21
    dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76: final
    function parameter must have type

    john@deneb:~$ go fmt github.com/the42/ogdat/...
    dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76:69:
    expected type, found ')'
    dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:77:2:
    expected ';', found 'if'

    exit status 2
    john@deneb:~$
    ===============

    The biggest difference I could spot is the omission of line offsets in the
    compiler messages. Is this intentional?

    Compiler: ogdatv21check.go:76:
    go fmt: ogdatv21check.go:76:69:
    partly because the plan 9 compiler doesn't record column info,
    and partly because the definition of column is not that relevant for utf-8
    source code.

    gofmt/govet just use the go/parser package, and it just reports the byte
    number, so it's
    not strictly a column number.
    as the go/types package is not finished yet, gofmt/govet can't catch every
    error that
    the compiler can, but in the future, they should be able to catch almost
    all errors in
    Go source (esp. for govet who needs to do type checks)

    --
  • Johann Höchtl at Jan 4, 2013 at 5:31 pm

    On 01/04/2013 05:44 PM, minux wrote:

    On Sat, Jan 5, 2013 at 12:05 AM, Johann Höchtl wrote:

    I use kate, the KDE default editor, as my primary development
    environment. It has GDB support and configurable build support
    (Build: go install, Clean: go clean -i, Quick Build: go build, ...)

    Until recently I thought the compiler output would not be suitable
    for the error / warning tab of kate, until I ran go fmt as a taget.
    The output of go fmt can be parsed into a file / lino information,
    yet the output of the compilers can't.

    ===============
    john@deneb:~$ go install github.com/the42/ogdat/.
    <http://github.com/the42/ogdat/.>..
    # github.com/the42/ogdat/ogdatv21
    <http://github.com/the42/ogdat/ogdatv21>
    dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76
    <http://github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76>: final
    function parameter must have type

    john@deneb:~$ go fmt github.com/the42/ogdat/.
    <http://github.com/the42/ogdat/.>..
    dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76:69 <http://github.com/the42/ogdat/ogdatv21/ogdatv21check.go:76:69>:
    expected type, found ')'
    dev/gocode/src/github.com/the42/ogdat/ogdatv21/ogdatv21check.go:77:2
    <http://github.com/the42/ogdat/ogdatv21/ogdatv21check.go:77:2>:
    expected ';', found 'if'

    exit status 2
    john@deneb:~$
    ===============

    The biggest difference I could spot is the omission of line offsets
    in the compiler messages. Is this intentional?

    Compiler: ogdatv21check.go:76:
    go fmt: ogdatv21check.go:76:69:

    partly because the plan 9 compiler doesn't record column info,
    and partly because the definition of column is not that relevant for
    utf-8 source code.

    gofmt/govet just use the go/parser package, and it just reports the byte
    number, so it's
    not strictly a column number.
    as the go/types package is not finished yet, gofmt/govet can't catch
    every error that
    the compiler can, but in the future, they should be able to catch almost
    all errors in
    Go source (esp. for govet who needs to do type checks)
    Thank you for this comprehensive answer! So thinking ahead, the goal
    will be that most (all?) tools will use go/types with go/types being
    UTF-8 aware and this kind of incosistency will go away, ie. will report
    rune offset.

    --
  • Aram Hăvărneanu at Jan 4, 2013 at 5:27 pm
    The compiler will not use go/types since the compiler is written in C, not Go.

    --
    Aram Hăvărneanu

    --
  • Johann Höchtl at Jan 4, 2013 at 8:37 pm

    On 01/04/2013 06:27 PM, Aram Hăvărneanu wrote:
    The compiler will not use go/types since the compiler is written in C, not Go.
    Right, forgot about that, thank you.

    <OT>
    Without asking for it --- more and more functionality of the compiler
    will be duplicated. At some point it might become feasible to have a
    pure Go compiler. Bootstrapping with gccgo.
    </OT>

    --
  • Minux at Jan 4, 2013 at 8:37 pm

    On Sat, Jan 5, 2013 at 1:25 AM, Johann Höchtl wrote:
    On 01/04/2013 05:44 PM, minux wrote:

    gofmt/govet just use the go/parser package, and it just reports the byte
    number, so it's
    not strictly a column number.
    as the go/types package is not finished yet, gofmt/govet can't catch
    every error that
    the compiler can, but in the future, they should be able to catch almost
    all errors in
    Go source (esp. for govet who needs to do type checks)
    Thank you for this comprehensive answer! So thinking ahead, the goal will
    be that most (all?) tools will use go/types with go/types being UTF-8 aware
    and this kind of incosistency will go away, ie. will report rune offset.
    i think only tools written in Go will ever report byte (not rune) offset
    within the line.
    the gc compiler won't get that ability (too large a change with too little
    benefit as
    even the line number is not 100% correct now).

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 4, '13 at 4:13p
activeJan 4, '13 at 8:37p
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase