sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: os, x/build: only write permissions 0222 for file result in successful read for linux-amd64
Labels: NeedsInvestigation

Coming here from https://go-review.googlesource.com/c/go/+/229357/3#message-c7922ea647b703faa8e858428f47221a6d921275 and https://storage.googleapis.com/go-build-log/b49db1e9/linux-amd64_454ff41f.log in which we have an odd test failure
```shell
# go run run.go -- fixedbugs/issue36437.go
incorrect output
Expected a non-nil error, but got:
	""
want
	"open /workdir/tmp/33921360662258/main.go: permission denied\n"
FAIL	fixedbugs/issue36437.go	0.291s
2020/04/22 23:32:59 Failed: exit status 1
go tool dist: FAILED
```
in which the relevant test is
```go
package main

import (
        "fmt"
        "io/ioutil"
        "os"
        "os/exec"
        "path/filepath"
)

func main() {
        tmpDir, err := ioutil.TempDir("", "issue36437")
        if err != nil {
                panic(err)
        }
        defer os.RemoveAll(tmpDir)

        msgOrErr := func(bmsg []byte, err error) string {
                msg := string(bmsg)
                if msg == "" && err != nil {
                        msg = err.Error()
                }
                return msg
        }

        // 2. Invoke the compiler with a file that we don't have read permissions to.
        path := filepath.Join(tmpDir, "main.go")
        if err := ioutil.WriteFile(path, []byte("package p"), 0222); err != nil {
                panic(err)
        }
        output, err = exec.Command("go", "tool", "compile", path).CombinedOutput()
        want := fmt.Sprintf("open %s: permission denied\n", path)
        if g, w := msgOrErr(output, err), want; g != w {
                panic(fmt.Sprintf("Expected a non-nil error, but got:\n\t%q\nwant\n\t%q", g, w))
        }
}
```

Is this perhaps just a problem with the builder? I'd expect that 0222 would make a file writable but would error on reading; other GOOS-GOARCH combinations work properly but not this one.
Repository: terminal
Issue: Background image should (optionally?) render pixel-for-pixel rather than scaling with the system scale
Labels: Help Wanted,Issue-Bug,Area-TerminalControl,Product-Terminal,Priority-3

# Description of the new feature/enhancement

This might be related to #2370, but it addresses a slightly different problem.

Currently, Windows Terminal scales the background image according to your system UI scale. So, for example, if your UI scale is set to 150% in Windows Settings, and you set a 100×100-pixel background image with `backgroundImageStretchMode: none`, the image will be rendered at 150×150. This might not be what you want, since the scaling will blur sharp edges, and the image will be much larger than you might have expected.

# Proposed technical implementation details (optional)

There should be some way to indicate that we want our background image to render pixel-for-pixel, rather than be enlarged according to the UI scale.

Or else maybe it should simply render pixel-for-pixel by default. This was my expectation; not sure if it matches the expectation of others.
Repository: flutter
Issue: Consider hiding windows until the engine is active in the desktop runner templates
Labels: engine,platform-mac,platform-windows,platform-linux,c: proposal,a: desktop,P3,team-macos,triaged-macos

A common request from people trying Flutter on desktop is being able to control initial window size and position from Dart, which makes sense given that application logic for Flutter apps often lives entirely in Dart. Currently, however, the windows are made as part of creating the associated engine, so their initial size is set in the platform (ObjC, C++) code.

The `window_size` FDE plugin (which will eventually be replaced with framework functionality) allows repositioning it, but because of the ordering and the async nature of engine startup, doing that at startup is very ugly; the window is briefly visible with one frame, then jumps to another frame. (This also means that the common desktop functionality of remembering window frames currently has to be done in platform code, not Dart, which is not ideal either.)

A possible solution here would be to have the runner template create the window hidden, and add an early lifecycle event to a system channel which would trigger the window to show. We could include a frame in that message, so that the window would only ever be visible with a frame controlled by Dart code. We could even consider having that message sent only after the first paint is finished to avoid an initial white frame.

This has to be balanced against the fact that it'll make the window slower to show up, but I think that will still be substantially better in most cases. If it's slow enough for that to be an issue, a splash screen that's separate from the window would be a much cleaner user experience (although of course ideally, it should be fast enough that that's not necessary)

Status:
* [x] Windows https://github.com/flutter/flutter/pull/109816
* [ ] macOS
* [ ] Linux
Repository: terminal
Issue: Dynamic Profile Generator for Windows PowerShell
Labels: Help Wanted,Area-Settings,Product-Terminal,Issue-Task

# Description of the new feature/enhancement

It'd be nice if the "Windows PowerShell" profile worked like the other profiles, and could be disabled using `disabledProfileSources`.

This would remove the need to carry a 'hidden' overriding profile per #5459, as `disabledProfileSources` made possible for the other profile sources.

# Proposed technical implementation details (optional)

I _guess_ it just needs new `IDynamicProfileGenerator` implementation, that replaces (and slurps up?) the existing Windows PowerShell profile if present, which appears to have a fixed GUID (`{61c54bbd-c2c6-5271-96e7-009a87ff44bf}`), fix the 'pick a default profile' logic, and then remove it from the defaults.json.

If the same thing is done for CMD, then I guess the risk appears of how to handle the case that there are _no_ profiles available, where right now I guess you always have those two profiles, even if somehow they are not usable.
Repository: material-ui
Issue: [TextField] Missing pseudo-classes generates error when overriding <Input>
Labels: bug 🐛,component: text field,ready to take

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

Trying to override the CSS class `adornedEnd` or `adornedStart` of `<Input />` generates an error  "Material-UI: the key X provided to the classes prop is not implemented in ForwardRef(Input).". When I use a `<FilledInput />` or `<OutlinedInput />` no error is generated.

## Expected Behavior 🤔

The CSS classes of `<Input />` should be consistently with other input components.

## Steps to Reproduce 🕹

Open this [codesandbox](https://codesandbox.io/s/xenodochial-breeze-7oo8l?file=/src/Demo.js) and look at the console.

## Context 🔦

I created a select using `<TextField variant="filled" />`. This select had a clear button as adornment and I used the CSS class to remove the padding. When I changed to the standard variation I got the error.

## Your Environment 🌎

<!--
  Include as many relevant details about the environment with which you experienced the bug.
  If you encounter issues with typescript please include version and tsconfig.
-->

| Tech        | Version |
| ----------- | ------- |
| Material-UI | v4.9.11  |
| React       |         |
| Browser     |         |
| TypeScript  |         |
| etc.        |         |

Possible fix: Add the missing pseudo-classes and update the TypeScript definitions to match the other input components.

I noticed that all input components wrap the `InputBase`. Should the TS definition use the `InputBaseClassKey` as base? [Input](https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Input/Input.d.ts) is different from [OutlinedInput](https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/OutlinedInput/OutlinedInput.d.ts).
Repository: flutter
Issue: Failed assertion: line 110 pos 12: '_positions.isNotEmpty'
Labels: framework,f: material design,f: scrolling,customer: wednesday,P2,team-design,triaged-design

I have 5 pieces of data in my Swiper, I have an Index record of the current position, and when I delete the last item, I move the Index forward and delete the last item. This is when the error is reported.

```console
flutter: The following assertion was thrown:
flutter: ScrollController not attached to any scroll views.
flutter: 'package:flutter/src/widgets/scroll_controller.dart':
flutter: Failed assertion: line 110 pos 12: '_positions.isNotEmpty'
flutter:
flutter: Either the assertion indicates an error in the framework itself, or we should provide substantially
flutter: more information in this error message to help you determine and fix the underlying cause.
```
Repository: PowerToys
Issue: Hide taskbar labels without combining icons
Labels: Idea-New PowerToy,Product-Tweak UI Design

# Summary of the new feature/enhancement

Windows doesn't provide an option to hide open apps labels without combining them together. Such a thing would be useful when you want to quickly switch between open windows of the same app. 

# Proposed technical implementation details (optional)

A place when I can choose those two options separately: 1. combined or not, 2. show/hide labels.
Repository: youtube-dl
Issue: Please add support for https://www.rtp.pt/play/p7170/e468013/estudarcomautonomia
Labels: site-support-request


## Checklist

- [X] I'm reporting a new site support request
- [X] I've verified that I'm running youtube-dl version **2020.03.24**
- [X] I've checked that all provided URLs are alive and playable in a browser
- [ ] I've checked that none of provided URLs violate any copyrights
- [ ] I've searched the bugtracker for similar site support requests including closed ones

## Example URLs

- Playlist: https://www.rtp.pt/play/p7170/e468013/estudarcomautonomia

## Description
lessons to K12 from national portuguese chanel
Repository: terminal
Issue: Can't drag the window using the pixels on top of the screen over a tab
Labels: Area-UserInterface,Product-Terminal,Issue-Task

# Environment

Windows build number: Microsoft Windows [version 10.0.18363.778]
Windows Terminal version (if applicable): 0.10.781.0

# Steps to reproduce

1. Maximize the terminal window
2. Open a lot of tabs to fill the title bar
3. Try to drag the window using the title bar, placing the mouse above one of the tabs (top of the screen)

# Expected behavior

The window should un-maximize and begin to move with the mouse, just like every other window.

# Actual behavior

The window doesn't move at all.
Repository: godot
Issue: `minimum_size_changed()` stops working after getting in a locked state
Labels: bug,topic:gui

**Godot version:** v3.2.1.stable.official (should be the same for master)

**OS/device including version:** Arch Linux 5.6.6-arch1-1 x86_64

**Issue description:** `minimum_size_changed()` stops working after getting in a locked state

![screenshot, label is not resized](https://user-images.githubusercontent.com/6108978/80093136-450e2480-8564-11ea-9740-e6f42a5201e8.png)




**Steps to reproduce:**

Open minimal reproduction project and run.

Push first button with code:

```gdscript
# in scene:
container.call_deferred("remove_child", label)
label.minimum_size_changed()
```

[control.cpp#L2565-L2589](https://github.com/godotengine/godot/blob/3.2/scene/gui/control.cpp#L2565-L2589) :

```cpp
// in core
data.updating_last_minimum_size = true;
MessageQueue::get_singleton()->push_call(this, "_update_minimum_size");
```

Then push second button

```gdscript
# in scene
container.add_child(label)
```

Push the third button

```gdscript
# in scene
label.text = "large banana"
```

```cpp
// in core
// same lines as above, my guess:
if (data.updating_last_minimum_size)
  return;
```

The size of the label doesn't adapt to its content. It is expected that it does adapt.

To resolve, push the fourth button:

```gdscript
# in scene
label._update_minimum_size()
```

[control.cpp#L296](https://github.com/godotengine/godot/blob/3.2/scene/gui/control.cpp#L296) :

```cpp
// in core
data.updating_last_minimum_size = false;
```

Then push the fifth button:

```gdscript
# in scene
label.text = "large apple"
```

Now the label size changed again as expected.

**Minimal reproduction project:**
[issue_minimum_size.zip](https://github.com/godotengine/godot/files/4521973/issue_minimum_size.zip)


**workaround**

Hooking the `_update_minimum_size()` function to the `node_added` signal seems to workaround the issue:

```gdscript
func _ready():
  get_tree().connect("node_added", self, "workaround")

func workaround(node):
  if node is Control:
    node.call_deferred('_update_minimum_size')
```
Repository: go
Issue: x/mobile: adding an assets/icon.png erases the app label
Labels: NeedsInvestigation,mobile

`go version go1.13.5 linux/amd64`

I added an icon asset to the network example from the gomobile examples directory. It did get an icon (yay!), but the program name became `org.golang.app.GoNativeActivity` instead of network.
Repository: rust
Issue: `for<'a> Send` is distinct from `Send`?
Labels: A-lifetimes,A-trait-system,T-compiler,C-bug

This code fails to compile with a pretty strange error:

```rust
use std::future::Future;
use std::pin::Pin;
use std::io::Read;

trait Service<R> {
    type Response;
    type Error;
    type Future: Future<Output = Result<Self::Response, Self::Error>>;
    
    fn call(&mut self, req: R) -> Self::Future;
}

struct BorrowerService<S> {
    service: Option<S>,
}

impl<S> Service<Box<dyn Read + Sync + Send>> for BorrowerService<S>
where
    for<'b> S: Service<&'b (dyn Read + 'static + Sync + Send), Response = i32, Error = ()> + 'static + Send,
    for<'b> <S as Service<&'b (dyn Read + 'static + Sync + Send)>>::Future: Send,
{
    type Response = i32;
    type Error = ();
    type Future = Pin<Box<dyn Future<Output = Result<i32, ()>> + Send>>;
    
    fn call(&mut self, req: Box<dyn Read + Sync + Send>) -> Self::Future {
        let mut service = self.service.take().unwrap();
        Box::pin(async move {
            service.call(&req).await
        })
    }
}
```

```
error[E0308]: mismatched types
  --> src/lib.rs:28:9
   |
28 | /         Box::pin(async move {
29 | |             service.call(&req).await
30 | |         })
   | |__________^ one type is more general than the other
   |
   = note: expected type `std::marker::Send`
              found type `for<'b> std::marker::Send`
```

The use of the trait object appears to be important - if I replace that with e.g. `String`, it compiles just fine:

```rust
use std::future::Future;
use std::pin::Pin;

trait Service<R> {
    type Response;
    type Error;
    type Future: Future<Output = Result<Self::Response, Self::Error>>;
    
    fn call(&mut self, req: R) -> Self::Future;
}

struct BorrowerService<S> {
    service: Option<S>,
}

impl<S> Service<Box<String>> for BorrowerService<S>
where
    for<'b> S: Service<&'b String, Response = i32, Error = ()> + 'static + Send,
    for<'b> <S as Service<&'b String>>::Future: Send,
{
    type Response = i32;
    type Error = ();
    type Future = Pin<Box<dyn Future<Output = Result<i32, ()>> + Send>>;
    
    fn call(&mut self, req: Box<String>) -> Self::Future {
        let mut service = self.service.take().unwrap();
        Box::pin(async move {
            service.call(&req).await
        })
    }
}
```
Repository: rust
Issue: Address CTFE perf regression introduced by #71005
Labels: C-enhancement,I-compiletime,T-compiler,A-const-eval,C-optimization

In an effort to treat the return place `_0` more closely to regular locals, #71005 has removed some optimizations that avoid allocating memory for locals when there's only a return place. This regresses the [CTFE stress test](https://github.com/rust-lang/rustc-perf/blob/master/collector/benchmarks/ctfe-stress-4/src/lib.rs) by around 8%.

It would be good to gain the lost performance back. https://github.com/rust-lang/rust/pull/71005#discussion_r412263905 contains some ideas for how to do that.
Repository: pytorch
Issue: Propagation of channels-last layout leads to massive slowdowns in 1.5 compared to 1.4
Labels: module: performance,module: internals,triaged,module: memory format

## 🐛 Bug

Backpropagation through `tensor.permute()` is a lot slower in pytorch 1.5 compared to pytorch 1.4. 
I'm not exactly sure what is causing this, but it seems like a bug.(?)

## To Reproduce

Run following file with pytorch 1.4 and pytorch 1.5. (You might have to adjust the number of iterations or size of the input tensor if it takes too much or too little time)

```
import torch
import torch.nn as nn

class Perm(nn.Module):
    def __init__(self):
        super().__init__()
        self.s = nn.Parameter(torch.tensor([1.0]))

    def forward(self, x):
        y = x.mean(dim=(2, 3), keepdim=True) # = torch.nn.functional.adaptive_avg_pool2d(x, output_size=(1, 1))
        y = y.permute(0, 2, 3, 1) # channels to last dim
        y = y*self.s  # without this, there is next to no difference
        y = y.permute(0, 3, 1, 2) # channels back to second dim
        y = x * y
        return y

device = torch.device('cuda:0') # can be changed to 'cpu'
net = Perm().to(device)
opt = torch.optim.Adam(params=net.parameters(), lr=0.001)

def train(device=device, iters=10):
    x = torch.zeros((10, 64, 256, 256)).to(device)
    for k in range(iters):
        y = net(x).sum()
        opt.zero_grad()
        y.backward()
        opt.step()

if __name__ == '__main__':
    import timeit
    print(timeit.timeit("train()", setup="from __main__ import train", number=10))
```


## Expected behavior

I expected both versions to have a similar run time, but in v1.5 we have a ~4x slowdown.
* Runtime on cpu: v1.4: 5.07s / v1.5: 21.5s
* Runtime on gpu: v1.4: 0.665s/ v1.5: 3.31s

## Environment

 - PyTorch Version (e.g., 1.0): 1.4 and 1.5
 - OS (e.g., Linux): Ubuntu 18.04
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source): - 
 - Python version: 3.7
 - CUDA/cuDNN version: 10.1
 - GPU models and configuration: nvidia  P6000
 - Any other relevant information: - 

## Additional context

<!-- Add any other context about the problem here. -->


cc @ezyang @gchanan @zou3519 @SsnL @albanD @gqchen @VitalyFedyunin @jamesr66a @ngimel
Repository: godot
Issue: Optional GDNative libraries not available on some platforms always trigger errors in the editor
Labels: bug,topic:editor,topic:gdextension

Godot 3.2.1

The title can be misleading, but here is the situation:
It is possible to not specify some platforms in a GDNative library if those platforms aren't supported natively.
I have a plugin containing such optional GDNative library to speed things up under specific platforms that I support. To keep the plugin working on other platforms, I fallback on a GDScript implementation, which I handle in code by deciding wether or not to load such library, and alternating between implementations of the same class (without type hints): https://github.com/Zylann/godot_heightmap_plugin/blob/master/addons/zylann.hterrain/native/factory.gd
This works well so far.

But the problem is, the editor still tries to *load* the `gdnlib` or `gdns` resources even on platforms where the library is not supported, which systematically causes confusing errors in the console even when the plugin actually works fine: https://github.com/Zylann/godot_heightmap_plugin/issues/156
Worse, unsupported editor versions would try to load the present library and also fail doing so due to potential ABI differences.

Here is what I suspect:
- Generating thumbnails? I see no point in loading the library for that
- Checking for global class names? I also see no point in that, such information could be available in text form inside the gdns file, without needing to load the library
- Preloading? I don't use any of that *on purpose*.
- Other?

At least Godot should only attempt to load the library when it actually can.
Repository: godot
Issue: Doppler Effect Cuts off at Certain Speed
Labels: bug,topic:audio,topic:3d

**Godot version:**
 v3.2.2.beta.custom_build.c7ad8f539

**OS/device including version:**
Linux

**Issue description:**
When using the Doppler effect on an AudioStreamPlayer3D the audio gets cut off, when the object its used on reaches a certain speed.

This video shows a cube accelerating towards the camera, while playing a rocket engine sound. At the ~3rd second the Doppler effect stops abruptly.
[doppler_audio_bug.zip](https://github.com/godotengine/godot/files/4522883/doppler_audio_bug.zip)

**Steps to reproduce:**
1. Add AudioStreamPlayer3D to RigidBody
2. Continue to call add_central_force() on the object while playing a sound with doppler_tracking activated (Idle or Physics).

**Minimal reproduction project:**
[doppler_audio_bug.zip](https://github.com/godotengine/godot/files/4522917/doppler_audio_bug.zip)
Repository: pytorch
Issue: Cuda profiler + DataParallel + manual profiling start = strange profiling overhead pattern
Labels: oncall: distributed,triaged

I learn a transformer language model (reusing fairseq components with my own training loop). I use DataParallel for multi-gpu. I tried two variants for kicking off the CUDA profiler:

1. `nvprof -s -f -o profile.sqlite --log-file profile.txt -- python3 ...`
![Screenshot_1](https://user-images.githubusercontent.com/1041752/80111481-3afa1f00-8580-11ea-90bd-ad9d67ce8950.png)

2. `nvprof --profile-from-start off -s -f -o profile.sqlite --log-file profile.txt -- python3 ...` and manual `torch.cuda.profiler.start()` call before DataParallel object creation.
![Screenshot_3](https://user-images.githubusercontent.com/1041752/80111585-5ebd6500-8580-11ea-98cc-637646d33817.png)

One can see that variant 2 has a huge Profiling Overhead pattern line and GPUs 1 and 2 are unused. Everything is okay in variant 1.

I wonder it's an indication of some bug.

nvprof switch `--profile-child-processes` had no effect in this DP setup so I didn't use it for the final repro.

The setup is torch 1.4.0 release running on Ubuntu 18.04, CUDA 10.1.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar