sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: is_on_floor() is wrong when using cylinder shape
Labels: bug,topic:physics,needs testing,topic:3d

### Godot version

 v3.3.4.stable.official.faf3f883d

### System information

Linux, GLES3

### Issue description

the reason it snaps to the floor is because it uses `move_and_slide_with_snap()`

### Steps to reproduce

step on the white or gray box at the spawn and walk off without jumping.
gray box is less likely to fail.

### Minimal reproduction project

[fpss.zip](https://github.com/godotengine/godot/files/7469718/fpss.zip)
Repository: flutter
Issue: add grayscale filter to BackdropFilter/ImageFilter
Labels: c: new feature,framework,f: material design,c: proposal,team-design,triaged-design

add an option to leave the items behind in black and white or grayscale.
 example: Scaffold behind a Drawer to grayscale

```dart
Widget build(BuildContext context) {
    double width = MediaQuery.of(context).size.width;
    double drawerWidth = width * 0.90; //* 0.65
    return SizedBox(
      width: drawerWidth ,
      child: Drawer(
        elevation: 0,
        backgroundColor: Colors
            .transparent, 
        child: BackdropFilter(
          filter: ImageFilter.grayscale(),
          child: Container(           
            decoration: BoxDecoration(
              image: DecorationImage(
                  image: AssetImage('assets/imagens/background_side_menu.png'),
                  fit: BoxFit.fill),
            ),
            child: ListView(           
              padding: EdgeInsets.fromLTRB(10, 100, 10, 10),
              children: <Widget>[                
               Text('Item of Menu'),      
               Text('Item of Menu'),            
              ],
            ),
          ),
        ),
      ),
    );
  }
```
Repository: TypeScript
Issue: Private field check narrows generic class too far
Labels: Bug,Fix Available,Rescheduled

# Bug Report

Discovered a potential issue with https://github.com/microsoft/TypeScript/pull/44648 in regards to how classes with type parameters are handled. The presence of the brand indicates that the object is an instance of this class, but doesn't say anything about the type arguments. For `instanceof` the current behavior is to pass `any` for all type arguments (see https://github.com/microsoft/TypeScript/issues/17473 for that issue) but the default here should be that the type matches the constraint for that corresponding type parameter.

### 🔎 Search Terms

`ts4.5-beta`, `private fields`, `brand checks`, `generic`, `type parameter`, `narrowing`

### 🕗 Version & Regression Information

TypeScript Version: `ts4.5-beta`
- I was unable to test this on prior versions because the feature didn't exist yet.

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.5.0-beta#code/C4TwDgpgBAwg9gOwM7AE4EMCWDhQLxQDeUAZnHAFxQqrYDmUAvlAD5FQBG6qVCArgFsOEVEwDcAKAkBjADbokSKAFkQMeYoA8AFSgQAHsAgIAJkvjI0WHAD4iEqI6gBiDhlP4oaPhElOoAG7osj5U2n5O0og0fNLAcKgAFEEhEGEAlPb+-sAAFphIAHQpPp4lvg5OjFL+UWAgAGrBPgBiqHACifpUcBwAVhBxmYSV2VCYJFCJru4m4whQ+sOjY04A9GuL1LlwfLJzwipqGkiaFjTWwDYrq175ReWe+sXNvlAbevqQcWHg0ADk5ys2GA-3GSgQcFwCiQmDoCHQHFk0HiXj+UH+2n+hRuVRW1WqMmiuAA7hgwJATC1yJ4EBASUd1DDEsQyJQoAAiNkcpjpSRRSxQMnoCkQEwAIW4tPpjJOLM43CoAEYAEwAZl5kmFoqp5EKdUarzaHUS2spktQfKJyDgyMKsjgdFN5Mp1LgL1ShTZfPem1AkE+32ASjZABpAq9wQrUBIgA)

### 💻 Code

```ts
type Constraint = { foo: string } | { bar: number };

class MyClass<T extends Constraint> {
    #brand = true;
    value: T;
    constructor(value: T) {
        this.value = value;
    }

    copyValueFrom(x: object) {
        if (#brand in x) {
            this.value = x.value; 
        }
    }
}

const wrappedFoo = new MyClass({ foo: "foo" });
const wrappedBar = new MyClass({ bar: 123 });
wrappedFoo.copyValueFrom(wrappedBar);
console.log(wrappedFoo.value.foo); // type expects foo, value is bar
```

### 🙁 Actual behavior

Assignment in `copyValueFrom` proceeded without error, results in mismatch between type and value.

### 🙂 Expected behavior

In `copyValueFrom`, expected brand to narrow `x` to `MyClass<Constraint>` and report error `Type 'Constraint' is not assignable to type 'T'.` when assigning `this.value = x.value`.
Repository: godot
Issue: `GraphEdit` minimap is not updated when `GraphNode` is deleted from the scene
Labels: bug,confirmed,topic:gui

### Godot version

3.3.4.stable, 3.4.rc3

### System information

Ubuntu 16.04.7 LTS, GLES2, GLES3

### Issue description

GrapEdit minimap not updated when graphnodes deleted from scene while not scroll or zoom graphedit.

### Steps to reproduce

Open Mrp and run it.
Press Delete Button.
Look at minimap, graph nodes is gone, but on minimap you can see graph nodes.

### Minimal reproduction project

[minimap_mrp.zip](https://github.com/godotengine/godot/files/7469990/minimap_mrp.zip)
Repository: godot
Issue: Exporting a PCK/ZIP file only does not copy GDNative libraries to the export directory
Labels: bug,topic:editor,topic:gdextension,topic:export

### Godot version

3.3.stable

### System information

Windows 10

### Issue description

When exporting a pck that requires dlls, either through gdnative or some other means, the dlls will not be copied into the export directory.

Interestingly, if the pck is instead exported as a project, the dll's will be copied to the export directory as expected.

This might have used to work in 3.2 at least according to this [comment](https://github.com/godotengine/godot/issues/31426#issuecomment-547343204); but I pulled down a version of 3.2 and had the same issue there so I think they might've been using "Export Project".


### Steps to reproduce

Precursor: Have a pck with a gdnative library inside of it. Alternatively, you can pull down the minimal project attached and skip steps 1 and 2.

1. Project->Export
2. Add a new preset such that your library is included
3. Click Export PCK/Zip

dlls will not be copied



1. Project->Export
2. Add a new preset such that your library is included
3. Click Export Project (or Export All)

dlls will be copied

### Minimal reproduction project

[dll_pck_wierdness.zip](https://github.com/godotengine/godot/files/7470211/dll_pck_wierdness.zip)

Just a note, test.dll is an empty text file, but it works for this. Using it for anything else will probably break things....
Repository: godot
Issue: Autoloaded images crash Godot
Labels: bug,topic:core,needs testing,crash

### Godot version

3.3.4.stable.official (Steam)

### System information

macOS High Sierra 10.13.6, MacBook 2010 geforce 320m

### Issue description

If autoloaded node contains a lot of sprites - it crashes the Godot. If the same node/scene added not by autoload - the Godot does not crash.

### Steps to reproduce

Create autoloaded scene
Add a lot of large sprite nodes to the autoloaded scene
or do many strings like
var xxx=load("res://large_spritexxx.png") 

### Minimal reproduction project

[crash_by_autoload.zip](https://github.com/godotengine/godot/files/7470497/crash_by_autoload.zip)
Repository: vscode
Issue: Expose preRestartTask
Labels: feature-request,debug

<!-- ⚠️⚠️ 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. -->

Currently, preRestartTask (and the other lifecycle tasks which are not preLaunchTask) are implemented but not exposed. It'd be great if we could use it in our own launch.json files.
Repository: godot
Issue: "TextureRect->ImageTexture->Image->New image" gives "Invalid image" error
Labels: discussion,topic:core,topic:editor

### Godot version

3.4.rc3

### System information

Linux Mint 20.1(Ubuntu 20.04 LTS)

### Issue description

Adding "TextureRect->ImageTexture->Image->New image" gives "Invalid image" error in the console output.

### Steps to reproduce

![Screenshot](https://user-images.githubusercontent.com/19222931/140191543-404f06ed-7263-46cd-8a69-fc0739eaacc8.png)


### Minimal reproduction project

_No response_
Repository: godot
Issue: Import As TextureAtlas doesn't work well with normal maps.
Labels: enhancement,topic:import,topic:2d

### Godot version

3.3.3.stable

### System information

Windows 7 64 bit

### Issue description

Let's say I have 3 images for an animation,
000.png 001.png 002.png

I create a texture atlas from these 3 images and call it "atlas.png".

Each of these images has an equivalent normal map version,
000_n.png 001_n.png 002_n.png

I create another texture atlas from these 3 images and call it "atlas_n.png".

Now in this simple example, the atlas for the diffuse animation and the normal map probably line up exactly so "atlas_n.png" could be used in a shader as a normal map for "atlas.png".

The problem is when I have a bigger project with several animations. The order in which I generated "atlas.png" from all the different animation images could vary wildly from the order I generated "atlas_n.png" by selecting all the files and clicking "import". Which leads to the normal map version of the atlas no longer matching the original.

I guess what I would like to request is either some consistency in generating atlas texture files in the editor, e.g. sort all the file names alphabetically before sending to the atlas generating algorithm so you can expect consistent results from atlas map generation.

Or, build in some native feature into the import settings to specify which file is the corresponding normal map for that image, so this can be taken into account when generating an atlas.

### Steps to reproduce

Assuming an animation with 3 frames:
000.png 001.png 002.png

And normal map versions of each of those images:
000_n.png 001_n.png 002_n.png

1. Select "000.png", "001.png", "002.png" in the editor, under the Import tab change "Import As:" to TextureAtlas. Save it as "atlas.png". Click "Reimport".
2. Select "000_n.png" and "002_n.png" in the editor, under the Import tab change "Import As:" to TextureAtlas. Save it as "atlas_n.png". Click "Reimport".
3. Select "001_n.png" in the editor, under the Import tab change "Import As:" to TextureAtlas. Select the "atlas_n.png" file that was already generated. Click "Reimport".

Your "atlas.png" and "atlas_n.png" do not match up. This simulates a common use case where new animations were added for testing (perhaps without normal maps), or frames were added/deleted and the normal map version wasn't re-imported in exactly the same way.

### Minimal reproduction project

_No response_

*Bugsquad edit (keywords for easier searching): AtlasTexture*
Repository: TypeScript
Issue: Add `digit` and other character classes to template literal types.
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

- template literal types
- ${number}

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

Typescript's template literal types support some built-in non-string types including number. These types are not documented anywhere I can find, certainly not the [Template Literal Types](https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html) page. `${number}` matches any string that `Number` can parse, which includes floating points, hex, binary and scientific notation.

I think typescript users will use `${number}` to incorrectly define types that _should_ only accept decimals. I recommend adding `Digits` and other common character classes[^1]

[^1]: Maybe using [POSIX character classes as a starting point](https://en.wikibooks.org/wiki/Regular_Expressions/POSIX_Basic_Regular_Expressions#Character_classes)

## 📃 Motivating Example
 Using `${number}px` seems like an interesting way to define api's that require css pixel values like `10px` but TypeScript's definition of `${number}` allows unexpected values like `0x1px` which aren't supported by css. I can find that exact example in the [typescript codebase](https://github.com/microsoft/TypeScript/blob/663b19fe4a7c4d4ddaa61aedadd28da06acd27b6/tests/cases/conformance/types/literal/templateLiteralTypes2.ts#L105)

```
let pixels: `${number}px`

pixels = '100px'

// oh no
pixels = '0x1px'
pixels = '0b1px'
pixels = '1e21px'
```

I don't expect TypeScript to understand CSS syntax, but the behavior of `${number}` leads to allowing values that are not valid css units. I think `${number}` is generally not the behavior that people expect and it will be miss used (especially because it's not well documented). 

## 💻 Use Cases

Refining the current `${number}` usecase.
Repository: vscode
Issue: Git - "Stage Change / Revert Change" hotkey doesn't work
Labels: bug,git

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.61.2
- OS Version: Win8.1

Steps to Reproduce:

1. In Keyboard Shotcuts, set any unique hotkey, for ex, Ctrl + Alt + Shift + M to a command "Git Stage Change" (not Changes, but **Change**)
2. Open Source Control Panel, click any modified file with unstaged changes (file will be opened in a diff mode)
3. Go to Next Change (default hotkey is Alt + F5)
4. Press the hotkey that you set up in the first step

Expected result: the change is staged
Actual result: the change is not staged (nothing happens)

Another steps to reproduce:
1. Set hotkey (the same as previously)
2. Open a file in a normal mode (not a diff mode)
2. Clicking the gutter indicator opens near the change an inline diff viewer with buttons will be appeared
3. Hover mouse pointer over a button 'Stage Change' and see a tooltip with your hotkey Ctrl + Alt + Shift + M
4. Press the hotkey

Expected result: the change is staged
Actual result: the change is not staged (nothing happens)

The same issue happens for 'Git Revert Change' command
Repository: flutter
Issue: Simple `Builder` widgets _sometimes_ take inexplicably long CPU times on a low end phone
Labels: framework,P2,team-framework,triaged-framework

Various internal traces have shown that on a low end Android Go type phone, a `Builder` that is just calling a closure can take much longer than expected (e.g. 1-2ms instead of a few us).

We should figure out what's going on there. I don't have a good reproduction of this yet, but am filing this bug to not forget to make one. I suspect having a deeply nested widget tree of builders could reproduce this (and perhaps even just a program with lots of recursive function calls that invoke closures), but need to verify. I also suspect that this is actually a VM bug rather than a framework bug, but leaving it labeled as framework until we have better evidence.

/cc @goderbauer fyi
Repository: pytorch
Issue: Conv2d kernel performance regression on CPU since PyTorch 1.9
Labels: module: performance,module: convolution,triaged,module: mkldnn,module: regression

🐛 Bug

**100X** slowdown can be observed from `conv2d` kernel on CPU for some cases. This does not happen for most of times, but we do find some cases for inference on CPU and lead to a significant performance regression overall. 

Particularly, in one of our CV models, 2 out of 21 convolution layers suffer from this performance regression.

Additionally, no performance regression is observed on GPU.

## To Reproduce

1. Download these two serialized tensor files: [input.pt](https://drive.google.com/file/d/1HquAEuXZP7YHCYV4e6EF19sEYdQPLsvb/view?usp=sharing) and [weight.pt](https://drive.google.com/file/d/1TkBWOtT35hKllExTSCzsmFw3FtJqUFx2/view?usp=sharing), and copy them to `/tmp` directory.
More details:
The input tensor has a shape of (1, 64, 1000, 15). It has 862,694 out of 960,000 positive elements.
The weight tensor has a shape of (128, 64, 1, 1).

**NOTE: The regression cannot be reproduced with random values in these two tensors.**

2.  Run the following script in PyTorch 1.8.1 and 1.9./1.10.
```
#include <iostream>
#include <torch/torch.h>

int main() {
    at::Tensor input;
    torch::load(input, "/tmp/input.pt");  // shape: 1, 64, 1000, 15
    at::Tensor weight;
    torch::load(weight, "/tmp/weight.pt");  // shape: 128, 64, 1, 1
    // NOTE: If the weight here is a random tensor, then the regression will disappear.
    // weight = torch::arange(8192.).reshape({128, 64, 1, 1});

    at::Tensor bias = torch::arange(128.);    

    auto start_time = std::chrono::system_clock::now();
    auto ret = at::convolution(input, weight, bias, {1, 1}, {0, 0}, {1, 1}, false, {{0, 0}}, 1);
    auto end_time = std::chrono::system_clock::now();
    std::cout << "at::convolution milliseconds = " << std::chrono::duration_cast<std::chrono::milliseconds>(end_time - start_time).count() << std::endl;

    return 0;
}
```

## Expected behavior

The execution time comparison on 1.8.1 and 1.9 are **6ms vs. 700ms**. This actually is **100X** slowdown. Upgrading to PyTorch 1.10 does not address this regression.

## Environment

GPU environment is not important here, since it is purely CPU inference code.

PyTorch version: 1.9.0
Is debug build: False
CUDA used to build PyTorch: 10.0
ROCM used to build PyTorch: N/A
OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.10
Python version: 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 21:52:21)  [GCC 7.3.0] (64-bit runtime)
Python platform: Linux-5.4.0-1055-gcp-x86_64-with-debian-buster-sid
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: Tesla T4
GPU 1: Tesla T4

Nvidia driver version: 460.73.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A


cc @VitalyFedyunin @ngimel @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh
Repository: material-ui
Issue: Adding Component Attribute into Styled Components
Labels: support: question

Before, i use styling with styledlike this
```
const ComponentStyled = styled(Grid)`
    background-color: red;
`
```

component used as
```
...
<ComponentStyled>
  {* Content *}
</ComponentStyled>
...
```
but how if i want to styling from this form
```
<Grid item md={2}>
  {* Content *}
</Grid>
```
in to styled version with passed md value or 'item' attribute?
Repository: go
Issue: cmd/compile: reorganize associative computation to allow superscalar execution
Labels: Performance,NeedsInvestigation,compiler/runtime

The compiler currently compiles `a+b+c+d` as `a+(b+(c+d))`. It should use `(a+b)+(c+d)` instead, because the latter can be executed out of order.

More broadly, we should balance trees of associative computation.

Doing this in the compiler with a rule tailored for a single computation type in round 4 of md5block.go yielded a 15% throughput improvement. (See below for details.)

It's not obvious to me whether we can do this with carefully crafted rewrite rules or whether a dedicated pass would be better. But it looks like there may be significant performance wins available on tight mathematical code.

I don't plan to work on this further, but I really hope someone else picks it up.

cc @randall77 @martisch @FiloSottile @mmcloughlin @mdempsky 

---

To reproduce the md5 results, disable the optimized assembly routines, and add this rewrite rule:

```
(Add32 <t> c:(Const32) (Add32 d:(Load _ _) (Add32 x:(Xor32 _ _) a:(Add32 _ _)))) => (Add32 (Add32 <t> c d) (Add32 <t> x a))
```

and disable this one to avoid an infinite loop:

```
(Add32 (Add32 i:(Const32 <t>) z) x) && (z.Op != OpConst32 && x.Op != OpConst32) => (Add32 i (Add32 <t> z x))
```
Repository: go
Issue: cmd/compile: mark CSE'd loads as rematerializable
Labels: Performance,NeedsInvestigation,compiler/runtime

CSE will unify loads from the same memory state. In computation-heavy code, such the generic code in crypto/md5, these loads can have a long lifetime, leading the loaded values being spilled to the stack. That's silly: We already have the value in memory, so we can reload it from there as needed, without using stack space.

Perhaps we can somehow mark such loads as rematerializable, so that the register allocator knows it can re-issue the load instead of spilling. There are some non-obvious details here, like what to do if we need to recalculate the address of the load, and if the calculation of the address is more expensive than spilling the loaded value.

But we currently generate some very silly code for crypto/md5's generic block.

To see this, patch in https://gist.github.com/josharian/42e66bf022f32da3da0a9b1bdf0a974b into the md5 code and then observe the effect of disabling CSE for loads, for example by adding to cmpVal code like:

```
if len(v.Args) > 0 && v.Args[len(v.Args)-1].Type.IsMemory() {
    return lt2Cmp(v.ID < w.ID)
}
```

The generated code goes from a morass of spills and restores to long, straightforward calculation.

There's no way I found to tweak the code to prevent such CSEs. (Issuing irrelevant writes causes other values to get spilled, negating the benefits of preventing CSE.)

cc @randall77
Repository: flutter
Issue: Porting chromium's clang plugin to flutter
Labels: engine,dependency: fuchsia,P2,c: tech-debt,team-engine,triaged-engine

## Use case

Related issue: https://github.com/flutter/engine/pull/29402#issuecomment-958979552

## Proposal

Chromium has a clang plugin that detects ordering of WeakPtrFactory ivars. Maybe we should port it to flutter.