sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Support `@ts-ignore` for suppressing errors in template literals
Labels: Suggestion,Awaiting More Feedback

At Google, we use `@ts-ignore` to suppress build errors when rolling out new TypeScript releases. However, we don't have a mechanism that we can apply in an automated way to suppress errors inside tagged template literals. This comes from the limitation that `@ts-ignore` only suppresses errors on the immediate next line, and for errors within a multi-line template the `// @ts-ignore` comments get consumed by the literal string itself. 

Illustrative example with multi-line tagged template literals:

```
function bar(x: string) { console.log(x);}
function foo(x: string) {  console.log(x); }

// @ts-ignore
bar`error in the line below  
${foo(true)} 
is not suppressed`
```

This does not work either (attempt2):
```
bar`error in the line below  
// @ts-ignore 
${foo(true)} 
is not suppressed`
```

[Playground link with relevant code](https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAIwIYCcAUAPAXIgZynRjAHMBKRAb0QgQLgBsBTAOibjJwoG4BfAFChIsBImBw4OfERLkqtOg2btO3bH0RDBAel2IAAlAIBaGGTBx0LQWnQADFunTXEpRFAAWLRE1K+yCycAO6IiIIAJNSS0sQgLBT8ETAEiFZQhCAADtk2BAQsACYOgnYYTi5uHt6+-mCBwXBhEfpGJuaW1r5RMVKY8YnJgqnpcJkEOXksBcUOQA)

### Actual behavior

The error is not suppressed, and the `// @ts-ignore` comment is consumed in the template literal in attempt2.   

### Expected behavior

Ideally, the error gets suppressed in attempt1. 

### Search Terms

ts-ignore, tagged-template-literals
Repository: pytorch
Issue: Documentation: torch.nn.functional.embedding docs could more clearly state the requirement that weight be a 2D tensor
Labels: module: docs,module: nn,triaged,module: embedding,topic: docs

### 🐛 Describe the bug

    import torch
    input = torch.tensor([[1, 2, 4, 5], [4, 3, 2, 9]])
    embedding_matrix = torch.rand(10)
    print(torch.nn.functional.embedding(input, embedding_matrix))

pytorch 1.9.0:
result: tensor([[0.3005, 0.3053, 0.9081, 0.4288],  [0.9081, 0.8599, 0.3053, 0.1734]])

pytorch 1.12.1:
result: RuntimeError: 'weight' must be 2-D

The descriptions in the pytorch1.8 and pytorch1.12 official documentation are the same, but 1.8 will run successfully with the same parameters, while 1.12 will throw an exception.

### Versions

pytorch: 1.9.0
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.1
GPU models and configuration: RTX3060
Operating System：Windows 

pytorch: 1.12.1
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows 

cc @svekars @carljparker @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Repository: pytorch
Issue: RuntimeError: CUDA error: device-side assert triggered
Labels: module: loss,triaged

### 🐛 Describe the bug

    import torch
    input = torch.rand([210, 6], dtype=torch.float32).cuda()
    target = torch.randint(0, 8, [210], dtype=torch.uint8).cuda()
    try:
        print(torch.nn.functional.nll_loss(input, target))
    except Exception as e:
        print(str(e))

result :  RuntimeError: CUDA error: device-side assert triggered.CUDA kernel errors might be asynchronously reported at some other API call,so the stacktrace below might be incorrect.For debugging consider passing CUDA_LAUNCH_BLOCKING=1.

When running on cuda, the test code problem should be Target 7 is out of bounds. The exception thrown is out of bounds. Expected object of scalar type Long but got scalar type Byte for argument #2 'target' in call to _thnn_nll_loss_forward. Expected object of scalar type long but got scalar type byte for argument #2 'target' in call to _thnn_nLL_loss_forward.

torch.nn.NLLLoss also has the same problem.

### Versions

pytorch: 1.12.1
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows
Repository: pytorch
Issue: torch.nn.functional.normalize: whether true is equal to 1
Labels: triaged,module: norms and normalization

### 🐛 Describe the bug

pytorch 1.8:

    import torch
    input = torch.rand([2, 3], dtype=torch.float32)
    print(torch.nn.functional.normalize(input, p=2.0, dim=True))

result : tensor([[0.7107, 0.6418, 0.2883], [0.0826, 0.2365, 0.9681]])


pytorch 1.12: 

    import torch
    input = torch.rand([2, 3], dtype=torch.float32)
    print(torch.nn.functional.normalize(input, p=2.0, dim=True))

result : TypeError: norm() received an invalid combination of arguments - got (Tensor, float, list, keepdim=bool), but expected one of: ... ....


pytorch 1.12: 

    import torch
    input = torch.rand([2, 3], dtype=torch.float32)
    print(torch.nn.functional.normalize(input, p=2.0, dim=1))

result : tensor([[0.1417, 0.4098, 0.9011], [0.3879, 0.4451, 0.8071]])


pytorch 1.12: 

    print(True == 1)

result : True
   
In both pytorch1.8 and pytorch1.12, the same code yields different results. Both pytorch versions work successfully when dim is changed from True to 1, but from a python perspective, the default value of True is 1. True==1 results in True, so I think the advanced version of torch.nn.functional.normalizeis handling True improperly.

### Versions

pytorch: 1.12
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows 

pytorch: 1.8.0
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.1
GPU models and configuration: RTX3060
Operating System：Windows
Repository: pytorch
Issue: prod_cpu not implemented for 'BFloat16'
Labels: module: cpu,triaged,module: bfloat16

### 🐛 Describe the bug

Test on the CPU:

    import torch
    m = torch.nn.Hardshrink()
    input = torch.rand([2], dtype=torch.bfloat16)
    print(m(input))

result: RuntimeError: "hardshrink_cpu" not implemented for 'BFloat16'


Test on the GPU:

    import torch
    m = torch.nn.Hardshrink()
    input = torch.rand([2], dtype=torch.bfloat16).cuda()
    print(m(input))

result: tensor([0.9102, 0.0000], device='cuda:0', dtype=torch.bfloat16)

In the pytorch 1.8 version, hardshrink_cpu does not support BFloat16 and Half, but cuda does. Then in the latest version, hardshrink_cpu already supports BFloat16, but it still does not support Half.

torch.nn.Softshrink has the same problem.

### Versions

pytorch: 1.8
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows 

cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Repository: rust
Issue: New trait with all other traits as supertrait suggestion never take into account user provided trait names
Labels: A-diagnostics,T-compiler

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5d6f2aa16ca42efb503a4a9e2525e625)

```rust
trait NewTrait {}
trait NewTrait2 {}

fn foo() -> NewTrait + NewTrait2 {}

fn main() {}
```

The current output is:

```
Compiling playground v0.0.1 (/playground)
error[[E0782]](https://doc.rust-lang.org/stable/error-index.html#E0782): trait objects must include the `dyn` keyword
 --> src/main.rs:4:13
  |
4 | fn foo() -> NewTrait + NewTrait2 {}
  |             ^^^^^^^^^^^^^^^^^^^^
  |
help: add `dyn` keyword before this trait
  |
4 | fn foo() -> dyn NewTrait + NewTrait2 {}
  |             +++

error[[E0225]](https://doc.rust-lang.org/stable/error-index.html#E0225): only auto traits can be used as additional traits in a trait object
 --> src/main.rs:4:24
  |
4 | fn foo() -> NewTrait + NewTrait2 {}
  |             --------   ^^^^^^^^^ additional non-auto trait
  |             |
  |             first non-auto trait
  |
  = help: consider creating a new trait with all of these as supertraits and using that trait here instead: `trait NewTrait: NewTrait + NewTrait2 {}`
  = note: auto-traits like `Send` and `Sync` are traits that have special properties; for more information on them, visit <https://doc.rust-lang.org/reference/special-types-and-traits.html#auto-traits>

Some errors have detailed explanations: E0225, E0782.
For more information about an error, try `rustc --explain E0225`.
error: could not compile `playground` due to 2 previous errors
```

<!-- The following is not always necessary. -->
Ideally the suggestion should avoid suggesting a trait with the same name as the user provided traits.

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions. The output might also be
different depending on the Edition.
-->


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Duplicate errors on mismatched types on constrained structs
Labels: A-diagnostics,T-compiler

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7b2b481886eb53caf9f83d11c1c86219

```rust
trait Uwu {}
struct Owo<T> where Owo<T>: Uwu { x: T }
impl Uwu for Owo<bool> {}

fn main() {
    let x: Owo<u8> = Owo { x: 0 };
}
```

The current output is:

```
error[[E0277]](https://doc.rust-lang.org/stable/error-index.html#E0277): the trait bound `Owo<u8>: Uwu` is not satisfied
 --> src/main.rs:6:12
  |
6 |     let x: Owo<u8> = Owo { x: 0};
  |            ^^^^^^^ the trait `Uwu` is not implemented for `Owo<u8>`
  |
  = help: the trait `Uwu` is implemented for `Owo<bool>`
note: required by a bound in `Owo`
 --> src/main.rs:2:29
  |
2 | struct Owo<T> where Owo<T>: Uwu { x: T }
  |                             ^^^ required by this bound in `Owo`

error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
 --> src/main.rs:6:31
  |
6 |     let x: Owo<u8> = Owo { x: 0};
  |                               ^ expected `bool`, found integer

error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
 --> src/main.rs:6:22
  |
6 |     let x: Owo<u8> = Owo { x: 0};
  |            -------   ^^^^^^^^^^^ expected `u8`, found `bool`
  |            |
  |            expected due to this
  |
  = note: expected struct `Owo<u8>`
             found struct `Owo<bool>`
```

At least some of those errors shouldn't be emitted, especially the second one is pretty confusing.

This is because of the `Owo<T>: Uwu` bound on the struct. Because `Uwu` is only implemented for `bool`, type inference uses that knowledge (it arguably shouldn't but that's a differnt topic :D) to know that every `Owo<_>` must actually be `Owo<bool>, so it infers the right hand side to be of type `Owo<bool>`. This causes two unnecessary errors.
Repository: PowerToys
Issue: Replace "V240" between "ctrl" by "Keyboard Manager"
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Needs-Repro

### Microsoft PowerToys version

0.64.1

### Installation method

Other (please specify in "Steps to Reproduce")

### Running as admin

Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

![ScreenShot_2022-11-20 221734](https://user-images.githubusercontent.com/68755916/202904214-fb397227-c347-4f21-9109-57961b2b87f7.png)


### ✔️ Expected Behavior

Working normally

### ❌ Actual Behavior

"ctrl" is always being pushing after replacing "VK240" between "ctrl" by Keyboard Manager


### Other Software

_No response_
Repository: opencv
Issue: CMake warning about LEGACY and GLVND libraries for OpenGL on Linux
Labels: bug

### System Information

OpenCV version: 4.x
Operating System / Platform: openSUSE Tumbleweed  (20221102) / Linux
Compiler & compiler version: g++ (SUSE Linux) 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7]


### Detailed description

When invoking cmake to configure the build of OpenCV there is a warning when configured with OpenGL:

```
CMake Warning (dev) at /usr/share/cmake/Modules/FindOpenGL.cmake:315 (message):
  Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when
  available.  Run "cmake --help-policy CMP0072" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  FindOpenGL found both a legacy GL library:

    OPENGL_gl_LIBRARY: /lib64/libGL.so

  and GLVND libraries for OpenGL and GLX:

    OPENGL_opengl_LIBRARY: /lib64/libOpenGL.so
    OPENGL_glx_LIBRARY: /lib64/libGLX.so

  OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for
  compatibility with CMake 3.10 and below the legacy GL library will be used.
Call Stack (most recent call first):
  modules/highgui/cmake/detect_gtk.cmake:40 (find_package)
  modules/highgui/cmake/init.cmake:35 (include)
  modules/highgui/cmake/init.cmake:39 (add_backend)
  cmake/OpenCVModule.cmake:298 (include)
  cmake/OpenCVModule.cmake:361 (_add_modules_1)
  cmake/OpenCVModule.cmake:385 (ocv_glob_modules)
  CMakeLists.txt:945 (ocv_register_modules)
This warning is for project developers.  Use -Wno-dev to suppress it.
```

### Steps to reproduce

Reproducer:
```bash
git clone -b 4.x https://github.com/opencv/opencv.git
mkdir opencv/build
cd opencv/build
cmake -DWITH_OPENGL=ON ..
```

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: pytorch
Issue: torch.nn.ReplicationPad1d:The description of the exception information thrown is not accurate
Labels: module: error checking,triaged,module: padding

### 🐛 Describe the bug

code1: 

    import torch
    m = torch.nn.ReplicationPad1d("max")
    input = torch.arange(8, dtype=torch.float).reshape(1, 2, 4)
    print(m(input))

result: TypeError: pad(): argument 'pad' (position 2) must be tuple of ints, not tuple

For the padding in torch.nn.ReplicationPad1d(padding), the input of the test code is of type str, but the exception information thrown is of type tuple.

The same problem exists with torch.nn.ReplicationPad2d.

### Versions

pytorch: 1.12.1
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows
Repository: rust
Issue: Tracking Issue for get_many_mut
Labels: T-libs-api,C-tracking-issue,disposition-merge,finished-final-comment-period

Feature gate: `#![feature(get_many_mut)]`

This is a tracking issue for `get_many_mut` and `get_many_unchecked_mut`, which provide `&mut T` access to multiple distinct slice elements.

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
impl [T] {
    pub unsafe fn get_many_unchecked_mut<const N: usize>(&mut self, indices: [usize; N]) -> [&mut T; N];
    pub fn get_many_mut<const N: usize>(&mut self, indices: [usize; N]) -> Result<[&mut T; N], GetManyMutError<N>>;
}

pub struct GetManyMutError<const N: usize> { /* private */ }
```

### Steps / History

- [x] Implementation:
    - Initial implementation in #83608, also received extensive discussion
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

### Unresolved Questions

- What should the error type / return type look like?
  -  See https://github.com/rust-lang/rust/pull/83608#issuecomment-914619139, https://github.com/rust-lang/rust/pull/83608#issuecomment-861382045, and other comments on that PR
- Should the interface support non-usize indices (e.g., `get_many_mut([0..3, 4..6])`)?
- What are the requirements for the interface? Do we sort the passed array, and then check distinctness, or check in `O(n^2)` time?

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: youtube-dl
Issue: [xhamster] support creator page
Labels: request,nsfw

## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.12.17. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar site feature requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a site feature request
- [x] I've verified that I'm running youtube-dl version **2021.12.17**
- [x] I've searched the bugtracker for similar site feature requests including closed ones


## Description
example link: https://xhday.com/creators/sweetbuttocks

log:
```
F:\downloader\xhamster>youtube-dl https://xhvid.com/creators/sweetbuttocks
[generic] sweetbuttocks: Requesting header
WARNING: Falling back on generic information extractor.
[generic] sweetbuttocks: Downloading webpage
[generic] sweetbuttocks: Extracting information
ERROR: Unsupported URL: https://xhvid.com/creators/sweetbuttocks
```
Repository: stable-diffusion-webui
Issue: [Feature Request]:  UNCROP in the img2img section.
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

just uncrop the image instead of using the height and width. Simple as at. Thanks!

![image](https://user-images.githubusercontent.com/56544202/202920571-64fb498d-a91f-46ee-9098-ff4597a55f34.png)


### Proposed workflow

mention above

### Additional information

_No response_
Repository: deno
Issue: Busy-loop code makes it impossible to attach inspector
Labels: debugger

Following situation works with --inspect-brk but not with --inspect.

Screen recording:

https://user-images.githubusercontent.com/13602871/202921080-168ae385-2144-413e-bc24-462f05b66678.mov

Notice that I can't open any file, start a memory profile or CPU profile.
Repository: angular
Issue: ngDoCheck hook has a bit misleading documentation
Labels: area: core,core: lifecycle hooks,core: change detection,P3,bug,area: docs

### Describe the problem that you experienced

Hello,

in my opinion the [documentation regarding the `DoCheck` hook](https://angular.io/api/core/DoCheck) is a bit misleading: 
*A lifecycle hook that invokes a custom change-detection function for a directive, **in addition to the check performed by the default change-detector.***

Text in bold implies that the default check was performed (for the component from which the hook is called), when in fact it doesn't need to be the case. If we have a component with the OnPush change detection strategy, its `ngDoCheck` hook is called from its parent, despite the fact that the default check was not performed on the component.

The following article sums up why ngDoCheck called =/=  change detection performed (it's from 2017, I think that many people fell in the trap of believing that ngDoCheck called = change detection performed):
https://medium.com/angular-in-depth/if-you-think-ngdocheck-means-your-component-is-being-checked-read-this-article-36ce63a3f3e5

### Enter the URL of the topic with the problem

_No response_

### Describe what you were looking for in the documentation

_No response_

### Describe the actions that led you to experience the problem

_No response_

### Describe what you want to experience that would fix the problem

_No response_

### Add a screenshot if that helps illustrate the problem

_No response_

### If this problem caused an exception or error, please paste it here

_No response_

### If the problem is browser-specific, please specify the device, OS, browser, and version

_No response_

### Provide any additional information here in as much as detail as you can

_No response_
Repository: pytorch
Issue: How can i patch the torch.jit in the second solution? Could not figure out entrypoint ?
Labels: oncall: jit

        Here are the workarounds I found to make things work.

### Solution 1: patch torchvision 0.2.2 (dirty and painful)
Pyinstaller works well with torchvision 0.2.2, thus if you do not use too many functionnalities of more recent version of torchvision, you can "patch" old torchvision 0.2.2 by adding the needed new tools. Note that this may need you first use compiled file of torchvision >= 3.0 (_C.so).

### Solution 2: Keep recent torchvision & patch torch.jit in your entry point
I found some monkey patch on stackoverflow and dev blogs that simply overwrite 2 methods of torch.jit.
Simply add this path at the beginning of your entry point:
```
def script_method(fn, _rcb=None):
    return fn
def script(obj, optimize=True, _frames_up=0, _rcb=None):
    return obj    
import torch.jit
torch.jit.script_method = script_method 
torch.jit.script = script
```


I still think there should be a more direct way to do that with pyinstaller, but this works for me.
I hope it will help others too.

_Originally posted by @Sstrap in https://github.com/pytorch/vision/issues/1899#issuecomment-598200938_
      

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel