sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Composing region does not extend while typing on Android emulator
Labels: a: text input,platform-android,framework,P2,team-android,triaged-android

### Issue
While typing in a Flutter `TextField` on an Android emulator using the software keyboard, when adding to the front of a pre-existing word, the composing region only includes the newly added text. On Android, the composing region extends to include both the newly added text and the rest of the pre-existing word. This same behavior can be observed when typing in Flutter on a hardware keyboard. See below:

| Flutter (software keyboard)      | Flutter (hardware keyboard)/Expected Android behavior |
| :-----: | :-----: |
|  ![issue_crtf_3](https://user-images.githubusercontent.com/43054281/166557964-07a067cc-80a5-4744-9954-77d10967c86e.gif) | ![crtf_issue_demo_2](https://user-images.githubusercontent.com/43054281/166557627-e5ec76f9-f42a-4ac1-b1f0-0da58d210032.gif) |  

### Reproduction steps

1. Run an app with a `TextField` such as one with the following code:
<details>
<summary>Reproduction code</summary>
<br>

```
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      title: 'Flutter Demo',
      home: MyHomePage(title: 'SC Demo'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: const Center(
        child: TextField(),
      ),
    );
  }
}
```

</details>



2. Type a word, then move the cursor back to the beginning of this word.
3. Add new text at this position and observe the composing underline only highlight the newly added text.
Repository: flutter
Issue: Make `Theme` a UbiquitousInheritedWidget
Labels: framework,f: material design,c: proposal,team-design,triaged-design

In https://github.com/flutter/flutter/pull/102336 we introduced the idea of the `_UbiquitousInheritedWidget` for `Directionality` which makes a tradeoff between faster build performance versus worse update performance.  I think we should consider moving `Theme` over to `UbiquitousInheritedWidget` as well.  All my other attempts to increase the speed of `InheritedWidget` have not panned out.

Reasons for migrating `Theme`:

1) `Theme.of` is the second most used caller of `dependOnInheritedWidget` in `build_bench.dart`
1) `customer:money` is seeing 16.7ms in `Theme.of` at startup, which isn't huge but is an easy win.
1) `InheritedWidget`s are consistently showing up as performance bottlenecks across different attempts to profile.
1) Profiling Flutter Gallery and clicking through the Material pages also identified `Theme` as the most used InheritedWidget.
1) `Theme`'s scope is so large, that changing one thing will likely cause may widgets to reload anyway (lowering the price difference in the update algorithm)
1) Theme data probably isn't changing all that often anyway.

My major misgiving about doing this though is that it would require making `UbiquitousInheritedWidget` part of the public API which might confuse authors of `InheritedWidget`s.  I can't think of an alternative unless we wanted to duplicate the declaration.  We could potentially transition it to a flag in `InheritedWidget` instead of a subclass.  I'm not sure if that's more desirable.

What do you think @goderbauer @jonahwilliams ?
Repository: flutter
Issue: [flutter_tools] RPCError at new _OutstandingRequest at package:vm_service/src/vm_service.dart
Labels: c: crash,tool,platform-web,P2,team-web,triaged-web

on `beta/2.13.0-0.3.pre`, with command `flutter run -d chrome` on Windows 10

```
Thread 0 main threadRPCError: ext.flutter.debugDumpApp: (-32603) ext.flutter.debugDumpApp: Unexpected error from chrome devtools:text: Uncaught (in promise)exception:  description: null  type: string  value: Unexpected null value.attempted JS eval: `require("dart_sdk").developer.invokeExtension(    "ext.flutter.debugDumpApp", JSON.stringify({}));

#0      handleErrorIfPresent (package:dwds/src/utilities/shared.dart:97:5)
#1      ChromeProxyService.callServiceExtension (package:dwds/src/services/chrome_proxy_service.dart:351:5)
<asynchronous suspension>
#2      StackZoneSpecification._registerUnaryCallback.<anonymous closure> (package:stack_trace/src/stack_zone_specification.dart:125:47)
<asynchronous suspension>

at new _OutstandingRequest(vm_service.dart:1734)
at VmService._call(vm_service.dart:2245)
at VmService.callServiceExtension(vm_service.dart:2216)
at FlutterVmService._checkedCallServiceExtension(vmservice.dart:776)
at FlutterVmService.invokeFlutterExtensionRpcRaw(vmservice.dart:795)
at FlutterVmService.flutterDebugDumpApp(vmservice.dart:544)
at ResidentHandlers.debugDumpApp(resident_runner.dart:651)
at <asynchronous gap>(async)
at TerminalHandler.processTerminalInput(resident_runner.dart:1685)
at <asynchronous gap>(async)
```
Repository: neovim
Issue: Text getter/setter using character columns as the horizontal coordinate
Labels: enhancement,api

### Feature already in Vim?

N/A

### Feature description

As a plugin author, I often draw text into random-access locations in a buffer to create a TUI. Right now, the functions `nvim_buf_[get|set]_text` use byte offsets for the horizontal coordinates. As a result, if I want to put text into a certain character column, I need to keep track of the byte widths and display widths of the characters to the left of where I want to add text. This is pretty cumbersome. It would be useful to have utility functions that let me work in char-column-space rather than byte-space.
Repository: pytorch
Issue: Support Positional-only Arguments in JIT
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

From Python 3.8, we have positional-only arguments for function definition which gives a better control of code behaviors.
However, it seems that PyTorch (1.11) JIT (`torch.jit.script`) does not support it.
For instance, if we replace the example code
```python
import torch
@torch.jit.script
def foo(x, y):
    if x.max() > y.max():
        r = x
    else:
        r = y
    return r
```
to positional-only definition
```python
import torch
@torch.jit.script
def foo(x, y, /):
    if x.max() > y.max():
        r = x
    else:
        r = y
    return r
```
It will raise error:
```
RuntimeError: 
undefined value x:
  File "/scratch-data/gao462/Coding/Ray/fretboard.py", line 4
@torch.jit.script
def foo(x, y, /):
    if x.max() > y.max():
       ~ <--- HERE
        r = x
    else:
```
Can we support this in future update?

### Alternatives

_No response_

### Additional context

_No response_
Repository: go
Issue: x/tools/gopls: eagerly compute the workspace symbol index
Labels: gopls,Tools,gopls/performance

This is a spin-off of #52602, which we're going to close as just an optiimization.

In the future, we should go one step further and populate the workspace symbol index at load time. There's a straightforward way to do this: while type-checking we _always_ have access to the full AST of each package, before filtering. If we eagerly compute the symbol table at that time, it should be ~free.

However, I don't want to do this yet, because the cost of inheriting all these symbol handles on each generation is still too high, and our heuristic for which symbol handles to keep around is essentially "all of them", not just those that are reachable from workspace packages.

Once we have more control over snapshot data, we can re-consider this eager calculation.
Repository: material-ui
Issue: [IconButton][ClickAwayListener] Unexpected behavior depending on where button is clicked
Labels: bug 🐛,component: icon button,component: ClickAwayListener

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

When the child of a ClickAwayListener component is visible, and the user clicks on the SVG element (light blue in example) of an IconButton, the child hides as expected. In the same scenario if the user clicks on the ButtonBase element (dark blue) of the IconButton, the IconButton and ClickAwayListener events conflict and the child briefly starts to hide and immediately shows again.

### Expected behavior 🤔

The ClickAwayListener child should hide regardless of where the IconButton is clicked, similar to the behavior of non-IconButton example of ClickAwayListener - https://mui.com/material-ui/react-click-away-listener/

### Steps to reproduce 🕹

https://codesandbox.io/s/clickaway-material-demo-forked-uwoh3k?file=/demo.js

Steps:

1. Click menu icon to show child element
2. Click SVG element (light blue) of an IconButton, child hides
3. Click ButtonBase element (dark blue) of an IconButton, child doesn't hide
4. Uncomment conditional workaround to achieve expected(?) behavior


### Context 🔦

This seems like an unintended behavior/bug but please let me know if I'm missing something. The example is a simplified version of my code, a menu icon that toggles a menu wrapped in a ClickAwayListener. The commented out id check for the originating button solves the issue, but it doesn't seem like it should be necessary?

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  System:
    OS: macOS 12.3.1
  Binaries:
    Node: 16.14.2
    Yarn: 1.22.17
    npm: 8.1.4
  Browsers:
    Chrome: Not Found
    Edge: 100.0.1185.44
    Firefox: 91.0.1
    Safari: 15.4
  npmPackages:
    @emotion/react: ^11.8.2 => 11.8.2 
    @emotion/styled: ^11.8.1 => 11.8.1 
    @mui/base:  5.0.0-alpha.74 
    @mui/codemod: ^5.6.0 => 5.6.0 
    @mui/icons-material: ^5.5.1 => 5.5.1 
    @mui/lab: ^5.0.0-alpha.75 => 5.0.0-alpha.75 
    @mui/material: ^5.5.3 => 5.5.3 
    @mui/private-theming:  5.5.3 
    @mui/styled-engine:  5.5.2 
    @mui/styles: ^5.5.3 => 5.5.3 
    @mui/system:  5.5.3 
    @mui/types:  7.1.3 
    @mui/utils:  5.5.3 
    @types/react:  17.0.4 
    react: ^17.0.1 => 17.0.2 
    react-dom: ^17.0.1 => 17.0.2 
    typescript:  4.5.2 

```
</details>
Repository: pytorch
Issue: `torch.addmv` backward fails
Labels: module: autograd,triaged,module: complex,actionable

### 🐛 Describe the bug

`torch.addmv` backward fails when `input` is `float64`, `mat` and `vec` are `complex128`

```python
import torch
input = torch.rand([2], dtype=torch.float64, requires_grad=True)
mat = torch.rand([2, 3], dtype=torch.complex128, requires_grad=True)
vec = torch.rand([3], dtype=torch.complex128, requires_grad=True)

res = torch.addmv(input, mat, vec)
print("addmv SUCCEED!")

res_2 = res.sum()
print("sum SUCCEED!")

res_2.backward()
# addmv SUCCEED!
# sum SUCCEED!
# RuntimeError: Expected isFloatingType(grad.scalar_type()) || (input_is_complex == grad_is_complex) to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

However, when `input` is `complex128`, `mat` and `vec` are `float64`, it will succeed to backward

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @anjali411 @dylanbespalko @mruberry
Repository: pytorch
Issue: Strange warning from `matmul(..., out=...)`
Labels: triaged,module: linear algebra

### 🐛 Describe the bug

The torch.matmul `out=` parameter seems to reshape its parameter down to two dimensions, which leads to a strange UserWarning:
```
U = torch.randn(2, 4, 3)
W = torch.randn(3, 5)
temp = torch.empty((U @ W).shape)
torch.matmul(U, W, out=temp)
UserWarning: An output with one or more elements was resized since it had shape [2, 4, 5], which does not match the required output shape [8, 5].This behavior is deprecated, and in a future PyTorch release outputs will not be resized unless they have zero elements. You can explicitly reuse an out tensor t by resizing it, inplace, to zero elements with t.resize_(0). (Triggered internally at  /Users/distiller/project/pytorch/aten/src/ATen/native/Resize.cpp:24.)
  torch.matmul(U, W, out=temp)
```
It seems like `temp` tensor should clearly have the right shape [2, 4, 5] and not [8, 5] like the warning says.

### Versions

Collecting environment information...
PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.3.1 (x86_64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.3)
CMake version: version 3.21.4
Libc version: N/A

Python version: 3.9.12 (main, Apr 11 2022, 01:47:47)  [Clang 13.1.6 (clang-1316.0.21.2)] (64-bit runtime)
Python platform: macOS-12.3.1-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] functorch==0.1.1
[pip3] numpy==1.19.5
[pip3] torch==1.11.0
[pip3] torchvision==0.12.0
[conda] Could not collect


cc @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
Repository: pytorch
Issue: `gradcheck` should support the comparison of NaN
Labels: module: autograd,triaged,enhancement,actionable

### 🐛 Describe the bug

`gradcheck` should support the comparison of NaN, like adding an argument that whether `NaN == NaN` in the check.

```python
import torch
input = torch.rand([4], dtype=torch.float64, requires_grad=True)
torch.autograd.gradcheck(torch.acosh, (input))
# torch.autograd.gradcheck.GradcheckError: Jacobian mismatch for output 0 with respect to input 0,
# numerical:tensor([[nan, nan, nan, nan],
#         [nan, nan, nan, nan],
#         [nan, nan, nan, nan],
#         [nan, nan, nan, nan]], dtype=torch.float64)
# analytical:tensor([[nan, nan, nan, nan],
#         [nan, nan, nan, nan],
#         [nan, nan, nan, nan],
#         [nan, nan, nan, nan]], dtype=torch.float64)
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: flutter
Issue: [Proposal] Add `retry` to `testWidgets`
Labels: a: tests,c: new feature,framework,c: proposal,P3,team-framework,triaged-framework

Hi thanks for the framework! I notice that `testWidgets` has no `retry` flag while `test` has. Therefore, it is impossible to retry a flaky widget test (or integration test) while it is possible for a unit test.

The solution may be quite simple: Just forward that argument.
Repository: pytorch
Issue: `gradcheck` fails for `torch.trace`
Labels: module: autograd,triaged,actionable

### 🐛 Describe the bug

`gradcheck` fails for `torch.trace` when `dim1 > dim0 + 1`

```python
import torch
input = torch.rand([5, 3], dtype=torch.float64, requires_grad=True)

torch.autograd.gradcheck(torch.trace, (input))

# torch.autograd.gradcheck.GradcheckError: Jacobian mismatch for output 0 with respect to input 0,
# numerical:tensor([[1.0000],
#         [0.0000],
#         [0.0000],
#         [0.0000],
#         [1.0000],
#         [0.0000],
#         [0.0000],
#         [0.0000],
#         [1.0000],
#         [0.0000],
#         [0.0000],
#         [0.0000],
#         [0.0000],
#         [0.0000],
#         [0.0000]], dtype=torch.float64)
# analytical:tensor([[1.],
#         [0.],
#         [0.],
#         [0.],
#         [1.],
#         [0.],
#         [0.],
#         [0.],
#         [1.],
#         [0.],
#         [0.],
#         [0.],
#         [1.],
#         [0.],
#         [0.]], dtype=torch.float64)
```

I think the `numerical:tensor` is right since `dim0 = 3` and there are 3 elements of the diagonal. Plus, when `dim1 = 4`, it will succeed. 

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: flutter
Issue: PrerollContext.has_texture_layer is sticky and impacts layers unrelated to the TextureLayer
Labels: engine,waiting for PR to land (fixed),P2,team-engine,triaged-engine

Looking at the code in ContainerLayer::PrerollChildren, there are 2 flags that are accumulated on a subtree basis: has_platform_layer and has_texture_layer. The has_platform_layer flag appears to be accumulated within a subtree but only affects parents and ancestors. The has_texture_layer flag, however, is only ever set and never reset so once a layer is encountered it leads all future layers, including its siblings, its downstream cousins, and the entire tree that is visited after it to believe that they are part of a subtree that contains a TextureLayer.

The logic should be updated to match how has_platform_layer is accumulated.

Relevant source code: https://github.com/flutter/engine/blob/0b46116471cc0ad4bb5a4d2fa80a49061d1d4b0d/flow/layers/container_layer.cc#L136

The logic was introduced in https://github.com/flutter/engine/pull/23793
Repository: pytorch
Issue: `addr, baddmm, dist, l1_loss` will backward fail when input tensors have different dtypes
Labels: module: autograd,triaged,module: complex,actionable,complex_autograd

### 🐛 Describe the bug

`addr, baddmm, dist, l1_loss` will backward fail when input tensors have different dtypes

```python
import torch
input = torch.rand([3, 2], dtype=torch.float64, requires_grad=True)
vec1 = torch.rand([3], dtype=torch.float64, requires_grad=True)
vec2 = torch.rand([2], dtype=torch.complex128, requires_grad=True)

res = torch.addr(input, vec1, vec2)
res2 = res.sum()
res2.backward()
# RuntimeError: expected scalar type ComplexDouble but found Double
```

```python
import torch
results = dict()
input = torch.rand([10, 3, 5], dtype=torch.float64, requires_grad=True)
batch1 = torch.rand([10, 3, 4], dtype=torch.complex128, requires_grad=True)
batch2 = torch.rand([10, 4, 5], dtype=torch.complex128, requires_grad=True)

res = torch.baddbmm(input, batch1, batch2)
res2 = res.sum()
res2.backward()
# RuntimeError: Expected isFloatingType(grad.scalar_type()) || (input_is_complex == grad_is_complex) to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

```python
import torch
input = torch.rand([5, 3], dtype=torch.complex128, requires_grad=True)
other = torch.rand([5, 3], dtype=torch.float64, requires_grad=True)

res = torch.dist(input, other)
res.sum().backward()
# RuntimeError: Expected isFloatingType(grad.scalar_type()) || (input_is_complex == grad_is_complex) to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

```python
import torch
input = torch.rand([3, 5], dtype=torch.complex128, requires_grad=True)
target = torch.rand([3, 5], dtype=torch.float64, requires_grad=True)

res = torch.nn.functional.l1_loss(input, target)
res.backward()
# RuntimeError: result type ComplexDouble can't be cast to the desired output type Double
```

All of them succeed to forward but fail to backward. However, some other APIs will backward successfully even if input tensors have different dtypes, for example

```python
import torch
input = torch.rand([5, 3], dtype=torch.complex128, requires_grad=True)
other = torch.rand([5, 3], dtype=torch.float64, requires_grad=True)

res = torch.nn.functional.poisson_nll_loss(input, other)
res.sum().backward()
# succeed
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @anjali411 @dylanbespalko @mruberry
Repository: pytorch
Issue: `cumprod, prod` will backward fail if `dtype` argument is different than the dtype of input tensor
Labels: module: autograd,triaged,module: complex,complex_autograd

### 🐛 Describe the bug

`cumprod, prod` will backward fail if `dtype` argument is different than the dtype of input tensor

```python
import torch

def fn(input):
    dim = -1
    dtype = torch.complex128
    fn_res = torch.cumprod(input, dim, dtype=dtype)
    return fn_res
input = torch.rand([5, 5, 5], dtype=torch.float64, requires_grad=True)
fn(input).sum().backward()

# RuntimeError: Expected isFloatingType(grad.scalar_type()) || (input_is_complex == grad_is_complex) to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

```python
import torch
input = torch.rand([3, 3], dtype=torch.float64, requires_grad=True)
def fn(input):
    dtype = torch.complex64
    fn_res = torch.prod(input, dtype=dtype, )
    return fn_res

res = fn(input)
res.backward()
# RuntimeError: Expected isFloatingType(grad.scalar_type()) || (input_is_complex == grad_is_complex) to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @anjali411 @dylanbespalko @mruberry
Repository: create-react-app
Issue: Looking forward to official support for no eject extension react-scripts/webpack
Labels: issue: proposal,needs triage

### Extended configuration is required

When we create react app with create-react-app, we almost always need to extend more configurations ( react-scripts or webpack ), and we want to not eject to continuously upgrade react-scripts.

The current available methods are as follows, but they all have their own problems.

1. `npm run eject`

    Cannot upgrade the react-scripts.

2. Modify the react-scripts source under the node_modules, and then use the [patch-packages](https://github.com/ds300/patch-package)

    Cannot be maintained when upgrading react-scripts.

3. Using the `--scripts` parameter, extend the custom react-scripts

    It is too expensive to customize a react-scripts for a single project. 

4. Other programs in the community

    - [craco](https://github.com/gsoft-inc/craco)
    - [react-app-rewired](https://github.com/timarney/react-app-rewired)
    - [rescripts](https://github.com/harrysolovay/rescripts)
    - ......

    These programs are great, but there is no way for community support to continue. When there is a destructive update, such as CRA5. Almost can not follow up to support, or even be abandoned.

    For example, I used to like using [craco](https://github.com/gsoft-inc/craco). But, when CRA5 is released, because the update is too big, the original author did not have much time to maintain it, and this plan was almost abandoned ([LOOKING FOR A NEW TEAM TO LEAD CRACO](https://github.com/gsoft-inc/craco/issues/415)).

### Describe the solution you'd like

Expect that the official can support a method. Without eject, we can extend the configuration ( react-scripts/webpack ), support parameters can be merged into the webpackConfig.

If it can be supported, we can preset some configurations when we make a custom cra-template.