sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Shaders don't seem to be working correctly in gles2
Labels: topic:shaders



<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Zorin OS 15.3 Nvidia GTX 650 450 proprietary drivers

**Issue description:**
<!-- What happened, and what was expected. -->
Shaders do not seem to be able to both use default alpha and sample from the draw
![image](https://user-images.githubusercontent.com/2453707/100292419-4017b600-2f35-11eb-9122-5df828333cea.png)
![image](https://user-images.githubusercontent.com/2453707/100292432-4e65d200-2f35-11eb-88b1-3a9e58c43a7b.png)
![image](https://user-images.githubusercontent.com/2453707/100292536-a13f8980-2f35-11eb-8424-32150c3f61b0.png)

Here is the slider without a shader
![image](https://user-images.githubusercontent.com/2453707/100292586-c502cf80-2f35-11eb-9274-f35495bb5ed6.png)


**Steps to reproduce:**
- Make a sliderbar
- Attack a shader to it with the code above
- See it doesn't work 

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[SliderShaderBug.zip](https://github.com/godotengine/godot/files/5600154/SliderShaderBug.zip)
Repository: rust
Issue: DepGraph::with_ignore misuse
Labels: T-compiler,A-incr-comp,C-bug

[`DepGraph::with_ignore(closure)`](https://github.com/rust-lang/rust/blob/05dde137cad043738e94a47f63256f1e66c83768/compiler/rustc_query_system/src/dep_graph/graph.rs#L158) either doesn't work as intended, or some clients are confused about what it does. Some clients are under the impression that this prevents the closure from modifying the dep graph, but that's not the case.

For example, in [`OnDiskCache::serialize`](https://github.com/rust-lang/rust/blob/05dde137cad043738e94a47f63256f1e66c83768/compiler/rustc_middle/src/ty/query/on_disk_cache.rs#L179), we serialize the query result cache, and we apparently don't want the process of serializing the cache to modify the graph itself (seems reasonable):

```rust
// Serializing the `DepGraph` should not modify it.
// (The comment is off--we're actually serializing the result cache here.)
tcx.dep_graph.with_ignore(|| {
    ...
})
```

But it does. The calls to queries `tcx.original_crate_name` and `tcx.crate_disambiguator` within that closure can and often do modify the graph (I verified by adding some `eprintln`s to print the graph node count before and after these queries). So, when we later (or in parallel) serialize the actual dep graph, it's inconsistent with the result cache. Specifically, the graph has nodes for which no query result was serialized, though perhaps they should have been ("perhaps" because I'm not sure it matters for the particular queries involved here).

I haven't investigated the full ramifications of this specific use of `with_ignore`. It may account for some existing incr-comp bugs. It's likely an even bigger problem for parallel builds, since the result cache and graph are serialized in parallel.

But this is just one of many uses of `with_ignore`. If the above analysis is correct, I think we need to provide a way to prevent dep graph modification while executing some code, and vet uses of `with_ignore` to see whether or not they actually need the functionality provided by it, or need the new don't-modify-dep-graph functionality. We may also want to rename `with_ignore` so that it's more clear what it does.

@rustbot label A-incr-comp
Repository: pytorch
Issue: anchored direct links to functions disappeared in 1.7.0 docs
Labels: module: docs,triaged,module: doc infra

## 📚 Documentation

There used to be an anchor that would link to the function in the API docs. There was a little "chain" link showing up (for those who knew to hover their mouse to the right of `[SOURCE]`) it has disappeared in 1.7.0 docs (re-appeared in master).

Before 1.7: 

https://pytorch.org/docs/1.6.0/distributed.html

![snapshot_5](https://user-images.githubusercontent.com/10676103/100293000-152e6180-2f37-11eb-8367-58f6282291d3.png)



In 1.7: 

https://pytorch.org/docs/1.7.0/distributed.html

![snapshot_4](https://user-images.githubusercontent.com/10676103/100293006-1790bb80-2f37-11eb-9275-54a08e07ac29.png)


https://pytorch.org/docs/master/distributed.html seems to have the anchor, so only 1.7.0 needs to be fixed if it's not too hard. 

I stumbled upon this while opening a doc issue and trying to link to a function and couldn't get the direct link.



cc @ezyang @zou3519 @jlin27 @mruberry
Repository: pytorch
Issue: [master] new default signature: op=<ReduceOp.SUM: 0>from `op=<ReduceOp.SUM>
Labels: oncall: distributed,module: docs,triaged

## 📚 Documentation

It looks like there was a change from `ReduceOp.SUM` to `ReduceOp.SUM: 0` in master version of the online docs:

https://pytorch.org/docs/1.7.0/distributed.html#torch.distributed.reduce_scatter
```
torch.distributed.reduce_scatter(output, input_list, op=ReduceOp.SUM, group=<object object>, async_op=False)
```
https://pytorch.org/docs/master/distributed.html#torch.distributed.reduce_scatter
```
torch.distributed.reduce_scatter(output, input_list, op=<ReduceOp.SUM: 0>, group=<object object>, async_op=False)
```
I don't see any change in the function signature in the code, not sure why the strange `: 0` addition in the docs.


cc @jlin27 @mruberry @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd
Repository: terminal
Issue: disableAnimations not disabling all animations
Labels: Issue-Bug,Area-UserInterface,Product-Terminal,Priority-3

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```none
Windows build number: Microsoft Windows [Version 10.0.19042.630]
Windows Terminal version (if applicable): 1.5.3242.0, 1.4.3141.0

Any other software?
No
```

# Steps to reproduce

Adding `"disableAnimations": true,` to my profile does not disable command palette animations or the animation that plays when opening the dropdown menu to open a new terminal. 

I have found that globally disabling animations in windows will disable these animations.

# Expected behavior

Those animations stop playing.

# Actual behavior

The animations continue playing.
Repository: TypeScript
Issue: The return value of function type is not checked when function may return any
Labels: Experimentation Needed

**TypeScript Version:**  4.2.0-dev.20201124

**Search Terms:**

function, type check, any

**Code**

```ts
const f1: () => number = () => {
  if (window) {
    return {} as any;
  }
  return "a"; // Pass
};

// Expected behavior
const f2: () => number = () => {
  return "a"; // Error: Type '() => string' is not assignable to type '() => number'
};

// Expected behavior
function f3(): number {
  if (window) {
    return {} as any;
  }
  return "a"; // Error: Type 'string' is not assignable to type 'number'.
};
```

**Expected behavior:**

`f1` causes an error because it returns a string.

**Actual behavior:**

`f1` does not cause an error.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

https://www.typescriptlang.org/play?ts=4.2.0-dev.20201124#code/MYewdgzgLgBAZgRgFwwBQEoYF4B8MwCuAtgEYCmATtmprjAN4BQMMAlnGgO6tgAmInTExYsKZKAQpgGAXxgBDCArABPANzMYMzWIlSYAInkG1MAPRmYABUURGMjYwswAogA8ADmWBQyvGOQAFvIAbqwgFIygkLBwAEwoGNh4hKSU1El0wjC6ktJGJuaWLhQUESgAKipeMADkmXjQFDwA5rVsSmAgsLasLWDyJAA2ZDBQIGPVo-W0KcTkFLX2js7uXj5+AWTBYRGMcARgPuHScADMGCipCwya7Fw8-IK3IjniebIKSvKqGizaone+gKplWpXKMCqNVqTVa7VYnW6XwgfQGw1G40m0OulFqADplowgA
Repository: flutter
Issue: [google_maps_flutter_web] Add "User-Editable Shapes" feature
Labels: c: new feature,p: maps,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

https://developers.google.com/maps/documentation/javascript/examples/user-editable-shapes 

<img width="416" alt="Screen Shot 2020-11-25 at 22 07 48" src="https://user-images.githubusercontent.com/661043/100303519-ab2faf80-2f6a-11eb-974c-7a163654aa4f.png">
Repository: ant-design
Issue: New Select component props: optionSelectedLabelProp, optionSelectableLabelProp
Labels: Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
The "optionLabelProp" is useful for choosing a label for a selected option (that differs from how it appears in the dropdown), but it doesn't work for AutoComplete, which always uses "value" instead to populate its search field.

So that a new feature to change this behavior is backwards-compatible, I propose adding two new explicit props that will work whether or not a search field is being used to show its selected option.

The two new props: "optionSelectedLabelProp" (for how the label appears when an option is selected) and "optionSelectableLabelProp" (for how an option's label appears in the dropdown).

The two new props will also make more sense and be more straight-forward as people migrate away from using Option and OptionGroup JSX to specifying their options via the "options" prop.

### What does the proposed API look like?
    <Select
      mode="combobox"
      optionSelectedLabelProp="selectedLabel"
      optionSelectableLabelProp="selectableLabel"
      optionFilterProp="selectableLabel"
      options={[
        {
          label: <div className="family-name">Smith</div>,
          options: [
            {
              value: 50002,
              selectableLabel: <div className="name">John</div>,
              selectedLabel: 'John Smith (Musician)',
            },
            {
              value: 50003,
              selectableLabel: <div className="name">Jane</div>,
              selectedLabel: 'Jane Smith (Software Engineer)',
            },
          ]
        }
      ]}
    />


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: Vulkan Api Backend Build Error with GCC
Labels: module: build,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

Steps to reproduce the behavior:

1. ccmake config with USE_VULKAN_API=1
2. ninja build

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->

## Environment

Currently using gcc-10.2.0

## Additional context

<!-- Add any other context about the problem here. -->
many errors:
e.g.:
```
../aten/src/ATen/native/vulkan/ops/Tensor.h:390:19: error: ‘class at::native::vulkan::ops::vTensor::View::State’ is private within this context
  390 |       const View::State::Bundle&);
```
```
../aten/src/ATen/native/vulkan/api/Pipeline.h:119:41: error: declaration of ‘typedef class at::native::vulkan::api::Handle<VkPipeline_T*, at::native::vulkan::api::destroy_Pipeline> at::native::vulkan::api::Pipeline::Factory::Handle’ changes meaning of ‘Handle’ [-fpermissive]
  119 |     typedef Handle<VkPipeline, Deleter> Handle;
```


cc @malfet @seemethere @walterddr
Repository: flutter
Issue: When adding an iOS widget extension, you can't use Flutter variables to set version
Labels: platform-ios,d: api docs,P3,team-ios,triaged-ios

## Use case
When you release a Flutter app with an iOS (home screen) widget extension you can't use the Flutter variables such as $(FLUTTER_BUILD_NAME)

## Proposal
When building a Flutter project, check for iOS extensions and make the variables

$(FLUTTER_BUILD_NAME)
$(FLUTTER_BUILD_NUMBER)

etc. available to the project so archiving the iOS app doesn't require manually syncing the app version. Also, add instruction on how to set up the .plist file properly. Perhaps warning/informing during the build phase.
Repository: pytorch
Issue: Add wheels for all cuda versions on pypi
Labels: module: binaries,triaged

## 🚀 Feature
Add wheels for all cuda versions on pypi.

## Motivation

In my software I want to specify the correct pytorch version, including the matching cuda version. While it's possible to install an exact version with `pip install torch===1.7.0+cu110 torchvision===0.8.1+cu110 torchaudio===0.7.0 -f https://download.pytorch.org/whl/torch_stable.html` and it's also possible to specify the `-f` link in a requirements.txt, this option is missing for setuptools. They removed the `dependency_link` parameter, because they believe it's bad practice, see discussion here: https://github.com/pypa/pip/issues/4187#issuecomment-415067034. 

## Pitch

Add wheels for all cuda versions on pypi, so that we can do `pip install torch===1.7.0+cu110 torchvision===0.8.1+cu110` without the `-f` link.

## Alternatives

Switch from setuptools to calling a process that does the pip install with the `-f` flag, but that expects the pip command to point to the correct pip installation, and is not as clean as setuptools.



cc @ezyang @seemethere @malfet @walterddr
Repository: pytorch
Issue: [complex] torch.abs: does not match numpy 
Labels: triaged,module: complex,module: numpy,module: NaNs and Infs

```python
import torch
import numpy as np

print('torch.cfloat\n')
x = torch.tensor([1e20+1e10j], dtype=torch.cfloat)
print(torch.abs(x), np.abs(x.numpy())) # non-vectorized: correct value
x = torch.tensor([1e20+1e10j] * 10, dtype=torch.cfloat)
print(torch.abs(x)) # vectorized: incorrect value
print(np.abs(x.numpy()))

print('\ntorch.cdouble\n')
x = torch.tensor([1e200+0j], dtype=torch.cdouble)
print(torch.abs(x), np.abs(x.numpy())) # non-vectorized: correct value
x = torch.tensor([1e200+0j] * 10, dtype=torch.cdouble)
print(torch.abs(x)) # vectorized: incorrect value
print(np.abs(x.numpy()))
```

**Output**
```
torch.cfloat

tensor([1.0000e+20]) [1.e+20]
tensor([       inf,        inf,        inf,        inf,        inf,        inf,
               inf,        inf, 1.0000e+20, 1.0000e+20])
[1.e+20 1.e+20 1.e+20 1.e+20 1.e+20 1.e+20 1.e+20 1.e+20 1.e+20 1.e+20]

torch.cdouble

tensor([1.0000e+200], dtype=torch.float64) [1.e+200]
tensor([        inf,         inf,         inf,         inf,         inf,
                inf,         inf,         inf, 1.0000e+200, 1.0000e+200],
       dtype=torch.float64)
[1.e+200 1.e+200 1.e+200 1.e+200 1.e+200 1.e+200 1.e+200 1.e+200 1.e+200
 1.e+200]
```

cc @ezyang @anjali411 @dylanbespalko @mruberry @rgommers @heitorschueroff
Repository: rust
Issue: False positive from dead_code lint when a repr(packed) struct is transmuted
Labels: C-enhancement,A-lints,T-compiler

I believe the lint exempts `repr(C)` structs for this reason. Since `repr(packed)` structs have a stable layout and can be soundly transmuted, I think they should be exempt as well.

```rust
#[repr(packed)]
struct Foo {
    a: u64,
}

#[repr(packed)]
struct Bar {
    x: u64, // this field is read as Foo.a after a transmute
}

fn main() {
    let bar = Bar { x: 5 };
    let foo: Foo = unsafe { std::mem::transmute(bar) };
    let value_of_bar_x = foo.a;
    println!("{}", value_of_bar_x);
}
```

([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3eb6e9cfd464d8dd6cd5c3aa24c3cd35))

Output:

```
5

```

Errors:

```
   Compiling playground v0.0.1 (/playground)
warning: field is never read: `x`
 --> src/main.rs:8:5
  |
8 |     x: u64, // this field is read as Foo.a after a transmute
  |     ^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.51s
     Running `target/debug/playground`

```
Repository: vscode
Issue: Code Lens Should Respect Command's Enablement
Labels: feature-request,code-lens

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

When a command's `enablement` is false, a `vscode.CodeLens` for the command is still shown as usable in the UI. Should either be rendered as disabled or filtered out.
Repository: storybook
Issue: Provide api for addon-backgrounds
Labels: feature request,addon: backgrounds

**Is your feature request related to a problem? Please describe**
I want to able select of backgrounds for story with api call using `@storybook/addon-backgrounds`

**Describe the solution you'd like**
I expect `@storybook/addon-backgrounds` will handle "CHANGE_COLOR" with argument  `color` and change selected story background

**Describe alternatives you've considered**
Current solution for my case is: create static decorator with black background for several stories

**Are you able to assist to bring the feature to reality?**
no
Repository: TypeScript
Issue: [JS] accessing nested namespaces from require() with destructuring leads to an error
Labels: Bug

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.2.0-dev.20201126

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** TS2305

**Code**

```js
// Must be in JS mode, works in TS mode
const { HttpUriPlugin } = require("webpack").experiments.schemes;
// TS2305: Module '"webpack"' has no exported member 'schemes'.

// Syntax equivalents that work:
const schemes = require("webpack").experiments.schemes;
const HttpUriPluginAlternative1 = require("webpack").experiments.schemes.HttpUriPlugin;
const { schemes: { HttpUriPlugin: HttpUriPluginAlternative2 } } = require("webpack").experiments;

console.log(HttpUriPlugin);
console.log(schemes.HttpUriPlugin);
console.log(HttpUriPluginAlternative1);
console.log(HttpUriPluginAlternative2);
```

**Expected behavior:**

Destructuring a nested namespace in JS mode doesn't lead to an error

**Actual behavior:**

An error is emitted.

The error also looks a bit weird: 

`Module '"webpack"' has no exported member 'schemes'.`
Something like `Namespace 'experiments' has no exported member 'schemes'.` would make more sense.
It seems like it looks up `schemes` on the wrong type...

**Playground Link:** [Link](https://www.typescriptlang.org/play?strictFunctionTypes=false&strictPropertyInitialization=false&strictBindCallApply=false&alwaysStrict=false&ts=4.2.0-dev.20201126&useJavaScript=true#code/JYWwDg9gTgLgBAIgHYQCYFMEG4BQpKyIDu6ARmAIYDGA1tnAPQNwAqEcFANpxEXDAAt0cMJwoBPAOZQIAVySp+7YEgDOMLp37iwwjADMVwGMAhq4+6HBLlqNHDiYcqVdKtUrJcJG5jpFSBQgbpSuqtbGAnAY6lCyVDCyUJ5wnOgUqOEw7BRIcOhQMlA4VGbqcADecAASMDBgAKrJAAqcspIqcAC+cAC8cFDoAI6ywIMAFAg2oXQAlAB06AAeusnBSDCq86pUQsGqWIzMLADKAEwAzAAMAKwAXHAAsmiyaXAA5FNkMwjvcAIUcIofIraB+RTBECkAofHZ7NzveYOJwncQbChLfIjYAANy46A2WQB8CI0BodxKZXgcPQ+z6A2GowmX1stAQC2Wq1ABM2212tLcuFKangtXqTWArXaKgAgpw-FBAiYcegAIz0wbY5nTOzsxYrArcwl8+FbMWNFptDpIIVUypwGn7B5Vc0SqXWh6uy3SpByhVK3HoM7dEP9TVM9CTHVsjkGtY8g4OYWqCBpeY8STjL2Sq0qWa2tSp9DpiCZx1uebZ915gsptMZrN1C05n1+goBlWq-OUwv10uN8Xe61txUUZVB7tAA)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->