sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Track widget objects that reference large chunks of memory
Labels: framework,c: performance,f: inspector,d: devtools,perf: memory,P3,team-framework,triaged-framework

Widgets per se do not have lifecycles - they're purely configuration for elements.

Nevertheless, some widgets can embed large items of memory, and without any lifecycle to reason about developers may become surprised or confused about how long a widget they think they are not using survives. A simple example from the framework is `Image.memory`, but a truly trivial example is

```
class BigWidget extends StatelessWidget {
  final List<int> myList = List<int>.filled(1000000, 1);

  @override
  Widget build(BuildContext context) {
    return const SizedBox(width: 10, height: 10);
  }
}
```

We should surface information about this and attempt to track it in devtools. Ideally, we should try to figure out ways to capture whether such widgets are widgets the developer would even want to keep in memory. We may also want to encourage developers using such widgets to offload the larger data structures to stateful widgets so they can release the memory when disposed.

/cc @jacob314 @terrylucas @goderbauer
Repository: pytorch
Issue: Error building docker image: No module named 'typing_extensions'
Labels: module: build,triaged,module: docker

## 🐛 Bug

I'm trying to build a docker image myself follow [these instructions](https://github.com/pytorch/pytorch#building-the-image-yourself) and it's failing with `ModuleNotFoundError typing_extensions`.
 
## To Reproduce

On a clean ubuntu 20.04 machine with the current head 96655e2b81765d94c359a5dc079ec00404244184 I run:

```
git clone https://github.com/pytorch/pytorch
cd pytorch
make -f docker.Makefile
```

and it fails with

```
#24 10.94 INFO CUPTI_INCLUDE_DIR = /usr/local/cuda/include
#24 10.94 -- Configured Kineto
#24 10.94 -- GCC 7.5.0: Adding gcc and gcc_s libs to link line
#24 10.94 -- Performing Test HAS_WERROR_FORMAT
#24 11.02 -- Performing Test HAS_WERROR_FORMAT - Success
#24 11.02 -- Performing Test HAS_WERROR_CAST_FUNCTION_TYPE
#24 11.05 -- Performing Test HAS_WERROR_CAST_FUNCTION_TYPE - Failed
#24 11.05 -- Looking for backtrace
#24 11.11 -- Looking for backtrace - found
#24 11.11 -- backtrace facility detected in default set of libraries
#24 11.11 -- Found Backtrace: /usr/include  
#24 11.11 -- don't use NUMA
#24 11.13 -- Performing Test COMPILER_SUPPORTS_NO_AVX256_SPLIT
#24 11.20 -- Performing Test COMPILER_SUPPORTS_NO_AVX256_SPLIT - Success
#24 11.24 Traceback (most recent call last):
#24 11.24   File "/opt/conda/lib/python3.7/runpy.py", line 193, in _run_module_as_main
#24 11.24     "__main__", mod_spec)
#24 11.24   File "/opt/conda/lib/python3.7/runpy.py", line 85, in _run_code
#24 11.24     exec(code, run_globals)
#24 11.24   File "/opt/pytorch/tools/codegen/gen.py", line 3, in <module>
#24 11.24     from typing_extensions import Literal
#24 11.24 ModuleNotFoundError: No module named 'typing_extensions'
#24 11.24 -- 
#24 11.24 CMake Error at cmake/Codegen.cmake:213 (message):
#24 11.24   Failed to get generated_cpp list
#24 11.24 Call Stack (most recent call first):
#24 11.24   caffe2/CMakeLists.txt:2 (include)
#24 11.24 
#24 11.24 
#24 11.26 -- Configuring incomplete, errors occurred!
```



## Expected behavior

Successfully builds docker image.  If I roll back to 57bffc3a8e4fee0cce31e1ff1f662ccf7b16db57 (1.7.1) this works.

## Environment

 - PyTorch Version (e.g., 1.0): n/a
 - OS (e.g., Linux): Ubuntu 20.04: `Linux ip-172-31-54-78 5.4.0-1038-aws #40-Ubuntu SMP Fri Feb 5 23:50:40 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux`
 - How you installed PyTorch (`conda`, `pip`, source): have not yet
 - Build command you used (if compiling from source): `make -f docker.Makefile`
 - Python version: docker.Makefile is configured for py3.7
 - CUDA/cuDNN version: none
 - GPU models and configuration: none
 - Any other relevant information: instance is aws c5a.2xl
- Docker version 19.03.8, build afacb8b7f0

## Additional context

My goal in building from source is to get a docker image that I can use with an old GPU per https://github.com/pytorch/pytorch/issues/31285


cc @malfet @seemethere @walterddr
Repository: pytorch
Issue: Have the ability to disable `__torch_function__` dispatch for torch.nn.functional functions
Labels: module: nn,triaged,module: __torch_function__

`torch.nn.Module` instances and `torch.` namespace ops represent a pretty good split between high-level (stateful) blocks and low-level (stateless) operations. `torch.nn.functional` calls seem to just get in the way in the vast majority of cases that I've seen. The fact that these participate in `__torch_function__` makes this weird middle-layer of abstraction that cannot be easily skipped. I can't even figure out how to skip them manually in a `__torch_function__` handler, we can't redispatch into the functional with a layer of tensor-like objects stripped because then we wouldn't get the calls inside the functional (but not the functional itself). Can we have some way to turn off dispatching to `__torch_function__` for `torch.nn.functional` calls?

(Additionally there's a separate issue where `torch.nn.functional` calls have this icky TorchScript `boolean_dispatch` thing

cc @hameerabbasi @rgommers @peterbell10 @albanD @mruberry @jbschlosser
Repository: rust
Issue: Switch `#[derive(PartialEq)]` to have separate lhs and rhs lifetimes
Labels: C-enhancement,A-lifetimes,A-macros,T-libs-api

As far as I can tell the following code shouldn't cause a lifetime error but it does. If `Iter::Item` is changed to `&'a ()` instead of `PhantomData<&'a ()>` the error goes away.

```rust
use core::marker::PhantomData;

fn g<A: Iterator, B: Iterator>(a: A, b: B) -> A
where
    A::Item: PartialEq<B::Item>,
{
    todo!()
}

pub struct Iter<'a>(&'a ());

impl<'a> Iterator for Iter<'a> {
    type Item = PhantomData<&'a ()>;
    fn next(&mut self) -> Option<Self::Item> {
        todo!()
    }
}

pub fn f<'a, B: AsRef<()>>(a: &'a (), b: B) -> &'a () {
    g(Iter(a), Iter(b.as_ref())).0
}

```

([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d27af5bf15b5ca4328b034316ef4aa64))

Errors:

```
   Compiling playground v0.0.1 (/playground)
error[E0309]: the parameter type `B` may not live long enough
  --> src/lib.rs:20:21
   |
19 | pub fn f<'a, B: AsRef<()>>(a: &'a (), b: B) -> &'a () {
   |              -- help: consider adding an explicit lifetime bound...: `B: 'a +`
20 |     g(Iter(a), Iter(b.as_ref())).0
   |                     ^ ...so that the type `B` is not borrowed for too long

error[E0309]: the parameter type `B` may not live long enough
  --> src/lib.rs:20:23
   |
19 | pub fn f<'a, B: AsRef<()>>(a: &'a (), b: B) -> &'a () {
   |              -- help: consider adding an explicit lifetime bound...: `B: 'a +`
20 |     g(Iter(a), Iter(b.as_ref())).0
   |                       ^^^^^^ ...so that the reference type `&B` does not outlive the data it points at

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0309`.
error: could not compile `playground`

To learn more, run the command again with --verbose.

```
Repository: pytorch
Issue: More AVX2 vectorization support for half (float16)
Labels: triaged,module: vectorization,module: half

## ❓ Questions and Help

Hello,

Currently, PyTorch has less AVX2 support for `float16`  in [`aten/src/ATen/cpu/vec256`](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/cpu/vec256/), than it does for `bfloat16`.
It's evident by the fact that `vec256_half.h` or `vec256_float16.h` doesn't exist.

In `vec256_bfloat16.h`, computations are performed after converting `BFloat16` to `Float`.
Please advise if similar `float16` AVX2 vectorization support can be added by simply using AVX2 intrinsics such as `_mm256_cvtps_ph` and `_mm256_cvtph_ps()`, or if it would entail some more intricate computation.
Caffe2 also seems to be using these AVX2 intrinsics for `float16`.

`float16` <-> `float` conversion seems to have lower latency than the `bfloat16` <-> `float` conversion techniques used in `aten/src/ATen/cpu/vec256/vec256_bfloat16.h`. So, is it worth adding `aten/src/ATen/cpu/vec256_half.h` that corresponds to [`aten/src/ATen/cpu/vec256/vec256_bfloat16.h`](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/cpu/vec256/vec256_bfloat16.h)?

I'm not implying in any manner that `float16` is better, but only that it might be worth adding `pytorch/aten/src/ATen/cpu/vec256/vec256_half.h` that corresponds to `pytorch/aten/src/ATen/cpu/vec256/vec256_bfloat16.h`.

Thank you!

cc @mingfeima @leslie-fang-intel @jgong5 @Jianhui-Li @malfet @ezyang @ngimel @kimishpatel
Repository: pytorch
Issue: Errors occur when operating broadcast with error log: Got completion with error 12, opcode 1, len 32547, vendor err 129
Labels: oncall: distributed,triaged

## 🐛 Bug
Errors occur when operating broadcast in pytorch v1.6.1 with nccl v2.7.8 as backend and set NCCL_BLOCKING_WAIT=1. There is 8 gpus in 1 docker and the rank0 broadcast tensor to other rank. Rank0 dump error logs:
```shell
tb2b07342:9298:11152 [0] transport/net_ib.cc:818 NCCL WARN NET/IB : Got completion with error 12, opcode 1, len 32602, vendor err 129
tb2b07342:9298:11152 [0] NCCL INFO include/net.h:28 -> 2
tb2b07342:9298:11152 [0] NCCL INFO transport/net.cc:357 -> 2
tb2b07342:9298:11152 [0] NCCL INFO proxy.cc:198 -> 2 [Proxy Thread]
```
and rank1 dump error logs:
```shell
-- Process 1 terminated with the following error:
Traceback (most recent call last):
  File "/miniconda3/envs/pytorch_esl1.6.0/lib/python3.7/site-packages/torch/multiprocessing/spawn.py", line 20, in _wrap
    fn(i, *args)
  File "/dev/shm/accl_test/pytorch_test/src/btry.py", line 34, in BroadcastWorker
    dist.broadcast(objects, src=0, async_op = False)
  File "/miniconda3/envs/pytorch_esl1.6.0/lib/python3.7/site-packages/torch/distributed/distributed_c10d.py", line 919, in broadcast
    work.wait()
RuntimeError: NCCL error: unhandled system error, NCCL version 2.7.8
```

## Test code
```python
def BroadcastWorker(gpuid, master_ip, master_port):
    dist_url = "tcp://{}:{}".format(master_ip, master_port)
    torch.cuda.set_device(gpuid)
    dist.init_process_group(backend="nccl", init_method=dist_url, world_size=8, rank=gpuid)

    data = list(range(2))
    if dist.get_rank() == 0:
        objects = torch.tensor(data, dtype=torch.int32).cuda()
    else:
        objects = torch.empty(size, dtype=torch.int32).cuda()
    data = torch.tensor(data, dtype=torch.int32)

    dist.broadcast(objects, src=0, async_op = False)

if __name__ == '__main__':
    master_ip=xx.xx.xx.xx
    master_ip=xxxxx
    mp.spawn(BroadcastWorker, nprocs=8, args=(master_ip, master_port))
```

some flowing code can fix this issue like:
1. dist.barrirer() in the end of function BroadcastWorker
2. time.sleep(5) in rank0 after operating broadcast.
3. **NCCL_BLOCKING_WAIT=0**

## Expected behavior

No issue happen and tensor can be broadcast from rank0 to rank1 - rank7

## Environment
 - PyTorch Version (e.g., 1.0):1.6.0
 - OS (e.g., Linux): CentOS 7.2
 - How you installed PyTorch (`conda`, `pip`, source):source
 - Build command you used (if compiling from source):
 ```shell
 USE_DISTRIBUTED=1 USE_LMDB=1 TORCH_NVCC_FLAGS="-Xfatbin -compress-all" BUILD_TEST=0 CMAKE_BUILD_PARALLEL_LEVEL=32 USE_SYSTEM_NCCL=1 USE_FBGEMM=0 python setup.py bdist_wheel
```
 - Python version: 3.7.6
 - CUDA/cuDNN version: 10.1.243
 - NCCL version: nccl-repo-rhel7-2.7.8-ga-cuda10.1-1-1.x86_64


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: flutter
Issue: [desktop] sogou input window can't track textfield cursor position
Labels: a: text input,engine,a: internationalization,platform-windows,a: desktop,has reproducible steps,P2,found in release: 2.0,found in release: 2.1,team-windows,triaged-windows

<!-- 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
-->

## Steps to Reproduce

<!-- You must include full steps to reproduce so that we can reproduce the problem. -->

1. Run `flutter create bug`.
2. Update the files as follows: ... <!-- include every file that is different from the template app! -->
3. ... <!-- describe how to reproduce the problem -->

**Expected results:** <!-- what did you want to see? -->

**Actual results:** <!-- what did you see? -->

<details>
  <summary>Logs</summary>

<!--
      Run your application with `flutter run --verbose` and attach all the
      log output below between the lines with the backticks. If there is an
      exception, please see if the error message includes enough information
      to explain how to solve the issue.
-->

```
```

<!--
     Run `flutter analyze` and attach any output of that command below.
     If there are any analysis errors, try resolving them before filing this issue.
-->

```
```

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
```

</details>
Repository: pytorch
Issue: [DOC] Incorrect image for the confusion matrix
Labels: module: docs,module: rnn,triaged

## 📚 Documentation

See https://pytorch.org/tutorials/intermediate/char_rnn_classification_tutorial

The displayed image
https://pytorch.org/tutorials/_images/sphx_glr_char_rnn_classification_tutorial_002.png
![](https://pytorch.org/tutorials/_images/sphx_glr_char_rnn_classification_tutorial_002.png)
does not match its description:

> You can pick out bright spots off the main axis that show which languages it guesses incorrectly, e.g. Chinese for Korean, and Spanish for Italian. It seems to do very well with Greek, and very poorly with English (perhaps because of overlap with other languages).

---

The correct image can be found at
https://github.com/spro/practical-pytorch/blob/master/char-rnn-classification/char-rnn-classification.ipynb

![image](https://user-images.githubusercontent.com/5284924/113830590-5a05b700-97b9-11eb-8060-ade5089e4094.png)


cc @brianjo @mruberry @zou3519
Repository: go
Issue: x/exp/apidiff: interface compatible assumption may be wrong
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.14.10 windows/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
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\x00371158\AppData\Local\go-build
set GOENV=C:\Users\x00371158\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS= -mod=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=D:\goproject
set GOPRIVATE=
set GOPROXY=https://goproxy.io,direct
set GOROOT=D:\go1.14
set GOSUMDB=off
set GOTMPDIR=
set GOTOOLDIR=D:\go1.14\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\xuxinhao\gana\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\X00371~1\AppData\Local\Temp\go-build498719130=/tmp/go-build -gno-record-gcc-switches
</pre></details>

### What did you do?

old package
```
type i interface {
	b()
}

type I interface {
	A()
	i
}

type X struct {

}

func (x X) b() {
}
```

if we change the I definition to this(adding a B() method), new package:
```
type i interface {
	b()
}

type I interface {
	A()
	B()
	i
}

type X struct {

}

func (x X) b() {
}
```

client code
```
type Impl struct {
	apidiff.X
}

func (i Impl) A() {
}

func TestAssert(t *testing.T)  {
	var a apidiff.I = Impl{}
	fmt.Println(a)
}
```



### What did you expect to see?
Incompatible changes


### What did you see instead?
```
Compatible changes:
- I.B: added
```

in the readme of this package, [here](https://pkg.go.dev/golang.org/x/exp/apidiff#readme-checking-go-package-api-compatibility), it says:
> Interfaces
> A new interface is compatible with an old one if and only if:
> 1. The old interface does not have an unexported method, and it corresponds to the new interfaces (i.e. they have the same method set), or
> 2. The old interface has an unexported method and the new exported method set is a superset of the old.

> Rule 2 is based on the observation that if an interface has an unexported method, the only way a client can implement it is to embed it. Adding a method is compatible in this case, because the embedding struct will continue to implement the interface. Adding a method also cannot break any call sites, since no program that compiles could have any such call sites.

in my example, this assumption is wrong.
Repository: rust
Issue: rustc segfaults on small program using rayon
Labels: I-crash,A-LLVM,T-compiler,C-bug


### Code

The attached tarball has two versions of my program, reduced as much as I can. In the `build` subdirectory the program works fine. In `fails` building it causes a segfault. In both, build command was `cargo build`. This is entirely reproducible for me.

[rustc-bug.tar.gz](https://github.com/rust-lang/rust/files/6269897/rustc-bug.tar.gz)

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.51.0 (2fd73fabe 2021-03-23)
binary: rustc
commit-hash: 2fd73fabe469357a12c2c974c140f67e7cdd76d0
commit-date: 2021-03-23
host: x86_64-unknown-linux-gnu
release: 1.51.0
LLVM version: 11.0.1

```

### Error output

```
10:25 exolobe1:~/tmp/rustc-bug $ cd builds/
10:25 exolobe1:~/.../builds $ cargo build -q
10:25 exolobe1:~/.../builds $ cd ../fails/
10:26 exolobe1:~/.../fails $ cargo build -q
warning: field is never read: `data`
  --> src/main.rs:24:5
   |
24 |     data: [u8; SIZE],
   |     ^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

error: could not compile `checksum-concurrency`

Caused by:
  process didn't exit successfully: `rustc --crate-name checksum_concurrency --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=bb6d00e4307bf22c -C extra-filename=-bb6d00e4307bf22c --out-dir /home/liw/tmp/rustc-bug/fails/target/debug/deps -C incremental=/home/liw/tmp/rustc-bug/fails/target/debug/incremental -L dependency=/home/liw/tmp/rustc-bug/fails/target/debug/deps --extern rayon=/home/liw/tmp/rustc-bug/fails/target/debug/deps/librayon-875aabede64e7eb2.rlib --extern sha2=/home/liw/tmp/rustc-bug/fails/target/debug/deps/libsha2-eb3b7d824c3f1ca0.rlib` (signal: 11, SIGSEGV: invalid memory reference)
[PREVIOUS COMMAND EXIT: 101]
10:48 exolobe1:~/.../fails $ 
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary><strong>Backtrace</strong></summary>
<p>
```
No backtrace.
</p>
</details>
Repository: PowerToys
Issue: Quick search layouts from keyboard
Labels: Idea-Enhancement,FancyZones-Editor,Product-FancyZones

## 📝 Provide a description of the new feature

_What is the expected behavior of the proposed feature?  What is the scenario this would be used?_

After using a hotkey to open the layout picker I would like to continue using the keyboard to select the new layout and confirm.

**Quick search**

After pressing the hotkey for layout selection the next keypresses should be added to a quick search.

1. Press layout hotkey
2. Press the first letters in the layout name (the best match is highlighted)
3. Press enter to confirm and close.

![image](https://user-images.githubusercontent.com/505330/113836628-59572b80-978d-11eb-8fc3-f73eadbc2460.png)


---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: ant-design
Issue: 建议select，treeSelect 添加全选功能
Labels: 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.

### What problem does this feature solve?
It is recommended to add the all-selection function for select, treeSelect，建议在select, treeSelect中增加全选功能。当筛选后的数据量多项时，需要手动点击若干选项，建议新增全选功能，以及筛选后全选

### What does the proposed API look like?
新增api提供开关


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: go
Issue: net: Conn.Close() does not error on double close on wasm
Labels: NeedsInvestigation,arch-wasm

### Does this issue reproduce with the latest release?

Yes

### What did you do?

Tried to write a test that checks whether a `net.Conn` is already closed by checking that calling `Close` returns an error and run it on wasm. See https://github.com/golang/go/blob/5d5f779db40528faa82e16c361691864dc80975b/src/crypto/tls/handshake_server_test.go#L1980-L1982 for the current workaround.

### What did you expect to see?

An error suggesting that the connection has already been closed, as is consistent with all other architectures tested.

### What did you see instead?

No error.

### Discussion

I think the offending code is here: https://github.com/golang/go/blob/5d5f779db40528faa82e16c361691864dc80975b/src/net/net_fake.go#L110-L115

On unix platforms the behaviour is to return `internal/poll.ErrNetClosing` or `internal/pool.ErrFileClosing`:

https://github.com/golang/go/blob/5d5f779db40528faa82e16c361691864dc80975b/src/internal/poll/fd_unix.go#L93-L96
https://github.com/golang/go/blob/5d5f779db40528faa82e16c361691864dc80975b/src/internal/poll/fd.go#L42-L47