Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apparent inconsistency in gofmt replacement rules application #643

Closed
gopherbot opened this issue Mar 4, 2010 · 7 comments
Closed

Apparent inconsistency in gofmt replacement rules application #643

gopherbot opened this issue Mar 4, 2010 · 7 comments

Comments

@gopherbot
Copy link
Contributor

by loughlinmchugh:

I have several files which implement the same functionality for orthogonal types and
following the example of the 
container/vector/Makefile I'm trying to generate these files from a single template file.

As an example of the code in the template:

    package buffer
    import "unsafe"

    type Buffer []interface{}
    func (b *Buffer) Bytes() IntBuffer { return *(*IntBuffer)(unsafe.Pointer(b)) }
    func (b *Buffer) iterate(c chan <- interface{}) {
        for _, v := range *b { c <- v }
        close(c)
    }
    func (b *Buffer) Iter() <-chan interface{} {
        c := make(chan interface{})
        go b.iterate(c)
        return c
    }

and in my Makefile I'm using the following rule to generate a type-specific version:

    generate: buffer.go
        < buffer.go cat\
        | gofmt -r='Buffer -> ByteBuffer'\
        | gofmt -r 'interface{} -> byte'\
        > bytebuffer.go\

When I run make, or when I use the statement gofmt -r='Buffer -> ByteBuffer' directly
Buffer is not replaced with ByteBuffer. 
However interface{} is correctly replaced with byte. The same result occurs regardless
of the order in which the two replacement 
rules are applied.

My platform details:

$GOOS = darwin
$GOARCH = 386
Go release = release.2010-03-04
@peterGo
Copy link
Contributor

peterGo commented Mar 4, 2010

Comment 1:

Read the documentation for the gofmt rewrite rule carefully.
http://golang.org/cmd/gofmt/
The pattern interface{} is a valid Go expression (a composite literal), the pattern
Buffer is not.

@gopherbot
Copy link
Contributor Author

Comment 2 by loughlinmchugh:

The thing is that Buffer is defined elsewhere as:
type Buffer []interface
which is identical to how Vector is defined in container/vector and the make rule is in
essence identical to the 
make rule used there
generate: vector.go vector_test.go
  < vector.go cat\
  | gofmt -r='Vector -> IntVector'\
  | gofmt -r='interface{} -> int'\
  > intvector.go\
and so the behaviour in the case I presented appears inconsistent with code that exists
in the standard pkg 
collection.

@gopherbot
Copy link
Contributor Author

Comment 3 by loughlinmchugh:

And therein was the problem... Buffer was defined in two separate places.
I'll close the issue and hang my head in appropriate shame for being such a thickie
thick thicky!

@gopherbot
Copy link
Contributor Author

Comment 4 by loughlinmchugh:

Apparently there is more going on here than just my stupidity as I have another
situation where apparently valid 
replacement rules aren't being honoured. In this case it's a simple transform for a
method name which doesn't 
result in any change:
gofmt -r 'TestRealloc -> TestPointerRealloc' buffer_test.go > pointer_test.go
is the command-line in question and I've attached the buffer_test.go file it's being
applied to.

Attachments:

  1. buffer_test.go (3040 bytes)

@griesemer
Copy link
Contributor

Comment 5:

Owner changed to g...@golang.org.

Status changed to Accepted.

@griesemer
Copy link
Contributor

Comment 6:

gofmt was broken by a change to the AST which introduced auxiliary node information 
that didn't need to match.

Status changed to Started.

@griesemer
Copy link
Contributor

Comment 7:

This issue was closed by revision b32f22b.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants