sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [Autofill] Switch to `SecSharedCredentials` on iOS, and explore how we can expose it in the framework
Labels: a: text input,c: new feature,platform-ios,framework,f: material design,a: internationalization,c: proposal,P2,team-design,triaged-design

## Use case

I work on a multi-platform e-commerce product that is available in several countries and has many associated domains. When using `AutofillGroup` as recommended by the [docs](https://api.flutter.dev/flutter/widgets/AutofillGroup-class.html) to save login/signup credentials for the first time, they get saved in association with the wrong domain. 

This is problematic because it can cause confusion to customers. To illustrate, consider the example below.

- Users from Germany access `company.de` on Safari and register their credentials using the keychain (which correctly associates these credentials with the `.de` domain).
- These users decide to access the product via the Flutter mobile App. When they try to log in on iOS, the keychain correctly identifies that the App has the `.de` associated domain and suggests the previously registered credentials.
- Users accept the suggestion and get their username/password auto-filled. 
- However, when pressing on the submission button, they are asked if they want to save new credentials because the **keychain is trying to store them in the wrong domain** (e.g. `company.ie`). 

_"If I have already saved my credentials for that product/service and nothing has changed, why am I being asked to save them again?"_

## Proposal

We need a way to **set which associated domain we want to use for storing credentials** with password managers and `AutofillGroup`

If a new user accesses the App with the `de_DE` locale, his/her credentials must be saved to the appropriate `company.de` domain instead of the other available options.
Repository: flutter
Issue: Select device category/type as flutter run subcommand
Labels: tool,c: proposal,a: annoyance,P3,team-tool,triaged-tool

As an extension to -d, it would be nice to have some easy to remember, easy to type high level subcommands to `flutter run` to point to specific device categories when flutter running.

- Running a naked `flutter run` is likely to bring up a slow target device selector to choose each time which adds friction.
- Even if you're a hobbyist and don't have 10 phones connected to your machine, it's still likely going to be exacerbated by the fact that going forward, chrome and macos etc will be permanently connected devices in your `flutter devices` list.
- Before running `flutter run`, you know what device type you want to target. You just likely don't remember what the device name/label is or its serial number. 
- `flutter run -d <device type>` is longer to type, and it often works, but sometimes don't. And when it doesn't occasionally, the loss of confidence makes you not use it. 

In the list below
```
Multiple devices found:
Pixel 3 (mobile)   • 8AXX11BS6                                • android-arm64  • Android 11 (API 30)
iPhone (mobile)    • cdcd493527f1f25a0ac91106540cf58186f2b4f0 • ios            • iOS 14.2
iPhone 12 (mobile) • 9E56D63B-8F4D-4110-A2AF-7D8F9BF8E54C     • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-2 (simulator)
macOS (desktop)    • macos                                    • darwin-x64     • Mac OS X 10.15.7 19H15 darwin-x64
Chrome (web)       • chrome                                   • web-javascript • Google Chrome 87.0.4280.88
[0]: Pixel 3 (8AXX11BS6)
[1]: iPhone (cdcd493527f1f25a0ac91106540cf58186f2b4f0)
[2]: iPhone 12 (9E56D63B-8F4D-4110-A2AF-7D8F9BF8E54C)
[3]: macOS (macos)
[4]: Chrome (chrome)
```

neither `flutter run -d android`, nor does `flutter run -d simulator` work despite there being only one of each being connected at a time. 

- Since Flutter is cross-platform, having more than 1 device of each type being connected may be less frequent.
Repository: flutter
Issue: Some tests should manually select the local engine variant
Labels: a: tests,c: new feature,tool,P2,team-tool,triaged-tool

See the discussion here https://github.com/flutter/flutter/pull/71721#issuecomment-743218994

@a-siva @mkustermann

@jonahwilliams who did some plumbing around this recently here https://github.com/flutter/flutter/pull/65802
Repository: opencv
Issue: Crash inside arithm_ipp_cmp8u
Labels: incomplete,needs reproducer

##### System information (version)

- OpenCV => 3.4.10
- Operating System / Platform => Ubuntu 16.04
- Compiler => gcc 5.4.0

##### Detailed description

We have a rare crash in our code. I don't have a way to repro it though. I just happens occasionally once every several day.
Here is a stacktrace I got:
<pre>
#0  0x00007fffea8c0ef7 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#1  0x00007fffea8c165d in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#2  0x000000000162da43 in backtrace_simple (state=<optimized out>, skip=skip@entry=3, callback=callback@entry=0x15169b0 <backtrace_simple_cb>, error_callback=error_callback@entry=0x15169e0 <backtrace_error_cb>, data=data@entry=0xc007c6d950) at simple.c:106
#3  0x0000000001516bde in cgo_traceback (arg=0xc007c6d970, arg@entry=<error reading variable: value has been optimized out>) at cgo_symbolizer.c:35
#4  0x000000000158d686 in x_cgo_callers (sig=23, info=0xc007c6daf0, context=0xc007c6d9c0, cgoTraceback=<optimized out>, cgoCallers=<optimized out>, sigtramp=0x8bf1a0 <runtime.sigtramp>) at gcc_traceback.c:22
#5  <signal handler called>
#6  0x00000000051446b3 in icv_y8_ownpi_CmpLT_8u_C1R ()
#7  0x0000000004ce336f in icv_y8_ippiCompare_8u_C1R ()
#8  0x0000000001896021 in cv::hal::arithm_ipp_cmp8u (cmpop=<error reading variable: Cannot access memory at address 0x384>, height=<error reading variable: Cannot access memory at address 0x390>, width=<error reading variable: Cannot access memory at address 0x410>, step=0, dst=0x37f45440 "", step2=<error reading variable: Cannot access memory at address 0x388>, src2=0x7fffabdc0730 "", step1=<error reading variable: Cannot access memory at address 0x3a0>, src1=0x2f6e1440 "") at /tmp/4shome_tmp/build/opencv/modules/core/src/arithm_ipp.hpp:286
#9  cv::hal::cmp8u (src1=0x2f6e1440 "", step1=<error reading variable: Cannot access memory at address 0x3a0>, src2=0x7fffabdc0730 "", step2=<error reading variable: Cannot access memory at address 0x388>, dst=0x37f45440 "", step=0, width=<error reading variable: Cannot access memory at address 0x410>, height=<error reading variable: Cannot access memory at address 0x418>, _cmpop=<error reading variable: Cannot access memory at address 0x420>) at /tmp/4shome_tmp/build/opencv/modules/core/src/arithm.simd.hpp:862
Backtrace stopped: Cannot access memory at address 0x408
</pre>
I noticed 3.4.12 includes https://github.com/opencv/opencv/pull/16236
Do you think this could be related?
I am testing with 3.4.12 now to see whether it helps. Will update later.
Repository: rust
Issue: asm!: lint on bare memory accesses without [] or offset
Labels: A-LLVM,C-enhancement,A-lints,A-inline-assembly,T-compiler,F-asm

In Intel syntax mode without prefixes, writing `mov rax, some_symbol` is equivalent to `mov rax, [some_symbol]`: in both cases it refers to the memory pointed to by the symbol. However, I've seen multiple people think the former syntax obtains the address of the symbol instead. (Referring to the address of the symbol requires `offset`, [which doesn't currently work in LLVM](https://github.com/rust-lang/rust/issues/79874).) This confusion can result in bugs that are quite difficult to debug.

I think it'd be appropriate, working in conjunction with a future version of LLVM's assembly parser, to catch "bare" uses of symbols, and suggest either adding `[]` around it to access the memory pointed to by the symbol, or adding `offset` to use the address of the symbol.
Repository: pytorch
Issue: A few years after #701 and PyTorch is still using implicit __all__ imports.
Labels: module: typing,triaged,module: pybind,better-engineering,module: codegen

A quick search for `import *` yields hundreds of results.
I think explicit imports would be beneficial for many reasons.

Excerpts from the 2017 issue I mentioned:

>i dont think we'll be fixing this. (i dont know if there's a way to do it either).

_Originally posted by @soumith in https://github.com/pytorch/pytorch/issues/701#issuecomment-329026903_

> > Maybe one could change `from torch._C import *` to `from torch._C import from_numpy, ...`?

> This seems simple enough. Are we certain this is the way to go? 
> I thought we'd need type hints (which would be way harder to convince people to use).
> Should we open another issue to discuss @moi90's solution?

_Originally posted by @cardoso-neto in https://github.com/pytorch/pytorch/issues/701#issuecomment-485272641_

If requested by a team member, I'd gladly do the tedious work replacing the import statements and pull requesting. :)
I would probably just need some pointers on how to do find out what is being imported from which C module, but I'd make quick work of it.
Long import statements could be indented very cleanly following [psf/black's](https://github.com/psf/black) style guides.

cc @ezyang @malfet @rgommers @xuzhao9 @gramster
Repository: storybook
Issue: In the description column in the ArgsTable, view properties of TypeScript types like an interface, enum, etc.
Labels: feature request,typescript,addon: docs,block: argstable

For example, if a component accepts a props `user`, which is of type `User`, where I have defined a `User` interface. Below is the resulting output:
<img width="1040" alt="Screen Shot 2020-12-15 at 2 28 21 PM" src="https://user-images.githubusercontent.com/18446243/102263028-cf373e80-3ee1-11eb-9b0f-ee4226c4de4c.png">


If I am a stakeholder, I want a way to see what properties the user object can have. Maybe if I hover over `User` under the description column, I can view the interface.

Another request would be to have a control for easily editing nested object properties, instead of the plain-text JSON. But that is a separate feature request that I think is already open.
Repository: TypeScript
Issue: Many errors on JSDoc use entire tag as errorNode
Labels: Bug

This is made more obvious by #41877, which corrects the spans of tags to their full spans, making the error spans even more ungainly. Here's one example; see the errors.txt diffs in the linked PR for more.

**Expected behavior:**

```ts
    /** @type {Gioconda} */
        ~~~~~~~~~~~~~~~~ // before #41877
        ~~~~~~~~~~~~~~~~~ // after #41877 (both are wrong)
!!! error TS8030: The type of a function declaration must match the function's signature.
    function monaLisa(sb) {
        return typeof sb === 'string' ? 1 : 2;
    }
```

**Actual behavior:**

```ts
    /** @type {Gioconda} */
               ~~~~~~~~
!!! error TS8030: The type of a function declaration must match the function's signature.
    function monaLisa(sb) {
        return typeof sb === 'string' ? 1 : 2;
    }
```
Repository: flutter
Issue: Provide some metadata for creation of Layers to help detect jank
Labels: c: new feature,framework,engine,a: debugging,d: devtools,P3,team-engine,triaged-engine

When a user examines a trace and finds that GPU/Raster time is higher than desired, they can see a set of layers that contributed to the frame:

![image](https://user-images.githubusercontent.com/8620741/102266676-a016d200-3ecd-11eb-8b59-59567aa34173.png)

In this particular case, the OpacityLayer looks suspiciously dominant of the time for the frame. It would be helpful if there was some metadata in the arguments of the trace that could tie this layer back to a specific line of application code, which would enable the developer to see where they introduced it and more easily experiment with changes.

/cc @jacob314 @kenzieschmoll for thoughts on how this might work with devtools.
Repository: pytorch
Issue: [doc] missing torch.pdist entry
Labels: module: docs,module: nn,triaged,small,module: distance functions

## 📚 Documentation
It is mentioned in `TorchScript Builtins`, but has no doc entry.

cc @jlin27 @mruberry @albanD @jbschlosser
Repository: flutter
Issue: Show available but not launched emulators in "flutter devices"/"doctor"
Labels: c: new feature,tool,t: flutter doctor,c: proposal,P3,team-tool,triaged-tool

`flutter devices` shows emulators that are running/booted.  Add a section for available but not running emulators, with a hint to `flutter emulators --launch` to run it.

This is a really long list for iOS, maybe only do this for `flutter devices -v`?  Ditto `doctor`?
Repository: TypeScript
Issue: Unexpected behavior when static methods are used in an array
Labels: Bug,Fix Available

**TypeScript Version:**  4.2.0-dev.20201211 (also tested with 4.2.0)

**Search Terms:** static method(s)

**Code**

```ts
class S {
  static f(a: number|string): void {}
}

function g(a: number): void {}

// Uncomment to see a different behavior of the `output` const type.
// type G = typeof g;

const y = [S.f, g];
const output: ((ctrl: number|string) => void)[] = y;
```

**Expected behavior:**
Consistent type checking result (an error) for the `output` const with and without `type G = typeof g`.

**Actual behavior:**
If the `type G = typeof g` is present, the error is thrown (as expected), otherwise there is no error thrown.

**Playground Link:**
[Playground link to reproduce the error.](https://www.typescriptlang.org/play?ts=4.2.0-dev.20201211#code/MYGwhgzhAEDK0G8BQ1oQC5nQS2NAZgBRgBc0AdgK4C2ARgKYBOAPho9uQOYCUZAbgHtsAE0QBfJBKT5K5YDgHlonYmSp0mvaIJHikSAPQHoAVTkDq1euXTR0AtPXrQw0Ydnz4m12wwAWYHzYAozQAvh2fs4ABgKU6AAO8dHQwIoYdgCeCfQAdIbG6NnOAOLQALxZOeHKANz6aeQZmRXQANqwufgANMoAuvWNGXGJ8WSEhPKMIGo0DCxsHDwVAHzaQsLcbX2tmbVAA)

// cc @alxhub @rkirov
Repository: pytorch
Issue: Inserting named tensor into other fails
Labels: triaged,enhancement,module: named tensor

## 🐛 Bug

Assigning a tensor to a view of another tensor (for insertion) fails because it implicitly calls tensor.view() which is not supported. This is so very basic functionality though so I wouldn't really consider this a feature request...

## To Reproduce

```
a = torch.zeros([1,2,3], names=('a', 'b', 'c'))
b = torch.zeros([2,3], names=('b', 'c'))

a[0] = b
```

produces

```
RuntimeError: view is not yet supported with named tensors. Please drop names via `tensor = tensor.rename(None)`, call the op with an unnamed tensor, and set names on the result of the operation.
```

## Expected behavior

I would expect this to work without name drop if the dimension names match accordingly.

## Environment

 - PyTorch Version (e.g., 1.0): 1.4.0


cc @zou3519
Repository: pytorch
Issue: clip_grad_norm_ performance regression
Labels: module: performance,triaged,module: norms and normalization

## 🐛 Bug

code

```python
import torch
import torch.nn as nn
import time

print(torch.__version__)

model = nn.Sequential(*(nn.Linear(512, 512) for i in range(100))).cuda()
elapsed = 0

for _ in range(1):
    inp = torch.rand(32, 512).cuda()
    out = model(inp)
    out.backward(torch.ones_like(out))

    torch.cuda.synchronize()
    t1 = time.time()
    for _ in range(1000):
        torch.nn.utils.clip_grad_norm_(model.parameters(), 1e-7)
    torch.cuda.synchronize()
    t2 = time.time()
    elapsed += (t2 - t1) * 1000


print(elapsed, 'ms')
```

The result I get on 2080ti on 1.5:
```
1.5.0
4177.280902862549 ms
```

The result I get on 2080ti on 1.7.1

```
1.7.1
7328.190803527832 ms
```

## Environment

```
Collecting environment information...
PyTorch version: 1.5.0
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Arch Linux (x86_64)
GCC version: (GCC) 10.2.0
Clang version: 11.0.0
CMake version: version 3.19.1

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: GeForce RTX 3090
GPU 1: GeForce RTX 2080 Ti

Nvidia driver version: 455.45.01
cuDNN version: Probably one of the following:
/usr/lib/libcudnn.so.8.0.5
/usr/lib/libcudnn_adv_infer.so.8.0.5
/usr/lib/libcudnn_adv_train.so.8.0.5
/usr/lib/libcudnn_cnn_infer.so.8.0.5
/usr/lib/libcudnn_cnn_train.so.8.0.5
/usr/lib/libcudnn_ops_infer.so.8.0.5
/usr/lib/libcudnn_ops_train.so.8.0.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.4
[pip3] torch==1.5.0
[conda] numpy                     1.19.4                   pypi_0    pypi
[conda] torch                     1.5.0                    pypi_0    pypi
```

cc @VitalyFedyunin @ngimel
Repository: rust
Issue: Compiler hangs at ObligationForest
Labels: T-compiler,C-bug,I-hang,T-types

<!--
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.
-->

I tried something like the code below:

[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2f6e4deaa95c0384060513f996786fe0)
```rust
struct Wrapper<T>(T);

struct Test;

pub unsafe trait Foo: Sized {
    type Bar: Bar<Self>;
}

pub unsafe trait Bar<B: Foo>: Sized {}

unsafe impl<S: Bar<Self>> Foo for Wrapper<&mut S> {
    type Bar = S;
}

unsafe impl<B: Foo<Bar = Self>> Bar<B> for Test {}

fn assert<B: Foo>(b: B) {}

fn test() {
    assert(Wrapper(&mut Test))
}
```

I thought this should compile, because everything checks out, but instead I got the compiler to go into an infinite loop! It *never* stops (I had one instance run for over 10 minutes, with no end in sight)
Repository: vscode
Issue: Git - Allow configuring git to use current VS Code version for editing commits
Labels: help wanted,feature-request,git

Issue Type: <b>Feature Request</b>

## Problem
We can [configure VS Code as the default git editor](https://code.visualstudio.com/docs/editor/versioncontrol#_vs-code-as-git-editor), but this currently hardcodes the `code` program name.

This means that if you are using the insiders version of VS Code and run a git command in the intergrated terminal, we end up launching  the stable version of VS Code to edit the commit message

## Feature Request
Make it possible to configure git to use the currently running version of VS Code as the default editor, falling back to stable or insiders if the git command was not run from VS Code



<!-- generated by issue reporter -->
Repository: flutter
Issue: Benchmark scaling marker_tasks and scavenger_tasks up/down based on CPU cores, and then enable it if it improves things
Labels: engine,c: performance,customer: dream (g3),customer: money (g3),perf: memory,perf: speed,perf: energy,P2,team-engine,triaged-engine

Examining traces on some four core lower end devices, I notice that concurrent marking in particular can eat up a lot of CPU on two threads, while Flutter is also trying to do rendering work on Raster/UI threads. This causes scheduling problems if e.g. the platform thread (or any other thread) needs to do work, and seems to contribute to jank.

See https://github.com/dart-lang/sdk/blob/9f0f569eafacb0724c86ab479b18dfe8d9491320/runtime/vm/flag_list.h#L139-L144

On a lower end system (e.g. a phone or embedded device with 4 CPUs), 2 threads for each of these is probably too many. 

We should look at the impact of changing this based on number of cores and determine if there are better value(s) to use based on that.

Things to track:

- Overall CPU utliization
- Avoid jank
- Overall memory utilization

We're also working with some internal customers to see if they already have benchmarks this would move meaningfully. If so, may be worth implementing earlier.
Repository: TypeScript
Issue: Add a module resolution mode to get module search path from Node.js executable itself
Labels: Suggestion,Awaiting More Feedback

## Search Terms

node path
module path
NODE_PATH

## Suggestion

TypeScript's effort to match Node.js's module resolution doesn't seem to always be accurate. Further, it can never be right if Node.js has been modified or configured in any way that does not match the emulation. It should be possible for TypeScript to locate type definitions using the *actual module search path* that `node` will be using at runtime, so that the runtime and the static type checking agree exactly on which files are used. After all, the TypeScript compilation is meant to reflect static properties of the code!

## Use Cases

My organization has a monorepo-style integration build of first party modules which are available in `$PREFIX/lib/node`. This path is used by the `node` executable when processing `require`, but TypeScript sadly needs to be taught it through tsconfig `baseUrl` or similar hack. I believe this should be zero config and would fix a bunch of other similar use cases where the Node.js runtime disagrees with the TypeScript compiler.

## Examples

One suggested way to set this up would be a new `moduleResolution` mode, alongside `node` and `classic`, which rather than emulating Node.js, actually calls Node.js itself to evaluate the actual module search path which will be used by a project. This mode could be called e.g. `nodeIntrospect` or something bikesheddable.

A facility to specify the command used to get the module search path could be provided for advanced usages such as running Node.js in a Docker container or other isolation mechanism. The command would merely be required to return a JSON array of paths or something.

(At this point I'm unsure if Node.js actually provides something similar to Python's `sys.path` for this, but if this issue is accepted in principle I could try to expose something for this in Node.js.)

## Checklist

My suggestion meets these guidelines:

* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behavior of existing JavaScript code
* [X] This could be implemented without emitting different JS based on the types of the expressions
* [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

Much appreciated! Thanks!
Repository: flutter
Issue: Shader objects (Gradient and ImageShader) should implement == to encourage reuse
Labels: framework,engine,c: rendering,P2,team-engine,triaged-engine

Other objects that map to a native object have a Dart wrapper that stores the attributes and lazily construct the native object when it is used to render or make a layer. That same mechanism allows the Dart wrappers to implement == so that when they are used in a Widget the various layers of Flutter can detect that the object is the same during frame updates and avoid marking lower level objects (RenderObject/Layer) as needing an update.

Unfortunately the Shader objects lack such a mechanism so unless the application carefully keeps its reference to the Shader and reuses it by instance every time, it will look like a brand new Shader on every frame.

Reusing the objects will lower processing time in creating new lower level trees (RenderObject/Layer) and in the future it will let us detect the stability of the various parts of a tree more easily.
Repository: storybook
Issue: Failed init with private packages
Labels: question / support,cli,has workaround,yarn / npm

I'm unable to run `npx sb init` on an existing codebase due to errors with private packages (GPM).

```
error An unexpected error occurred: "https://registry.npmjs.org/my-private-repo: Not found".
```

The same packages work fine for normal `npm -i` or `yarn` CLI dependency management.

Is there a known requirement / issue around this?