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

When using go generate, genny does not remove the original go generate comment. #25

Open
ammario opened this issue Jul 24, 2016 · 5 comments

Comments

@ammario
Copy link

ammario commented Jul 24, 2016

When using go generate, genny does not remove the original go generate comment causing subsequent go generates to fail after a gen-gen-file.go is created. This creates the nuisance of having to manually remove the go generate line in generated files.

@xiegeo
Copy link

xiegeo commented Jul 25, 2016

I don't run in to this problem.
With:

package ...

import (
    "bytes"
    "encoding/binary"
    "github.com/cheekybits/genny/generic"
)

//go:generate genny -in=$GOFILE -out=gen_$GOFILE gen "ValueType=int16,int32,float32"

type ValueType generic.Type

func ...

go generate produces:

// This file was automatically generated by genny.
// Any changes will be lost if this file is regenerated.
// see https://github.com/cheekybits/genny

package ...

import (
    "bytes"
    "encoding/binary"
)

func ...

Can you show a simplified version of your file so others can reproduce it?

@ammario
Copy link
Author

ammario commented Jul 25, 2016

This is what I'm using

package util
//go:generate $GOPATH/bin/genny -in=$GOFILE -out=gen-$GOFILE gen "valueType=Thread"


import (
        "sync"

        "github.com/cheekybits/genny/generic"
)

type valueType generic.Type

//valueTypeSlice is a synchronizable slice that supports easy deletion of indices.
type valueTypeSlice struct {
        Slice []valueType
        sync.Mutex
}

//Delete deletes an index from a slice by replacing the value at the end with the last index then reslicing to prune the last element.
//A call to delete must be synchronized via the built in mutex.
//Delete does not check bounds and will panic if index is outside the bounds of the slice.
func (s *valueTypeSlice) Delete(index int) {
        s.Slice[index] = s.Slice[len(s.Slice)-1]
        if len(s.Slice) > 0 {
                s.Slice = s.Slice[:len(s.Slice)-1]
        }

}

go generate (1.6.2) produces

// This file was automatically generated by genny.
// Any changes will be lost if this file is regenerated.
// see https://github.com/cheekybits/genny

package util

import "sync"

//go:generate $GOPATH/bin/genny -in=$GOFILE -out=gen-$GOFILE gen "Thread=Thread"

//ThreadSlice is a synchronizable slice that supports easy deletion of indices.
type ThreadSlice struct {
        Slice []Thread
        sync.Mutex
}

//Delete deletes an index from a slice by replacing the deleted value with the last value of the slice and pruning.
//A call to delete must be synchronized via the built in mutex.
//Delete does not check bounds and will panic if index is outside the bounds of the slice.
func (s *ThreadSlice) Delete(index int) {
        s.Slice[index] = s.Slice[len(s.Slice)-1]
        if len(s.Slice) > 0 {
                s.Slice = s.Slice[:len(s.Slice)-1]
        }

}

@xiegeo
Copy link

xiegeo commented Jul 26, 2016

I can reproduce now.

Change $GOPATH/bin/genny to genny will fix it. After putting $GOPATH/bin/ in your path, and delete any existing gen_* files.

It looks like genny only recognize //go:generate genny ... as a genny command to be removed from the output, and not when the full path is specified.

@ammario
Copy link
Author

ammario commented Jul 27, 2016

Thanks, would this still be considered a bug?

A part of me feels like there should never be //go:generate's lingering?

@loren-osborn
Copy link

Just as a related comment $GOPATH/bin/genny should probably not be used as GOPATH can contain multiple paths separated by colons, but it would be nice if genny could register itself as a “tool” known by the compiler.

I personally have never put the //go:generate in the generic file before as it seems the client calling the generic should usually be the one specifying how it’s expanded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants