sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Excessive instantiation depth with fluent chaining API
Labels: Needs Investigation,Domain: Performance

@amcasey reduced a perf complaint from https://github.com/glideapps/glide-code-columns/blob/master/src/columns/as-array.ts to [this playground](https://www.typescriptlang.org/play?ts=4.6.0-dev.20211105#code/MYGwhgzhAEDCD2IA8AVACmATmAthAfNAN4BQ050ADgK4BGIAlsNAO4MAuAFgEoCmAjtQaZeAEzSYGODgwBuvDNhyoAcrl7ReAD3a8AdqJgR2kvQHN8ACj3qAXNBRqcvAJTEyFTyPbVMe6NQGvABmDHpiAITQkHCISB6eiQ6KuDAAZMTQImCi8HogAJ7QANoA0tBhDk68ALr2YHpFAL4JifgA3K0tLSThLLEgli6tAHRsXHyCwmISUjLyKTiWAESyYCDUvMvDnmMcPAJCIuKS0uxyCli4K2sbWzsUexOH0ydz5wtXS6vrm9uj4wOU2OszOF0WN1+9wB+0mRxmp3mlyUkLu-12gLhr1BSIhPzRD3ITyB8LeYM+KPxf0J0GJWJBiI+yOuVOhGNhLwZ73BX1R1Jhz2BCO5FJZt357MFpJxTLx4rZj0xnOF5OZ33l6MVHKFZNxvNZmqJSp1Mp5lI1NLpyt1sv1FugAHoHdAABIcIzsMDAADW0EYZyAA):

```ts
class Col<TParams> {
    public withRequiredPrimitiveParam<TName extends string>(name: TName) {
        return undefined! as Col<
            TParams & { readonly [K in TName]: any }
        >;
    }
}

new Col()
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value")
    .withRequiredPrimitiveParam("value") // Hits stack limit
```

Each additional chain results in a new instantiation of `Col` with an additional `{ value: any }` intersected with the previous instantiation’s type argument. These intersections don’t seem to get simplified for some reason—hovering the third call in the chain yields the quick info

```ts
(method) Col<{ readonly value: any; } & { readonly value: any; }>.withRequiredPrimitiveParam<"value">(name: "value"): Col<{
    readonly value: any;
} & {
    readonly value: any;
} & {
    readonly value: any;
}>
```

Working with a more realistic simplification of the source, @amcasey measured type instantiations as a function of calls in the chain:

![Chart showing exponential increase of instantiations, skyrocketing at around 12 calls](https://user-images.githubusercontent.com/3277153/141338167-39adbfaf-9cd4-4a5d-b742-f6710d97a8e6.png)

It seems that the function is the same even for this dead simple reproduction where each call after the first doesn’t meaningfully change the return type since we max out at the same number of calls, and it’s not obvious to me why that pattern is exponential.
Repository: angular
Issue: HttpHeader with the same key are not split by comma 
Labels: breaking changes,area: common/http,P5,bug,detected: breaking change

### Which @angular/* package(s) are the source of the bug?

common

### Is this a regression?

No

### Description

According to the Http spec: [rfc7230 section 3.2.2](https://www.rfc-editor.org/rfc/rfc7230#section-3.2.2)
>A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that  header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
>A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the  semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma.  The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when
   forwarding a message.
> Note: In practice, the "Set-Cookie" header field ([RFC6265]) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on multiple header fields with the same name.  Since it cannot be combined into a single field-value, recipients ought to handle "Set-Cookie" as a special case while processing header fields.  (See Appendix A.2.3 of [Kri2001] for details.)
      


### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-eengp8?file=src%2Fapp%2Fapp.component.html

### Please provide the exception or error you saw

```true
No exception just not matching spec
`httpHeaders.getAll(key)` returns [ "value1, value2" ] should be [ "value1", "value2" ]
```


### Please provide the environment you discovered this bug in

```true
Angular CLI: 11.2.6
Node: 14.18.0
OS: linux x64

Angular: 11.2.7
... animations, cdk, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router
... service-worker
Ivy Workspace: Yes
```


### Anything else?

The same issue is present in later angular versions
Repository: terminal
Issue: Hyperlink tooltips are flaky, don't always appear
Labels: Help Wanted,Issue-Bug,Area-TerminalControl,Product-Terminal,Priority-3

> One more random data point in case someone finds it useful: I seem to be in an in-between world where sometimes it works and sometimes it doesn't.  It seems that if I move the mouse in from the left side of the screen on the same line as the link, I usually get no tooltip. If the mouse comes from the bottom (or otherwise goes over _non_-link text) before hitting the link, I do get the tooltip.  Even coming from the left, I still get it maybe 10% of the time (estimated).
>
> _from @zb140_
Repository: pytorch
Issue: [FX][docs] Document gotcha about `training` flag
Labels: triaged,module: fx

When using functionals like `torch.nn.functional.dropout`, it will be common for the `training` argument to be passed in as `self.training`. During FX tracing, this will likely be baked in as a constant value:

```
import torch
import torch.fx

class DropoutRepro(torch.nn.Module):
  def forward(self, x):
    return torch.nn.functional.dropout(x, training=self.training)


traced = torch.fx.symbolic_trace(DropoutRepro())
print(traced.code)
"""
def forward(self, x):
    dropout = torch.nn.functional.dropout(x, p = 0.5, training = True, inplace = False);  x = None
    return dropout
"""

traced.eval()

x = torch.randn(5, 3)
torch.testing.assert_allclose(traced(x), x)
"""
AssertionError: Tensor-likes are not close!

Mismatched elements: 15 / 15 (100.0%)
Greatest absolute difference: 1.6207983493804932 at index (0, 2) (up to 1e-05 allowed)
Greatest relative difference: 1.0 at index (0, 0) (up to 0.0001 allowed)
"""
```

However, when the standard `nn.Dropout()` submodule is used, the training flag is encapsulated and--because of the preservation of the `nn.Module` object model--can be changed.

```
class DropoutRepro2(torch.nn.Module):
  def __init__(self):
    super().__init__()
    self.drop = torch.nn.Dropout()

  def forward(self, x):
    return self.drop(x)

traced = torch.fx.symbolic_trace(DropoutRepro2())
print(traced.code)
"""
def forward(self, x):
    drop = self.drop(x);  x = None
    return drop
"""

traced.eval()

x = torch.randn(5, 3)
torch.testing.assert_allclose(traced(x), x)
```

We should document this as a common "gotcha" in tracing and potentially explore if we can provide better warnings or mitigations for this scenario.

cc @ezyang @SherlockNoMad
Repository: pytorch
Issue: clang-tidy shows false positive failure on PRs that rename files
Labels: module: ci,module: lint,triaged

##  🐛 CI Bug

Example PR https://github.com/pytorch/pytorch/pull/67943 renames the file:

```
diff --git a/torch/csrc/jit/codegen/cuda/shape_inference.cpp b/torch/csrc/jit/codegen/cuda/type_inference.cpp
similarity index 52%
rename from torch/csrc/jit/codegen/cuda/shape_inference.cpp
rename to torch/csrc/jit/codegen/cuda/type_inference.cpp
```

Failing CI job still looks for the old one https://github.com/pytorch/pytorch/runs/4145667458

```
Processing 72 clang-tidy jobs
error: no input files [clang-diagnostic-error]
error: no such file or directory: '/__w/pytorch/pytorch/torch/csrc/jit/codegen/cuda/shape_inference.cpp' [clang-diagnostic-error]
error: unable to handle compilation, expected exactly one compiler job in '' [clang-diagnostic-error]
```

I tried to run clang-tidy tool locally on this PR but couldn't reproduce it.

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: flutter
Issue: No separation of hintText and suffixText with end-aligned TextField
Labels: a: text input,framework,f: material design,a: quality,has reproducible steps,found in release: 2.5,found in release: 2.6,team-design,triaged-design

## Steps to Reproduce

Focus the TextField.

**Expected results:**
The hint text and suffix text are separated by a space, the way the entered text is separated from the suffix text.

**Actual results:** <!-- what did you see? -->
The hint text and suffix text are not separated.

<details>
<summary>Code sample</summary>

```
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(
          child: TextField(
            textAlign: TextAlign.end,
            decoration: InputDecoration(
              hintText: 'hintText',
              suffixText: 'suffixText',
            ),
          ),
        ),
      ),
    );
  }
}
```


</details>

<details>
  <summary>Logs</summary>

```
Reproduced on DartPad - Based on Flutter 2.5.3 Dart SDK 2.14.4
```

</details>

No text entered:
<img width="156" alt="Screenshot 2021-11-11 at 20 43 13" src="https://user-images.githubusercontent.com/39824113/141359043-bf6b7a64-8c70-48ee-a258-57f859e69b77.png">

Text "hintText" entered:
<img width="182" alt="Screenshot 2021-11-11 at 20 44 27" src="https://user-images.githubusercontent.com/39824113/141359177-92dfb8e0-8838-450f-8a7d-00b1d84060b4.png">
Repository: godot
Issue: SkeletonIK rotates bones by 180 degrees
Labels: bug,topic:core,confirmed,topic:animation,topic:3d

### Godot version

3.4.stable

### System information

Void Linux x86_64 5.13.19, GLES3, Mesa Intel(R) HD Graphics 5500 (BDW GT2)

### Issue description

https://user-images.githubusercontent.com/79333625/141367831-a4409c55-8841-474c-b0a3-ee67a3451e30.mp4

### Steps to reproduce

Simply move the target up.

### Minimal reproduction project

[iktest.zip](https://github.com/godotengine/godot/files/7523217/iktest.zip)
Repository: pytorch
Issue: Feature Request: Scriptable Python Source-of-Truth for operator shape functions
Labels: feature,triaged

## 🚀 Feature

It would be great if, analogous to `torch.ops.*`, there was `torch.shapes.*` which contains Python functions the define shape computations. This already kind of exists in the form of [symbolic_shape_registry.cpp](https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/runtime/symbolic_shape_registry.cpp).

## Motivation

In [Torch-MLIR](https://github.com/llvm/torch-mlir), we have a need to access such shape calculations in a scriptable way, and being able to just bulk load them from the Python source of truth instead of writing (and testing...) them ourselves would be ideal.

It sounds like there could be some advantages for PT as well, such as generating meta tensor definitions from Python (emitting C++). There's some good synergies for remixing the various technologies/layerings that already exist, such as the TorchScript compiler/optimization passes, in service of this goal.
Repository: terminal
Issue: Extra newline when copying line with wide glyph on the edge
Labels: Product-Conpty,Area-Output,Issue-Bug,Priority-2

### Windows Terminal version (or Windows build number)

10.0.19043.1348, 1.12.2931.0

### Other Software

Ubuntu 21.04 in WSL

### Steps to reproduce

1. Open tab with some WSL distro, shouldn't matter which.

2. Create python3 file with the following content:

```python
import os
import sys
cols = os.get_terminal_size().columns
sys.stdout.buffer.write(b'a'*(cols-1))
sys.stdout.buffer.write(b'\xea\xb0\x9c')
```

3. Run it:

```bash
python3 1.py
```

4. Copy output with the mouse and paste to some editor.

### Expected Behavior

There should be only single line of text.

### Actual Behavior

There're two lines of text, see screenshots.

![1](https://user-images.githubusercontent.com/533383/141378349-7ccab42d-d1e2-47c4-976e-f2be0ea33abc.png)
![2](https://user-images.githubusercontent.com/533383/141378343-bf8d1612-6b0a-4c4b-85dc-08a5ba018094.png)

The problem doesn't appear if that 3-byte symbol is not on the edge of the line. Also 2-byte symbols work fine too.
Repository: pytorch
Issue: Make `torch.Tensor.view` support autograd for appropriate cases
Labels: module: autograd,triaged,enhancement,module: viewing and reshaping

## 🚀 Feature
When viewing a real tensor as complex, or the other way around, `torch.Tensor.view` should support autograd.

## Motivation

This feature was asked for here: https://github.com/pytorch/pytorch/pull/66493#issuecomment-966655813

## Pitch

It should be possible to support autograd for all cases where we view a real or complex as a complex or real (respectively), where the real dtype matches the complex dtype's base dtype.

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: TypeScript
Issue: What is `ts.sys.readDirectory` even supposed to do?
Labels: Needs Investigation

Following up on https://github.com/microsoft/TypeScript/pull/46673#issuecomment-960097500, I started a more thorough investigation of `ts.matchFiles` (which is just `ts.sys.readDirectory` without the system host) and discovered that even its long-standing behavior prior to 4.4 is confusing and probably undesigned. Consider this file system:

```
projects/
├─ a/
│  ├─ subfolder/
│  │  └─ 1.ts
│  └─ 2.ts
└─ b/
   └─ 3.ts
```

Things tend to work as expected if you do three things: (1) use relative paths, (2) read the same directory as your CWD, and (3) don’t use any `includes` that access a sibling folder with `"../"`. If you start doing those things, especially in combination, the behavior is a bit unpredictable.

Let’s start with a simple example where I think things are working as intended:

```
> process.cwd()
'/projects/a'

> ts.sys.readDirectory(".", [".ts"], /*excludes*/ undefined, /*includes*/ ["**/*"])
[
  '2.ts',
  'subfolder/1.ts'
]
```

Note that the entries are relative to our CWD / the directory we’re reading (which one? We don’t know yet because they’re the same), but without the leading `./`. This seems probably intentional because it matches the format of `fs.readdir`. Also, replacing the first argument with the empty string yields the same results.

Ok, let’s see what happens if we `include` something outside of the directory we’re reading:

```
> process.cwd()
'/projects/a'

> ts.sys.readDirectory(".", [".ts"], /*excludes*/ undefined, /*includes*/ ["**/*", "../b/**/*"])
[
  '2.ts',
  'subfolder/1.ts'
]
```

No change. This seems to make sense with the name `readDirectory`. Now let’s find out whether our results are relative to our CWD or to the directory we’re reading. We’ll `cd` up a level first:

```
> process.cwd()
'/projects'

> ts.sys.readDirectory("a", [".ts"], /*excludes*/ undefined, /*includes*/ ["**/*"])
[
  'a/2.ts',
  'a/subfolder/1.ts'
]
```

Interesting—they’re relative to our CWD, not the directory we’re reading, which is a divergence from `fs.readdir`. Does this mean we can now get `includes` outside of the directory we’re reading?

```
> ts.sys.readDirectory("a", [".ts"], /*excludes*/ undefined, /*includes*/ ["**/*", "../b/**/*"])
[
  'a/2.ts',
  'a/subfolder/1.ts',
  'b/3.ts'
]
```

Yes it does! `readDirectory` can return results outside of the target directory, but not outside the CWD. This seems very odd to me. Let’s `cd` back into `a` and try absolute paths:

```
> process.cwd()
'/projects/a'

> ts.sys.readDirectory("/projects/a", [".ts"], /*excludes*/ undefined, /*includes*/ ["**/*"])
[
  '/projects/a/2.ts',
  '/projects/a/subfolder/1.ts'
]
```

Absolute in, absolute out. Quite possibly an accident? Now for the final test, an absolute input path with an `includes` outside the CWD:

```
> ts.sys.readDirectory("/projects/a", [".ts"], /*excludes*/ undefined, /*includes*/ ["**/*", "../b/**/*"])
[
  '/projects/a/2.ts',
  '/projects/a/subfolder/1.ts',
  '/projects/b/3.ts'
]
```

👀
Repository: opencv
Issue: div: inconsistent div-by-zero behavior
Labels: category: core,RFC

#8413 issue forces to use IEEE 754 rules for floating points.
#12826 implements that (OpenCV 4.0.0).

However there is implicit conversion to float+ type if src/dst types does not match:

https://github.com/opencv/opencv/blob/4223495e6cd67011f86b8ecd9be1fa105018f3b1/modules/core/src/arithm.cpp#L696-L697

So processing is performed by IEEE rules, which may emit Inf/NaN values.

Conversion of result float values to destination of integer signed type (8S/16S/32S) may emit "min" values (-128, -32768, INT_MIN) which may be not expected by Users.

Problem comes from `cvRound(nan/inf/int32 overflow/int32 underflow) => INT_MIN (-2147483648)`

```
std::cout << cvRound(std::numeric_limits<float>::quiet_NaN()) << std::endl;
std::cout << cvRound(std::numeric_limits<float>::infinity()) << std::endl;
std::cout << cvRound(-std::numeric_limits<float>::infinity()) << std::endl;
std::cout << cvRound(1e30f) << std::endl;
std::cout << cvRound(-1e30f) << std::endl;
```

Test code:

```
cv::Mat m1(N, N, CV_8S, Scalar::all(1));
cv::Mat m2(N, N, CV_8U, Scalar::all(0));
Mat dst;
int dstType = CV_8S;
double scale = 2.5;
cv::divide(m1, m2, dst, scale, dstType);
std::cout << dst.type() << std::endl << dst << std::endl;  // -128
```

The same types works as documented:

```
cv::Mat m1(N, N, CV_8S, Scalar::all(1));
cv::Mat m2(N, N, CV_8S, Scalar::all(0));
Mat dst;
int dstType = CV_8S;
double scale = 2.5;
cv::divide(m1, m2, dst, scale, dstType);
std::cout << dst.type() << std::endl << dst << std::endl;  // 0 as expected
```
Repository: rust
Issue: Wrong `where Self: 'a` GAT bound suggested
Labels: A-diagnostics,T-compiler,GATs-triaged,A-GATs

Relates to https://github.com/rust-lang/rust/pull/89970 and potentially to https://github.com/rust-lang/rust/issues/90808.

```rust
#![feature(generic_associated_types)]

trait MyTrait {
    type AT<'a> where Self: 'a;
    
    fn selfreffing<'a>(&'a self) -> Self::AT<'a> { unimplemented!(); }
}

struct Inner;
impl MyTrait for Inner {
    type AT<'b> where Self: 'b = ();
}

struct Outer<'a, T>(&'a T);
impl<'a, T: MyTrait> MyTrait for Outer<'a, T> {
    type AT<'b> = T::AT<'b>;
    // type AT<'b> where T: 'b = T::AT<'b>; // suggested
    // type AT<'b> where Self: 'b = T::AT<'b>; // compiles
}
```

[Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=00824257ba73c09a7be35170019c02e0)
Repository: godot
Issue: Vulkan: SDFGI does not make the editor redraw until it has fully converged
Labels: bug,topic:rendering,topic:editor,topic:3d

*Related to https://github.com/godotengine/godot/issues/62887.*

### Godot version

4.0.dev (c89061e98)

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

### Issue description

SDFGI does not make the editor redraw until it has fully converged. This means that when toggling SDFGI or changing a setting that causes it to regenerate (such as changing the number of cascades), it will have partially-converged appearance until you move the 3D camera around a bit (or cause the editor viewport to update somehow, e.g. by hovering controls).

In https://github.com/godotengine/godot/pull/53353, we resolved this by making the editor redraw continuously when a FogVolume is visible and volumetric fog with temporal reprojection are enabled. This isn't an ideal solution, as it wastes CPU and GPU resources (which in turn decreases battery life on laptops). Nonetheless, it prevents the 3D rendering from mismatching how the running project will look like.

Ideally, we should resolve this by redrawing for `rendering/global_illumination/sdfgi/frames_to_converge` frames (30 by default) whenever a SDFGI update is requested in RenderingServer. We can then stop redrawing once SDFGI has fully converged.

https://user-images.githubusercontent.com/180032/141387932-9aa9e23a-daaf-4b7a-a782-f14a5290558a.mp4

### Steps to reproduce

- Add some MeshInstances with their GI Mode set to **Baked**.
- Add a WorldEnvironment node with a Environment resource.
- Enable SDFGI, but don't move the 3D editor camera afterwards for a bit.
- Start moving the 3D editor camera.

### Minimal reproduction project

[test_sdfgi.zip](https://github.com/godotengine/godot/files/7524055/test_sdfgi.zip)

*Keywords for easier searching: low processor mode, low-processor mode*
Repository: godot
Issue: Vulkan: FogVolume with volumetric fog temporal reprojection enabled causes the editor to redraw continuously, wasting CPU and GPU resources
Labels: enhancement,discussion,topic:rendering,topic:3d,performance

### Godot version

4.0.dev (c89061e98)

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

### Issue description

*Related to https://github.com/godotengine/godot/issues/54892.*

If at least one FogVolume node is visible in the scene tree, the editor will redraw continuously when volumetric fog and temporal reprojection are enabled. This wastes CPU and GPU power, which in turn harms the project's performance when run from the editor and decreases battery life on laptops.

We should use the temporal reprojection setting to determine at which point redrawing is no longer necessary. With the default value of `0.9`, there is most likely no meaningful visual difference after 20 frames of convergence or so. (At higher values, we need to wait for more frames for volumetric fog to mostly converge.)

Notice the update spinner in the top-right corner:

https://user-images.githubusercontent.com/180032/141389151-87dbc636-b29c-4376-8d06-efb67ff0a70a.mp4

### Steps to reproduce

- Enable **Show Update Spinner** in the Editor Settings.
- Add a WorldEnvironment node with a Environment resource.
- Enable volumetric fog. Despite temporal reprojection being enabled, the editor will only redraw when needed. (This can cause fog to become outdated like in https://github.com/godotengine/godot/issues/54892, but this is what we're aiming to resolve here too.)
- Add a FogVolume node. Notice how the editor starts redrawing constantly, even when nothing on screen has changed.
- Toggle the FogVolume node's visibility. Notice how the editor no longer redraws constantly when the FogVolume node is hidden.

### Minimal reproduction project

[test_fog_volume.zip](https://github.com/godotengine/godot/files/7524028/test_fog_volume.zip)

*Keywords for easier searching: low processor mode, low-processor mode*