sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react-native
Issue: Switch animation does not seem to work correctly when updating value prop
Labels: Platform: iOS,Component: Switch,Never gets stale

Hi. I noticed a strange behaviour of switch component when value is changed any other way than actual interact with switch. (so, basically, when we set a new prop value)

## Description
When you set new "value" prop value Android animation is working, but it does not have that ripple effect (idk if it is supposed to work like that), and iOS animation is not working at all that looks not pretty.

## React Native version:
<details>
<summary>$ react-native info</summary>

System:
    OS: macOS 11.5
    CPU: (8) arm64 Apple M1
    Memory: 68.00 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.2.0 - ~/.nvm/versions/node/v16.2.0/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v16.2.0/bin/yarn
    npm: 7.16.0 - ~/.nvm/versions/node/v16.2.0/bin/npm
    Watchman: 2021.06.07.00 - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.10.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4
    Android SDK:
      API Levels: 28, 29, 30
      Build Tools: 28.0.3, 29.0.2, 30.0.2, 30.0.3, 31.0.0, 31.0.0, 31.0.0
      System Images: android-29 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 Atom, android-30 | Google APIs ARM 64 v8a, android-S | Google APIs ARM 64 v8a
      Android NDK: Not Found
  IDEs:
    Android Studio: Not Found
    Xcode: 12.5.1/12E507 - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_292 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1 
    react-native: 0.64.1 => 0.64.1 
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found
</details>

## Steps To Reproduce
Just update a value prop for Switch component

## Snack, code example, screenshot, or link to a repository:
See an example here: [mrAnomalyy/rn-switch-issue](https://github.com/mrAnomalyy/rn-switch-issue)
<details>
  <summary>iOS GIF</summary>

![Simulator Screen Recording - iPhone 12 - 2021-08-06 at 14 12 56](https://user-images.githubusercontent.com/39645529/128500154-9385fe2d-9478-4e65-afe7-1f779f92560b.gif)

</details>
<details>
  <summary>Android GIF</summary>

![Screen-Recording-2021-08-06-at-2](https://user-images.githubusercontent.com/39645529/128500403-b8a8a196-324a-48e8-84b5-290a074e3ea5.gif)

</details>

P.S. I've been digging on RN iOS code for Switch component and I was able to fix the issue just by replacing this value (see pic below) with YES, but obviously it does not look like a good solution.

![image](https://user-images.githubusercontent.com/39645529/128500723-a129914e-3c77-45c1-821b-622b6ba3550d.png)
Repository: go
Issue: x/website/go.dev: erratic scrolling on mobile devices when reaching the bottom of solutions page
Labels: NeedsInvestigation,website

<!--
Please answer these questions before submitting your issue. Thanks!
-->
 
### What is the URL of the page with the issue?
 
 [https://go.dev/solutions/#use-cases](https://go.dev/solutions/#use-cases) 
 
### What is your user agent?
 Mozilla/5.0 (iPhone; CPU iPhone OS 14_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/92.0.4515.90 Mobile/15E148 Safari/604.1
<!-- 
You can find your user agent here:
https://www.whatismybrowser.com/detect/what-is-my-user-agent
-->
 
 
 
### Screenshot
 
<!--
Please paste a screenshot of the page.
-->
 
 
![2C6F62B3-4E42-458F-A81E-47FBFC4141B7](https://user-images.githubusercontent.com/70889123/128506749-67c8456d-3c87-425a-9e98-af374f515939.png)

 
### What did you do?
 Scroll to end of page and in addition to, more physical interaction than was was necessary to accomplish this, but if the same type, intensity, and frequency as was required to achieve the desired effect from a distance prior to the undesired result.
<!--
If possible, provide a recipe for reproducing the error.
-->
 
 
 
### What did you expect to see?
 
 The end of the page as a stable, static image.
 
### What did you see instead?

The end and not-end of the page in an erratic and sporadic display of anomalous light.
Repository: pytorch
Issue: Conjugate fallback dispatch key should be per-backend
Labels: triaged,module: complex,module: dispatch

#59380 reminded me that conjugate fallback dispatch key is pretty finely balanced. In particular, when we add support for fast paths, we poke a hole in the Conjugate dispatch key with fallthrough and let the CPU/CUDA backend see conjugated tensors. This is error prone for a few reasons:

1. If the backend doesn't actually handle conjugation, you'll silently get wrong results (since the data pointers will just silently report everything is normal)
2. If a non-CPU/CUDA backend is executed (e.g., lazy tensor core) and you didn't port it over, you'll also get wrong results (some backends know to respect conjugate bits, others don't).

A more robust way would be to have per-backend Conjugate, e.g., ConjugateCPU, ConjugateCUDA, and then either fallthrough/register fused conjugation kernels when we know we have an implementation, and continue with boxed fallback otherwise.

We can't actually do this until @bdhirsh gets open device extension going, and then it becomes cheap to add "per-backend" keys.

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved @bdhirsh
Repository: godot
Issue: GPUParticles interpolation does not affect property curves such as scale, color and rotation
Labels: bug,topic:rendering,confirmed,topic:particles

### Godot version

4.0.dev (85186bc0c)

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 465.31)

### Issue description

The new GPUParticles3D interpolation feature smoothes out particle movement, but not property updates such as scale, color and rotation. This is important to fix as particle systems now run at 30 Hz (interpolated) by default, instead of running every frame like they did in `3.x`.

This is with **Fixed Fps** set to 10 to make the issue more obvious:

https://user-images.githubusercontent.com/180032/128522939-36e339a6-dfad-4df4-8c39-e2d5ffc42381.mp4

As a workaround, disable Fixed Fps or set it to a higher value like 60.

### Steps to reproduce

- Create a GPUParticles3D node.
- Set up a particle system with color and scale changes using curves.
- Set Fixed Fps to 10, keep interpolation enabled.
- Movement is smooth, but curve changes are locked to 10 FPS.

### Minimal reproduction project

[test_gpuparticles_interpolation.zip](https://github.com/godotengine/godot/files/6946031/test_gpuparticles_interpolation.zip)
Repository: pytorch
Issue: Type of first constructor parameter of ElasticDistributedSampler and DistributedSampler
Labels: oncall: distributed,module: dataloader

Hello,
I am implementing a custom BatchSampler that make use of ElasticDistributedSampler. I noticed that DistributedSampler "requires" a Dataset type as first parameter, while other samplers need only a Sized data type; the code of DistributedSampler uses the parameter only to get the length of the dataset.
I know that this is not a real problem, but is there any reason for a so specialised data type?

Thanks,
Giacomo

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23 @SsnL @VitalyFedyunin @ejguan
Repository: pytorch
Issue: Add a mechanism to not universally dispatch to python for all for all operations when using __torch_dispatch__ 
Labels: triaged,module: __torch_dispatch__

## 🚀 Feature
The proposal here is to add a mechanism to not dispatch to python unless stated otherwise when using __torch_dispatch__ . 

## Motivation

This is especially useful for wrapper tensors like `FiniteTensor`, `LoggingTensor`, and `LinearOperator` classes (barring the likes of `DiagonalTensor`) where very few torch functions are overloaded in the given subclass and majority of the functions just unwrap the class object and call into the torch function and returns a wrapped tensor object.

## Pitch

A mechanism to specify a list of functions that should dispatch to python. The idea here is very similar to our boxed fallback mechanism in C++.

cc. @ezyang
Repository: flutter
Issue: Performance issue when using `BoxDecoration` with `CustomPainter`
Labels: framework,engine,c: performance,has reproducible steps,P2,found in release: 2.2,found in release: 2.5,team-engine,triaged-engine

## Steps to Reproduce

<!-- You must include full steps to reproduce so that we can reproduce the problem. -->

1. Download the demo project attached on this issue
2. Run in profile mode in a physical device (I've tested on a Xiaomi Redmi Note 8)

`flutter run --profile -d <DEVICE>`

3. Scroll through the list

**Expected results:** Fluid scrolling behavior

**Actual results:** Stutter animation

**OBS**: It's interesting that removing `decoration: _buildCardDecoration()` makes the performance issue disappear. It seems to be something related between the painter example combined with `BoxDecoration`

Demo: 
[perf.zip](https://github.com/flutter/flutter/files/6946172/perf.zip)


https://user-images.githubusercontent.com/11745745/128526909-cd02aeab-fe48-4b5a-814d-6cad8bb71ea5.mp4

<details>
  <summary>Logs</summary>

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
[✓] Flutter (Channel stable, 2.2.3, on macOS 11.5.1 20G80 darwin-x64, locale en-BR)
    • Flutter version 2.2.3 at /Users/guilhermegirotto/flutter
    • Framework revision f4abaa0735 (5 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /Users/guilhermegirotto/Library/Android/sdk
    • Platform android-30, build-tools 30.0.2
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.1

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] VS Code (version 1.56.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.24.0

[✓] Connected device (4 available)
    • Redmi Note 8 (mobile)               • 2842ae                               • android-arm64 • Android 10 (API 29)
    • Girotto iPhone (mobile)             • 00008020-000929411401002E            • ios           • iOS 14.7.1
    • iPhone SE (2nd generation) (mobile) • 9022EA23-AC9A-419D-B12D-98ED4351E1A5 • ios           • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • macOS (desktop)                     • macos                                • darwin-x64    • macOS 11.5.1 20G80 darwin-x64

• No issues found!
```

</details>
Repository: rust
Issue: initial-exec not reduced to less strict hint on unsupported platforms
Labels: A-thread-locals,requires-nightly

As discovered in https://github.com/rust-lang/rust/issues/81334 and "fixed" for the compiler in https://github.com/rust-lang/rust/pull/85807, -Ztls-model=initial-exec does not work on some platforms. However, it seems like LLVM and/or rustc can automatically detect this on known unsupported platforms and either ignore or reduce the hint as needed.

See https://github.com/rust-lang/rust/pull/85807#issuecomment-850848217, https://github.com/rust-lang/rust/pull/85807#issuecomment-851363785.
Repository: terminal
Issue: Settings editor saves settings.json lines with trailing whitespace
Labels: Help Wanted,Issue-Bug,Area-Settings,Product-Terminal,Priority-3,good first issue

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

1.9.1942.0

### Other Software

_No response_

### Steps to reproduce

I have my settings.json tracked in a dotfiles git repo. Recently (now that settings UI is available) I've noticed that the settings.json is save with a trailing space after a name. This appears to be the case when the name is an array or object whose contents continue onto the next line (i.e. the space after the name is always added without considering whether a string value or array/object value will follow.

### Expected Behavior

Lines are trimmed when saving

### Actual Behavior

Extra spaces are left behind for entries which span multiple lines.
Repository: rust
Issue: improper_ctypes diagnostic should advise to avoid improper C types because their ABI is unstable
Labels: C-enhancement,A-diagnostics,A-FFI,T-compiler,L-improper_ctypes

<!--
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.
-->

Spawned off of this [zulip thread](https://zulip-archive.rust-lang.org/131828tcompiler/23501slicesvectorsinexternC.html).

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
extern {
    fn __enzyme_autodiff(_: usize, a: &[f32], d_a: &mut [f32]);
}
```

The current output is:

```
warning: `extern` block uses type `[f32]`, which is not FFI-safe
 --> src/lib.rs:2:39
  |
2 |     fn __enzyme_autodiff(_: usize, a: &[f32], d_a: &mut [f32]);
  |                                       ^^^^^^ not FFI-safe
  |
  = note: `#[warn(improper_ctypes)]` on by default
  = help: consider using a raw pointer instead
  = note: slices have no C equivalent

warning: `extern` block uses type `[f32]`, which is not FFI-safe
 --> src/lib.rs:2:52
  |
2 |     fn __enzyme_autodiff(_: usize, a: &[f32], d_a: &mut [f32]);
  |                                                    ^^^^^^^^^^ not FFI-safe
  |
  = help: consider using a raw pointer instead
  = note: slices have no C equivalent

warning: 2 warnings emitted
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
warning: `extern` block uses type `[f32]`, which is not FFI-safe
 --> src/lib.rs:2:39
  |
2 |     fn __enzyme_autodiff(_: usize, a: &[f32], d_a: &mut [f32]);
  |                                       ^^^^^^ not FFI-safe
  |
  = note: `#[warn(improper_ctypes)]` on by default
  = help: consider using a raw pointer instead
  = note: slices have no C equivalent, and their ABI is unstable

warning: `extern` block uses type `[f32]`, which is not FFI-safe
 --> src/lib.rs:2:52
  |
2 |     fn __enzyme_autodiff(_: usize, a: &[f32], d_a: &mut [f32]);
  |                                                    ^^^^^^^^^^ not FFI-safe
  |
  = help: consider using a raw pointer instead
  = note: slices have no C equivalent, and their ABI is unstable

warning: 2 warnings emitted
```

Why: Currently, people might reverse-engineer the current ABI, and use a Rust type in an `extern "C"` block despite the warning. Reminding the reader that the ABI is unstable will help discourage that practice.
Repository: rust
Issue: Reservation impls in rustdoc
Labels: T-rustdoc,T-libs-api,A-docs,C-bug,F-rustc_attrs

I’ve been browsing rustdoc and just noticed a very confusing blanket [impl on `Infallible`](https://doc.rust-lang.org/1.54.0/std/convert/enum.Infallible.html#impl-From%3C!%3E-1).

![Screenshot_20210806_191027](https://user-images.githubusercontent.com/3986214/128547444-d86f9a18-754d-46c9-8343-61b3808c1a97.png)


Confusing because it’s obviously in conflict with the explicit `From<!> for Infallible` as well as the generic `From<T> for T` implementation. Only after [looking at the source code](https://doc.rust-lang.org/1.54.0/src/core/convert/mod.rs.html#559-563) I could find out that this _isn’t even an implementation at all_. Searching for existing issues, the original issue on this topic is closed and concluded

> This is how it currently looks, and I think it's "good enough". Going to close the issue.
> 
> ![image](https://user-images.githubusercontent.com/155238/66155518-ccf30800-e5ed-11e9-8112-c9780ec32dd9.png)
> <hr>
>
> * _source: https://github.com/rust-lang/rust/issues/64633#issuecomment-538078589_

This comment however is only visible [on the page of the `From` trait itself](https://doc.rust-lang.org/1.54.0/std/convert/trait.From.html#impl-From%3C!%3E-2).

Another example of this problem, [the same `impl` on the `Option<T>` type](https://doc.rust-lang.org/1.54.0/std/option/enum.Option.html#impl-From%3C!%3E).

I’m also confused by the fact that the `impl` is only shown on _some_ types in `std` but not all. E.g. [on the `cmp::Ordering` type](https://doc.rust-lang.org/1.54.0/std/cmp/enum.Ordering.html#blanket-implementations) you can’t see it at all.

I don’t feel like it would be a difficult change to just make this `From` impl entirely invisible in rustdoc. I don’t see any value in displaying it, and it can be very confusing, especially when displayed without the accompanying comment. 

@rustbot label T-rustdoc, F-rustc_attrs, T-libs-api, A-docs, C-bug

Tagging `T-libs-api, A-docs` as well because the situation could immediately and easily be somewhat improved by adding the “this impl does not yet exist” explanation docs to the `from` method, as that one’s at least being displayed everywhere (if you click the `[+]` button sufficiently often).
Repository: pytorch
Issue: distributed/elastic/multiprocessing/api_test is flaky on ROCm
Labels: module: rocm,triaged,module: flaky-tests,needs research,oncall: r2p

## 🐛 Bug

Example failure:
```
12:45:06 ======================================================================
12:45:06 ERROR [3.945s]: test_multiprocess_context_close (__main__.StartProcessesListTest)
12:45:06 ----------------------------------------------------------------------
12:45:06 Traceback (most recent call last):
12:45:06   File "distributed/elastic/multiprocessing/api_test.py", line 236, in tearDown
12:45:06     shutil.rmtree(self.test_dir)
12:45:06   File "/opt/conda/lib/python3.6/shutil.py", line 477, in rmtree
12:45:06     onerror(os.lstat, path, sys.exc_info())
12:45:06   File "/opt/conda/lib/python3.6/shutil.py", line 475, in rmtree
12:45:06     orig_st = os.lstat(path)
12:45:06 FileNotFoundError: [Errno 2] No such file or directory: '/tmp/StartProcessesListTest_wbdco4lw'
12:45:06 
12:45:06 ----------------------------------------------------------------------
12:45:06 Ran 38 tests in 23.323s
12:45:06 
12:45:06 FAILED (errors=1)
12:45:06 
12:45:06 Generating XML reports...
12:45:06 Generated XML report: test-reports/dist-gloo/distributed.elastic.multiprocessing.api_test/TEST-RunProcResultsTest-20210806124443.xml
12:45:06 Generated XML report: test-reports/dist-gloo/distributed.elastic.multiprocessing.api_test/TEST-StartProcessesListTest-20210806124443.xml
12:45:06 Generated XML report: test-reports/dist-gloo/distributed.elastic.multiprocessing.api_test/TEST-StartProcessesTest-20210806124443.xml
12:45:06 Generated XML report: test-reports/dist-gloo/distributed.elastic.multiprocessing.api_test/TEST-StdTest-20210806124443.xml
12:45:07 Traceback (most recent call last):
12:45:07   File "test/run_test.py", line 1091, in <module>
12:45:07     main()
12:45:07   File "test/run_test.py", line 1070, in main
12:45:07     raise RuntimeError(err_message)
12:45:07 RuntimeError: distributed/elastic/multiprocessing/api_test failed!
```

https://ci.pytorch.org/jenkins/job/pytorch-builds/job/pytorch-linux-bionic-rocm4.2-py3.6-test2/11988/console

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @dzhulgakov @KyleCZH @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23
Repository: kubernetes
Issue: declarative defaults need to handle const values
Labels: sig/api-machinery,triage/accepted

Declarative defaulting is awesome.  For literal values, it is super useful.

HOWEVER...

Many (most) of our default values are `const` and it seems wrong to copy the values into the API comments. For example:

```
type Container struct {
    // ... lots ...
    TerminationMessagePath string `json:"terminationMessagePath,omitempty" protobuf:"bytes,13,opt,name=terminationMessagePath"`
    // ... lots ...
}
```

in defaults.go, we find:

```
func SetDefaults_Container(obj *v1.Container) {
    // ... other stuff ...
    if obj.TerminationMessagePath == "" {
        obj.TerminationMessagePath = v1.TerminationMessagePathDefault
    }
````

If I delete this defaulting code (win!!!) and use declarative defaults, I WANT to say:

```
 // +default=TerminationMessagePathDefault
 TerminationMessagePath string `json:"terminationMessagePath,omitempty" protobuf:"bytes,13,opt,name=terminationMessagePath"`
```

...but that doesn't work.  The defaulter code calls `json.Unmarshall()` and barfs.

I can change that to:

```
 // +default="/dev/termination-log"
 TerminationMessagePath string `json:"terminationMessagePath,omitempty" protobuf:"bytes,13,opt,name=terminationMessagePath"`
```

...but there are at least 2 places of this being needed. That's a risk for drift and bugs.  Other examples like `Protocol` are used ALL OVER.

What I think should happen is that, before calling `json`, we should parse the value.  If it tastes like a go symbol reference, use that.  But it's a LITTLE tricky because of the flat package namespace.  Ideally what we'd get is logic that allows either:

staging/src/k8s.io/api/core/v1/types.go:
```
// +default=TerminationMessagePathDefault
```

...meaning `k8s.io/api/core/v1.TerminationMessagePathDefault` (the package being where the default was used) or else ...

```
// +default=k8s.io/api/core/v1.TerminationMessagePathDefault
```

...being an unambiguous way to use consts in another package.  The default-gen would then ensure that package was imported in the generated code.

And when we render openapi or whatever, we would do the same, but dereference the value so the docs contained the literal.
Repository: pytorch
Issue: Use `linecache.lazycache` in torch.fx
Labels: module: bootcamp,triaged,module: fx

`torch.fx` makes its traced forward graph executable by emitting Python code and `exec`ing it. In order for this to compose well with other Python functionality (e.g. stack traces, `inspect`, pickle, and so on), we need to tell Python how to find the original source information for the `exec`'d function.

Today we do this by [patching](https://github.com/pytorch/pytorch/blob/97dc43beeb767761f86360e8fc54f47360674fcf/torch/fx/graph_module.py#L23-L38) `linecache.getline`, which works well enough but is not awesome because it mutates global Python behavior.

We figured out a cleaner way to do it in `torch.package` by [utilizing the `linecache` APIs](https://github.com/pytorch/pytorch/blob/master/torch/package/package_importer.py#L319-L322).

This task is to port the `linecache` code in `torch.fx` over to the `torch.package` way of doing things.

cc @ezyang