Thanks for your kind and instant reply.
Allow me to explain myself a bit more.
My code has two kinds of data races. First one is a global struct without
any pointer member being written and read by multiple Goroutines. Second
one is a struct's string member being written and read by
multiple Gour
Ian, thanks for your explanation, it really shed light on that for me. I
certainly will fix the data race.
Thanks to all for your time.
On Tue, 19 Nov 2024 at 22:46, Ian Lance Taylor wrote:
> On Tue, Nov 19, 2024 at 3:50 AM Lin Lin wrote:
> >
> > Thanks for your kind and instant reply.
> >
> >
On Tue, 2024-11-19 at 15:52 +0100, Chris Burkert wrote:
> Hi Axel,
>
> > Maybe you can add something like `var _ = SkipIfIntegration` to
> > your package? i.e. trick the linter to stop it from complaining?
> >
>
>
> I already tried this, but it did not help.
>
> I even added the following, wh
Well, the init() function in the test package leads to an additional
complaint:
$ deadcode ./...
test/test.go:8:6: unreachable func: init#1
test/test.go:14:6: unreachable func: SkipIfIntegration
It works it I import the test package in my main package and fake call it
there: if false { test.SkipI
Hm, sorry, no, come to think of it, that wouldn't help either.
So, I don't know. Apart from "don't use that linter" or "ignore that
complaint", I'm out of ideas.
On Tue, 19 Nov 2024 at 15:56, Axel Wagner
wrote:
> You could also call it from a test within your test package.
>
> On Tue, 19 Nov 202
You could also call it from a test within your test package.
On Tue, 19 Nov 2024 at 15:53, Chris Burkert wrote:
> Hi Axel,
>
> Maybe you can add something like `var _ = SkipIfIntegration` to your
>> package? i.e. trick the linter to stop it from complaining?
>>
>
> I already tried this, but it d
Hi Axel,
Maybe you can add something like `var _ = SkipIfIntegration` to your
> package? i.e. trick the linter to stop it from complaining?
>
I already tried this, but it did not help.
I even added the following, which made things worse:
func init() {
_ = SkipIfIntegration
}
$ deadcode ./...
t
Hey there,
I have a package "test", which is only used in tests and which contains one
function: https://go.dev/play/p/Ne1xGXsQNmy
This leads to a finding when running deadcode:
$ deadcode ./...
test/testg.go:8:6: unreachable func: SkipIfIntegration
I tried several things:
- renaming the packag
On Tue, 19 Nov 2024 at 15:25, Chris Burkert wrote:
> Hey there,
>
> I have a package "test", which is only used in tests and which contains
> one function: https://go.dev/play/p/Ne1xGXsQNmy
>
> This leads to a finding when running deadcode:
>
> $ deadcode ./...
> test/testg.go:8:6: unreachable fu
As I shared, ANY data race can lead to a panic. You can be interfering with the GC object tracking. I agree with you that it seems not possible, but I was surprised to learn that it is. It is not the case in Java as there are assignment guarantees even without concurrency - but the data race can ca
10 matches
Mail list logo
