sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [Text Field] `MuiInput-formControl` changed to `MuiInputBase-formControl` not documented in migration guide
Labels: docs,component: text field,v5.x migration

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

The global style overrides for the class `.MuiInput-formControl` don't work anymore as the class name has been apparently changed to `.MuiInputBase-formControl`.

### Expected behavior 🤔

This needs to be documented under the migration guide. There might be other cases of class name changes not documented too.

### Steps to reproduce 🕹

Steps:

1. Override styles for the class `.MuiInput-formControl` in v4
2. Migrating to v5 results in overrides not being applied anymore

### Context 🔦

Migration to v5

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

  System:
    OS: macOS 12.2
    CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
    Memory: 27.00 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.2 - /usr/local/bin/node
    Yarn: 1.22.5 - ~/.npm/bin/yarn
    npm: 8.1.2 - /usr/local/bin/npm
  Managers:
    Homebrew: 3.3.3 - /usr/local/bin/brew
    pip3: 21.1.1 - /usr/local/bin/pip3
    RubyGems: 3.0.3.1 - /Users/danedavid/.rbenv/shims/gem
  Utilities:
    Make: 3.81 - /usr/bin/make
    GCC: 4.2.1 - /usr/bin/gcc
    Git: 2.32.0 - /usr/bin/git
    Clang: 13.0.0 - /usr/bin/clang
  Servers:
    Apache: 2.4.51 - /usr/sbin/apachectl
  Virtualization:
    Docker: 20.10.12 - /usr/local/bin/docker
  IDEs:
    Nano: 2.0.6 - /usr/bin/nano
    VSCode: 1.64.1 - /usr/local/bin/code
    Vim: 8.2 - /usr/local/bin/vim
    Xcode: /undefined - /usr/bin/xcodebuild
  Languages:
    Bash: 3.2.57 - /bin/bash
    Go: 1.16.5 - /usr/local/bin/go
    Java: 1.8.0_265 - /usr/bin/javac
    Perl: 5.34.0 - /usr/local/bin/perl
    Protoc: 3.17.3 - /usr/local/bin/protoc
    Python: 2.7.18 - /usr/bin/python
    Python3: 3.9.5 - /usr/local/bin/python3
    Ruby: 2.6.8 - /Users/danedavid/.rbenv/shims/ruby
  Databases:
    PostgreSQL: 12.3 - /Applications/Postgres.app/Contents/Versions/latest/bin/postgres
    SQLite: 3.36.0 - /usr/bin/sqlite3
  Browsers:
    Chrome: 98.0.4758.80
    Safari: 15.3
```
</details>
Repository: godot
Issue: Editing an array in running game using inspector causes references to be replaced by EncodedObjectAsId objects (fixed in `master`)
Labels: bug,topic:core

### Godot version

3.5-stable

### System information

Windows 11

### Issue description

If you have an exported array (or just an array) of referenced objects (say, a custom Resource), and you resize the array or change its contents using the inspector while the game is running (in the Remote tree, or using Synchronize Scene Changes/hot reload), all referenced objects inside the array will be replaced by EncodedObjectAsID objects.

Additionally, the ID it holds will not actually point back to the original reference object.

May be related to #42725 

### Steps to reproduce

Scene: A node with some exported textures, I.E.
```gdscript
extends Node

export(Array, Texture) var resources := []
```
with a single texture in the array (the project icon, for example.)

1. Run the game
1. Use the Inspector in Remote to grow the array by 1
1. See that the ID of the referenced tex changed. Accessing it shows that it's become an EncodedObjectAsID, and its internal ID number is just a garbage number.

![image](https://user-images.githubusercontent.com/2823241/153956305-5f22f639-2532-41be-9099-8e6c39ab1d05.png)

![image](https://user-images.githubusercontent.com/2823241/153956221-7f697615-0d02-422e-b5d7-19c55c4e80ee.png)

![image](https://user-images.githubusercontent.com/2823241/153956330-f4f3a19e-8a57-4d42-b5ab-fc9727afdf86.png)

![image](https://user-images.githubusercontent.com/2823241/153956251-914356e2-e9d1-4cff-b5b6-d1495f66c1c2.png)


### Minimal reproduction project
[mrp_encodedasid.zip](https://github.com/godotengine/godot/files/9270043/mrp_encodedasid.zip)
Repository: godot
Issue: Add `BIND_METHOD_ERR_RETURN_DOC` macros throughout class bindings to improve generated class reference
Labels: enhancement,discussion,topic:core,documentation

### Godot version

4.0.alpha2

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 495.46)

### Issue description

In `master`, it's possible to [define which methods of a class can return specific error codes](https://github.com/godotengine/godot/pull/52077).
Here's the only example in the codebase so far: https://github.com/godotengine/godot/blob/d02db6306ebcb57296dece3e8d990ae188b39aad/core/io/config_file.cpp#L320

This should be done for more methods to improve the generated class reference XML (`<returns_error>` tags in each method).

### Steps to reproduce

- Search for methods that have an Error return type.
- Look at the source code implementation and see which errors they can return. You can also look at the existing class reference descriptions, but I highly recommend reading the source code implementation again (just in case the current documentation is incorrect or outdated).
- Add a `BIND_METHOD_ERR_RETURN_DOC("method_name", ERR_CODE);` macro *after* the method has been bound in a class' `_bind_methods()` function. You can use this macro several times for the same function. Note that the `OK` return value is *always* implicitly added, so you do not need to add it explicitly.

### Minimal reproduction project

N/A
Repository: pytorch
Issue: `{Batch,Instance}Norm{1,2,3}d` works when `num_features != C`!
Labels: module: nn,triaged

### 🐛 Describe the bug

`BatchNorm{1,2,3}d` and `InstanceNorm{1,2,3}d` work when `num_features != C` when C is 0. Based on its documentation, num_features is C from an expected input of size (N, C, H, W), so they should not work.

```python
import torch

a = torch.rand([1, 0, 2, 2])
batchnorm = torch.nn.BatchNorm2d(5)
batchnorm(a)
# work
```

By contrast, `LazyBatchNorm` will fail when C is 0.
```python
import torch

a = torch.rand([1, 0, 2, 2])
lazybatchnorm = torch.nn.LazyBatchNorm2d()
lazybatchnorm(a)
# IndexError: select(): index 0 out of range for tensor of size [0] at dimension 0
```

### Versions

pytorch: 1.10.1

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: pytorch
Issue: Some loss functions support `dtype` broadcast but some do not
Labels: module: nn,module: loss,triaged,module: type promotion

### 🐛 Describe the bug

Some loss functions support `dtype` broadcast but some do not. For example,

```python
import torch
results = dict()
a = torch.rand([3], dtype=torch.float32)
b = torch.rand([3], dtype=torch.float64)
torch.nn.BCEWithLogitsLoss()(a, b)
# work
torch.nn.BCELoss()(a, b)
# RuntimeError: Found dtype Double but expected Float
```

I think they should have the same behavior in term of broadcasting.

### Versions

pytorch: 1.10.1

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @nairbv
Repository: rust
Issue: bootstrap: RUSTFLAGS_*_BOOTSTRAP does not affect build scripts
Labels: T-bootstrap

It's unclear if this _should_ be a bug report for Rust's bootstrap or not, but it feels like it's appropriate if only for tracking the problem for when others run into the same. I think closing this is also reasonable.

When `RUSTFLAGS_BOOTSTRAP`/`RUSTFLAGS_NOT_BOOSTRAP` is passed to to `x.py` (gets picked up [here](https://github.com/rust-lang/rust/blob/c5c610aad0a012a9228ecb83cc19e77111a52140/src/bootstrap/builder.rs#L1028-L1037)), those variables are forwarded as `RUSTFLAGS` here:

https://github.com/rust-lang/rust/blob/c5c610aad0a012a9228ecb83cc19e77111a52140/src/bootstrap/builder.rs#L1856

This works most of the time. However, there is a known bug in Cargo (rust-lang/cargo#5754 / rust-lang/cargo#4423) that makes it so that if `--target` is passed to a `cargo` invocation, even if the passed triple is the same as the host triple, `RUSTFLAGS` is _not_ passed to build scripts. And since bootstrap _always_ passes `--target`, `RUSTFLAGS_*_BOOTSTRAP` do not take effect for builds scripts:

https://github.com/rust-lang/rust/blob/c5c610aad0a012a9228ecb83cc19e77111a52140/src/bootstrap/builder.rs#L1001

This is problematic when `RUSTFLAGS` includes arguments that are critical to building, most notably in the form of `-Clink-arg`s without which any attempt to link may fail.

There isn't an obvious fix to the problem beyond fixing the upstream problem(s) in Cargo. One possibility is to detect when `target == host` in the bootstrap logic and avoid passing `--target` to `cargo` in that instance. That way build scripts will respect `RUSTFLAGS` again, though it may still pose a problem for cross-compiling use-cases, I'm not sure?

### Meta

`rustc --version --verbose`:
```
rustc 1.58.1 (db9d1b20b 2022-01-20)
binary: rustc
commit-hash: db9d1b20bba1968c1ec1fc49616d4742c1725b4b
commit-date: 2022-01-20
host: x86_64-unknown-linux-gnu
release: 1.58.1
LLVM version: 13.0.0
```
Repository: pytorch
Issue: Toggling deterministic mode for individual autograd backward functions
Labels: module: autograd,triaged,needs research,module: determinism

### 🚀 The feature, motivation and pitch

At the moment, we can easily turn off deterministic mode for one or more operations in forward mode by just doing this:

```python
torch.use_deterministic_algorithms(False)
operation()
torch.use_deterministic_algorithms(True)
```

However, when we call the backward function, the entire thing is either deterministic or not. For instance:

```python
import torch

torch.use_deterministic_algorithms(True)

a = torch.randn(10, 10, requires_grad=True, device='cuda')
index = torch.tensor([[0]], device='cuda')

torch.use_deterministic_algorithms(False)
r = a.gather(0, index)
torch.use_deterministic_algorithms(True)

r.backward()
```

When this is run in Pytorch 1.11, this is the output:

```
Traceback (most recent call last):
  File "/home/kurtamohler/tmp/tmp.py", line 12, in <module>
    r.backward()
  File "/work2/kurtamohler/development/pytorch-storage-followup/torch/_tensor.py", line 363, in backward
    torch.autograd.backward(self, gradient, retain_graph, create_graph, inputs=inputs)
  File "/work2/kurtamohler/development/pytorch-storage-followup/torch/autograd/__init__.py", line 173, in backward
    Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
RuntimeError: scatter_add_cuda_kernel does not have a deterministic implementation, but you set 'torch.use_deterministic_algorithms(True)'. You can turn off determinism just for this operation, or you can use the 'warn_only=True' option, if that's acceptable for your application. You can also file an issue at https://github.com/pytorch/pytorch/issues to help us prioritize adding deterministic support for this operation.
```

The backward function for `torch.gather` is nondeterministic, so it throws an error. It might be useful if we could toggle determinism for individual backward functions. There might be a couple different ways to offer this feature.

One way could be for each backward function to just use the same deterministic mode that was used during the corresponding forward function call. Maybe a way to implement this would be to add a bool to each autograd node, indicating whether it's deterministic or not.

I'm curious if anyone would find this feature useful, so please let me know.

### Alternatives

_No response_

### Additional context

This idea was first discussed here: https://github.com/pytorch/pytorch/issues/50469#issuecomment-1031828294

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @mruberry @kurtamohler
Repository: create-react-app
Issue: paths.appTsConfig ignored in ForkTsCheckerWebpackPlugin
Labels: needs triage,issue: bug report

### Describe the bug

Overriding `paths.appTsConfig` no longer works in 5.0 like it did in 4.x.

In `webpack.config.js` in `react-scripts` 4.0.3, the `ForkTsCheckerWebpackPlugin` received the option `tsconfig: paths.appTsConfig`. This meant you could use various overriding tools to point CRA to a different tsconfig.

In `react-scripts` 5.0.0, there is no equivalent line, which means the ts checker plugin always defaults to `tsconfig.json` when configuring the `typescript-reporter` in `fork-ts-checker-webpack-plugin`.

This seems like an oversight, because the rest of `webpack.config.js` is written to assume `paths.appTsConfig` is where the tsconfig is located.

Adding:

```diff
       // TypeScript type checking
       useTypeScript &&
         new ForkTsCheckerWebpackPlugin({
           async: isEnvDevelopment,
           typescript: {
+            configFile: paths.appTsConfig,
             typescriptPath: resolve.sync('typescript', {
               basedir: paths.appNodeModules,
             }),
```

fixes it.

### Steps to reproduce

Use react-app-rewired to change `paths.appTsConfig`.

### Expected behavior

It correctly uses the same tsconfig everywhere.

### Actual behavior

It always uses `tsconfig.json`.

Note: while this seems like unofficial functionality, it would be nice to fix it.
Repository: godot
Issue: File import bug - tiny files cause problems
Labels: bug,topic:editor,confirmed,topic:import,regression

### Godot version

4.0.2/1 dev 

### System information

mac book pro 2017

### Issue description

When duplicating or creating new files on my system, godot always shows them with an X next to them and I cannot use them.

Even just duplicating a file that already exists and godot likes, does not work.

Duplicating it within godot, it does work.  

Second, deleting a file using the selector freezes godot.



### Steps to reproduce

Please see recording.  https://youtu.be/RiwGOjuYgz4


### Minimal reproduction project

included below
Repository: opencv
Issue: I have built Opencv with cuda support but pycharm couldnt find it
Labels: duplicate,question (invalid tracker)

I have build it using cmake and virtual studio 2019
Which paths do i have to set so that it recognizes opencv with cuda support
Repository: flutter
Issue: [web] TextField do not show soft keyboard in the built-in browser Redmi or vivo phones
Labels: a: text input,e: device-specific,platform-android,engine,platform-web,e: web_html,P2,team-engine,triaged-engine

Flutter web TextField cannot pop up the soft keyboard in the built-in browser of some Redmi or vivo mobile phones. You need to long-press or continuously click anywhere on the page about 9 times, and then click TextField to pop up the soft keyboard. This will make us unable to adapt to all browsers for flutter web development.
Repository: create-react-app
Issue: Support of es6 module in test
Labels: needs triage,issue: bug report

### Describe the bug

react-scripts test fails if imported package is esm module only.
Build woks fine and have no issues.
Issue is similar to https://github.com/facebook/create-react-app/issues/5241

### Which terms did you search for in User Guide?
https://create-react-app.dev/docs/running-tests

### Environment

current version of create-react-app: 5.0.0

  System:
    OS: Windows 10 10.0.19042
    CPU: (8) x64 Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
  Binaries:
    Node: 16.13.2 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Spartan (44.19041.1266.0), Chromium (98.0.1108.50)
    Internet Explorer: 11.0.19041.1202
  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

<!--
  How would you describe your issue to someone who doesn’t know you or your project?
  Try to write a sequence of steps that anybody can repeat to see the issue.
-->

(Write your steps here:)

1. Create a basic package which only produce esm module.
2. Create a new App with create-react-app.
3. Import one of the class in App.tsx
4. Build works fine, Test fails.
Repository: go
Issue: net/http: check connection from pool before use
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

go1.16.3 darwin/amd64

### Does this issue reproduce with the latest release?

yes


### What operating system and processor architecture are you using (`go env`)?

GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/laozhang/Library/Caches/go-build"
GOENV="/Users/laozhang/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/laozhang/go/pkg/mod"
GONOPROXY="git.code.oa.com"
GONOSUMDB="git.code.oa.com,git.code.woa.com"
GOOS="darwin"
GOPATH="/Users/laozhang/go"
GOPRIVATE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pg/7d_r_s8j6v362rgv9nqkrsbh0000gn/T/go-build3091927261=/tmp/go-build -gno-record-gcc-switches -fno-common"


### What did you do?

I used "net/http/httputil/reverseproxy.go" to build a http proxy, but it often happens: Request forwarding failed with error "EOF". It should be because: after the link is taken out from the link pool, the peer end closes the link when the proxy sends the request, causing the proxy to report an "EOF" error when it reads the response. Because it is a POST request, retrying may cause other unexpected errors.
Can an optimization be done here? After removing the link from the link pool, do a health check before using it. For example, if you try to read a byte from the link, the theoretical result should be: neither data can be read nor an error reported; any other result means that The currently fetched link is unavailable and should be discarded.

### What did you expect to see?

has already been said above.

### What did you see instead?

 has already been said above.
Repository: flutter
Issue: [video_player] `seekTo` beginning happens after delay because of the buffering on Android
Labels: platform-android,p: video_player,package,has reproducible steps,P3,found in release: 2.10,found in release: 2.11,team-android,triaged-android

When I call the videoPlayerController.seekTo(Duration.zero) or Duration( .. : .. ), video starts to play after buffering process finish in Android. It works good in iOS. I think that the problem in here is happening because ExoPlayer works like that. I've made a lot of research and found an [article](https://takusemba.medium.com/deep-understanding-of-seek-4e10079165ec). Maybe video_player library can give us a chance to change SeekParameters or maybe caching will prevent this unnecessary buffering. I don't think that we need buffer process in here because I want to play same video.

When I call videoPlayerController.seekTo(Duration.zero) the first log is:
 --> D/AudioTrack(26148): stop(59): called with 194560 frames delivered
 
After some time (depends on video size), for my case 3-4 seconds for a 20 mb video, the other logs came:

 --> D/AudioTrack(26148): getTimestamp_l(60): device stall time corrected using current time 21442303047753 
 --> D/AudioTrack(26148): getTimestamp_l(60): stale timestamp time corrected, currentTimeNanos: 21440694441753 < limitNs: 21442169902753 < mStartNs: 21442230902753 
 --> W/AudioTrack(26148): getTimestamp_l(60): retrograde timestamp time corrected, 21442169902753 < 21442303047753,

After these logs are printed video starts to play.

Note: This behaviour is not happening for setLooping(true), but in my case I have to use seekTo.
Repository: material-ui
Issue: [InputLabel] does not accept prop "size" in TypeScript
Labels: discussion,status: expected behavior

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

I add the prop size="small" to an InputLabel component, and TypeScript complains:

![image](https://user-images.githubusercontent.com/16855788/154033378-c0fc8311-c65e-478b-a582-b81e1fac1ef5.png)




### Expected behavior 🤔

TypeScript should accept "size" as a prop, since the prop does what it is supposed to. It is simply not added to the typing.

### Steps to reproduce 🕹

Steps:

1. Add an `<InputLabel>` component to the app.
2. Add `size="small"` as a prop to the component.
3. The component renders as expected.
4. TypeScript is not happy.


### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

  System:
    OS: Linux 5.10 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
    Memory: 28.06 GB / 31.23 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 16.13.1 - /usr/local/bin/node
    npm: 8.1.2 - /usr/local/bin/npm
  Managers:
    Apt: 2.0.6 - /usr/bin/apt
  Utilities:
    Make: 4.2.1 - /usr/bin/make
    GCC: 9.3.0 - /usr/bin/gcc
    Git: 2.25.1 - /usr/bin/git
  Virtualization:
    Docker: 20.10.9 - /usr/bin/docker
  IDEs:
    Nano: 4.8 - /usr/bin/nano
    Vim: 8.1 - /usr/bin/vim
  Languages:
    Bash: 5.0.17 - /usr/bin/bash
    Perl: 5.30.0 - /usr/bin/perl
    Python: 2.7.18 - /usr/bin/python
    Python3: 3.8.10 - /usr/bin/python3
  Browsers:
    Chrome: 98.0</details>
Repository: node
Issue: Maintaining a project board to manage feature requests
Labels: meta

Refs: https://github.com/nodejs/node/issues/41113

I started experimenting with it in https://github.com/orgs/nodejs/projects/4

I think that if done well it will be beneficial for us collaborators and for users.
Now if other people agree with me, the next steps would be:
- Determine the fields (and their possible values) that we need to filter and organize the issues efficiently.
- Determine the views that we want to make available.
- Add all existing open feature requests to the project.
- Setup a GitHub action that adds an issue to the project when it is labeled "feature request" and removes it from it when the label is removed.
- Update the [feature-request-management document](https://github.com/nodejs/node/blob/HEAD/doc/contributing/feature-request-management.md)

/cc @nodejs/tsc