sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: ant-design
Issue: Mac系统下，Radio按钮在选中状态被禁用时，有很大概率会出现Radio选中状态闪烁的情况
Labels: 🐛 Bug,help wanted,Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[https://ant.design/components/radio/](https://ant.design/components/radio/)

### Steps to reproduce
放置一个Radio Button，通过OnClick事件改变Radio的disabled的状态。有大概率会出现在改变disabled状态时，Radio会出现未选中又突然选中的闪烁状态。

### What is expected?
当改变Radio的disabled的状态时，Radio不应该出现从未选中又突然选中的闪烁状态

### What is actually happening?
当改变Radio的disabled的状态时，Radio有较大概率出现从未选中又突然选中的闪烁状态

注：经测试，仅在Mac系统下会出现此类动画显示的bug，Windows系统下不会出现此类bug

| Environment | Info |
|---|---|
| antd | 4.18.5 |
| React | react@^16.8.6 |
| System | MacOS Big Sur 11.1 |
| Browser | Chrome |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: Nested functions with `#[no_coverage]` lead to non-obvious results.
Labels: T-compiler,C-bug,A-code-coverage

The fact that coverage is based on source ranges of function bodies means that an inner functions ranges are being "shadowed" by the outer function. When rendered, the source ranges appear to be covered (by the outer function) even though they are not.

An example from https://github.com/rust-lang/rust/pull/92695:

```rust
    pub fn outer(is_true: bool) {
        println!("called and covered");
        inner_not_covered(is_true);

        #[no_coverage]
        fn inner_not_covered(is_true: bool) {
            if is_true {
                println!("called but not covered");
            } else {
                println!("absolutely not covered");
            }
        }
    }
```

Pretty printing the coverage report looks like this:

```
   45|      1|    pub fn outer(is_true: bool) {
   46|      1|        println!("called and covered");
   47|      1|        inner_not_covered(is_true);
   48|      1|
   49|      1|        #[no_coverage]
   50|      1|        fn inner_not_covered(is_true: bool) {
   51|      1|            if is_true {
   52|      1|                println!("called but not covered");
   53|      1|            } else {
   54|      1|                println!("absolutely not covered");
   55|      1|            }
   56|      1|        }
   57|      1|    }
```
Repository: go
Issue: cmd/compile/internal/amd64: huge performance degradation (register allocation issue?)
Labels: 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.6 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="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/user/opt/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/user/opt/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.6"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
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 -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2989573659=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

I have wrote a function which I guess stresses the register allocation in the Go compiler.
The problem I (accidentally) discovered is that swapping two independent lines in the source code causes spillage of the variables from the registers into the stack. This reduces performance of my benchmark by 30%!

Excerpt from the "fast" code version:
```go
// ...lines identical in both versions...
diagonalValue = state[begin-1]
end := min(col+maxDist, patternLen)
// ...lines identical in both versions...
```

Excerpt from the "slow" code version:
```go
// ...lines identical in both versions...
end := min(col+maxDist, patternLen)
diagonalValue = state[begin-1]
// ...lines identical in both versions...
```

As you can see the lines are independent and the compiler is free to reorder the code.
I have a self-contained 150 line source file ready for `go test -bench` which reproduces this issue.  I can share this file with the compiler developers privately for the purpose of the issue reproduction only due to the code being proprietary. Please advise on how to proceed.


### What did you expect to see?

I expect to see both versions compiled into the same binary code with the same performance.

### What did you see instead?

Function asm code change from `STEXT nosplit size=1158 args=0x68 locals=0x40 funcid=0x0` to `STEXT size=1355 args=0x68 locals=0x78 funcid=0x0`. Performance drop of ~30% from 2618 ns/op to 3905 ns/op.
Repository: rust
Issue: Huge performance gap between lto="fat",cgu=1 and default release profile
Labels: I-slow,O-wasm

I was told on Rust's Discord that I should maybe post this issue here together with my research so far which can be found following [this GitHub issue link](https://github.com/paritytech/wasmi/issues/339). The GitHub issue links to other sources of information such as the [GitHub Gist](https://gist.github.com/Robbepop/0644e9eb000bb1dad6a003a72534263a) that accumulates a lot of benchmark results.

The **tl;dr** is that we see slowdowns of up to x4.21 with the default release profile compared to using
```toml
[profile.release]
lto = "fat"
codegen-units = 1
```
Which is a lot more than the 10-15% that I usually see between both profiles.

People told me that maybe this is due to some edge cases within the optimization pipeline. I personally ran out of ideas since whatever I do I usually see slowdowns of at least 75-100% which is unacceptable since this is a very performance critical library. The major problem with the custom profile using `lto="fat",cgu=1` is that it compiled massively slow and probably won't be used by all library users by default which will lead to very poor performance in the default case for those users. The only thing I can do rn is to spam potential users with warnings about using the correct profile settings.

----

[I also asked this in Rust's Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Massive.20requirement.20on.20lto.3Dfat.20and.20codegen-units.3D1) but didn't gain a lot of really useful information out of it unfortunately.
Repository: rust
Issue: Bad suggestions when trying to initialize an enum as a struct.
Labels: A-diagnostics,T-compiler,D-papercut,D-invalid-suggestion

<!--
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.
-->

Occurs in nightly-2022-01-26

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2eec42713e64ef9243a12589aece967c

```rust
pub type Foos = i32;

pub enum Foo {
    A,
    B,
    C,
}

mod module0 {
    pub struct Foo {
        a: i32,
    }
}
mod module1 {
    pub struct Foo {}
}
mod module2 {
    pub enum Foo {} // This one actually gets correctly filtered out
}

fn main() {
    let foo = Foo { b: 0 };
}

```

The output is a mess of false suggestions, I managed to hit an error that looked very similar to this while refactoring:

```
error[E0574]: expected struct, variant or union type, found enum `Foo`
   --> src/main.rs:22:15
    |
 1  | pub type Foos = i32;
    | -------------------- similarly named type alias `Foos` defined here
 ...
 22 |     let foo = Foo { b: 0 };
    |               ^^^
    |
 help: a type alias with a similar name exists
    |
 22 |     let foo = Foos { b: 0 };
    |               ~~~~
 help: consider importing one of these items instead
    |
 1  | use crate::module0::Foo;
    |
 1  | use crate::module1::Foo;
```


At a minimum we should detect that these suggestions are invalid and not suggest them:
```
error[E0574]: expected struct, variant or union type, found enum `Foo`
   --> src/main.rs:22:15
    |
 22 |     let foo = Foo { b: 0 };
    |               ^^^
    |
```

However maybe we should instead suggest that the user try to properly use Foo as an enum?

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: next.js
Issue: Script component results in different attributes based on the strategy
Labels: bug,Script (next/script)

### Run `next info` (available from version 12.0.8 and up)

next info output:
```
Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 20.6.0: Wed Nov 10 22:23:07 PST 2021; root:xnu-7195.141.14~1/RELEASE_X86_64
    Binaries:
      Node: 16.13.0
      npm: 8.1.0
      Yarn: 1.22.11
      pnpm: 6.24.2
    Relevant packages:
      next: 12.0.8
      react: 17.0.2
      react-dom: 17.0.2
```

### What version of Next.js are you using?

12.0.8

### What version of Node.js are you using?

16.13.0

### What browser are you using?

Chrome

### What operating system are you using?

macOS

### How are you deploying your application?

next start

### Describe the Bug

I premise that I am not sure it is a problem, however I have not found this behavior documented anywhere.

I'm using the Script component and I'm seeing some differences when setting the strategy to `beforeInteractive` compared to other strategies.
The main difference I'm seeing is on the `defer` and `crossorigin` attributes. I set `corssorigin=anonymous` and `defer=false` in some of our scripts.
Setting `beforeInteractive` strategy the ending DOM element always has the defer attribute (no matter what I pass to the component) and the crossorigin is ignored.

Examples:
with code like this
```js
<Script
  src="test.js"
  id="test"
  crossOrigin="anonymous"
  data-test="test"
  defer={false}
  strategy="beforeInteractive"
/>
```
the output is
```html
<script src="test.js" id="test" data-test="test" defer="" data-nscript="beforeInteractive"></script>
```
with code like this
```js
<Script
  src="test.js"
  id="test"
  crossOrigin="anonymous"
  data-test="test"
  defer={false}
  strategy="afterInteractive"
/>
```
the output is
```html
<script src="test.js" id="test" crossorigin="anonymous" data-test="test" defer="false" data-nscript="afterInteractive"></script>
```

### Expected Behavior

`defer` and `crossorigin` attributes are not changed based on strategy

### To Reproduce

I created [a repository](https://github.com/albertodeago/next-script-bug-repro) to reproduce it easily.
Just clone it, `npm run dev`, and open localhost:3000

In the console two scripts are being printed, the two have the same attributes except for the strategy.
Repository: storybook
Issue: process.env is empty since 6.4.10
Labels: bug,has workaround,core

**Describe the bug**
At runtime, inside of a story, we need access to a (subset of) process.env to pass some values from the buildserver onto Storybook, and ultimately the application proper.

In Storybook 6.4.9 this worked fine.
In Storybook 6.4.10 this got broken. `process.env` is now `{ }`.
In Storybook 6.4.14 this is not fixed, unfortunately.

Neither env variables from the CLI are passed, nor variables from `.env`. We use both, and neither end up in `process.env`.

Is it possible that #17174 broke this? That one is the only fix that remotely seems to have anything to do with `process.env`, assuming the changelog is complete.

**To Reproduce**
I'm not sure what has been done to get this to work in the first place, or whether this is standard functionality. I do see `dotenv` being exported from `paths.js`, but it's really difficult to dig into Storybook to see what it's doing with that, if anything.

**System**
```
Environment Info:

  System:
    OS: Windows 10 10.0.19043
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
  Binaries:
    Node: 16.13.2 - C:\Program Files\nodejs\node.EXE
    npm: 8.3.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 97.0.4692.99
    Edge: Spartan (44.19041.1266.0), Chromium (97.0.1072.62)
  npmPackages:
    @storybook/addon-a11y: 6.4.10 => 6.4.10
    @storybook/addon-actions: 6.4.10 => 6.4.10
    @storybook/addon-controls: 6.4.10 => 6.4.10
    @storybook/addon-docs: 6.4.10 => 6.4.10
    @storybook/addons: 6.4.10 => 6.4.10
    @storybook/preset-create-react-app: 3.2.0 => 3.2.0
    @storybook/react: 6.4.10 => 6.4.10
    @storybook/theming: 6.4.10 => 6.4.10
```
Repository: flutter
Issue: [Desktop] Windows tablet mode has no bottom inset when the soft keyboard is visible
Labels: framework,platform-windows,a: desktop,has reproducible steps,P2,found in release: 2.8,found in release: 2.10,team-windows,triaged-windows

**1. run this code in windows tablet mode**
```dart
import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(const App());
}

class App extends StatefulWidget {
  const App({Key? key}) : super(key: key);

  @override
  State<App> createState() => _AppState();
}

class _AppState extends State<App> with WidgetsBindingObserver {
  @override
  void initState() {
    WidgetsBinding.instance?.addObserver(this);
    super.initState();
  }

  @override
  void dispose() {
    WidgetsBinding.instance?.removeObserver(this);
    super.dispose();
  }

  @override
  void didChangeMetrics() {
    final window = WidgetsBinding.instance?.window;
    if (window == null) return;

    final insets = EdgeInsets.fromWindowPadding(
      window.viewInsets,
      window.devicePixelRatio,
    );
    debugPrint('insets1: $insets');

    super.didChangeMetrics();
  }

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Builder(
        builder: (context) {
          final insets = MediaQuery.of(context).viewInsets;
          debugPrint('insets2: $insets');

          return const CupertinoTextField(
            autofocus: true,
            placeholder: 'please open soft keyboard',
            placeholderStyle: TextStyle(color: Colors.black),
          );
        },
      ),
    );
  }
}
```

**2. open the soft keyboard**


**result**: the output inset1 and inset2 are all EdgeInsets.zero
**expect**: the bottom inset should have a value, which equals to the soft keyboard height
Repository: vscode
Issue: Outline is empty when using Split JSON mode for settings editor
Labels: bug,settings-editor,confirmed

Issue Type: <b>Bug</b>

1. Set `"workbench.settings.useSplitJSON": true`
2. Open JSON settings editor
3. :bug: Outline view is empty

![image](https://user-images.githubusercontent.com/6726799/151152941-195e5ddb-1f50-44e0-ae06-b2fda87c75e9.png)

4. Set `"workbench.settings.useSplitJSON": false` or delete the line from settings.json, save, close editor and reopen it.
5. Outline view shows JSON outline as expected.

VS Code version: Code - Insiders 1.64.0-insider (45060913204279d4ecfe0575ca69d68211fb3798, 2022-01-26T05:17:50.284Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No


<!-- generated by issue reporter -->
Repository: flutter
Issue: [InteractiveViewer]: When pan or scale is performed, only position is changed while size of the child remains same. 
Labels: framework,f: material design,has reproducible steps,found in release: 2.8,found in release: 2.9,team-design,triaged-design

When pan or scale is performed on an InteractiveViewer widget, the positions of its child widget will change, while the sizes keep the same. Here we use RenderBox to get widget's size and location. 

Here is an example demonstrating this behaviour.

[https://dartpad.dev/?id=d826dd341fa43709ef41a44debab7520](https://dartpad.dev/?id=d826dd341fa43709ef41a44debab7520)

Output sample
`
inner Offset(176.6, 303.1), outer Offset(-9.0, -11.4)
inner Size(500.0, 300.0), outer Size(861.0, 912.0)
inner Offset(176.6, 303.1), outer Offset(-9.0, -11.4)
inner Size(500.0, 300.0), outer Size(861.0, 912.0)
inner Offset(161.7, 292.3), outer Offset(-42.9, -54.5)
inner Size(500.0, 300.0), outer Size(861.0, 912.0)
inner Offset(161.7, 292.3), outer Offset(-42.9, -54.5)
inner Size(500.0, 300.0), outer Size(861.0, 912.0)
inner Offset(161.7, 292.3), outer Offset(-42.9, -54.5)
inner Size(500.0, 300.0), outer Size(861.0, 912.0)
inner Offset(161.7, 292.3), outer Offset(-42.9, -54.5)
`
Repository: godot
Issue: Vulkan: Add a bounce threshold to GPUParticles to skip bouncing if the velocity is too low
Labels: bug,topic:rendering,confirmed,topic:3d

### Godot version

v4.0.alpha.custom_build [d28944834]

### System information

Linux, Vulkan

### Issue description

The Particles are too bouncy, even on lower bounce settings, the only way to prevent this is by making them almost not bounce, which sucks.

this only happens on lower particle framerates, like 30, it's still horrible especially when it lags.

### Steps to reproduce

grab particles, make them bouncy

### Minimal reproduction project

[TooBouncy.zip](https://github.com/godotengine/godot/files/7941617/TooBouncy.zip)


and a video


https://user-images.githubusercontent.com/85245131/151161998-35437f09-2a23-48ff-a452-9c19fda53940.mp4

(it's actually an .avi, but gitshit doesn't upload it with .avi instead of .mp4)

### Fix

make a bounce threshold that makes particles stop bouncing completely when they don't bounce much anymore

example:

some particle is .01 bouncy

make it 0 bouncy
Repository: godot
Issue: Vulkan: GPUParticles Bounce is tied to Fixed Fps
Labels: bug,topic:rendering,documentation

### Godot version

v4.0.alpha.custom_build [d28944834]

### System information

Linux, Vulkan

### Issue description

The Particle bounces are locked to framerate

and the difference it huge

### Steps to reproduce

change particle framerate and bouncyness 1 big difference

### Minimal reproduction project

[TooBouncy.zip](https://github.com/godotengine/godot/files/7941686/TooBouncy.zip)

(wait 5 secs for them to spread, left is 30, right is unlocked framerate)
Repository: pytorch
Issue: Regression in multi-node training speed with Transformers + PyTorch
Labels: high priority,triage review,oncall: distributed,triaged,module: regression,module: ddp

### 🐛 Describe the bug

We have seen a regression in multi-node training speed with the [Huggingface Transformers CLM test case](https://github.com/huggingface/transformers/blob/master/examples/pytorch/language-modeling/run_clm.py) happening at PyTorch commit [38ac9e6](https://github.com/pytorch/pytorch/commit/38ac9e6) which reverts commit [3957ed4](https://github.com/pytorch/pytorch/commit/3957ed4) "[DDP] Disable reducer hooks from running outside of DDP backwards". Between those two commits I get around 28 `train_samples_per_second` (as reported by the CLM test) using two nodes with 4xNVIDIA A100 GPUs each. Afterwards speed drops to around 10 `train_samples_per_second`. This can be reliably reproduced every time.

My testing script can be found here, although it's a bit difficult to reproduce at it requires building the singularity containers and a cluster with at least two nodes: https://github.com/mvsjober/pytorch-clm-test-case/blob/main/pytorch_clm_test.sh

The PyTorch container has been created with [this build recipe](https://github.com/mvsjober/pytorch-clm-test-case/blob/main/pytorch_git_custom.def). It's a CentosOS 7.7 image with CUDA 11.1, cuDNN 8.1.0, NCCL 2.8.4.

### Versions

Collecting environment information...
PyTorch version: 1.10.0a0+git38ac9e6
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: CentOS Linux 7 (Core) (x86_64)
GCC version: (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2)
Clang version: Could not collect
CMake version: version 2.8.12.2
Libc version: glibc-2.17

Python version: 3.8.11 (default, Sep  1 2021, 12:33:46)  [GCC 9.3.1 20200408 (Red Hat 9.3.1-2)] (64-bit runtime)
Python platform: Linux-3.10.0-1160.41.1.el7.x86_64-x86_64-with-glibc2.2.5
Is CUDA available: True
CUDA runtime version: 11.3.109
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/lib64/libcudnn.so.8.1.0
/usr/lib64/libcudnn_adv_infer.so.8.1.0
/usr/lib64/libcudnn_adv_train.so.8.1.0
/usr/lib64/libcudnn_cnn_infer.so.8.1.0
/usr/lib64/libcudnn_cnn_train.so.8.1.0
/usr/lib64/libcudnn_ops_infer.so.8.1.0
/usr/lib64/libcudnn_ops_train.so.8.1.0
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.1
[pip3] torch==1.10.0a0+git38ac9e6
[pip3] torchaudio==0.9.1
[pip3] torchtext==0.10.1
[pip3] torchvision==0.10.1+cu111
[conda] Could not collect


cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @jbschlosser @bhosmer @cpuhrsch
Repository: rust
Issue: impl trait error does not explain its reasoning
Labels: A-diagnostics,T-compiler,A-impl-trait

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1497daa8a96b61decc37bed908eec352

```rust
use std::fmt::Display;

trait Foo {
    type Bar;
}

impl Foo for () {
    type Bar = Vec<i32>;
}

fn foo() -> impl Foo<Bar = impl Display> {
    ()
}
```

The current output is:

```
error[E0277]: `Vec<i32>` doesn't implement `std::fmt::Display`
  --> src/main.rs:11:13
   |
11 | fn foo() -> impl Foo<Bar = impl Display> {
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Vec<i32>` cannot be formatted with the default formatter
   |
   = help: the trait `std::fmt::Display` is not implemented for `Vec<i32>`
   = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
```

Ideally the output should look like:

```
error[E0277]: `Vec<i32>` doesn't implement `std::fmt::Display`
  --> src/main.rs:11:13
   |
11 | fn foo() -> impl Foo<Bar = impl Display> {
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Vec<i32>` cannot be formatted with the default formatter
   |
   = help: the trait `std::fmt::Display` is not implemented for `Vec<i32>`
   = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
note: required due to associated type of `impl Foo for ()`
   | 
 9 |     type Bar = Vec<i32>;
   |                ^^^^^^^^
```