sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Adding `impl Add<char> for String` breaks code (adding an impl leads to breakage due to deref coercions)
Labels: A-trait-system,T-lang,A-inference,C-bug,A-coercions

I just prepared a PR to fix #38784. I wanted to add `Add<char>` and `AddAssign<char>` impls for String. However, this breaks the following code:

```rust
let a = String::from("a");
let b = String::from("b");
a + &b;
```

([Playground](https://play.rust-lang.org/?gist=81fafb1dc39fdad9908b1e730985a589&version=nightly&mode=debug))

Apparently, without `Add<char>`, deref coercion is used to turn `&String` into `&str`. With the additional impl, deref coercion is no more and thus it results in:

```
error[E0277]: cannot add `&std::string::String` to `std::string::String`
[...]
     = help: the trait `std::ops::Add<&std::string::String>` is not implemented for `std::string::String`
```

This is unexpected, because [RFC 1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md) says that adding an implementing for a non-fundamental trait is a minor change and thus should not require a major version bump. But if I were to submit a PR which adds `Add<char> for String`, it would probably not be merged, because it breaks a bunch of crates. `a + &b` for `a` and `b` being `String` is widely used.

I would have expected that either deref coercion wouldn't happen in cases where it influences the trait selection (in order to avoid this breakage) or that deref coercion would still happen if there is more than one `impl`. Since the former is not possible anymore, I think the latter is the solution to this problem.

The third option (I can see) would be to change RFC 1105 and amend a section about this special case.
Repository: pytorch
Issue: [feature request] freeze() for nn.Module
Labels: module: nn,low priority,triaged,enhancement

I want to suggest a freeze() method to freeze an already trained module, and its parameters. However, for modules like BatchNorm it is not sufficient to set requires_grad = False, because the running_mean and running_var are still updated unless the the module is set to .eval() . 

Unless I am missing something, ATM, I only can solve this with

```
            self.bn.train(self.bn.training and self.bn.weight.requires_grad)
            x = self.bn(x)
```
which feels quite hacky.  

The idea would be that freeze() sets all the parameters of a module to requires_grad = False, sets self.training = False  and sets a flag self.is_frozen =  True which blocks all future .train() calls to the module. 

cc @albanD @mruberry
Repository: go
Issue: all: port to Windows/ARM32
Labels: OS-Windows,NeedsInvestigation,arch-arm

Hi everyone, we will be submitting a patch in the near future that adds Windows/ARM32 support to GO. All but a few tests are passing, and this implementation has been used to compile GO itself and run Docker containers on Windows/ARM32. We look forward to working with the community to iron out the last remaining issues and get this merged!
Repository: go
Issue: cmd/go: module chatter hides actual errors
Labels: NeedsInvestigation,modules

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
go version go1.10.3 darwin/amd64 vgo:2018-02-20.1

### Does this issue reproduce with the latest release?

yes i built from source today

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN="/Volumes/Repositories/go/bin"
GOCACHE="/Users/jlorenzini/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Volumes/Repositories/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/8w/7ndx_j6s36x9hm9dns67j21s3hynqn/T/go-build299230517=/tmp/go-build -gno-record-gcc-switches -fno-common"
VGOMODROOT="/Users/jlorenzini/repos/operator"
```

### What did you do?
vgo mod -vendor

### What did you expect to see?
The vendor directory to be populated with the packages defined in my go.mod.


### What did you see instead?
The vendor directory is empty after command seemed to download packages.
Repository: rust
Issue: dead_code lint false negative when dead code in warned about dead code
Labels: A-lints,A-trait-system,T-compiler,C-bug,L-dead_code

```rust
#![crate_type="dylib"]
// #![allow(dead_code)]

/* pub */ fn dead_code_test() {
    #[warn(dead_code)] {
        match () {
            #![deny(dead_code)]
            () => { fn im_dead() {} }
        }
        
        fn im_also_dead() {}
    }
}
```

Despite the obvious dead code (the `im_dead` function), this compiles just fine on the [playground](http://play.rust-lang.org/?gist=b8c32cec2714f23997a97a951ec5e8b2&version=stable&mode=debug). It gives the following output:

```
warning: function is never used: `dead_code_test`
 --> src/lib.rs:4:11
  |
L | /* pub */ fn dead_code_test() {
  |           ^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(dead_code)] on by default
```

Neither `im_dead` nor `im_also_dead` emit their compiler error / warning. It makes sense for `im_also_dead` to not do so because it'd be redundant with the error already given. On the other hand, with the `deny`, it should be a hard error.

You'll also note that there's commented out code. By uncommenting either other, the false negative is removed and it fails to compile correctly.
Repository: opencv
Issue: unnecessary lookup table entries
Labels: category: calib3d,Hackathon

I am referring to `prefilterXSobel()` in [`calib3d/stereobm`](https://github.com/opencv/opencv/blob/master/modules/calib3d/src/stereobm.cpp#L196).

Table lookup occurs at `d0+2*d1+d2+OFS`.  
`dN` is in the range `-255 .. 255` thus `d0+2*d1+d2` is in the range `-4*255 .. 4*255`.  
Therefor `d0+2*d1+d2`**+`OFS`** is in the range `4*(256-255) .. 4*(256+255)` ⊂ `0 .. 2*OFS` for `OFS = 4*256`. Thus a capacity of `2*OFS` should be enough and the [additional `256` entries](https://github.com/opencv/opencv/blob/master/modules/calib3d/src/stereobm.cpp#L199) are not needed.
Repository: flutter
Issue: [camera] Access realtime image frames for pre-processing and effect overlays
Labels: c: new feature,p: camera,package,team-ecosystem,P3,triaged-ecosystem

Is it possible to access the real-time camera frame feed to do pre-processing or to be used for ML implementations like face-recognition, Image overlays, filters, etc.?
Repository: pytorch
Issue: Deployment for ios for 1.0
Labels: caffe2

I have a quick question regarding your future release for 1.0, do you guys plan on developing a converter from Pytorch models to coreML? I know Onnx.ai exist.
Repository: rust
Issue: suggest replacing dash with underscore when in-code lint name cannot be found.
Labels: A-diagnostics,A-trait-system,A-parser,T-compiler,C-feature-request,A-suggestion-diagnostics,D-papercut

I was looking at ````rustc -D help```` for additional lints to enable in one of my projects
````
                          anonymous-parameters  allow    detects anonymous parameters
                           bare-trait-objects  allow    suggest using `dyn Trait` for trait objects
                                 box-pointers  allow    use of owned (Box type) heap memory
                    elided-lifetimes-in-paths  allow    hidden lifetime parameters are deprecated, try `Foo<'_>`
            ellipsis-inclusive-range-patterns  allow    `...` range patterns are deprecated
                 missing-copy-implementations  allow    detects potentially-forgotten implementations of `Copy`
                missing-debug-implementations  allow    detects missing implementations of fmt::Debug
                                 missing-docs  allow    detects missing documentation for public members
.....
````
however when trying to enable some of these
````rust
#![warn(anonymous-parameters)]
````
I got an obscure warning;
````
   Compiling fooo v0.1.0 (file:///tmp/fooo)
error: expected one of `(`, `)`, `,`, `::`, or `=`, found `-`
 --> src/main.rs:2:18
  |
2 | #![warn(anonymous-parameters)]
  |                  ^ expected one of `(`, `)`, `,`, `::`, or `=` here
error: unexpected token: `parameters`
 --> src/main.rs:2:19
  |
2 | #![warn(anonymous-parameters)]
  |                   ^^^^^^^^^^ unexpected token after this
error: aborting due to 2 previous errors
error: Could not compile `fooo`.
To learn more, run the command again with --verbose.
````

Apparently I have to translate all dashes ````-```` to underscores ````_```` for it to work.
````rust
#![warn(anonymous_parameters)]
````
An appropriate error message would have been greatly appreciated and saved me a couple of minutes figuring this out.
Something like
````
Could not find "anonymous-parameters", did you mean "anonymous_parameters"?
````
Repository: rust
Issue: The recursion limit for monomorphizations are different than for macro expansions
Labels: I-slow,A-macros

Currently the recursion limit for monomorphization is 64 which the [toml_edit](https://github.com/ordian/toml_edit) crate ended up hitting as reported in https://github.com/Marwes/combine/issues/172 . The solution here is to manually specify a higher recursion limit via the `recursion_limit` attribute.

This does mean that the attribute ends up in a bit of a weird situation though, since `recursion_limit` also affects macro expansions which has a default value of 1024. So any explicitly set value between 64 and 1024 actually ends up reducing the recursion limit for macros.

I assume that there is a good reason for the monomorphization limit being so low compared to the macro limit. But if that is the case then it is perhaps a bit problematic that any increase of the limit for the sake of macro expansion will actually also end up increasing it for monomorphizations as well, only it is increased by a factor of 20 or more.

...

I don't think there is anything that is actually directly actionable in this issue now that I have written it out. But I figure I should still post this as I did end up being rather confused by the fact that setting the recursion_limit to 1024 actually fixed the issue in toml_edit, despite the fact that I remember it being increased to 1024 some time ago (only when I dug up the [issue](https://github.com/rust-lang/rust/pull/41676) did I realize it was only for macros)
Repository: godot
Issue: Rim is broken on a particular mesh
Labels: bug,topic:rendering,confirmed

Godot 3.0.4
Windows 10 64 bits
nVidia geForce GTX 1060

I found a case where spatial material rim light is broken, and I can't reproduce it with another mesh so far.
Basically, it makes the mesh uniformly lighter (or all white) instead of applying, well, a rim effect.

![image](https://user-images.githubusercontent.com/1311555/42128446-bfdc1f4e-7ca3-11e8-8a7f-05549d7eb648.png)

Something even weirder: I had this mesh in my project for a while, and I already made rim working with it.
Here is how it looked like with working rim (but in a different scene with different material):

![image](https://user-images.githubusercontent.com/1311555/42128501-e5259db0-7ca4-11e8-9e63-6fa30dd3df8e.png)

But today I wanted to make a new testbed scene in which I re-used the same mesh, and that's where the bug started happening. The problem persists even if I restart Godot or delete the import folder. I tried to reproduce it with a simple sphere mesh, to no avail.

I made a redux of my project containing only the minimum reproducing the bug:
[RimBugAllWhite.zip](https://github.com/godotengine/godot/files/2152126/RimBugAllWhite.zip)
Repository: godot
Issue: C# Exporting variables not working when Nullable is used
Labels: enhancement,topic:dotnet

When writing a script in C# and exporting a Nullable variable the exported variable doesn't appear in the Godot editor.
To reproduce:
1. create a node in your scene
2. add a script to it
3. add the following variable to your class:
```C#
[Export]
    public float _testVariable;
[Export]
    public Nullable<float> _testVariable2;
```

After you do some magic for the exported variable to appear in the Godot Inspector (mainly rebuilding the project) you will see that _testVariable appears in the Godot Inspector but _testVariable2 does not.

About the versions i am using:
Godot 3.0.4.stable.mono.official.916135
macOS High Sierra 10.13.4

Sorry if this is duplicated just couldn't find it.

Thank you,
Blake
Repository: rust
Issue: Lint against float literals like 4444444444_f32 that "overflow" their mantissa
Labels: A-lints,T-lang,C-feature-request

`4444444444_f32` is actually the number `4444444700` because `f32` doesn't have enough bits to represent `4444444444`. This seems like an obvious thing we should be linting against, but http://play.rust-lang.org/?gist=3e360c4ab4deb3ef9cc16b9c9a084f6e&version=stable&mode=debug&edition=2015 emits no warnings today.

I'm not sure if this should be a new lint or part of the existing `overflowing_literals` lint. It obviously "feels" like the same sort of issue, and it's hard to imagine a situation where you'd want to allow/deny/forbid this and not the other kinds of `overflowing_literals`. But it's also clearly not "overflowing" in the usual sense of being an unrepresentable value greater than MAX or less than MIN, rather it's an unrepresentable value in-between multiple representable values.

(thought of this when reading https://github.com/rust-lang/rust/issues/51534#issuecomment-396917857)
Repository: rust
Issue: trace_macros shows nothing if rustc never actually finishes
Labels: C-enhancement,A-diagnostics,A-macros,T-compiler

Observed in #51754, the following `main.rs`

```
#![feature(trace_macros)]
trace_macros(true);

macro_rules! there_is_a_bug {
    ( $id:ident: $($tail:tt)* ) => {
        there_is_a_bug! { $($tail:tt)* }
    };
}
fn main() {
    there_is_a_bug! { something: more {} }
}
```

never shows *anything* because it never hits an error. The reason that it never hits an error is the focus of #51754, but in summary rustc is performing clones that amount to time spent that is quadratic in the (already exponential) token stream length.

Ideally `trace_macros` should produce output more strictly.  I imagine it currently does not due to however it uses the diagnostics API.

Probably even once #51754 is fixed this example will still show nothing except `out of memory (core dumped)`.
Repository: go
Issue: cmd/compile: msan cannot handle structs with padding
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

go version devel +0dc814c Sat Jun 30 01:04:30 2018 +0000 linux/amd64

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

linux/amd64

### What did you do?

Attempted to dereference a C struct with padding from Go with the memory sanitizer enabled:

```go
// msan.go

package main

/*
#include <stdlib.h>

struct s {
 	int i;
	char c;
};

struct s* mks(void) {
	struct s* s = malloc(sizeof(struct s));
	s->i = 0xdeadbeef;
	s->c = 'n';
	return s;
}
*/
import "C"
import "fmt"

func main() {
	s := *C.mks()
	fmt.Println(s.c)
}
```

I compiled with:

```
CC=clang-6.0 CXX=clang++-6.0 go build -msan -o msan msan.go
```

Upon execution, msan crashes spuriously:

```
~/go1.10/misc/cgo/testsanitizers/src/foo$ ./msan
Uninitialized bytes in __msan_check_mem_is_initialized at offset 5 inside [0x701000000000, 8)
==21637==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4e8b08  (/home/benesch/go1.10/misc/cgo/testsanitizers/src/foo/msan+0x4e8b08)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/benesch/go1.10/misc/cgo/testsanitizers/src/foo/msan+0x4e8b08) 
Exiting
```

The problem appears to be that the Go instrumentation is coarser than the C instrumentation. Only bytes 0-5 are marked as initialized by C (bytes 6-8 are padding), but Go asks msan to verify that all 8 bytes are initialized when it stores `s`.

In this particular example, there are two easy ways to soothe msan. The first is to remove the padding from the struct (e.g., `struct s { int i; int c }`). The second is to access fields within the struct without storing it into a temporary (e.g., `fmt.Println(C.mks().c)`). Neither of these "workarounds" are viable for real programs.
Repository: TypeScript
Issue: meta: factory function inconsistencies
Labels: Bug,Help Wanted,API

Related to #25220 

There are quite a few inconsistencies among the factory functions:

* naming: sometimes the name doesn't really describe what it does.
  * `createStatement` instead of `createExpressionStatement`: what statement does it create?
  * `createBinary`: maybe binary number literal?
  * `createParen`: `ParenthesizedExpression` or `ParenthesizedType`?
  * `createSpread`: `SpreadElement` or `SpreadAssignment`?
  * `createThrow`: becomes ambiguous once the ThrowExpression proposal advances to stage 4
  * `createDo`: becomes ambiguous once the DoExpression proposal advances to stage 4
  * Should all of the factory function names match the name of the Node exactly? If so, should they be renamed while keeping a deprecated alias around for backwards compatibility (like #25348)?
* nullable parameters:
  * `createTypeLiteral` allows the `members` parameter to be `undefined` 
  * `createInterfaceDeclaration` on the other hand requires an array as `members` parameter
* overload signatures to avoid creating invalid nodes:
  * `createYield` has overloads for that purpose
  * `createImportClause` or `createExportDeclaration` for example allow all parameters to be `undefined`, resulting in an invalid node
* optional parameters:
  * `objectAssignmentInitializer` in `createShorthandPropertyAssignment` is optional
  * `typeArguments` in `createTypeReferenceNode` is required although it's nullable
* `decorators`
  * e.g. `createConstructor` or `createExportAssignment` require a `decorators` parameter although it's an error to have decorators on those nodes
* `modifiers`
  * e.g. `createExportAssignment` requires a `modifiers` parameter although this node cannot have any modifiers (not even `declare`)
Repository: TypeScript
Issue: Why do we need to manually type unified overload signatures?
Labels: Suggestion,Awaiting More Feedback

Please close if this has been asked before - nothing came up when searching.

## Search Terms

overload, function, multiple, default, combine, unify, top

## Suggestion

Today, when defining an overloaded call signature you have to manually type the implementation. Would it be possible to extend contextual types so TS can infer the implementation's types from context, just like TS already does for non-overloaded signatures?

## Use Cases

Today, contextual typing isn't able to infer parameter types for overloaded call signatures. Instead, users have to manually type the implementation.

## Examples

### Before

```ts
type Reserve = {
  (from: Date, to: Date, destination: string): Reservation
  (from: Date, destination: string): Reservation
}

let reserve: Reserve = (
  from: Date,
  toOrDestination: Date | string,
  destination?: string
) => { /* ... */ }
```

### After

```ts
type Reserve = {
  (from: Date, to: Date, destination: string): Reservation
  (from: Date, destination: string): Reservation
}

let reserve: Reserve = (
  from,             // inferred as Date | Date = Date
  toOrDestination,  // inferred as Date | string
  destination       // inferred as string | undefined
) => { /* ... */ }
```

## Checklist

My suggestion meets these guidelines:
* [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: godot
Issue: Mono: Add reload icon to refresh export variables in the editor
Labels: enhancement,topic:dotnet

**Godot version:**
3.0/3.1

**OS/device including version:**
All

**Issue description:**
Currently sometimes the editor already doesn't consistently reload exported variables in the editor, but another issue is when dev's are building outside of the editor using msbuild. There's no way to reload the editor to see those changes


**Suggest:**
Give us a little reload icon to refresh the editor without exiting the editor to detect these changes on command.
Repository: rust
Issue: Diagnostic `error[E0408]: variable ... is not bound in all patterns` should be more helpful with typos.
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut,D-terse

Example:

```rust
enum Lol {
    Foo,
    Bar,
}

fn foo(x: (Lol,Lol)) {
    use Lol::*;
    match x {
        (Foo,Bar)|(Ban,Foo) => {}
        _ => {}
    }
}

fn main() {
    use Lol::*;
    foo((Foo,Bar));
}
```

```
error[E0408]: variable `Ban` is not bound in all patterns
 --> src/main.rs:9:9
  |
9 |         (Foo,Bar)|(Ban,Foo) => {}
  |         ^^^^^^^^^  --- variable not in all patterns
  |         |
  |         pattern doesn't bind `Ban`
```

I want it to detect atypical upper-cased variable and trigger search for of enum variants with small edit distance. The notice about the type may be even shown before the actual error message itself to avoid missing it.
Repository: pytorch
Issue: [caffe2] how to substract the mean value ?
Labels: caffe2

I have a trouble that ,how caffe2 sub the mean val:
```python
# cast to float
data = m.Cast(data_uint8, "data", to=core.DataType.FLOAT)
# sub the mean val
mean = workspace.FeedBlob("meanval", np.array(127.5))
data = m.Sub(data, "meanval", data, broadcast=1)
# scale 
data = m.Scale(data, 'data', scale=float(scale_factor))
```
when execute the line: m.Sub, I got : 
TypeError: _CreateAndAddToSelf() takes at most 4 arguments (6 given)