sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Coherence rules are not consistent when applied to auto traits
Labels: C-enhancement,A-trait-system,T-lang

The coherence rules which allow blanket trait implementations to coexist with more specific impls are not consistent when applied to normal traits and auto traits. An example is provided below. If this is expected behavior, I could not find it documented anywhere.

The same error occurs on both stable and nightly compilers.

```rust
// `Test` implements neither `Clone` nor `Send`.
struct Test {
    ptr: *mut u8, 
}

trait NotSend {}
impl<T> NotSend for T where T: Send {}

trait NotClone {}
impl<T> NotClone for T where T: Clone {}

// Coherence rules allow `Test` to have its own implementation of `NotClone`.
impl NotClone for Test {}

// However, the same logic does not apply to `Send`. This results in:
// error[E0119]: conflicting implementations of trait `NotSend` for type `Test`.
// impl NotSend for Test {}
```

[playground link](https://play.rust-lang.org/?gist=100507f67e2f9832e355d7da76af3e4a&version=nightly&mode=debug)
Repository: godot
Issue: AudioDriverWASAPI error while using editor if another application is using exclusive mode
Labels: bug,platform:windows,topic:porting,confirmed,topic:audio

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.0.3 RC1

**OS/device including version:**
Windows 10, not related to video, apparently.


**Issue description:**
I have used the editor for a while and never got this error before, I haven't even used the audio features, yet this error message seems to be related to the audio:
```
ERROR: AudioDriverWASAPI::thread_func: WASAPI: GetCurrentPadding error
   At: drivers\wasapi\audio_driver_wasapi.cpp:533
```

**Steps to reproduce:**
Unkown

**Minimal reproduction project:**
unkonwn
Repository: go
Issue: cmd/compile: incorrect error for function conversion based on cyclic definition (esoteric)
Labels: NeedsInvestigation,compiler/runtime

I'm only reporting this for future use should we ever get to a more thorough rethink of the type checker. This is a completely esoteric test case: https://play.golang.org/p/JjZZGCopERA

The error message is "cannot convert nil to type F" but F is clearly a function and thus nil can be converted into that function (of whatever type). The problem here is the type cycle; the conversion looks at a type that is not yet fully set up.

This example is primarily interesting as a test case.
Repository: pytorch
Issue: [Caffe2] Negative export to ONNX fails
Labels: caffe2

The following sample fails. The error seems to be coming from the exact same cause of #7020, but I cannot workaround the error with the same fix in frontend.py.

After some debugging I found out that for `Negative`, the export process goes through `C.support_onnx_export()` and `C.export_to_onnx()` unlike #7020. These functions checks the schema in https://github.com/pytorch/pytorch/blob/master/caffe2/operators/negative_op.cc to return the corresponding name for ONNX, but for some reason returning the wrong name.

## Sample
```python
#!/usr/bin/env python
import onnx
import caffe2.python.onnx.frontend as oc2f
import caffe2.python.predictor.predictor_exporter as pe
import caffe2.python.predictor.mobile_exporter as c2me
from caffe2.python import model_helper, workspace, brew, utils
IN_DATA_NAME = "in_data"
OUT_DATA_NAME = "out_data"

DATA_SHAPE = (1, 3, 3, 3)

model = model_helper.ModelHelper(name="neg_net")
model.net.Negative(IN_DATA_NAME, OUT_DATA_NAME)

model.param_init_net.UniformFill([], IN_DATA_NAME, shape=DATA_SHAPE)
workspace.RunNetOnce(model.param_init_net)

init_net, predict_net = c2me.Export(workspace, model.net, [IN_DATA_NAME])

value_info = {
}

onnx_model = oc2f.caffe2_net_to_onnx_model(
        predict_net,
        init_net,
        value_info)
onnx.checker.check_model(onnx_model)
print(onnx_model)
with open("neg.onnx", 'wb') as f:
    f.write(onnx_model.SerializeToString())
```

## Error
```
Traceback (most recent call last):
  File "./gen_neg.py", line 38, in <module>
    value_info)
  File "/home/masato/repo/pytorch/build/caffe2/python/onnx/frontend.py", line 337, in caffe2_net_to_onnx_model
    model = make_model(cls.caffe2_net_to_onnx_graph(*args, **kwargs),
  File "/home/masato/repo/pytorch/build/caffe2/python/onnx/frontend.py", line 273, in caffe2_net_to_onnx_graph
    checker.check_graph(graph_def)
  File "/home/masato/repo/onnx/onnx/checker.py", line 45, in checker
    proto.SerializeToString(), ctx)
onnx.onnx_cpp2py_export.checker.ValidationError: No Schema registered for Negative with domain_version of 7

==> Context: Bad node spec: input: "in_data_0" output: "out_data_1" name: "" op_type: "Negative"
```
- OS: Ubuntu 16.04.4 x86_64
- PyTorch version: 5c2015d133d1a6c54b4daba35e54fd0c84806463
- ONNX version: dee6d89781fb885d1ed3b935992b27338befe1cd
- Python version: 3.5.2
Repository: go
Issue: x/crypto/salsa20: implement cipher.Stream interface
Labels: help wanted,NeedsFix

salsa20 is the odd one out that implements only a stateless XORKeyStream at the package level.
Repository: go
Issue: x/crypto/cryptotest: new package
Labels: Proposal-Accepted,NeedsFix,Proposal-Crypto

crypto/cipher has well defined interfaces with plenty of tricky requirements (about aliasing, different lengths, state) that are hard to test for and easy to overlook.

cryptotest will be an interface test suite, like nettest. It caught a bug in x/crypto/internal/chacha20 and can replace a bunch of duplicated tests in the standard library, too.

It's useful to expose it in x/crypto for external implementations of the interface to use it. It will be vendored back.

Originally submitted as an internal package in https://golang.org/cl/102196
Repository: pytorch
Issue: Multi queue for dataloader when workers > 1
Labels: module: dataloader,triaged,enhancement

Recently I have read the implementation of dataloader and get some ideas may be make dataloader faster when use multi prefetch data loader. Currently there is only one index_queue and data_queue, sampler will put batch indices to index_queue, and multi processes will put the single data_queue at the same time , ther is an race condition and would be blocking. May be create an queue per worker should be more efficiently.

cc @SsnL @VitalyFedyunin @ejguan
Repository: go
Issue: test: generate gcgort
Labels: help wanted,NeedsFix

In e0adc35c470d9bf7f462c9d26340b494cbe7ce43 test/gcgort.go is added. This test may benefit from being generated instead of hand-written to increase maintainability by reducing repeating and narrow test coverage by removing extraneous setup code like the modifier struct.

This change would be after 1.11 and my opinion is it should only be done if the test strategy is also updated for the stated garbage collector, types, and concurrency interactions coverage. Currently the test failure relies on the runtime implementation causing a panic.

From https://go-review.googlesource.com/c/go/+/93715 discussion with @aclements.
Repository: go
Issue: doc: eliminate commit-message skew between Contribution Guide and wiki
Labels: Documentation,help wanted,NeedsInvestigation

After @rasky's updates, https://tip.golang.org/doc/contribute.html#commit_messages has a nice, clear guide to Go commit messages. https://github.com/golang/go/wiki/CommitMessage has a very similar guide.

Unfortunately, they have a bit of skew: for example, the wiki mentions a 76-column limit, whereas `contribute.html` does not.

We should eliminate that skew: either both documents should list the full details, or one should provide a more concise summary and link to the other for details.
Repository: go
Issue: cmd/compile: call memmove on amd64 for large OpMove
Labels: Performance,NeedsInvestigation,compiler/runtime

Currently we lower OpMove with large size into REP MOV.
Memmove has optional AVX&co codepath, so it should be faster than  REP MOV, or at least as fast if REP MOV is optimal (call overhead is insignificant for large sizes). We should probably generate a call to memmove for really big OpMove.
Repository: TypeScript
Issue: "program.emit" produces wrong declaration file if "declaration" option is false or not specified
Labels: Bug,Help Wanted,API

**TypeScript Version:** 2.9.0-dev.20180506

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** declaration, emitting.

**Code**

```ts
declare module ModuleName {}
declare var ModuleName: { prototype: any };
export { ModuleName };
```

Steps to reproduce:
1. Create `index.ts` with content above
1. Open `node` in folder with this file and installed `typescript` and type the following:

    ```js
    var ts = require('typescript');
    var program = ts.createProgram(['index.ts'], {});
    var res = program.emit(undefined, undefined, undefined, true);
    ```

**Expected behavior:**

Possible that calling `program.emit` with `emitOnlyDtsFiles = true` and without specifying `declaration: true` in the config should produce an error, but I am not sure that it is good solution.

**Actual behavior:**

The compiler produces `index.d.ts` file with only one line `export { ModuleName };` which is incorrect definitions (`res` is object with the following state: `{ emitSkipped: false, diagnostics: [], emittedFiles: undefined, sourceMaps: undefined }`).

For `2.8.3` version it produces

```ts
declare module ModuleName {
}
declare var ;
export { ModuleName };
```

which is broken declaration too.

If run from cmd `./node_modules/.bin/tsc --emitDeclarationOnly` it fails with `error TS5052: Option 'emitDeclarationOnly' cannot be specified without specifying option 'declaration'`.
Repository: vscode
Issue: [Emmet] Include should be more like DocumentSelector
Labels: help wanted,feature-request,emmet

Currently, the Emmet extension has a setting called `emmet.includeLanguages` which just targets language IDs to map to the Emmet-capable language ID. I think it would be very useful if instead you could use something more like `DocumentSelector`, which also allows [`DocumentFilter`](https://code.visualstudio.com/docs/extensionAPI/vscode-api#DocumentFilter) instead of just language ID.
Repository: storybook
Issue: Show more source files in storysource
Labels: feature request,addon: storysource

Hello,
I'm interested in getting the version of this demo https://building.coursera.org/coursera-ui/?selectedKind=Welcome&selectedStory=to%20Storybook&full=0&addons=0&stories=1&panelRight=0&addonPanel=storybook%2Factions%2Factions-panel

to render, test and play out locally.
Can you help with where to clone/download it?
The only one I found was outdated.
thanks
Repository: go
Issue: crypto/rand: add package example
Labels: Documentation,help wanted,NeedsFix

The crypto/rand package has no package example; even just copying the Read example up to the package level would be helpful.

The crypto/rand package also doesn't have the same convenience helpers that math/rand has, so it might be helpful to see e.g. how to implement Intn using the crypto/rand package.
Repository: pytorch
Issue: [feature request] torch.nn.DataParallel should work nicely both for cpu and gpu devices
Labels: triaged,enhancement,module: data parallel

If the working machine has a GPU card, it seems that there is no way for torch.nn.DataParallel to work on the CPU.  
This is due to the following lines in the torch.nn.DataParallel. 
```
        if not torch.cuda.is_available():
            self.module = module
            self.device_ids = []
            return
```


Thus, we should provide an option that if device_ids = None then torch.nn.DataParallel works on the CPU.

if devices_ids = [], then all available GPUs should be used.

or implement the to() method for torch.nn.DataParallel.

So we can freely run the code on GPU or CPU if torch.nn.DataParallel is used.
Repository: flutter
Issue: Encourage reproducible builds
Labels: c: new feature,framework,P2,team-framework,triaged-framework

I've been thinking about how this could be tackled for a while, but what triggered me to open this issue was a question by a fellow flutter dev.

"Is there any way to see which flutter version someone is using from their github repo?"  - @iampawan
 Although I consider good practice writing `pubspec.yaml` with specific versions (no ^ or ranges) and explicit flutter version `environment: \n flutter: 0.x.x` , these rarely happen.

I noticed `pubspec.lock` doesn't contain a number to the flutter version used as well:
```
  flutter:
    dependency: "direct main"
    description: flutter
    source: sdk
    version: "0.0.0"
  flutter_test:
    dependency: "direct dev"
    description: flutter
    source: sdk
    version: "0.0.0"
```
Repository: TypeScript
Issue: Improve references for import type of JS modules
Labels: Bug

See `findAllRefs_importType_js.ts` (added in #23998)
Repository: pytorch
Issue: Make c10d/FileStore cache file descriptor
Labels: newcomer,oncall: distributed,feature,triaged

Per comment from @apaszke in #7439, there is no need to reopen the underlying file for every operation. Instead we can keep the file open and only acquire/release the shared/exclusive lock.
Repository: kubernetes
Issue: CRDs: support binary encoding 
Labels: area/extensibility,sig/api-machinery,kind/feature,priority/important-longterm,area/custom-resources,lifecycle/frozen

/kind feature

I think eventually we will be asked to add a proto encoding for CRDs. It's very non-obvious how to do this, so I think we should start talking about it now.

I can think of two approaches off the top of my head:
1. Require the user to supply a proto spec as part of the CRD object.
2. Add x-proto-field-number extensions to OpenAPI spec documents. Require the user to set them in the CRD's `validation` field (which we should really rename, but that's another issue). (We'd also have to add type information, or define a strict mapping between the types we express in the spec and proto types.)

1 has the benefit of being very obvious, and probably less work. But I think I prefer 2, because it lets us expose the proto format for built-in types in exactly the same way.
Repository: go
Issue: net/http: document when url.Error type is returned
Labels: Documentation,NeedsFix

Document when url.Error type is returned. (which Client methods)
Repository: terminal
Issue: Copying with Ctrl-Shift-C copies literal buffer, not lines
Labels: Work-Item,Product-Conhost,Area-Interaction,Issue-Task

Selecting text and copying with Ctrl-Shift-C copies the buffer literally, which gives a line full of spaces and no newline. Copying with right click works as intended. Verified in cmd.exe, pwsh.exe and zsh.

* Your Windows build number:  (Type `ver` at a Windows Command Prompt)
17666

* What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
```
PS> echo "foo`nbar"
foo
bar
PS> # copy those two lines with Ctrl-Shift-C and paste into notepad
PS> # should have a line full of spaces before "bar"
```

* What's wrong / what should be happening instead:
It should do the same thing as right click copy - lines have a new line at the end instead of being filled with spaces.
Repository: go
Issue: x/build/cmd/gerritbot: does not respect codereview.cfg for fixing commit messages
Labels: help wanted,Builders,NeedsFix

https://go-review.googlesource.com/112277, which came from PR golang/vgo#4, said "Fixes #24099." The git-codereview tool would have read the vgo repo's codereview.cfg and automatically rewritten that line to say "Fixes golang/go#24099." This helps both authors and reviewers, neither of whom have to think about this anymore. The PR-bot should do the same, because as a reviewer I certainly don't want to lapse back into being in charge of catching this trivial but common mistake. Because the bot did not fix the commit message, the eventual submit did not close the issue.
Repository: rust
Issue: Incorrect padding on hexadecimal formatting of integers
Labels: C-enhancement,T-libs-api

The behavior in https://github.com/rust-lang/rust/pull/48978 does not seem correct.

[Playground link](https://play.rust-lang.org/?gist=ccadba488e9120ff29235cbdfdca799b&version=beta&mode=debug)

The number of digits in the output doesn't seem to match the requested amount of padding.
Repository: go
Issue: cmd/go: go test -list does things other than listing tests
Labels: NeedsInvestigation

This is a small quibble, but caused me some surprise recently.

### What version of Go are you using (`go version`)?
go version go1.10.2 linux/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/eric/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/eric/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build753721336=/tmp/go-build -gno-record-gcc-switches"
```

### What did you do?

foo_test.go
```
package foo

import (
	"fmt"
	"testing"
)

func init() {
	fmt.Println("Hello, world!")
}

func TestFoo(t *testing.T) {}
```

```
$ go test -list=TestFoo
```

### What did you expect to see?
```
TestFoo
```

### What did you see instead?

```
Hello, world!
TestFoo
ok  	github.com/echlebek/foo	0.001s
```

In https://github.com/golang/go/issues/17209, Nemith proposes that `go test -list` would list the tests, but no tests would be run or any other operation.

I think that since it can be statically determined what the tests in a package are, the -list functionality should not depend on executing the test binary.
Repository: go
Issue: x/text/language: Cannot parse ISO/IEC 15897 (C, POSIX, etc.) as language tags
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?

```console
~/.local/lib/go/src/golang.org/x/text $ go version
go version go1.10.2 linux/arm64
~/.local/lib/go/src/golang.org/x/text $ git describe
v0.3.0-48-g67e48ad
```

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

```console
$ go env GOARCH
arm64
```

### What did you do?

```console
$ cat main.go 
package main

import (
        "fmt"

        "golang.org/x/text/language"
)

func main() {
        tag, err := language.Parse("POSIX")
        fmt.Printf("%v\n%v\n", tag, err)
}
$ go run main.go 
und
language: tag is not well-formed
```

### What did you expect to see?

A POSIX language tag.

### What did you see instead?

A "tag is not well-formed" error.  Passing `C` instead of `POSIX` produces the same error.

Neither of these subtags are in [the IANA registry][1], so the current errors are strictly compliant with [the current BCP 47 claim][2].  But [POSIX defines a collation order][3] which the current behavior does not provide access to.  As far as I can tell, there's currently no way to [create a `Collator`][4] that will sort using the POSIX rules.  Do folks who need to support them need to roll their own sorter, or should x/text/language be extended to support locales from the [ISO/IEC 15897][5] registry?  Is this related to the `posix` variant discussed [here][6], [here][7], and [here][8] (but not [registered][1] or [grandfathered][9]?)?  Maybe I should be translating `LC_COLLATE=POSIX` and `LC_COLLATE=C` to a `und-u-va-posix` language tag for sorting?  See also the distinction between languages and locales [in RFC 2277][10].  This may be related to [this TODO][11]?

[1]: https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
[2]: https://github.com/golang/text/blob/7922cc490dd5a7dbaa7fd5d6196b49db59ac042f/language/language.go#L19
[3]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_02_06
[4]: https://godoc.org/golang.org/x/text/collate#New
[5]: https://en.wikipedia.org/wiki/ISO/IEC_15897
[6]: https://unicode.org/reports/tr35/#Legacy_Variants
[7]: https://unicode.org/cldr/trac/ticket/7958
[8]: https://unicode.org/pipermail/cldr-users/2014-September/000142.html
[9]: https://tools.ietf.org/html/rfc5646#section-2.2.8
[10]: https://tools.ietf.org/html/rfc2277#section-4.3
[11]: https://github.com/golang/text/blob/7922cc490dd5a7dbaa7fd5d6196b49db59ac042f/internal/language/compact/gen_index.go#L50
Repository: pytorch
Issue: [caffe2] How to use multiple CPUs?
Labels: caffe2

I want to run a caffe2 model on multiple CPUs (evaluation).

Is there a way to do that directly? Maybe it requires OpenBLAS?

I don't think is it possible to use multiprocessing and call RunNet on different workspaces.
Repository: go
Issue: x/net/ipv4: add IPv4 header checksum computation for ipv4.Header type
Labels: Proposal,Proposal-Accepted

I'm working on a project that uses packet sockets directly, and I have to calculate the IPv4 checksum on my own since I'm building from Ethernet frames up.

I notice that `x/net/ipv4` doesn't provide any way to easily calculate a checksum, but I think such a function/method could be useful in conjunction with the `ipv4.Header` type.

I wrote a basic implementation in ~30 lines with documentation comments, and would be happy to submit it upstream.  At this point, my questions are:

- Is this something that would be considered generally useful enough to go in `x/net/ipv4`?
- If so, what should the API look like?

My current implementation accepts a byte slice from the output of `ipv4.Header.Marshal`, but I could see a method making sense as well.

```go
// ipv4Checksum computes the IPv4 header checksum for input IPv4 header bytes.
func ipv4Checksum(b []byte) (uint16, error) {
    // ...
}
```

/cc @mikioh
Repository: opencv
Issue: Mouse Wheel Zoom cannot be disabled?
Labels: feature,priority: low,category: highgui-gui

Hi,

I'm using version 3.4.0 for python on Ubuntu. I want to implement custom functionality by listening to mouse-wheel events (wheel up and down).

How can I disable the by default activated zoom in the window when using the mouse wheel?

Thanks a lot,
Kim