sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [image_picker] Small png image returned as `.jpg` instead of `.png` on `iOS 14` & above
Labels: platform-ios,p: image_picker,package,e: OS-version specific,has reproducible steps,P3,found in release: 3.10,found in release: 3.11,team-ios,triaged-ios

I'm having the same issue as #70812, which has been from iOS 14.
This is not the same as #17947.

- The plugin uses `PHPicker` on iOS 14, whereas using `UIImagePickerController` on older versions.
    ```objective-c
      if (@available(iOS 14, *)) {
        // PHPicker is used
        [self pickImageWithPHPicker:1];
      } else {
        // UIImagePicker is used
        [self pickImageWithUIImagePicker];
      }
    ```
    https://github.com/flutter/plugins/blob/729c3e4117e6d1a026b50f363b2a202352231fdd/packages/image_picker/image_picker/ios/Classes/FLTImagePickerPlugin.m#L142-L148

- After picking an asset (which is just meta info) by `PHPicker`, the plugin try to use `PHImageManager` to get the real binary data, with `nil` options. And maybe this default value makes the manager pick a jpg file, not a png one.
    ```objective-c
              [[PHImageManager defaultManager]
                  requestImageDataForAsset:originalAsset
                                   options:nil
    ```
    https://github.com/flutter/plugins/blob/729c3e4117e6d1a026b50f363b2a202352231fdd/packages/image_picker/image_picker/ios/Classes/FLTPHPickerSaveImageToPathOperation.m#L109-L111

- In this case, using a new `PHImageRequestOptions` instance that has `version` set to `PHImageRequestOptionsVersionOriginal`, the right original png file is returned.
    ```objective-c
              // fixed
              PHImageRequestOptions *options = [[PHImageRequestOptions alloc] init];
              options.version = PHImageRequestOptionsVersionCurrent;

              [[PHImageManager defaultManager]
                  requestImageDataForAsset:originalAsset
                                   options:options
    ```
Repository: flutter
Issue: Starting an Activity with a cached engine containing platform views should recreate the platform views
Labels: a: platform-views,P3,team-android,triaged-android

When an engine is detached from a `FlutterActivity`. [FlutterActivity.release](https://github.com/flutter/engine/blob/6c8ef61b5358d54b62a7acd195b9994c4246cff1/shell/platform/android/io/flutter/embedding/android/FlutterActivity.java#L649) is called. This eventually leads down to calling [PlatformViewsController.destroyOverlaySurfaces](https://github.com/flutter/engine/blob/6c8ef61b5358d54b62a7acd195b9994c4246cff1/shell/platform/android/io/flutter/plugin/platform/PlatformViewsController.java#L970). And when the cached engine is detached from an Activity and reused with a new Activity this leads to:
```
E/flutter: [ERROR:flutter/shell/platform/android/platform_view_android_jni_impl.cc(49)] java.lang.IllegalStateException: The overlay surface (id:0) doesn't exist
        at io.flutter.plugin.platform.PlatformViewsController.onDisplayOverlaySurface(PlatformViewsController.java:796)
        at io.flutter.embedding.engine.FlutterJNI.onDisplayOverlaySurface(FlutterJNI.java:960)
        at android.os.MessageQueue.nativePollOnce(Native Method)
        at android.os.MessageQueue.next(MessageQueue.java:336)
        at android.os.Looper.loop(Looper.java:174)
        at android.app.ActivityThread.main(ActivityThread.java:7356)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
A/flutter: [FATAL:flutter/shell/platform/android/platform_view_android_jni_impl.cc(1414)] Check failed: CheckException(env). 
A/libc: Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 15403 (e.myapplication), pid 15403 (e.myapplication)
``` 

Despite that, the old `PlatformView`s are attached to the old `Activity`, so all references should/will be removed. So I believe the only way Flutter could support detaching a cached engine containing `PlatformView`s and restarting a new Activity with it, is if it recreated all the `PlatformView`s with the new `Activity` and their creation arguments. (e.g. [PlatformViewFactory.create](https://github.com/flutter/engine/blob/master/shell/platform/android/io/flutter/plugin/platform/PlatformViewFactory.java#L28)).
Repository: angular
Issue: Check generic types when using `ViewChild`/`ContentChild` and through DI
Labels: feature,area: compiler,compiler: template type-checking,feature: under consideration

### Which @angular/* package(s) are relevant/releated to the feature request?

compiler

### Description

Imagine we have a parent component `NgxOptions<T>` and a child `NgxOption<T>`, with the following definition:

```ts
@Component({ /*...*/ })
export class NgxOptions<T> {
  @Input() options: T[];
}

@Component({ /*...*/ })
export class NgxOption<T> {
  @Input() display: (option: T) => string;

  // Forced parent component to be of the same generic type
  constructor(options: NgxOptions<T>) { }
}
```

```html
<ngx-options [options]="options">
   <!-- I'd expect the compiler and language service to enforce both components have the same generic type -->
   <ngx-option [display]="displayOption"></ngx-option>
</ngx-options>
```



### Proposed solution

It would be great to enforce type checking of components with a generic type when there is a relationship between them, such as `ViewChild`/`ContentChild` or injection

### Alternatives considered

Right now the strict checking only applied to templates. However, it is only implemented for inputs/outputs, not for generic types in components when they are related.
Repository: godot
Issue: Viewport instantiation is very slow when using GLES3
Labels: topic:rendering,performance

### Godot version

3.3.stable

### System information

Windows 10

### Issue description

Each time a Viewport is instantiated, a spike can be seen in the profiler. This spike can cause a drop of a few frames. This is only the case when using GLES3.

Using a C++ profiler, I was able to track the slowdown to the texture_create method, but I don't know why it would  be slower in GLES3 than GLES2.

### Steps to reproduce

Instantiate a Viewport.

### Minimal reproduction project

Use the profiler to profile this project. A Viewport is instantiated every few frames. Spikes can be seen periodically when using GLES3, but not when using GLES2.
[viewport_instance.zip](https://github.com/godotengine/godot/files/7047715/viewport_instance.zip)
Repository: go
Issue: syscall/js: CopyBytesToGo increased memory allocation
Labels: NeedsInvestigation,arch-wasm,OS-JS

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16.6 darwin/amd64
</pre>

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env

</pre></details>

### What did you do?
For the Webassembly version of [Pigo](https://github.com/esimov/pigo) face detection library I needed to transform the results returned by the `getImageData` Javascript method into a `Uint8Array`, which is the only value type accepted by the `js.CopyBytesToGo` function. For seamless user interaction it's requested the frame rate to be updated at a high frequency (ideally 60FPS) which cause the memory allocation to increase considerably and in the end the web browser crashes because of `Out of memory` error.

![image](https://user-images.githubusercontent.com/883386/130805679-e65eb7b1-b89f-43aa-8b84-6710837700b1.png)

This is my code:

```go
if err := det.UnpackCascades(); err == nil {
		c.wg.Add(1)
		go func() {
			defer c.wg.Done()
			c.renderer = js.FuncOf(func(this js.Value, args []js.Value) interface{} {
				c.reqID = c.window.Call("requestAnimationFrame", c.renderer)
				// Draw the webcam frame to the canvas element
				c.ctx.Call("drawImage", c.video, 0, 0)
				rgba := c.ctx.Call("getImageData", 0, 0, width, height).Get("data")

				uint8Arr := js.Global().Get("Uint8Array").New(rgba)
				js.CopyBytesToGo(data, uint8Arr)
				// pixels := c.rgbaToGrayscale(data)
				// res := det.DetectFaces(pixels, height, width)
				// c.drawDetection(res)

				// if len(res) > 0 {
				// 	c.send(string(c.stringify(res[0])))
				// }
				data = data[:cap(data)]
				return nil
			})
			c.window.Call("requestAnimationFrame", c.renderer)
			c.detectKeyPress()
			<-c.done
			c.renderer.Release()
		}()
		c.wg.Wait()
	}
```
I commented out the above code section in the hope that memory consumption will decrease, but was not the case, so I'm quite confident that this issue is related to `js.CopyBytesToGo` method.

### What did you expect to see?
To not crash the browser.


### What did you see instead?
After a few minutes of continuous running the browser crashes.
Repository: rust
Issue: Check codegen backends for compatibility with the loading rustc
Labels: C-enhancement,T-compiler

This would have helped with https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20How.20to.20load.20codegen.20backend.20when.20custom-built.20rustc where a codegen backend was accidentally built against the librustc_driver.so of a rustc different from the one which actually loaded the codegen backend.

Checking just the rustc version in the `.rustc` section of the dylib is not correct. For example if a stage 1 rustc is used the librustc_driver.so it will compile the codegen backend against doesn't match the librustc_driver.so the rustc is linked against. The librustc_driver.so it is linked against is compiled by a different version of rustc.

It should instead check the dylib dependency list to see if the hash in the filename of librustc_driver.so as depended on by the codegen backend matches the librustc_driver.so depended on by the current rustc.

cc @antoyo
Repository: vscode
Issue: [UI/UX] problem with disassembly page.
Labels: bug,debug,debug-disassembly

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.59.1
- OS Version:  Windows 7 x64 SP1

Steps to Reproduce:

# In disassembly page, the width of the yellow background is less than the width of the blue border line.
**Was it originally designed to be like this? Or is this a bug?**

![](https://i.bmp.ovh/imgs/2021/08/73acb9090e87b419.png)

**My editor font size setting is 20**

Originally from @thefatwhale at https://github.com/microsoft/vscode-cpptools/issues/8051
Repository: create-react-app
Issue: Recommend using GitHub's Codespaces for the development of/contributions to CRA
Labels: issue: proposal,tag: internal

### Is your proposal related to a problem?

Currently checking out & running `create-react-app`'s tests makes some changes to your development machine if you're not running in a Docker container/sandboxed environment; this can be frustrating for new, potential contributors.

### Describe the solution you'd like

I'm proposing that we use/recommend GitHub's Codespaces for new contributions, especially if they are small in nature. This recommendation should help increase the number of folks that participate in the project as it should reduce the friction to contribution.

### Describe alternatives you've considered

- Refactoring the project/tests to not modify environment configs &/or ensure it cleans up after itself

### Additional context

- We previously discussed this change/recommendation in a maintainers call

/cc @iansu @mrmckeb
Repository: go
Issue: x/build/cmd/updatestd: ability to split large updates into a sequence of smaller update CLs, for better bisection
Labels: Builders,NeedsInvestigation,FeatureRequest

At this time the `updatestd` command updates all golang.org/x versions to latest available when it is run. If run fairly infrequently (e.g., twice per cycle, so every 3 months), there can be many changes in all golang.org/x dependencies, and they're currently all included in one CL.

For purposes of improving the ability to bisect and find a narrower set of changes that may have introduced a problem, it would be better to split such large updates into multiple smaller CL.

Comment https://github.com/golang/go/issues/36905#issuecomment-833757864 makes this suggestion.

A strategy of making a CL per module may not scale in the general case: updating to the latest version of module A may cause newer versions of module B to be also pulled in, and since module requirements can have loops, module B can also require newer module A.

Another strategy to consider is to split the large update by time: instead of updating from "3 months old" versions to "latest" directly, it can be "update to versions that were latest 2 months ago", then "update to 1 month old", then finally "latest latest". This can be automated, and needs to be careful to avoid making CLs that move some dependency versions back in time.

There's like some overlap here with issue #41589, but they're not the same.

CC @golang/release, @bcmills.
Repository: pytorch
Issue: [LTC] Investigate a testing utility to make sure correct lowering has happened
Labels: triaged,module: lazy

Investigate a testing utility to make sure correct lowering has happened. Currently, in AtenLtcTsTensorTest, we don't have a way to tell the above, but only relies on manual instrument, gdb or logging to see if the correct lowered function is called.
Repository: pytorch
Issue: benchmark.Compare raises: TypeError: object of type 'NoneType' has no len()
Labels: module: error checking,triaged,module: benchmark

```
Traceback (most recent call last):
  File "test.py", line 12, in <module>
    compare.print()
  File "/Users/ezyang/miniconda3/lib/python3.7/site-packages/torch/utils/benchmark/utils/compare.py", line 298, in print
    print(str(self))
  File "/Users/ezyang/miniconda3/lib/python3.7/site-packages/torch/utils/benchmark/utils/compare.py", line 278, in __str__
    return "\n".join(self._render())
  File "/Users/ezyang/miniconda3/lib/python3.7/site-packages/torch/utils/benchmark/utils/compare.py", line 305, in _render
    output.append(self._layout(group))
  File "/Users/ezyang/miniconda3/lib/python3.7/site-packages/torch/utils/benchmark/utils/compare.py", line 321, in _layout
    return table.render()
  File "/Users/ezyang/miniconda3/lib/python3.7/site-packages/torch/utils/benchmark/utils/compare.py", line 252, in render
    col_widths = [max(len(j) for j in i) for i in zip(*string_rows)]
  File "/Users/ezyang/miniconda3/lib/python3.7/site-packages/torch/utils/benchmark/utils/compare.py", line 252, in <listcomp>
    col_widths = [max(len(j) for j in i) for i in zip(*string_rows)]
  File "/Users/ezyang/miniconda3/lib/python3.7/site-packages/torch/utils/benchmark/utils/compare.py", line 252, in <genexpr>
    col_widths = [max(len(j) for j in i) for i in zip(*string_rows)]
TypeError: object of type 'NoneType' has no len()
(base) ezyang-mbp:~ ezyang$ cat test.py
import torch
import torch.utils.benchmark as benchmark

results = []
results.append(benchmark.Timer(
    stmt='2',
    label='foo',
    sub_label='bar',
).blocked_autorange(min_run_time=1))

compare = benchmark.Compare(results)
compare.print()
```

I know how to fix it (add description) but it shouldn't raise an uninterpretable error like this.
Repository: TypeScript
Issue: Stack overflow on certain platforms
Labels: Bug

From @h-joo at https://github.com/microsoft/TypeScript/issues/45571

```ts
type SomeType = number | string | SomeType[];

declare var obj: { key: SomeType; };

declare namespace jasmine {
    interface Matchers<T> {
        toEqual(expected: Expected<T>): void;
    }

    type Expected<T> = T | {
        [K in keyof T]: ExpectedRecursive<T[K]>;
    }

    type ExpectedRecursive<T> = T | {
        [K in keyof T]: ExpectedRecursive<T[K]>;
    };
}

declare function expect<T>(actual: T): jasmine.Matchers<T>;

expect(obj).toEqual({ key: 'value1' });
```

With `tsc` or in the editor

```
> tsc -p src
src/index.ts:19:21 - error TS2589: Type instantiation is excessively deep and possibly infinite.

expect(obj).toEqual({key: 'value1'});
                    ~~~~~~~~~~~~~~~
```

Or in the playground for me:

```
simpleWorker.ts:125 Uncaught (in promise) RangeError: Maximum call stack size exceeded
    at isTypeAssignableTo (tsWorker.js:60285)
    at isApplicableIndexType (tsWorker.js:56207)
    at findApplicableIndexInfo (tsWorker.js:56187)
    at getApplicableIndexInfo (tsWorker.js:56236)
    at getPropertyTypeForIndexType (tsWorker.js:58675)
    at getIndexedAccessTypeOrUndefined (tsWorker.js:59018)
    at getIndexedAccessType (tsWorker.js:58940)
    at instantiateTypeWorker (tsWorker.js:60141)
    at instantiateTypeWithAlias (tsWorker.js:60092)
    at instantiateType (tsWorker.js:60075)
```

_____

> This seems to have been caused by the newly introduced recursive definition of
the IDBValidKey, and this causes an infinite type instantiation.
Repository: create-react-app
Issue: Dotenv file custom path/env
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Standard support for environment files is limited to reading defined paths (https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use); Therefore, it is impossible to define what environment file we want to use when building a project for non-end users build, but for example, staging/demo.

### Describe the solution you'd like

Allow the definition of an additional pre-production environment by setting an env variable (eg. DOTENV_CUSTOM_ENV) or an argument for npm run buld --staging/demo. In the following order or otherwise:
react-scripts/config/env.js
```
// https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use
const dotenvFiles = [
	`${paths.dotenv}.${NODE_ENV}.local`,
	// Don't include `.env.local` for `test` environment
	// since normally you expect tests to produce the same
	// results for everyone
	NODE_ENV !== "test" && `${paths.dotenv}.local`,
	`${paths.dotenv}.${process.env.DOTENV_CUSTOM_ENV}`,
	`${paths.dotenv}.${NODE_ENV}`,
	paths.dotenv,
].filter(Boolean);
```
With this solution, running a script by "DOTENB_CUSTOM_ENV=staging npm run build", react-scripts reads the file .env.staging

### Describe alternatives you've considered

An alternative solution would be to allow set the full path to the .env file. This method would point to an environment file that could be used by many different projects.
Repository: pytorch
Issue: bazel build warning: Artifact 'torch/csrc/api/include/torch/version.h' is duplicated
Labels: module: build,triaged,module: build warnings,module: bazel

## 🐛 Bug

Bazel build produces warning:

```
$ bazel build --verbose_failures //:tensor_test
WARNING: /home/azureuser/src/pytorch/pytorch/BUILD.bazel:1864:11: in hdrs attribute of cc_library rule //:torch_headers: Artifact 'bazel-out/k8-fastbuild/bin/torch/csrc/api/include/torch/version.h' is duplicated (through '//:torch/csrc/api/include/torch/version.h' and '//:version_h'). Since this rule was created by the macro 'cc_library', the error might have been caused by the macro implementation
```


## Expected behavior

No warnings.

## Environment

```
PyTorch version: 1.10.0a0+git6c73c1b
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.2 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.19.6
Libc version: glibc-2.10

Python version: 3.7.10 (default, Feb 26 2021, 18:47:35)  [GCC 7.3.0] (64-bit runtime)
Python platform: Linux-5.4.0-1041-azure-x86_64-with-debian-bullseye-sid
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

Versions of relevant libraries:
[pip3] mypy==0.812
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.20.1
[pip3] torch==1.10.0a0+gite187899
[pip3] torchaudio==0.10.0a0+8a347b6
[pip3] torchvision==0.11.0a0+bf2fe56
[conda] blas                      1.0                         mkl  
[conda] mkl                       2021.2.0           h06a4308_296  
[conda] mkl-include               2021.2.0           h06a4308_296  
[conda] mkl-service               2.4.0            py37h7f8727e_0  
[conda] mkl_fft                   1.3.0            py37h42c9631_2  
[conda] mkl_random                1.2.2            py37h51133e4_0  
[conda] mypy                      0.812              pyhd3eb1b0_0  
[conda] mypy_extensions           0.4.3                    py37_0  
[conda] numpy                     1.20.1           py37h93e21f0_0  
[conda] numpy-base                1.20.1           py37h7d8b39e_0  
[conda] torch                     1.10.0a0+gite187899           dev_0    <develop>
[conda] torchaudio                0.10.0a0+8a347b6          pypi_0    pypi
[conda] torchvision               0.11.0a0+bf2fe56          pypi_0    pypi
```

## Additional context

bazel 4.2.0

CC @werkt 

cc @malfet @seemethere @walterddr
Repository: node
Issue: doc: version picker issue (due to ESM doc shuffling?)
Labels: doc

# 📗 API Reference Docs Problem

<!--

Thank you for wanting to make nodejs.org better!

This template is for issues with the Node.js API
reference documentation.

For problems with nodejs.org beyond the API
reference documentation, please open an issue
using the issue tracker for our site repository.

  https://github.com/nodejs/nodejs.org

For more general support, please open an issue
using the issue tracker for our help repository.

  https://github.com/nodejs/help

---

For the issue title, please enter a one-line
summary after “doc: ” (preferably 50 characters
or less and no more than 72).

The “✍️” are placeholders signifying requests for
input. Replace them with your responses.

If you are unsure of something, do your best.

-->

<!-- The output of “node --version”. -->

- **Version**: 16.7.0

<!-- The output of “uname -a” (UNIX) or version
and 32-bit or 64-bit (Windows). -->

- **Platform**: n/a

<!-- The name of affected core module. -->

- **Subsystem**: doc

## Location

https://nodejs.org/dist/latest-v16.x/docs/api/packages.html

Affected URL(s):

- https://nodejs.org/dist/latest-v16.x/docs/api/packages.html#

## Description

If you go to the version picker and select 13.x, you got a 404. Someone had generally fixed the issue at some point, but it's broken now on this page because (I'm guessing) this page was created after 13.x went EOL and so the docs that were moved here from another page never got moved in 13.x.

<!-- If applicable, include any screenshots that
may help solve the problem. -->



---

<!-- Use “[x]” to check the box below if you are
interested in contributing. -->

- [ ] I would like to work on this issue and
      submit a pull request.