sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Link component used in Jest not working properly
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.6.0: Thu Sep 29 20:13:56 PDT 2022; root:xnu-8020.240.7~1/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.15.1
      npm: 8.11.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.0.7-canary.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue

https://github.com/viktorrenkema/testing-link

### To Reproduce

1. Run `yarn test`
2. Notice Next informs us of below error. Next thinks we're using the /app directory, but we are not:
```
Dynamic href `/[foo]` found in <Link> while using the `/app` router, this is not supported. Read more: https://nextjs.org/docs/messages/app-dir-dynamic-href
```

### Describe the Bug

1. We found that this was introduced recently by https://github.com/vercel/next.js/pull/43074.
2. That PR is supposed to fix another issue (https://github.com/vercel/next.js/issues/42715) that we also experienced ourselves.


We also went through all prior versions of Next 13 with the following results:
`13.0.1` works
`13.0.2-5` breaks, known issue https://github.com/vercel/next.js/issues/42715 looking something like:
 ```
Expected the element to have attribute: href=“/bar”
Received: href=“/[foo]?foo=bar”
```
`13.0.6` breaks, with the error described in this issue. We get the error as introduced in the PR named in step 2.
```
Dynamic href `/[foo]` found in <Link> while using the `/app` router, this is not supported. Read more: https://nextjs.org/docs/messages/app-dir-dynamic-href
```

### Expected Behavior

Jest test is supposed to know we are:
1. Link component should return correct URL in Jest, not appending the link parameters to it
2. not using the /app directory, when we are not

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_
Repository: godot
Issue: PhysicsMaterial `Bounce` behaves random/broken when enabling continous Collision Detection for a RigidBody3D
Labels: bug,confirmed,topic:physics,topic:3d

### Godot version

v4.0.beta7.official [0bb1e89fb]

### System information

Arch Linux, Nvidia 3080

### Issue description

Probably since the _collision detection_ divides the motion into multiple sub-steps but and the "bounce" is only based on the last instead of the total motion?

### Steps to reproduce

Launch/play the  attached project.

Hold SPACE until the ball slides down the Wall and does not bounce.

Observe that the ball's physical material has a `bounce` value of 0.5.

 Change  the BOUNCE constant in `ball.gd` to `true`:
```gdscript
const BOUNCE : bool = true
```
This will disable `continuous_cd` on the `RigidBody3D`. 

Relaunch and hold SPACE to see the ball bounce properly.
(But will tunnel at higher speeds.)

Not that the force / distance / .. are chosen so that no bouncing happens with CD enabled. However, bounces can happen for other values. Probably dependent on the CD steps.

### Minimal reproduction project

[BounceBug3D.zip](https://github.com/godotengine/godot/files/10167153/BounceBug3D.zip)
Repository: node
Issue: Cpplint produces false positives for FastApiOptions
Labels: c++,good first issue,python

Following line is a perfectly fine declaration for v8 fast API.

```c++
using CFunctionCallbackWithInput =
    void (*)(v8::Local<v8::Value> receiver,
             const v8::FastOneByteString& source,
             const v8::FastApiTypedArray<uint8_t>& destination,
             const v8::FastApiTypedArray<uint32_t>& result,
             v8::FastApiCallbackOptions& options);
```

But it produces the following error

```
Running C++ linter...
src/node_encoding.cc:101:  Is this a non-const reference? If so, make const or use a pointer: FastApiCallbackOptions& options  [runtime/references] [2]
Done processing src/node_encoding.cc
src/node_external_reference.h:20:  Is this a non-const reference? If so, make const or use a pointer: v8::FastApiCallbackOptions& options  [runtime/references] [2]
Done processing src/node_external_reference.h
Total errors found: 2
make: *** [tools/.cpplintstamp] Error 1
```
Repository: pytorch
Issue: quantization observers: can we relax the default epsilon value?
Labels: oncall: quantization,low priority,triaged

### 🐛 Describe the bug

In `https://github.com/pytorch/pytorch/blob/master/torch/ao/quantization/observer.py#L208`, the epsilon value used to determine the uniform quantization scale is defined as

```
eps=torch.finfo(torch.float32).eps
```

This resolves to 1.19e-7 for float32, and the value from `finfo` is chosen so that he smallest representable number such that 1.0 + eps != 1.0.  This definition is generic might not apply well to choosing the quantization scale, I would expect the smallest uniform quantization scale value to be determined by restrictions of the underlying backend.  For example, for XNNPACK the recommended epsilon value is 2e-12.

On the pretrained weights of MobileNetV3 on ImageNet-1K from torchvision, the weights of the `features.4.block.2.fc1` and `features.4.block.2.fc2` layers are too small in magnitude for PTQ to work correctly with the current default scale value, leading to poor quantization accuracy of these layers in PTQ.

We should consider epsilon in a smarter way.  I would expect the overall impact to be low as this is an edge case, but it will be a free accuracy win for PTQ for that edge case.

### Versions

master

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @jgong5 @Xia-Weiwen @leslie-fang-intel
Repository: rust
Issue: Tracking Issue for `process_setsid`
Labels: T-libs-api,C-tracking-issue,A-process

Feature gate: `#![feature(process_setsid)]`

This is a tracking issue for adding a `setsid` method to the `std::os::unix::process::CommandExt` trait.

Add a new `setsid` method to the `CommandExt` trait for UNIX systems. Using the `setsid` method, a caller can create a new session and process group whilst still benefiting from the POSIX spawn fast path code.

### 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
trait CommandExt {
    fn setsid(&mut self) -> &mut Command
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #105377
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: pytorch
Issue: quantization qconfig: can we set per-channel quant as default for qnnpack?
Labels: oncall: quantization,triaged

### 🐛 Describe the bug

The current default qconfig for qnnpack is per-tensor quantization.  Can we update the default qnnpack qconfig to per-channel quantization?  I heard that per-channel has been supported for awhile in the qnnpack kernels - is that still true?  Is there anything blocking us from upgrading the default?

Motivation: PTQ accuracy on MobileNetV3 + ImageNet 1k is:
* 0.75282 fp32 baseline
* 0.40968 with qnnpack default (per-tensor quant)
* 0.6747 with qnnpack default but per-channel quant enabled

### Versions

master

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @jgong5 @Xia-Weiwen @leslie-fang-intel
Repository: angular
Issue: Throw NG0300 error at built-time rather than at runtime
Labels: help wanted,hotlist: error messages,area: core,area: compiler,core: directive matching,P3,bug

### Which @angular/* package(s) are relevant/related to the feature request?

compiler

### Description

Currently, [NG0300](https://angular.io/errors/NG0300) is thrown at runtime.
I am wondering whether it is possible to throw this error already at built-time.
This would improve DX in the way that an app with this error would not be possible to ship.

### Proposed solution

Detect and throw error at built-time.
Might implement an extended diagnostic for it!?

### Alternatives considered

Since this is very likely a static code analysis, linting tools should also be able to detect these.
However, I haven't found any lint rule that would report this error.
Repository: flutter
Issue: Navigation suite contrast updates
Labels: framework,f: material design,P3,team-design,triaged-design

We will be increasing the contrast between non-text elements (e.g. icons) to 3:1. Known components: 

- [ ] Navigation bar
- [ ] Navigation drawer
- [ ] Navigation rail

Internal issue b/332483256
Repository: flutter
Issue: Investigate using emulators for flutter/packages Android tests
Labels: team,package,team-ecosystem,P2,triaged-ecosystem

Currently we use FTL for Android tests in CI; my understanding is that this is because emulators weren't an option. With the work to support emulators in LUCI, we should investigate migrating our Android integration tests to LUCI with emulators, instead of FTL:
- FTL **does not run** in presubmit for non-team members. This means we have to remember to manually push to PRs to trigger tests, and if we don't things like https://github.com/flutter/plugins/pull/6796 happen.
- FTL results are not available to non-team members, making debugging issues that don't happen locally very difficult.

We could potentially keep some additional tests if we still want device coverage, but it shouldn't be our sole way of running integration tests.

/cc @reidbaker
Repository: godot
Issue: Godot 4.0 beta 7 - randi() in Vector2i() produces negative numbers
Labels: discussion,topic:core

### Godot version

v4.0.beta7.official [0bb1e89fb]

### System information

Windows 10

### Issue description

When using randi() in Vector2i(), it produces negative numbers.
Discovered this, when trying to generate a random position in the viewport.

### Steps to reproduce

Kindly see code below.

### Minimal reproduction project

```
extends Node2D

func _ready() -> void:

	print("--- TEST A ---")
	for i in range(10):
		var test_a: Vector2i = Vector2i(randi(), randi())
		print(test_a)

	print("--- TEST B ---")
	for i in range(10):
		var test_b: Vector2i = Vector2i(randi(), randi()) % Vector2i(640, 360)
		print(test_b)

	print("--- TEST C ---")
	for i in range(10):
		var test_c: Vector2i = Vector2i(randi() % 640, randi() % 360)
		print(test_c)
```

Results :

--- TEST A ---
(1806296788, -1897042084)
(983833438, 1443881349)
(1894031998, -1861650848)
(-141651958, -1576647642)
(-1127344993, -1328438374)
(-1643842200, -959493189)
(906330563, 1402981330)
(-736853035, 1510943120)
(-1572733590, 1720123564)
(-138079385, 711575314)

--- TEST B ---
(208, -353)
(151, -131)
(-120, -52)
(-267, 177)
(-277, 240)
(-510, -287)
(-513, -121)
(-596, -158)
(-294, -60)
(-139, -195)

--- TEST C ---
(39, 86)
(441, 351)
(462, 314)
(546, 339)
(610, 110)
(170, 43)
(490, 117)
(457, 100)
(630, 232)
(23, 298)
Repository: kubernetes
Issue: Decide on RBAC for aggregated API servers to be able to create and manage identity leases
Labels: sig/api-machinery,sig/auth,triage/accepted

> > Question: who owns setting up RBAC for aggregated API servers to be able to create and manage their leases?
>
> I'm flexible here.  @andrewsykim may have opinions about how much cross talk he's willing to allow and that may require that aggregated apiservers use a different namespace and wire their own GC to avoid them being able to impact kube-apiserver leases.
>
> I think this PR is a step in the right direction either way.

_Originally posted by @deads2k in https://github.com/kubernetes/kubernetes/issues/114240#issuecomment-1339586027_
Repository: vscode
Issue: Terminal can essentially become bricked after pressing ctrl+s
Labels: bug,help wanted,good first issue,terminal-input

On Linux/macOS if you press ctrl+s it will pause the pty, the way to undo this is to press ctrl+q but we route that to a vscode keybinding so it essentially bricks the terminal. See https://github.com/microsoft/terminal/issues/13217
Repository: electron
Issue: [Bug]: printToPDF has blank iframes from different origin
Labels: platform/macOS,component/printing,bug :beetle:,status/confirmed,22-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

22.0.0

### What operating system are you using?

macOS

### Operating System Version

MacOS 12.6.1

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

The generated PDF should include all content that was successfully rendered in the browser, including cross-origin iframes with `sandbox="allow-same-origin"`

### Actual Behavior

Only iframe content from the same origin is included; the cross-origin iframe is blank in the PDF (even though it rendered in Electron).

### Testcase Gist URL

https://gist.github.com/4de3b99eb855215fc5b7812cbff09f5c

### Additional Information

Some notes:
 * The testcase gist will write a message to the console with the location of the generated PDF: `Wrote PDF successfully to [location]`
 * This definitely worked at some point in the past, but the oldest I can check on now is Electron 11 because I have an ARM Mac, and it doesn't work there.
 * Electron 22.0.0 and 21.3.3 prints the page, but the iframes are blank. In 20.1.4 and older, the `printToPDF()` promise never resolves (not even with an error).
 * If I use headless Chrome and `--print-to-pdf`, it _does_ print both iframes, in case that helps narrow the problem.
 * Here's the source code of the page the gist is loading: https://github.com/jerryorr/electron-printtopdf-iframe/blob/main/index.html
Repository: vscode
Issue: Remote SSH incorrectly strips empty but defined environment variables from shell environment
Labels: bug,help wanted,remote,terminal-process

VSCode Version: 1.63.2
SSH Remote extension latest preview (v0.71.2021121615 Pre-Release)
Local OS Version: Fedora 35
Remote OS Version: CentOS 7.9
Remote Extension/Connection Type: SSH

Consider the following setup in your SSH config:

```
Host slpcomp1-prj
  HostName slpcomp1
  User mkrause
  ForwardX11 yes
  RemoteCommand bash -c "export TESTVAR1=HELLO; export TESTVAR2=HITHERE; export TESTVAR3; bash"
```
And connect to this node using this config with the SSH Remote Extension with RemoteCommand enabled.

Result:
![image](https://user-images.githubusercontent.com/25175069/149989704-89edcd46-9bda-44dd-9d00-a2a10e2e513e.png)

TESTVAR3 is incorrectly missing from the environment. This can be a problem if e.g. certain paths prefixes are encoded in such variables and on some machines they are intentionally empty. The behavior does NOT change if TESTVAR3 is defined as an empty string like so `export TESTVAR3=""`

I think I also understand why: For VS Code itself the variable most probably does exist, but not inside the terminals that are spawned. Reason seems to be the PTY bootstrap script that is launching the Terminal shells:

![image](https://user-images.githubusercontent.com/25175069/149990653-b12c1aaa-81e4-4ef5-8904-a69ab298e234.png)

The red arrow shows the actual bash shell in which VS Code is running remotely for the correct environment.
The green arrow displays the actual Terminal bash shell embedded inside VS Code.
The blue arrow points to the bootstrap Javascript processes which according to what I was able to see somehow post-process the environment and seem to strip those defined but empty variables from the env before the bash is spawned.

This needs to be fixed.

/cc @mhoeher
Repository: neovim
Issue: inconsistent behavior for nvim_cmd to run parsed "copen"
Labels: bug,api,has:repro

### Neovim version (nvim -v)

NVIM v0.8.1

### Vim (not Nvim) behaves the same?

no

### Operating system/version

archlinux

### Terminal name/version

st 0.8.5

### $TERM environment variable

tmux-256color

### Installation

system package manager

### How to reproduce the issue

* `nvim --clean`
* case 1 `:lua vim.api.nvim_cmd(vim.api.nvim_parse_cmd('copen', {}), {})`
* case 2 `copen`
* case 3 `:lua vim.api.nvim_cmd({cmd = "copen"}, {})`
* case 4 `:lua vim.api.nvim_cmd({cmd = "copen", args = {10}}, {})`

### Expected behavior

case 1, 2, 3 will open the quickfix window with height 10.
for the case 4, i would expect it worked just like `:copen 10`

### Actual behavior

case 1 opens quickfix window with height `1`;
case 4 failed to run;
Repository: pytorch
Issue: Unknown buildin op: aten::pad
Labels: oncall: jit

### 🐛 Describe the bug

I'm loading a torchscript EffiecientNet model from Monai into c++ via:

`	auto m = torch::jit::load(datapath + "enet-b0_.pt");
`

Here is the text from the error that gets thrown:

Unknown builtin op: aten::pad. Here are some suggestions:  aten::svd aten::cat aten::prod aten::put aten::ord aten::grad aten::pop aten::gcd aten::var aten::std aten::add aten::max aten::... ...}

The libtorch code is running under Windows 10, built with VS2019, version 1.10.2+cu113.

I checked the current version of op_registry.cpp, but don't see aten::pad listed, so I'm guessing getting a new build won't help.


### Versions

Collecting environment information...
PyTorch version: 1.13.0
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Microsoft Windows Server 2019 Standard
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.8.8 (default, Apr 13 2021, 15:08:03) [MSC v.1916 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.17763-SP0
Is CUDA available: True
CUDA runtime version: 11.6.124
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: Tesla V100S-PCIE-32GB
GPU 1: Tesla V100S-PCIE-32GB
GPU 2: Tesla V100S-PCIE-32GB
GPU 3: Tesla V100S-PCIE-32GB

Nvidia driver version: 516.94
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin\cudnn_ops_train64_8.dll
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.20.1
[pip3] numpydoc==1.1.0
[pip3] torch==1.13.0
[pip3] torchaudio==0.13.0
[pip3] torchinfo==1.7.1
[pip3] torchvision==0.14.0
[conda] blas                      1.0                         mkl
[conda] mkl                       2021.2.0           haa95532_296
[conda] mkl-service               2.3.0            py38h2bbff1b_1
[conda] mkl_fft                   1.3.0            py38h277e83a_2
[conda] mkl_random                1.2.1            py38hf11a4ad_2
[conda] numpy                     1.20.1           py38h34a8a5c_0
[conda] numpy-base                1.20.1           py38haf7ebc8_0
[conda] numpydoc                  1.1.0              pyhd3eb1b0_1
[conda] pytorch                   1.13.0          py3.8_cuda11.6_cudnn8_0    pytorch
[conda] pytorch-cuda              11.6                 h867d48c_0    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchaudio                0.13.0                   pypi_0    pypi
[conda] torchinfo                 1.7.1              pyhd8ed1ab_0    conda-forge
[conda] torchvision               0.14.0                   pypi_0    pypi

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Repository: TypeScript
Issue: static initialization blocks do not parse prototype
Labels: Bug,Help Wanted

# Bug Report

When using static initialization blocks, changes to prototype are not parsed.  They are only parsed when outside of the class.

### 🔎 Search Terms

static initialization block, iife, prototype, salsa

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about `protoype`

### ⏯ Playground Link

[Playground Link](https://www.typescriptlang.org/play?jsx=0&ts=5.0.0-dev.20221206&filetype=js#code/MYGwhgzhAEBiD29oG8CwAoa0IBcw4EtgUMssF4A6ABwCd4cGBPagU0oIDtPXboBeaAFYA3KTI4AFgQg16jHC3ZcetACrSYg0eIC+GcTla4AFAEoSmMsHicI8EOxDwA5iakzK8AK5G+AamgARjMxKywbOwcnV3dNDm5eaECQsLJoSPtHSmc3D1kVXg0ZZODQvQN0fXQME3MBAD5LdIo5BmY2L19eAEke2ABRAWEw3TNzMIxWunbFTp8-YdEgA)

### 💻 Code

````js
class Foo {
  static {
    Foo.prototype.inner = 5;
    this.prototype.innerThis = 5;
  }

  test() {
    console.log(this.outer + 1);
    console.log(this.inner + 1);
    console.log(this.innerThis + 1);
  }

}

(() => {
    Foo.prototype.outerIIFE = 5;
})();

Foo.prototype.outer = 5;
````

### 🙁 Actual behavior

Only `Foo.prototype.outer` has its type inferred.

### 🙂 Expected behavior

I can understand if `Foo.prototype.outerIIFE` and `Foo.prototype.innerThis` are not working. But `Foo.prototype.inner` should be parsed. (bonus if we can add the other ones).

-------------

Usage would be to avoid having code appended to the end of a class, and instead, inside the class improving code clarity. That was one of the goals of implementing static initialization blocks. Sometimes properties need to be defined before instance initialization instead of after `constructor()` is called (eg: `HTMLElement.observedAttributes` needing to be ready before `constructor()` is called.). I believe `prototype` checking was added around Typescript 3.0, and static class blocks didn't exist yet.