Re: [go-nuts] ast.NewPackage errors for built in types

FWIW: I'm not surprised that it's slower because it's handling significantly more of the compilation. The parser is very fast. Adding in type-checking is going to be less fast. IIRC, the packages package also has to make network calls and do filesystem I/O behind the scenes in some cases. The pars

Re: [go-nuts] ast.NewPackage errors for built in types

I converted my code to x/tools/go/packages and while it did solve the problem it's VERY slow in comparison. I have a set of 21 tests operating on a single package which has at most two very basic types, no imports and using go/parser

Re: [go-nuts] Will the generics support be enabled by default in Go 1.18?

On Fri, Oct 15, 2021, 12:49 AM Henry wrote: > I thought that hiding generics behind a flag is already a thing in Go 1.17? > For the record: not really. 1.17 happens to have some incomplete and buggy support for type parameters, and there is an undocumented flag to turn that on. But nobody shou

Re: [go-nuts] Inconsistency between calls to "os.Chtimes()" and "stat.Sys().(syscall.Stat_t).Mtimespec"

* Marvin Renich [211015 08:04]: > Also note that different filesystems on the same running host can have > different resolutions. FAT filesystems (e.g. USB memory sticks) have > only 2-second resolution, while ext2 is, I think, 1 millisecond, and > ext4 is 1 nanosecond. According to [1], it appe

Re: [go-nuts] Inconsistency between calls to "os.Chtimes()" and "stat.Sys().(syscall.Stat_t).Mtimespec"

* Kurtis Rader [211014 13:22]: > Note that file timestamp resolution depends on the system: both hardware > and OS. Even when using the same OS (e.g., Linux) on the same hardware the > resolution might be different due to how the OS kernel was built. I'm not > aware of any system that provides nan