sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: errors involving aliased types should use the alias name
Labels: NeedsFix,compiler/runtime

In https://golang.org/cl/63277, @ianlancetaylor notes:

> Right now if I compile
>
> ```go
> package p
>
> type myByte = byte
> var _ myByte = "uc"
> ```
>
> I get
>
> `foo.go:4:16: cannot use "uc" (type string) as type byte in assignment`
>
> Arguably that is wrong.  For example, gccgo prints
>
> `foo.go:4:5: error: incompatible type in initialization (cannot use type string as type myByte)`
>
> If we first fix the compiler to use the alias name in the error message as I think it should, then perhaps we can apply this change while retaining good error messages.

Concretely: if the compiler reports a type error involving an alias, it should use the aliased name of the type rather than the underlying/canonical name.

That would allow us to use type aliases for a larger subset of C types (#13467) without producing overly-cryptic error messages for mismatched types.
Repository: go
Issue: cmd/compile: constant folding math/bits functions
Labels: Suggested,Performance,help wanted

### What version of Go are you using (`go version`)?

Current git master 577967799c22e5a443ec49f494039f80e08202fe

### What did you expect to see?

There is a very easy optimization possibility of constant folding various functions from math/bits.

Would there be interest in implementing these? 

Personally, I could work on this, but I'm pretty new to the compiler internals and don't have a CLA yet.


```
$ git diff 577967799c22e5a443ec49f494039f80e08202fe

diff --git a/src/cmd/compile/internal/ssa/gen/generic.rules b/src/cmd/compile/internal/ssa/gen/generic.rules
index 92b5b04962..7a81712ccc 100644
--- a/src/cmd/compile/internal/ssa/gen/generic.rules
+++ b/src/cmd/compile/internal/ssa/gen/generic.rules
@@ -142,6 +142,14 @@
 (Div32F (Const32F [c]) (Const32F [d])) -> (Const32F [f2i(float64(i2f32(c) / i2f32(d)))])
 (Div64F (Const64F [c]) (Const64F [d])) -> (Const64F [f2i(i2f(c) / i2f(d))])
 
+// TODO: add more functions from math.bits here
+(BitLen32 (Const32 [c])) && config.PtrSize == 4 -> (Const32 [int64(bits.Len32(uint32(c)))])
+(BitLen32 (Const32 [c])) && config.PtrSize == 8 -> (Const64 [int64(bits.Len32(uint32(c)))])
+(BitLen64 (Const64 [c])) && config.PtrSize == 4 -> (Const32 [int64(bits.Len64(uint64(c)))])
+(BitLen64 (Const64 [c])) && config.PtrSize == 8 -> (Const64 [int64(bits.Len64(uint64(c)))])
+// TODO: is there a "ConstInt" to avoid "PtrSize" checks and simplify the rules above ?
+// TODO: do we have to reimplement math.bits in the compiler because of bootstrap issues ?
+
 // Convert x * 1 to x.
 (Mul8  (Const8  [1]) x) -> x
 (Mul16 (Const16 [1]) x) -> x
diff --git a/src/cmd/compile/internal/ssa/gen/rulegen.go b/src/cmd/compile/internal/ssa/gen/rulegen.go
index c23a54d9b5..e7dc2b39af 100644
--- a/src/cmd/compile/internal/ssa/gen/rulegen.go
+++ b/src/cmd/compile/internal/ssa/gen/rulegen.go
@@ -155,10 +155,12 @@ func genRules(arch arch) {
        fmt.Fprintln(w)
        fmt.Fprintln(w, "package ssa")
        fmt.Fprintln(w, "import \"math\"")
+       fmt.Fprintln(w, "import \"math/bits\"")
        fmt.Fprintln(w, "import \"cmd/internal/obj\"")
        fmt.Fprintln(w, "import \"cmd/internal/objabi\"")
        fmt.Fprintln(w, "import \"cmd/compile/internal/types\"")
        fmt.Fprintln(w, "var _ = math.MinInt8  // in case not otherwise used")
+       fmt.Fprintln(w, "var _ = bits.UintSize // in case not otherwise used")
        fmt.Fprintln(w, "var _ = obj.ANOP      // in case not otherwise used")
        fmt.Fprintln(w, "var _ = objabi.GOROOT // in case not otherwise used")
        fmt.Fprintln(w, "var _ = types.TypeMem // in case not otherwise used")
```
Repository: flutter
Issue: Cupertino library sometimes depends on specific widget types
Labels: framework,f: cupertino,c: proposal,P2,team-design,triaged-design

We should always be agnostic about the child widget type, otherwise it violates our composition model.

There's basically two principles we can apply here:

* Wrapping a widget X in a widget Y that does nothing but return the widget X should always work exactly the same as using X directly. For example, wrapping a Text in a Tooltip should always work.

* Replacing a widget X with an entirely independent widget Y that happens to be implemented exactly the same way should always work exactly the same as using X directly.

Ideally, anywhere you accept a Widget you should accept a Placeholder or a widget equivalent to Placeholder, and act the same as if you'd gotten anything else.

Places I've noticed where we violate this:

- [x] CupertinoNavigationBar.middle + CupertinoNavigationBar.largeTitle, we assert that `middle is Text`.
- [ ] CupertinoScaffold.tabbed requires a CupertinoTabBar.
- [x] CupertinoScaffold.navigationBar is handled differently if it is a CupertinoNavigationBar

cc @xster @cbracken
Repository: react
Issue: A faster diff algorithm
Labels: Type: Discussion,Component: Reconciler

This is an invitation to discussion...

So, react is pretty freaking awesome and I used it quite a bit. One thing unfortunately where react is not as strong is in performance, which gave roots to Inferno and Preact. Although, this is generally a non-issue on desktop, while mobile might be a bottleneck.

I know many members of the team have been working on improving bundle size (I believe through rollup support in a talk I heard), asynchronous scheduling, etc. I am also aware that @trueadm (the creator of inferno) joined the React team and is working on improving it.

The point I want to bring up is this library [petit-dom](https://github.com/yelouafi/petit-dom). It uses, is a diff algorithm (links that explain it provided in the README) and it seems to score incredibly on [vdom performance tests](https://github.com/krausest/js-framework-benchmark). In fact, it is only beat by 2 technologies, vanillajs and surplusjs [per the benchmark snapshot](https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html).

petit-dom beats inferno, preact, mithril, vue, angular, etc. Of course, it is not a proper js framework, however the point I am trying to make is that it is far faster and a major difference between the other frameworks seems to be its diff algorithm.

I realize this would mean a rewrite of a good portion of react-dom, which is why it is simply a discussion :D.

If this is unfeasible, or simply going after the wrong target/bottleneck, let me know as it is after all a discussion.
Repository: go
Issue: cmd/cgo: C functions that return void incorrectly return Go values
Labels: NeedsInvestigation,compiler/runtime

`cgo` fails to reject the following program — despite numerous errors involving values of type `C.void`, which ought to be completely uninstantiable. (The word “void” itself means “empty”, so it's nonsensical for the type “void” to contain a value!)

I'm not sure to what extent this is fixable, given that the fix for #3729 added a test verifying that Go callers can bind `_, err` to the result of a call to a void-returning function.

```go
package p

/*
static void return_void() { return; }
*/
import "C"

func F() {
	x := C.return_void() // ERROR HERE
	var y C.void = x     // ERROR HERE
	var z *C.void = &y   // ERROR HERE
	var b [0]byte = *z   // ERROR HERE
	_ = b
}
```
Repository: pytorch
Issue: support grid_sample with batch=1 but supprting batch affine parameters
Labels: triaged,module: vision,module: interpolation

I'm trying to use the grid_affine with grid_sample to do the ROIAlign operation.
In my cases, one feature tensor is accompanied with many boxes, and one box means one affine parameter. Therefore, I use `feature.expand(number_of_box, C, H, W)` to expand the feature to the same batch as the affine parameter.  In this way, it cost much GPU memory.
```
feature = feature.expand(number_of_box,C, H, W)
grid_size = torch.Size([number_of_box, 1, 7,7])
grid = F.affine_grid(theta, grid_size)
sub_feature = F.grid_sample(feature, grid)
```
If I use a loop to do these operations, the memory usage is less than the above one.
```
all_roi = []
for j in range(number_of_box):
  _grid = grid.narrow(0, j, 1)
  _roi_feature = F.grid_sample(feature, _grid)
  all_roi.append( _roi_feature )
```
What causes this problem? Is it possible to support affine_sample with batch size = 1, but shared for the batched affine_parameters?

cc @fmassa @vfdev-5 @pmeier
Repository: create-react-app
Issue: Deploy both ES5 and ES2015+ code in production
Labels: issue: proposal

### Is this a bug report?

No

Everything described in [this article](https://philipwalton.com/articles/deploying-es2015-code-in-production-today/).

 But for lazy ones I'll add some highlights here.

```html
<!-- Browsers with ES module support load this file. -->
<script type="module" src="main.js"></script>

<!-- Older browsers load this file (and module-supporting -->
<!-- browsers know *not* to load this file). -->
<script nomodule src="main-legacy.js"></script>
```

> Warning! The only gotcha here is Safari 10 doesn’t support the nomodule attribute, but you can solve this by [inlining a JavaScript snippet](https://gist.github.com/samthor/64b114e4a4f539915a95b91ffd340acc) in your HTML prior to using any <script nomodule> tags. (Note: this has been fixed in Safari Tech Preview, and should be released in Safari 11).

And here is the [working example](https://github.com/philipwalton/webpack-esnext-boilerplate).
Repository: vscode
Issue: Word selection when holding Ctrl and dragging with mouse
Labels: feature-request,editor-wordnav

in VS2015 you can select whole words by holding down CTRL and do selection, it's faster and easier !!

you can also CTRL + CLICK to select a whole word. 

MAKE IT SO ... please :) 

---

*Edit by @hediet:*
Video: https://www.youtube.com/watch?v=bfyO8haWKfg
Repository: go
Issue: os/exec: CommandContext does not forward the context's error on timeout
Labels: NeedsInvestigation

Go version: Latest release - 1.9

Using `CommandContext` in combination with `Context.WithTimeout` shows very few information about the reason of the error when the execution times out.
Using a small variation of the [CommandContext example
](https://golang.org/pkg/os/exec/#example_CommandContext) proves this:
```
package main

import (
        "context"
        "fmt"
        "os/exec"
        "time"
)

func main() {
        ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
        defer cancel()

        if err := exec.CommandContext(ctx, "sleep", "5").Run(); err != nil {
                fmt.Println("cmd: ", err)
                fmt.Println("ctx: ", ctx.Err())
        }
}
```
Output:
```
cmd:  signal: killed
ctx:  context deadline exceeded
```

Also, if the context is already done then the `cmd.Run` gets called, the error matches the context's error:
```
package main

import (
        "context"
        "fmt"
        "os/exec"
        "time"
)

func main() {
        ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
        defer cancel()
        time.Sleep(150 * time.Millisecond)

        if err := exec.CommandContext(ctx, "sleep", "5").Run(); err != nil {
                fmt.Println("cmd: ", err.Error())
                fmt.Println("ctx: ", ctx.Err().Error())
        }
}
```
Output:
```
cmd:  context deadline exceeded
ctx:  context deadline exceeded
```
Repository: vscode
Issue: XHR Failed on trying to install plugins via Visual Studio code
Labels: bug,proxy

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode. -->

<!-- Use Help > Report Issues to prefill these. -->
- VSCode Version: 1.16.0
- OS Version: Windows 10

Steps to Reproduce:

1. When trying to install a plugin, i get an error **XHR Failed**. 
2. Also when i try to download the extensions manually and try to install it via the options "install from VSIX", it fails silently.
3. I am behind a proxy network.
Repository: go
Issue: cmd/go: ignore *.syso files in -msan mode
Labels: NeedsFix,GoCommand

Packages with syso files currently fail in -msan mode because the syso file calls out to a routine like memcmp which then falsely reports uninitialized memory.

It's not possible to prepare a syso file that works regardless of memory-sanitizer setting, at least not if the code makes any memory writes, which most code does. Instead you'd have to prepare both a standard syso and an msan-enabled syso, and the go command conventions provide no way to tell those apart.

I suggest we simply ignore syso files in -msan mode. That will result in missing link symbols, but then package authors can revise their packages to avoid the syso in -msan mode. That gives package authors at least one way to write a package that has a syso and still works with -msan. Today there are zero ways.

A more complex change would be to introduce a new class of objects like \*.syso.msan or \*_msan.syso, but let's not do that until there's a compelling reason. In the case where this came up, the "ignore syso files" is good enough.
Repository: TypeScript
Issue: Add Length Parameter to typed arrays
Labels: Suggestion,Domain: lib.d.ts,Awaiting More Feedback

The goal is pretty straight forward, since typed arrays have a fixed length it would be a more accurate and helpful type it you could specify length. Then you could get complaints if you try to assign or access a higher index or use a array of the incorrect length.

**Code**

```ts
type Vector2d = Int32Array<2>;
type Vector3d = Int32Array<3>;
type Matrix = Int32Array<16>;

const add =
  (vecA:Vector2d) =>
    (vecB:Vector2d, target:Vector2d = new Int32Array(2) ):Vector2d => {
      target[0] = vecA[0] + vecB[0];
      target[1] = vecA[1] + vecB[1];
      return target;
    };

const add3d =
  (vecA:Vector3d) =>
    (vecB:Vector3d, target:Vector3d = new Int32Array(3) ):Vector3d => {
      target[0] = vecA[0] + vecB[0];
      target[1] = vecA[1] + vecB[1];
      target[2] = vecA[2] + vecB[2];
      return target;
    };

const position = new Int32Array(2);
const position3d = new Int32Array(3);
const velocity = new Int32Array([1,1]);
const velocity3d = new Int32Array([1,2,3]);

add(position)(velocity, position);
const newPosition = add(position)(velocity);

add3d(position3d)(velocity3d, position3d);
add(position3d)(velocity3d, position3d); // Fails due to incorrect array length
```
Repository: pytorch
Issue: Proposal: simplify overloaded Tensor function signatures
Labels: triaged

Currently we have a few functions on Tensor with multiple overloads. This makes parsing, documentation, and error messages more complicated.

These overloads get ambiguous with zero-dim tensors (scalars) because they can bind to either the "float" or "Tensor" overloads.

We should combine the Tensor/scalar overloads and move optional arguments to the end of the function (as keyword-only args). The old signatures will be deprecated (issue a warning) and removed from the documentation and error messages.

Functions which accept a `Tensor` arguments will also accept Python numbers in their place. The numbers will automatically get promoted to zero-dim tensors.

`torch.max` currently has three overloads:

```
torch.max(input) -> Tensor
torch.max(input, dim, keepdim=False) -> Tensor, LongTensor
torch.max(input, other)
```

We should combine the first two overloads and make the third overload (element-wise max) a separate function (`fmax`). Eventual `max` over an array should only return the max elements (not the indices) unless `return_indices=True`. For backwards compatibility, if `return_indices` is unspecified, 



```python
def max(input, dim=None, keepdim=False, return_indices=None):
  if isinstance(dim, torch.Tensor):
      # raise deprecation warning
      return fmax(input, other)
  if return_indices is None:
     if dim is not None:
       # raise deprecation warning about return_indices
     return_indices = dim is not None
  # dispatch to ATen implementation
  ...

def fmax(input, other):
   # element-wise maximum preferring non-NaN
```

We should also do the same for `torch.min`.

We have already updated `add`, `addmm`, `addbmm`, `addcmul`, `sub`.
Repository: TypeScript
Issue: @ts-check complains about the object given to Object.defineProperty not having Object properties
Labels: Bug,Help Wanted,Domain: lib.d.ts,VS Code Tracked

_From @kenchris on September 14, 2017 13:28_

 ie. ```[js] Property 'removeAttribute' does not exist on type 'PropertyDescriptor'.```

Though this code works fine

```
constructor() {
    super();
 
    for (const prop in this.constructor.properties) {
      const symbol = Symbol.for(prop);
      const { type: typeFn, value, reflectToAttribute } = this.constructor.properties[prop];

      Object.defineProperty(this, prop, {
        get() { return this[symbol] || value; },
        set(v) {
          let value = typeFn(v)
          this[symbol] = value;
          if (reflectToAttribute) {
            if (typeFn.name === 'Boolean') {
              if (!value) {
                this.removeAttribute(prop);  
              } else {
                this.setAttribute(prop, prop);
              }
         ...
```

_Copied from original issue: Microsoft/vscode#34377_
Repository: TypeScript
Issue: Add WebVR API to lib.d.ts
Labels: Suggestion,Help Wanted,Revisit,Domain: lib.d.ts

Docs at https://developer.mozilla.org/en-US/docs/Web/API/WebVR_API
Repository: react
Issue: What should portals do when container has a child managed by React?
Labels: Component: DOM,Type: Discussion

**Do you want to request a *feature* or report a *bug*?**
Bug

**What is the current behavior?**
`ReactDOM.unstable_createPortal(<Component/>, target)` appends the rendered component in the target instead of replacing the contents of the target

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/ebsrpraL/).**

https://codesandbox.io/s/pjx8x9z2o7

**What is the expected behavior?**

It should replace the contents of the target with the new rendered component

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

react@16.0.0-rc.3
react-dom@16.0.0-rc.3


Note: I might have completely misunderstood how portals work. @gaearon [encouraged me](https://twitter.com/dan_abramov/status/908443416173924352) to open this issue 😄
Repository: TypeScript
Issue: VS Code Intellisense seems to wrongly infer revealing module pattern 
Labels: Suggestion,In Discussion,VS Code Tracked,Domain: JavaScript

_From @lodybo on September 12, 2017 9:44_

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode. -->

<!-- Use Help > Report Issues to prefill these. -->
- VSCode Version: 1.16.0
- OS Version: Windows 10

Steps to Reproduce:

1. Copy the code below into a file called `greeter.js`
2. Run `node greeter.js` in a terminal

```javascript
var Greeter = (function(country) {
  // Private
  this.country = country;

  function getCountry() {
    return country;
  }
  
  // Public
  var performGreeting = function (name) {
    var country = getCountry();
    
    return 'Hello ' + name + ', from ' + country;
  }
  
  return {
    greet: performGreeting
  }
});

var greeter = new Greeter("The Netherlands");
console.log(greeter.greet("Lody"));
console.log(greeter.country);
```
Using the revelealing module pattern in VS Code seems to trip up Intellisense into suggesting the wrong members. The code above was tested in multiple browsers and consoles and run with Node v6.3.0 which behaved as expected. They ran the `greet()` function and returned `undefined` for `greeter.country`:
```bash
λ node greeter.js
Hello Lody, from The Netherlands
undefined
```

But VS Code's Intellisense reports that `greeter` only contains `country`:
![image](https://user-images.githubusercontent.com/1598330/30318944-d12c85de-97ae-11e7-9e18-b82689b34769.png)

It also reports the expected interface of `greeter` for the class itself (`Greeter`):
![image](https://user-images.githubusercontent.com/1598330/30318992-eed8773c-97ae-11e7-8678-9e279455fa38.png)

What is expected is VS Code correctly inferring `greeter.greet` to be a function of `Greeter`, with a parameter `name`.

This was reproduced in a clean folder of VS Code, with no extensions (launched with `code --disable-extensions`), and no `jsconfig.json`.

_Copied from original issue: Microsoft/vscode#34214_
Repository: TypeScript
Issue: New Feature Requesting for `const` Parameter
Labels: Suggestion,Awaiting More Feedback

I have a small **new feature** to request. Let say we have this piece of code:
```ts
function setButton(button: Button | undefined) {
    if (button) {
        button.onclick = () => {
            // tsc complains button might be undefined(well done!), 
            // because it might be set to undefined later on,
            // as you can see below `button = undefined;`. 
            button.setAttribute('disabled', 'true'); //error
        }
    }
    // some other code goes here...
    // and eventually, button is set to undefined.
    button = undefined;
}
```
Fortunately, there is a way to fix this:
```ts
function setButton(button: Button | undefined) {
    const constButton = button;
    if (constButton) {
        constButton.onclick = () => {
            // now tsc is satisfied.
            constButton.setAttribute('disabled', 'true'); 
        }
    }
    
    // impossible to assign to a const variable.
    // constButton = undefined;
}
```
But can we twist the code a little bit, which is what I asking for? Something like this:
```ts
function setButton(const button: Button | undefined) {
    if (button) {
        button.onclick = () => {
            button.setAttribute('disabled', 'true'); 
        }
    }
}
```
So you can see there really are some cases a `const` parameter might come to handy. Thank you.




P.S. Just for demonstrating the point, here's a full demo:
```ts
class Button {
    onclick?: () => void;
    performClick() {
        if (this.onclick) this.onclick();
    }
    setAttribute(key: string, value: string) {
        //set attribute to this button
    }
}

function setButton(button: Button | undefined) {
    if (button) {
        button.onclick = () => {
            button.setAttribute('disabled', 'true');
        }
    }
    button = undefined;
}

const button = new Button();
setButton(button);
button.performClick();
```
Repository: rust
Issue: [idea] Allow .rmeta to be translated in .rlib files
Labels: I-compiletime,T-compiler,C-feature-request

We could then teach cargo to make .rmeta files and concurrently convert them to .rlib files. If you only need .rmeta files for dependencies cargo could convert the .rmeta files when some cores are idle. This would be more efficient, as a crate can be compiled before llvm is run for its dependencies.