sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: A procedural macro library can exceed the PE/COFF export ordinal limit on x86_64-pc-windows-gnu
Labels: O-windows

Please see the [SixtyFPS issue #764](https://github.com/sixtyfpsui/sixtyfps/issues/764).

When building `sixtyfps-rs` on Windows, its procedural macro library fails to build with the linker error `export ordinal too large`.

The library has 70000+ exports (the exact number depends on the rust toolchain version and platform). The majority of the exports relate to the library's dependencies, not the symbols provided by the library itself.

The PE/COFF format has a limit of 65535 export ordinals.

When building on Windows, procedural macro libraries must compile into PE/COFF, to match the native toolchain.

This seems related to the Rust [issue #37530](https://github.com/rust-lang/rust/issues/37530), which solved the "export everything" problem for `cdylib`s.

(I am just a dabbler in Rust and this is my first issue submission here. Not sure what are the options. Maybe some workaround on the SixtyFPS side is possible? How other procedural macro libraries avoid this problem?)
Repository: create-react-app
Issue: `eslint-config-react-app@7.0.0` using dependencies instead of peerDependencies
Labels: needs triage,issue: bug report

Using `dependencies` for plugins in sharable configs for `eslint` is an antipattern. According to [the docs](https://eslint.org/docs/developer-guide/shareable-configs#publishing-a-shareable-config), these dependencies should be put to `peerDependencies`. The reason is that multiple sharable configs could lock their version of plugins and expect different implementation and eslint wouldn't know which one to use. The user should be always the one to select and install eslint plugins. Reused shareable configs, parsers or other packages can be in `dependencies` tho.

The older version of `eslint-config-react-app` had it correct, the new version has it wrong.
Repository: godot
Issue: Xbox controller L2 and R2 inputs swapped on Android
Labels: confirmed

### Godot version

3.4.2

### System information

Android 11, Samsung Galaxy A02S

### Issue description

When exporting my project for android, I noticed that my L2 and R2 inputs were swapped. I expected the inputs to not be swapped, and to work as it does on windows, but that wasn't the case.

### Steps to reproduce

- Download the minimal reproduction project
- Export it for android
- Run it
- Left side should change to `true` if L2 is pressed and vice versa, but doesn't

### Minimal reproduction project

[minimal-reproduction.zip](https://github.com/godotengine/godot/files/7765529/minimal-reproduction.zip)
Repository: create-react-app
Issue: cannot import modules in src aliased in tsconfig paths compilerOptions
Labels: needs triage,issue: bug report

### Describe the bug
Cannot import files aliased in the tsconfig paths. imports sometimes work for some files but often don't. I can't say i know why, but when the break the errors are cascading causing imports with aliased paths to break too and forcing the whole project to revert back to relative path imports

(Write your answer here.)

### Did you try recovering your dependencies?
Yes

### Which terms did you search for in User Guide?
https://create-react-app.dev/docs/adding-typescript/#troubleshooting


### Environment

<!--
  To help identify if a problem is specific to a platform, browser, or module version, information about your environment is required.
  This enables the maintainers quickly reproduce the issue and give feedback.

  Run the following command in your React app's folder in terminal.
  Note: The result is copied to your clipboard directly.

  `npx create-react-app --info`

  Paste the output of the command in the section below.
-->

Environment Info:

  current version of create-react-app: 5.0.0
  running from /home/craft/.config/yarn/global/node_modules/create-react-app

  System:
    OS: Linux 5.14 Arch Linux
    CPU: (8) x64 Intel(R) Xeon(R) CPU           W3530  @ 2.80GHz
  Binaries:
    Node: 17.3.0 - /tmp/yarn--1640220951632-0.6230549606809872/node
    Yarn: 1.22.17 - /tmp/yarn--1640220951632-0.6230549606809872/yarn
    npm: 8.3.0 - /usr/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: 95.0.2
  npmPackages:
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    react-scripts: 5.0.0 => 5.0.0
  npmGlobalPackages:
    create-react-app: Not Found


### Steps to reproduce

1. yarn create react-app sample --template typescript
2. cd sample
3. add ```"baseUrl" : "."``` and ```"paths" : { "@app/*":  ["src/*"] } ``` options to the```compilerOptions``` in tsconfig.json 
4. cd src
5. mkdir sub
6. cd sub
7. touch index.ts
8. create a valid default export of any variable, constant, class, or function in the index.ts file just created
9. cd ..
10. add the line ```import sub from '@app/sub';``` to your App.tsx imports in the src/ directory
11. and try running yarn start from application root



### Expected behavior
No errors


### Actual behavior
```
Compiled with problems:

ERROR in ./src/App.tsx 6:0-27

Module not found: Error: Can't resolve '@app/sub' in '/home/craft/Projects/node/cra/src'
```


### Reproducible demo
could not recreate the problem in https://codesandbox.io/s/trusting-morse-bs8tc?file=/src/App.tsx because it seams to work just fine there.
Repository: pytorch
Issue: Empty or NaN data pollute gradient even if they are not involved during backward
Labels: module: autograd,triaged,module: NaNs and Infs

### 🐛 Describe the bug

Hi, Probably this is not a bug, but I am just wondering how the behavior is caused and if it could be improved.

Say I have 2 pieces of data in a batch. One is valid and the other is NaN. I pass it to my network and get a batch of two losses. Obviously, one loss is valid and the other is NaN. I backward only the valid loss and expect the training to still work good, but it turns out that the training is polluted by NaN even if I did not backward the NaN loss. Please see the following code piece:

```
import numpy as np
import torch
from torch import nn

embed_dim = 512
batch_size = 2
token_num = 20
iter_num = 5

class FC(nn.Module):
    def __init__(self):
        super(FC, self).__init__()
        self.fc = nn.Linear(embed_dim, 1)

    def forward(self, x):
        return self.fc(x).flatten(1, -1).sum(1)

def train(data, model, optimizer):
    for i in range(iter_num):
        optimizer.zero_grad()
        l = model(data[i])
        print(i, l)

        l[0].backward() # WE ONLY BACKWARD THE LOSS CORRESPONDING TO THE VALID DATA
        optimizer.step()

data = torch.rand(iter_num, batch_size, embed_dim)

seed = 8; np.random.seed(seed); torch.manual_seed(seed); torch.cuda.manual_seed(seed)
model = FC()
optimizer = torch.optim.AdamW(model.parameters())
train(data, model, optimizer)
print('----')

seed = 8; np.random.seed(seed); torch.manual_seed(seed); torch.cuda.manual_seed(seed)
model = FC()
optimizer = torch.optim.AdamW(model.parameters())
data[:, 1:] = np.nan # Set an invalid piece of NaN data
train(data, model, optimizer)
```

I got output like: 
```
0 tensor([-0.2391, -0.3819], grad_fn=<SumBackward1>)
1 tensor([-0.5708, -0.7382], grad_fn=<SumBackward1>)
2 tensor([-0.5046, -0.7748], grad_fn=<SumBackward1>)
3 tensor([-0.9986, -0.9386], grad_fn=<SumBackward1>)
4 tensor([-1.2657, -1.0637], grad_fn=<SumBackward1>)
----
0 tensor([-0.2391,     nan], grad_fn=<SumBackward1>)
1 tensor([nan, nan], grad_fn=<SumBackward1>)
2 tensor([nan, nan], grad_fn=<SumBackward1>)
3 tensor([nan, nan], grad_fn=<SumBackward1>)
4 tensor([nan, nan], grad_fn=<SumBackward1>)
```

For the second case, the model weight is polluted as NaN from the #1 iter. Similar behavior is also observed for partially empty sequence in MultiHeadAttention module.



### Versions

PyTorch 1.8

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: vscode
Issue: Notebooks  inserts/edits code cell
Labels: debt,smoke-test-failure,notebook

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=147845&view=logs&j=306b2268-2a17-5e97-ab97-f41a26dc5206&t=f99521cb-b554-56f1-45de-e2bc176b0ad3&l=72

```
  1) VSCode Smoke Tests (Electron)
       Notebooks
         inserts/edits code cell:
     Error: Timeout: get element '.quick-input-widget' after 20 seconds.
      at poll (D:\a\1\s\test\automation\out\code.js:65:19)
      at async Code.waitForElement (D:\a\1\s\test\automation\out\code.js:184:16)
      at async QuickInput.waitForQuickInputClosed (D:\a\1\s\test\automation\out\quickinput.js:32:9)
      at async QuickInput.selectQuickInputElement (D:\a\1\s\test\automation\out\quickinput.js:41:13)
      at async QuickAccess.runCommand (D:\a\1\s\test\automation\out\quickaccess.js:146:9)
      at async Notebook.openNotebook (D:\a\1\s\test\automation\out\notebook.js:15:9)
      at async Context.<anonymous> (out\areas\notebook\notebook.test.js:26:13)
```

Screenshot reveals that the command cannot be found? Is there a missing extension activation?


![inserts_edits_code_cell](https://user-images.githubusercontent.com/900690/147201186-710dac0f-dd5b-41d5-a787-8f77b4b25787.png)
Repository: godot
Issue: Gdnative Multithreaded Crash when using different functions from same gdnative file in different threads
Labels: bug,topic:core,topic:gdextension,crash

### Godot version

3.4.stable

### System information

Windows 10, GLES3, Intel 11th Generation Graphics (30.0.100.9864)

### Issue description

Godot seems to crash when different functions from the same gdnative file are called in different threads. There does not seem to be a crash or other issue when the same function is what is called in both of the threads. I would expect that the functions in a gdnative file could be accessed from any number of threads with no crash. I understand this may not be fixable or desirable to fix since gdnative is being replaced by extensions in 4.0. There should at least be a warning in the documentation about this if this is to be expected though since it is confusing to figure out that this is what is causing the crash. 

### Steps to reproduce

Create a project with one node with a gdscript script and another node with a gdnative script with at least two accessible functions in the gdnative script. Create a thread in gdscript. Call one of the functions from the main thread at the same time as the other function is accessed by the other thread.

To run the project, press play. It should crash after a few seconds.

### Minimal reproduction project

[https://mega.nz/file/0UwUFJ7T#eU5jPehOe1zLIcJYGYu4ueJMS-FmSxjqHz9F3xUGbrU](https://mega.nz/file/0UwUFJ7T#eU5jPehOe1zLIcJYGYu4ueJMS-FmSxjqHz9F3xUGbrU)
Repository: pytorch
Issue: Add hints for gradient long time overflow when using torch.cuda.amp
Labels: module: cuda,triaged,module: amp (automated mixed precision),Stale

### 🚀 The feature, motivation and pitch

When I use a custom loss which may lead to gradient overflow with the torch.cuda.amp, it will not output a warning or other message and skip update instead. This caused some confusion when I tried to locate the problem. Output prompts like apex may help locate problems during debugging.

### Alternatives

_No response_

### Additional context

_No response_

cc @ngimel @jeffdaily @sunway513 @jithunnair-amd @ROCmSupport @KyleCZH @mcarilli @ptrblck
Repository: flutter
Issue: Feature: Reading current `DeviceOrientation` configuration
Labels: c: new feature,framework,engine,c: proposal,good first issue,a: layout,P3,team-engine,triaged-engine

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

Flutter supports setting the devices allowed device orientation by using [`SystemChrome.setPreferredOrientations()`](https://api.flutter.dev/flutter/services/SystemChrome/setPreferredOrientations.html). I would like to read the current orientation in order to do something like:

1. Read & save current configuration
2. Temporarily set a different preferred device orientation
3. Reset to the configuration from step 1

## Proposal

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching something showing what you are imagining:
      * images
      * videos
      * code samples

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->

Add an API like 
```dart
List<DeviceOrientation> currentPreferredOrientations =  await SystemChrome.getPreferredOrientations();
```
Repository: vscode
Issue: [folding] functioning example available — navigate to previous/next line on same folding level
Labels: feature-request,editor-folding

<!-- ⚠️⚠️ 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. -->
**I'd like to propose providing a way for quick navigation of code:**

**Long stretches of code** can quickly be jumped over, with the use of this navigation shortcut,
that takes you to the **next or previous line** on the **same indentation level** 
as the line where the cursor is positioned currently.

![image](https://user-images.githubusercontent.com/12367437/217118583-ecc9691a-f145-4256-b544-616d72c82b2c.png)

Possible keybinding: `Ctrl + ArrowUp` / `Ctrl + ArrowDown`

Functioning Example:
https://github.com/bbodi/vscode-indentation-level-movement
https://marketplace.visualstudio.com/items?itemName=MikiFos.indentation-level-movement2

![image](https://raw.githubusercontent.com/florisvdg/vscode-indentation-level-movement/master/images/indentation-level-movement.gif)
Repository: pytorch
Issue: nan return by nn.CrossEntropyLoss when all the labels are ignore_index in torch 1.11
Labels: module: nn,triaged,Stale

### 🐛 Describe the bug

If you update torch to 1.11, the following issue will be occur:

```python
import torch
loss_fct = torch.nn.CrossEntropyLoss()

loss = loss_fct(torch.rand(10,5), torch.tensor([-100]*10))
print(loss)
# tensor(nan)
```


### Versions

docker image: nvcr.io/nvidia/pytorch:21.12-py3
torch version: 1.11.0a0+b6df043

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: go
Issue: cmd/compile:  optimize dead store
Labels: Performance,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.5 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.5"
GCCGO="/usr/local/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/root/trygo/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2126714397=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->
1. try following code:
```
➜  trygo more x.go
package main

func main() {
        x()
}

func x() (i int) {
        i = 5
        i = 67
        p := &i
        *p = 12
        return
}
```
2. use `go tool compile -S x.go` to see generated assembly code of function x.

### What did you expect to see?
The multiple times of assignment can be optimized to `MOVQ $12, AX` in regABI,
with three reasons:
- variable `i` is located in local stack frame.
- the assignations of `i=0`(zeroing)/`i=5`/`i=67` are not read by any subsequent instruction.
- no explicit memory barriers(I'm not sure if `atomic.Store` operations can be optimzed here).

### What did you see instead?

```
"".x STEXT nosplit size=61 args=0x0 locals=0x10 funcid=0x0
        0x0000 00000 (x.go:7)   TEXT    "".x(SB), NOSPLIT|ABIInternal, $16-0
        0x0000 00000 (x.go:7)   SUBQ    $16, SP
        0x0004 00004 (x.go:7)   MOVQ    BP, 8(SP)
        0x0009 00009 (x.go:7)   LEAQ    8(SP), BP
        0x000e 00014 (x.go:7)   FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x000e 00014 (x.go:7)   FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x000e 00014 (x.go:7)   MOVQ    $0, "".i(SP)
        0x0016 00022 (x.go:8)   MOVQ    $5, "".i(SP)
        0x001e 00030 (x.go:9)   MOVQ    $67, "".i(SP)
        0x0026 00038 (x.go:11)  MOVQ    $12, "".i(SP)
        0x002e 00046 (x.go:12)  MOVL    $12, AX
        0x0033 00051 (x.go:12)  MOVQ    8(SP), BP
        0x0038 00056 (x.go:12)  ADDQ    $16, SP
        0x003c 00060 (x.go:12)  RET
```
Repository: terminal
Issue: [Terminal> Rename Tab/Window]: Name of 'Tab Title' edit field is not defined.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,Priority-3,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.22504.1010

### Other Software

**Test Environment:**
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator
Tool: Accessibility Insights for Windows Version 1.1.1741.1

### Steps to reproduce

Repro Steps:
1. Open Windows Terminal.
2. Open Settings page using 'Ctr+,'.
3. Navigate to Settings> Action> Add new button.
4. Add shortcut 'Ctrl + Shift +r' for 'Rename Tab Title' actions.
5. Open Narrator using 'Win + Ctrl+ Enter' keys.
6. Save Changes using 'Save' button.
6. Then press 'Ctrl + Shift + r' to rename tab title.
7. Observe the issue.

**User Experience:**
Screen Reader users UX will not be good if they are not able to know the purpose of the edit field. 

**Guideline Reference:**
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value

**Attachments:**
[Name of 'Tab Title' edit field is not defined..zip](https://github.com/microsoft/terminal/files/7769308/Name.of.Tab.Title.edit.field.is.not.defined.zip)


### Expected Behavior

Name of 'Tab Title' edit field should be defined.
i.e. For 'Windows Terminal' tab title, Screen Reader should announce 'Rename Tab Title edit <placeholder text>'

### Actual Behavior

Name of 'Tab Title' edit field is not defined.
i.e. For 'Windows Terminal' tab title, Screen Reader is only announcing 'edit <placeholder text>'.

**Note Issue:** _Screen Reader is only announcing 'Edit placeholder' for 'Window 1 Enter a new name' edit field inside 'Windows 1' pop-up._
Repository: tensorflow
Issue: Tensorflow conv1d computed incorrectly on GPU
Labels: stat:awaiting tensorflower,type:bug,comp:gpu,TF 2.7

<em>Please make sure that this is a bug. As per our
[GitHub Policy](https://github.com/tensorflow/tensorflow/blob/master/ISSUES.md),
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template</em>

**System information**
- Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
- OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 16.04
- Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: 
- TensorFlow installed from (source or binary):  binary
- TensorFlow version (use command below): 2.7
- Python version: 3.6
- Bazel version (if compiling from source):
- GCC/Compiler version (if compiling from source):
- CUDA/cuDNN version: Cuda-11.2
- GPU model and memory: Tesla K80

You can collect some of this information using our environment capture
[script](https://github.com/tensorflow/tensorflow/tree/master/tools/tf_env_collect.sh)
You can also obtain the TensorFlow version with:
1. TF 1.0: `python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"`
2. TF 2.0: `python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"`

**Describe the current behavior**
Computing a single filter 1d convolution on GPU with kernel_size=15, padding='valid' and strides=1 on a (1, 64, 32) input tensor (1 sample X 64 coordinates X 32 input channels) results in data from the end of the input tensor effecting the beginning of the output vector. 

This behavior only happens when performing the calculation on GPU (specifically nvidia Telsa K80). 
On CPU results are fine.

**Describe the expected behavior**
Receptive field should be limited to the kernel size. 

**[Contributing](https://www.tensorflow.org/community/contribute)**

- Do you want to contribute a PR? (yes/no): no
- Briefly describe your candidate solution(if contributing):

**Standalone code to reproduce the issue**
Issue reproduces on colab with GPU:
https://colab.research.google.com/drive/1pK1tNxWVtC9qilcX0u5sbpGmQEZiCDEX?usp=sharing


**Other info / logs** Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.
[Tensorflow-bug.ipynb - Colaboratory.pdf](https://github.com/tensorflow/tensorflow/files/7769397/Tensorflow-bug.ipynb.-.Colaboratory.pdf)