[go-nuts] Re: Seeing high RES memory but very little inuse_space

2023-02-16 Thread Mohit Goyal 
Note: the json library is https://github.com/goccy/go-json

On Thursday, February 16, 2023 at 9:03:13 PM UTC-8 Mohit Goyal wrote:

> We have a job executor that runs periodic jobs. We have being seeing a 
> constant growth in the RES memory (to the tune of 10 GB). However, our heap 
> usage is constant at around 75-85MB. Here are the stats for the same - 
>
>- process_resident_memory_bytes 1.0107805696e+10 = 10GB
>- go_memstats_heap_idle_bytes 1.00286464e+08 = 100MB
>- go_memstats_heap_inuse_bytes 1.01433344e+08= 100MB
>- go_memstats_alloc_bytes 9.0241416e+07  = 90MB 
>
>
>- go_gc_cycles_automatic_gc_cycles_total = 8249
>- go_gc_heap_allocs_bytes_total 9.9512908776e+10 = 99 GB
>- go_gc_heap_frees_bytes_total  9.942266736e+10  = 99GB
>
> The go version is 1.19.1. Looking at the call graph, we see that json to 
> struct conversion has been allocating a lot of space (40GB out of 99GB). 
> However, its only seen in the alloc_space and not in the inuse_space. Any 
> pointers to what could be the reason and if its anything you have also seen 
> would be helpful. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cf911d6c-1c36-4439-82d8-7e09ae92dc27n%40googlegroups.com.

Re: [go-nuts] CGO Struct used as type parameter causes issue in Go 1.20

2023-02-16 Thread Ian Lance Taylor 
On Thu, Feb 16, 2023 at 8:33 PM Jan Pfeifer  wrote:
>
> Indeed.
>
> But it feels like that an incomplete type as type parameter should be ok if 
> we are never instantiating it, and only using pointers to it. From what I see 
> this was not considered in https://go.dev/issue/54765.
>
> Should this be raised as an issue for 1.21 or a 1.20.1 ? Any thoughts ?

I think it's very subtle to ensure that the type is only being used in
acceptable ways.  I'd rather not attempt to do that unless it is very
important to be able to use that kind of type argument.

Ian



> On Fri, Feb 17, 2023 at 12:43 AM Ian Lance Taylor  wrote:
>>
>> On Thu, Feb 16, 2023 at 2:38 AM Jan  wrote:
>> >
>> > Apologies, actually it was trickier than I thought, the issue happens in 
>> > not fully defined C types only. So here is an example that runs in go 
>> > 1.19.5, but fails in go 1.20
>> >
>> > ```
>> > package main
>> >
>> > /*
>> > // Forward reference of C++ types.
>> > struct SomeType;
>> > typedef struct SomeType SomeType;
>> >
>> > // Fully defined type.
>> > typedef struct {
>> > char C;
>> > } FullyDefinedType;
>> > */
>> > import "C"
>> > import (
>> > "fmt"
>> > )
>> >
>> > type Wrapper[T any] struct {
>> > P *T
>> > }
>> >
>> > type SomeTypeHolder struct {
>> > *Wrapper[C.SomeType]
>> > }
>> >
>> > type FullyDefinedTypeHolder struct {
>> > *Wrapper[C.FullyDefinedType]
>> > }
>> >
>> > func main() {
>> > //var p *C.SomeType
>> > var x SomeTypeHolder
>> > var y FullyDefinedTypeHolder
>> > fmt.Printf("x.Wrapper=%x\n", x.Wrapper)
>> > fmt.Printf("y.Wrapper=%x\n", y.Wrapper)
>> > }
>> > ```
>> >
>> > In go 1.19.5 it prints:
>> >
>> > $ go run .
>> > x.Wrapper=0
>> > y.Wrapper=0
>> >
>> > In go 1.20 it prints:
>> >
>> > $ go run .
>> > # ...
>> > ./main.go:22:3: cannot use incomplete (or unallocatable) type as a type 
>> > argument: main._Ctype_struct_SomeType
>>
>> Giving an error here is https://go.dev/issue/54765.  That is, fixing
>> that issue in 1.20 is what causes this program to not compile.
>>
>> Ian
>
>
>
> --
> Jan Pfeifer
> Research Engineer
> Google Switzerland GmbH
> @ : pfei...@gmail.com
> @ : ja...@google.com
> T : +41 79 907 3855
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU-ky5d_MWt118k84oBU65ux8XWb3oXsG03cEjC50BXZg%40mail.gmail.com.

[go-nuts] Seeing high RES memory but very little inuse_space

2023-02-16 Thread Mohit Goyal 
We have a job executor that runs periodic jobs. We have being seeing a 
constant growth in the RES memory (to the tune of 10 GB). However, our heap 
usage is constant at around 75-85MB. Here are the stats for the same - 

   - process_resident_memory_bytes 1.0107805696e+10 = 10GB
   - go_memstats_heap_idle_bytes 1.00286464e+08 = 100MB
   - go_memstats_heap_inuse_bytes 1.01433344e+08= 100MB
   - go_memstats_alloc_bytes 9.0241416e+07  = 90MB 


   - go_gc_cycles_automatic_gc_cycles_total = 8249
   - go_gc_heap_allocs_bytes_total 9.9512908776e+10 = 99 GB
   - go_gc_heap_frees_bytes_total  9.942266736e+10  = 99GB

The go version is 1.19.1. Looking at the call graph, we see that json to 
struct conversion has been allocating a lot of space (40GB out of 99GB). 
However, its only seen in the alloc_space and not in the inuse_space. Any 
pointers to what could be the reason and if its anything you have also seen 
would be helpful. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/40841f08-bd5a-4794-8d4d-3ec104355ec0n%40googlegroups.com.

Re: [go-nuts] CGO Struct used as type parameter causes issue in Go 1.20

2023-02-16 Thread Jan Pfeifer 
Indeed.

But it feels like that an incomplete type as type parameter should be ok if
we are never instantiating it, and only using pointers to it. From what I
see this was not considered in https://go.dev/issue/54765.

Should this be raised as an issue for 1.21 or a 1.20.1 ? Any thoughts ?



On Fri, Feb 17, 2023 at 12:43 AM Ian Lance Taylor  wrote:

> On Thu, Feb 16, 2023 at 2:38 AM Jan  wrote:
> >
> > Apologies, actually it was trickier than I thought, the issue happens in
> not fully defined C types only. So here is an example that runs in go
> 1.19.5, but fails in go 1.20
> >
> > ```
> > package main
> >
> > /*
> > // Forward reference of C++ types.
> > struct SomeType;
> > typedef struct SomeType SomeType;
> >
> > // Fully defined type.
> > typedef struct {
> > char C;
> > } FullyDefinedType;
> > */
> > import "C"
> > import (
> > "fmt"
> > )
> >
> > type Wrapper[T any] struct {
> > P *T
> > }
> >
> > type SomeTypeHolder struct {
> > *Wrapper[C.SomeType]
> > }
> >
> > type FullyDefinedTypeHolder struct {
> > *Wrapper[C.FullyDefinedType]
> > }
> >
> > func main() {
> > //var p *C.SomeType
> > var x SomeTypeHolder
> > var y FullyDefinedTypeHolder
> > fmt.Printf("x.Wrapper=%x\n", x.Wrapper)
> > fmt.Printf("y.Wrapper=%x\n", y.Wrapper)
> > }
> > ```
> >
> > In go 1.19.5 it prints:
> >
> > $ go run .
> > x.Wrapper=0
> > y.Wrapper=0
> >
> > In go 1.20 it prints:
> >
> > $ go run .
> > # ...
> > ./main.go:22:3: cannot use incomplete (or unallocatable) type as a type
> argument: main._Ctype_struct_SomeType
>
> Giving an error here is https://go.dev/issue/54765.  That is, fixing
> that issue in 1.20 is what causes this program to not compile.
>
> Ian
>


-- 
Jan Pfeifer
Research Engineer
Google Switzerland GmbH
@ : pfei...@gmail.com
@ : ja...@google.com
T : +41 79 907 3855

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsX9%2BOrnJ0kCFSEn_xGD%2BydK%3Dxhe4NkywjMHrKvTfFFAew%40mail.gmail.com.

Re: [go-nuts] CGO Struct used as type parameter causes issue in Go 1.20

2023-02-16 Thread Ian Lance Taylor 
On Thu, Feb 16, 2023 at 2:38 AM Jan  wrote:
>
> Apologies, actually it was trickier than I thought, the issue happens in not 
> fully defined C types only. So here is an example that runs in go 1.19.5, but 
> fails in go 1.20
>
> ```
> package main
>
> /*
> // Forward reference of C++ types.
> struct SomeType;
> typedef struct SomeType SomeType;
>
> // Fully defined type.
> typedef struct {
> char C;
> } FullyDefinedType;
> */
> import "C"
> import (
> "fmt"
> )
>
> type Wrapper[T any] struct {
> P *T
> }
>
> type SomeTypeHolder struct {
> *Wrapper[C.SomeType]
> }
>
> type FullyDefinedTypeHolder struct {
> *Wrapper[C.FullyDefinedType]
> }
>
> func main() {
> //var p *C.SomeType
> var x SomeTypeHolder
> var y FullyDefinedTypeHolder
> fmt.Printf("x.Wrapper=%x\n", x.Wrapper)
> fmt.Printf("y.Wrapper=%x\n", y.Wrapper)
> }
> ```
>
> In go 1.19.5 it prints:
>
> $ go run .
> x.Wrapper=0
> y.Wrapper=0
>
> In go 1.20 it prints:
>
> $ go run .
> # ...
> ./main.go:22:3: cannot use incomplete (or unallocatable) type as a type 
> argument: main._Ctype_struct_SomeType

Giving an error here is https://go.dev/issue/54765.  That is, fixing
that issue in 1.20 is what causes this program to not compile.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWf3H-TAQU-cW_ku-jah53-SUKfbEpLtGydpcP3FxMtrQ%40mail.gmail.com.

Re: [go-nuts] Re: Why can't a regexp.Regexp be const

2023-02-16 Thread Pat Farrell 
Yes of course.
At least your version is easier for humans to read.
In the application, I expect the whole regexp thing is trivially small part 
of
the execution process. But I'm trying to write proper idiomatic go, and 
yours is nicer


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2f24866b-43e8-4058-8784-aef89cf570c2n%40googlegroups.com.

Re: [go-nuts] Go 1.20 "cold start" slows down CI pipeline stages due to first building stdlib

2023-02-16 Thread TheDiveO 
Many 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c4e6eb0c-72c1-442c-bb77-3fa66e1491c4n%40googlegroups.com.

Re: [go-nuts] Go 1.20 "cold start" slows down CI pipeline stages due to first building stdlib

2023-02-16 Thread 'Sean Liao' via golang-nuts 
- restore cache (go version as cache key)
- go build std
- save cache (GOCACHE)
- original build steps follow here

- sean

On Thu, Feb 16, 2023, 19:54 TheDiveO  wrote:

> As Go 1.20 doesn't ship anymore with prebuild stlib packages, the first
> build after installation will take longer. Obviously, in a full Kubernetes
> build this is negligible (if not outward laughable). But for many small CI
> Go build stages this probably eats considerably into CPU time and energy
> consumption.
>
> For instance, a small module
> https://github.com/thediveo/caps/actions/runs/4197604787 takes around 36s
> for Go 1.19 versus Go 1.20 with 63s (times for "go test" phase only).
>
> Now I'm curious: is there some way to "preheat" Go 1.20 in order to cache
> the locally built Go stdlib?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e300c706-da67-4cb9-8a37-bf15bd041e7dn%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGabyPpYTiYa7oixaiJvFSWzrC96M-dwRRy6gP%3D8AK6CdcK9nA%40mail.gmail.com.

Re: [go-nuts] Learning Go on internal server

2023-02-16 Thread Chris Burkert 
Go can be run on a regular Mac or PC. Maybe you don’t need a tools server
for this at all.

However, in a corporate environment caching dependencies may be a good
thing. With modules this is done by running your own Go proxy. Take a look
at
https://github.com/gomods/athens
 or
https://github.com/goproxy/goproxy.

Rich  schrieb am Do. 16. Feb. 2023 um 17:48:

> So, I've been writing go code for my company, and many have expressed an
> interest in learning Go. So what I want to do is create a learning
> environment for them on one of our 'tools' servers. The problem is that the
> tools server doesn't have good connectivity to the internet. So using go
> mod to download packages doesn't work. Is there a place I can download the
> package, put it on the server in a shared location so that go mod can pick
> up that it's already available?
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/64642177-5c5c-41d8-b508-66318e429276n%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALWqRZp3%2BPdqoGD4wsVeHX8GEUyA1tGPa%2BB-ffiMSM5gJRQF5A%40mail.gmail.com.

[go-nuts] Go 1.20 "cold start" slows down CI pipeline stages due to first building stdlib

2023-02-16 Thread TheDiveO 
As Go 1.20 doesn't ship anymore with prebuild stlib packages, the first 
build after installation will take longer. Obviously, in a full Kubernetes 
build this is negligible (if not outward laughable). But for many small CI 
Go build stages this probably eats considerably into CPU time and energy 
consumption.

For instance, a small 
module https://github.com/thediveo/caps/actions/runs/4197604787 takes 
around 36s for Go 1.19 versus Go 1.20 with 63s (times for "go test" phase 
only).

Now I'm curious: is there some way to "preheat" Go 1.20 in order to cache 
the locally built Go stdlib?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e300c706-da67-4cb9-8a37-bf15bd041e7dn%40googlegroups.com.

[go-nuts] Learning Go on internal server

2023-02-16 Thread Rich 
So, I've been writing go code for my company, and many have expressed an 
interest in learning Go. So what I want to do is create a learning 
environment for them on one of our 'tools' servers. The problem is that the 
tools server doesn't have good connectivity to the internet. So using go 
mod to download packages doesn't work. Is there a place I can download the 
package, put it on the server in a shared location so that go mod can pick 
up that it's already available?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/64642177-5c5c-41d8-b508-66318e429276n%40googlegroups.com.

Re: [go-nuts] liteide x38.2 released

2023-02-16 Thread Rich 
Glad to see ya'll are still working on Liteide. I've used it in the past 
and for a while was my main Go IDE. I'll have to give it another try. 

On Monday, February 13, 2023 at 7:12:44 PM UTC-5 vfc wrote:

> Hi all, liteide x38.2 released!
>
> * update gotools to fix generic code lookup and code completion
> * refactoring the Go class view and outline to support generic views
> * update Delve debug plug-in, add disassembly view, and repair windows 
> process exit
>
> * LiteIDE Source code
> https://github.com/visualfc/liteide
>
> * Release downloads
> * https://github.com/visualfc/liteide/releases/latest
> * https://sourceforge.net/projects/liteide/files
> * [baidu pan](https://pan.baidu.com/s/1wYHSEfG1TJRC2iOkE_saJg) 
> password: jzrc
>
> ### 2023.02.14 Ver X38.2
> * LiteIDE
> * fix and update gotools & gocode
> * refactor astview outline
> * update dlv debugger plugin
> * GolangAst
> * new outline view by pos
> * support typeparams
> * LiteDebug
> * add disassemble view
> * DlvDebugger
> * fix generics func sync
> * fix dlv process exit on windows
> * refactor gorountines model
> * support disassemble model
> * LiteBuild
> * gosrc.xml TARGETNAME use BUILD_DIR_PATH
> * GolangEdit
> * support any and comparable
> * GolangCode
> * support any and comparable
> * gotools
> * types fix find obj field 
> * types fix object string
> * gotest fix run test file use -run mode
> * astview add new -outline for outline
> * astview add new -tp for typeparams
> * astview fix interface embedded type 
> * gocode
> * fix identifier comparable 
> * update lookup object
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9177f897-0ae0-47eb-ae01-b04b052afbfan%40googlegroups.com.

Re: [go-nuts] Why is runtime.Gosched needed in this single-threaded, no-goroutines cgo program?

2023-02-16 Thread David Finkel 
On Wed, Feb 15, 2023 at 4:05 PM Ian Lance Taylor  wrote:

> On Wed, Feb 15, 2023 at 8:42 AM 'Marko Bencun' via golang-nuts
>  wrote:
> >
> > I am running into a a weird error in C code that only materializes
> > when calling it from Go using cgo. I hope you could help me understand
> > this behaviour and why calling runtime.Gosched() seems to resolve the
> > issue. I worry that this may not be the right fix, so I want to
> > understand what is going on.
> >
> > I communicate to a USB HID device and get an error every once in a
> > while, only when using cgo, in around 5% of the messages sent to the
> > device, non-deterministically. The messages sent and received are all
> > the same and work most of the time.
> >
> > The C functions I am calling are hid_write and hid_read from here:
> >
> https://github.com/libusb/hidapi/blob/4ebce6b5059b086d05ca7e091ce04a5fd08ac3ac/mac/hid.c
> >
> > If I call hid_write and hid_read in a loop in a C program, everything
> > works as expected:
> >
> > ```
> > #include "hidapi.h"
> > #include "hidapi_darwin.h"
> >
> > int run(hid_device *handle) {
> > int res;
> >
> > const uint8_t write[64] = "";
> > const uint8_t expected[64] = "";
> > uint8_t read[64] = {0};
> >
> > while(1) {
> > res = hid_write(handle, write, sizeof(write));
> > if(res < 0) return -1;
> > res = hid_read(handle, read, sizeof(read));
> > if(res < 0) return -1;
> > if (memcmp(read, expected, 64)) return -1;
> > }
> >
> > return 0;
> > }
> > ```
> >
> > I ported the above to Go using cgo like below. I link `hid.o`, the
> > same object file used in the C program, to make sure the same code is
> > running to rule out differences in compilation:
> >
> > ```
> > package main
> >
> > import (
> > "bytes"
> > "encoding/hex"
> > )
> >
> > /*
> > #cgo darwin LDFLAGS: -framework IOKit -framework CoreFoundation
> > -framework AppKit hid.o
> > #include "hidapi.h"
> > #include "hidapi_darwin.h"
> > */
> > import "C"
> >
> > func main() {
> > dev := C.hid_open(...)
> > if dev == nil {
> > panic("no device")
> > }
> > write := []byte("")
> > expected := []byte("")
> > b := make([]byte, 64)
> > for {
> > written := C.hid_write(dev, (*C.uchar)([0]),
> C.size_t(len(write)))
> > if written < 0 {
> > panic("error write")
> > }
> > read := C.hid_read(dev, (*C.uchar)([0]), C.size_t(len(b)))
> > if read < 0 {
> > panic("error read")
> > }
> > if !bytes.Equal(b, expected) {
> > panic("not equal")
> > }
> > }
> > }
> > ```
> >
> > The Go program errors on hid_write with a "generic error" error code
> > non-deterministically in about 5% of the messages sent. The USB device
> > receives the message and responds normally however.
> >
> > I randomly tried adding `runtime.Gosched()` at the bottom of the
> > Go-loop, and the issue disappeared completely. I am very confused why
> > that would help, as the Go program has, as far as I can tell, no
> > threads and no goroutines (except main).
> >
> > Other things I have checked:
> >
> > - If I move the loop from Go to C by calling `C.run(dev)` (the looping
> > function defined above) from Go, there is no issue.
> > - LockOSThread: if the loop runs in a goroutine and that goroutine
> > switches OS threads, the issue reappears after some time (not
> > immediately after a thread switch - the error happens
> > non-deterministically) even if `runtime.Gosched()` is called.
> > `runtime.LockOSThread()` is needed to fix it in that case. Since the
> > goroutine is locked to an OS thread during the execution of a C
> > function call anyway, this indicates that either hidapi or the macOS
> > HID functions rely on thread-local vars across multiple C calls in
> > some way, which seems a bit crazy.
> > - In the above code (no goroutines), I checked that the OS thread ID
> > (pthread_self()) is constant for all calls, and yet the issue appears
> > unless runtime.Gosched() is called, which seems to contradict the
> > previous point
> > - I tried multiple Go versions between 1.16 and 1.20 and multiple
> > macOS SDK versions between 10.13 and 13.1, all with the same problem
> > (and same working fix).
> > - only macOS is affected - on linux and Windows, there is no similar
> > issue (these platforms use different C code to interact with the
> > device).
> >
> > Does anyone have any insight into why invoking the scheduler could be
> > necessary here or what could be going on in general? My worry is that
> > using `runtime.LockOSThread()` and `runtime.Gosched()` are not proper
> > fixes.
>
>
> I didn't try to look at this in detail, but I did glance at the C code
> you are calling, and it uses pthread_mutex_lock and friends.  In
> general pthread mutexes must be unlocked by the thread that locked
> them, so it is quite possible that LockOSThread is required for
> correct operation.  I don't have an

Re: [go-nuts] CGO Struct used as type parameter causes issue in Go 1.20

2023-02-16 Thread Jan 
Apologies, actually it was trickier than I thought, the issue happens in 
not fully defined C types only. So here is an example that runs in go 
1.19.5, but fails in go 1.20

```
package main

/*
// Forward reference of C++ types.
struct SomeType;
typedef struct SomeType SomeType;

// Fully defined type.
typedef struct {
char C;
} FullyDefinedType;
*/
import "C"
import (
"fmt"
)

type Wrapper[T any] struct {
P *T
}

type SomeTypeHolder struct {
*Wrapper[C.SomeType]
}

type FullyDefinedTypeHolder struct {
*Wrapper[C.FullyDefinedType]
}

func main() {
//var p *C.SomeType
var x SomeTypeHolder
var y FullyDefinedTypeHolder
fmt.Printf("x.Wrapper=%x\n", x.Wrapper)
fmt.Printf("y.Wrapper=%x\n", y.Wrapper)
}
```

In go 1.19.5 it prints:

$ go run .
x.Wrapper=0
y.Wrapper=0

In go 1.20 it prints:

$ go run .
# ...
./main.go:22:3: cannot use incomplete (or unallocatable) type as a type 
argument: main._Ctype_struct_SomeType

THanks!
On Thursday, February 16, 2023 at 9:35:09 AM UTC+1 Jan Mercl wrote:

> On Thu, Feb 16, 2023 at 8:22 AM Jan  wrote:
>
> > Any thoughts ?
>
> A minimal, self-contained and runnable reproducer would be rather
> useful in this case.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0375b4c1-9551-4d87-85ef-1ff48cf66236n%40googlegroups.com.

Re: [go-nuts] CGO Struct used as type parameter causes issue in Go 1.20

2023-02-16 Thread Jan Mercl 
On Thu, Feb 16, 2023 at 8:22 AM Jan  wrote:

> Any thoughts ?

A minimal, self-contained and runnable reproducer would be rather
useful in this case.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WDX4vjPunJNBjNspm%2Bj1tdC8cFyO8%3De5xwprsAxaZYGA%40mail.gmail.com.