The documentation for parser.ParseExpr says that the position information in the AST it returns "is undefined". I opserved the result as having position information. This looks like a bug.
https://play.golang.org/p/tpzqDF3EZ_S demonstrates this bug. On Thursday, August 9, 2018 at 11:48:10 PM UTC-4, Mark Nahabedian wrote: > > I've done some further exploring. > > The expression computed by the line > > https://github.com/MarkNahabedian/Goshua/blob/ee72218487f39d2e97ade086df23dbcfcb4c2db3/rete/rule_compiler/rule_compiler.go#L214 > has both a valid Pos() and a valid End(). parseExpression is defined at > > https://github.com/MarkNahabedian/Goshua/blob/ee72218487f39d2e97ade086df23dbcfcb4c2db3/rete/rule_compiler/ast_helpers.go#L12 > It just panic-guards a call to parser.ParseExpr. ParseExpr does > not take a File or FileSet as argument, so how can the expression > it returns have valid Pos values? > > I believe these Pos values are being misinterpreted by > printer.indentList (defined at line 1085 of > https://golang.org/src/go/printer/nodes.go) and causing it to > iintroduce spurious newlines. > > After many hours of mindless coding I now have a function that > will strip Pos information from an ast. When parseExpression > uses that function on its results the spuriouys newline probem > goes away. > > I'm convinced that the ast returned by parser.ParseExpr should > not contain any Pos values since they can't possibly be > meaningful. > > > On Wednesday, July 4, 2018 at 6:38:44 PM UTC-4, Mark Nahabedian wrote: >> >> I'm using go/ast and friends to generate go code. I'm having trouble >> with spurious newlines being added to the output. These cause the >> compiler to balk. >> >> For broader context, my code can be found at >> >> https://github.com/MarkNahabedian/Goshua/tree/master/rete/rule_compiler/rule_compiler.go >> . >> >> The point of the code below is to build a map from strings that are >> the names of go types to a function that returns true when invoked on >> an object of that type. This because I've not found a way to use >> types as first class objects. >> >> // line 214 >> e := parseExpression(fmt.Sprintf( >> `rete.EnsureTypeTestRegistered("%s", func(i interface{}) bool { _, ok := >> i.(%s); return ok })`, >> pType, pType)) >> initFunc.Body.List = append(initFunc.Body.List, >> &ast.ExprStmt{ X: e}) >> >> // line 221 >> newAstFile.Decls = append(newAstFile.Decls, initFunc) >> >> // line 224 >> writeFile(fset, newAstFile, outname) >> >> >> parseExpression is defined in ast_helpers.go. It calls >> parser.ParseExpr and panics if there'sd an error. >> >> writeFile is defined in utils.go. It calls format.Node to >> serialize the generated source code. >> >> >> Here is some sample output that illustrates the problem I'm observing. >> Note that the spurious whitespace is not added consistently. Two of >> these three return statements get the error "not enough arguments to >> return" which go away if the extra newlines are removed. >> >> rete.EnsureTypeTestRegistered("Couple", func(i interface{}) bool { >> _, ok := i.(Couple) >> return >> >> ok >> }) >> rete.EnsureTypeTestRegistered("FaceToFace", func(i interface{}) bool { >> _, >> ok := i.(FaceToFace) >> return ok >> }) >> rete.EnsureTypeTestRegistered("Tandem", func(i interface{}) bool { >> _, ok := i.(Tandem) >> return >> >> ok >> }) >> >> Also observe that in the middle case spurious whitespace is added to >> the assignment/declaration statement rather that the return statement. >> >> Why is this happening and how do I prevent it? >> >> Thanks. >> >> -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
