sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Chinese fonts in iOS app set Locale in Japanese
Labels: platform-ios,framework,f: material design,a: internationalization,has reproducible steps,found in release: 2.1,team-design,triaged-design

I have an issue that the text in the iOS app display in Chinese font.
I tried three patterns. all patterns don't work.
In the iOS simulator, the text display in Japanese font, but it doesn't work in the build iOS app. 
How can I reflect localization?

1. set locales in supportedLocales.

```
    return MaterialApp(
        　　localizationsDelegates: [
              GlobalCupertinoLocalizations.delegate,
              GlobalMaterialLocalizations.delegate,
              GlobalWidgetsLocalizations.delegate,
            ],
            supportedLocales: [
              const Locale('ja', 'JP'),
            ],
        .....
        );
```

2. set locale in TextStyle

```
　Text('', style: TextStyle(
　　　　fontWeight: FontWeight.bold,
　　　　locale: Locale('ja', 'JP'),
      )),
```

3. set CFBundleLocalizations in iOS/Runner/info.plist

 ```
   <key>CFBundleLocalizations</key>
    	<array>
    		<string>ja</string>
    	</array>
```


**Expected results:** <!-- what did you want to see? -->

<img width="551" alt="スクリーンショット 2021-03-30 20 34 16" src="https://user-images.githubusercontent.com/58324974/112983150-485c5800-9198-11eb-8b2c-d7812c7deadc.png">


**Actual results:** <!-- what did you see? -->
Chinese font
<img width="551" alt="スクリーンショット 2021-03-30 20 34 22" src="https://user-images.githubusercontent.com/58324974/112983205-5d38eb80-9198-11eb-8b04-b12dac8ab51a.png">

the screenshot in app setting in the iOS simulator
<img width="374" alt="スクリーンショット 2021-03-30 20 13 14" src="https://user-images.githubusercontent.com/58324974/112984464-e0a70c80-9199-11eb-96df-86f07a9023f5.png">


the screenshot in app setting in the iOS simulator
![IMG_95034903F51C-1](https://user-images.githubusercontent.com/58324974/112984484-e69ced80-9199-11eb-880a-d0a44a2c2c93.jpeg)

<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.
-->

```
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.3, on macOS 11.2.3 20D91 darwin-x64, locale ja-JP)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.1)
[✓] VS Code (version 1.54.3)
[✓] Connected device (1 available)

• No issues found!
```

</details>
Repository: react
Issue: [Fast Refresh] Don’t Scan the Tree
Labels: Difficulty: challenging,Component: Fast Refresh,Resolution: Backlog,React Core Team

We had a conversation with @sebmarkbage about https://github.com/facebook/react/issues/20417. He had a different implementation idea that should resolve such issues. I probably won't do this now but I want to write it down for future reference.

Currently, after we gather a list of types that need to be updated in the tree, we scan the tree and tag Fibers to be updated. This happens [here](https://github.com/facebook/react/blob/0853aab74dc8285401e62d1e490551ba3c96fd64/packages/react-reconciler/src/ReactFiberHotReloading.new.js#L267-L339). But like https://github.com/facebook/react/issues/20417 shows, this doesn't work if the type is not in the tree. E.g. if the function we changed is only being called directly, and its "type" is not the actual wrapper that exists in the tree.

An alternative implementation could instead inject a special Hook call into each registered component. For example by generating a wrapper. That Hook would return the latest actual implementation, _and_ schedule updates on itself when it changes. Which means there would be no need to scan the tree at all. Instead, each component would register itself for updates. For false positives outside of React rendering, the Hook would just be callthrough so it wouldn't break anything.

This seems like a pretty significant change to the implementation so I'm probably not going to work on this now. Maybe we could consider it next time we need to change the implementation details. Or maybe somebody sufficiently motivated wants to hack on this. I can provide some code pointers but it’s not a beginner-friendly issue.
Repository: godot
Issue: [Bullet] Rigid and Kinematic bodies use different collision detection algorithms.
Labels: bug,topic:physics

**Godot version:**
3.2.3


**OS/device including version:**
N/A

**Issue description:**

From the bullet manual, the default algorithms used for collision detection are taken from this matrix:

|                                     | box           | sphere        | convex, cylinder, cone, capsule | compound | triangle_mesh |
|-------------------------------------|---------------|---------------|---------------------------------|----------|---------------|
| **box**                             | boxbox        | spherebox     | gjk                             | compound | concaveconvex |
| **sphere**                          | spherebox     | spheresphere  | gjk                             | compound | concaveconvex |
| **convex, cylinder, cone, capsule** | gjk           | gjk           | gjk or SAT                      | compound | concaveconvex |
| **compound**                        | compound      | compound      | compound                        | compound | compound      |
| **traingle_mesh**                   | concaveconvex | concaveconvex | concaveconvex                   | compound | gimpact       |

In Godot's bullet backend rigid bodies seem to use the default algorithms, however kinematic bodies seem to use `gjk` for all convex shapes including box and sphere.

This can make a major a difference for boxbox collisions when using large collision margins.  Bullet uses the `margin` value to round out sharp edges with spheres that have a radius equal to the margin value. However, bullet's `boxbox` algorithm is a special case that does not use the margin value, while `gjk` does.

Here's a demonstration showing the difference for the boxbox case. I used OpenSCAD's `minkowski()` to generate visual representations of the exact collision shapes used by bullet in the `gjk` case. The red boxes are rigid bodies, the gray ones kinematic:


https://user-images.githubusercontent.com/79001820/113001106-d3971700-91b3-11eb-9741-4efcd558de17.mp4


There doesn't seem to be much difference for the `spheresphere` and `spherebox` cases, however minor differences in how rigid and kinematic bodies calculate the separation between shapes can contribute to https://github.com/godotengine/godot/issues/31981 (though this is not the main cause of that bug).

**Steps to reproduce:**

* Create kinematic and rigid boxes with large margin values and collide them together.

**Minimal reproduction project:**
[bullet-boxbox-collisions.zip](https://github.com/godotengine/godot/files/6229755/bullet-boxbox-collisions.zip)
Repository: PowerToys
Issue: Snap a Window to Center Horizontally and/or Vertically
Labels: Idea-Enhancement,Product-Window Manager

We need a simple way to center any app window horizontally and/or vertically. On larger displays, making an app full screen can be overwhelming and wastes space that could used for other purposes. We have shortcuts to easily snap windows to the top, bottom or sides. We also have PowerToys Fancy Zones which is awesome for custom snap zones. However, we don't have a way to center a window on the horizontal or vertical axis while leaving its size untouched. 

I rarely want a window to be dead center. So, it's important to allow for separate horizontal and vertical positioning. For me, app window height and width are always custom/app-dependent. For example, my browser, Teams and messaging apps are all sized differently. However, when I'm focusing on one of them, I want it centered horizontally. Yes, this can be done to a "close enough" standard manually, but so can all other sizing/positioning features that do have shortcuts. I would use this far more frequently.
Repository: rust
Issue: feature use after accidentally using an outer comment might give lots of 'enable feature' errors
Labels: C-enhancement,A-diagnostics,T-compiler,D-verbose

If you start a module like this:

```rust
/// accidentally outer comment
#![feature(generators)]  // could be any nightly feature
```

and then go on to use that feature in lots of code, you will get an error like this:

```
error: an inner attribute is not permitted following an outer doc comment
  --> tests/async_gen.rs:16:1
   |
14 | /// * sender_drop
   | ----------------- previous doc comment
15 | 
```

unfortunately, you might not notice for all the errors telling you to enable the feature. more than my terminal's scrollback in this case, apparently.
Repository: flutter
Issue: Better exception reporting during teardown
Labels: a: tests,framework,a: error message,P3,team-framework,triaged-framework

Sometimes exceptions are thrown during teardown of a test when the widget tree used by the test is replaced with a container: 

https://github.com/flutter/flutter/blob/95e2cbb132923c2f777e41c7102b2ad669cee350/packages/flutter_test/lib/src/binding.dart#L800

When those exceptions happen, it's often not immediately clear that they happened during teardown after the user-written test code is already done executing. it would be nice if these exception would report that they happened during tear down to give the user a little more context and to avoid confusion. 

See also: https://github.com/flutter/flutter/issues/74389
Repository: flutter
Issue: CupertinoAlertDialog jank
Labels: framework,engine,c: performance,f: cupertino,perf: speed,P2,team-design,triaged-design

This has been reported to show early-onset jank caused by CupertinoAlertDialog:
https://github.com/timsneath/cupabox
Repository: pytorch
Issue: CUBLAS_STATUS_EXECUTION_FAILED error on torch >= 1.8.0 and CUDA 11.1
Labels: needs reproduction,module: cuda,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->
When trying to run fairscale unittests with torch >= 1.8.0 and cuda 11.1, I am getting many CUBLAS failures This did not happen with 1.7.1. I've also tried March 30 nightly torch 1.9.0 and see the same error.

> attn_output_weights = torch.bmm(q, k.transpose(1, 2))
E RuntimeError: CUDA error: CUBLAS_STATUS_EXECUTION_FAILED when calling `cublasSgemmStridedBatched( handle, opa, opb, m, n, k, &alpha, a, lda, stridea, b, ldb, strideb, &beta, c, ldc, stridec, num_batches)`
https://app.circleci.com/pipelines/github/facebookresearch/fairscale/2192/workflows/9d16d5d4-d104-4aee-971e-4eb329da80c8/jobs/14498

This does not occur with torch 1.7.1 and cuda 11.1



## To Reproduce

Steps to reproduce the behavior:

1.
1.
1.

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```
PyTorch version: 1.9.0.dev20210330+cu111
Is debug build: False
CUDA used to build PyTorch: 11.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 16.04.7 LTS (x86_64)
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
Clang version: Could not collect
CMake version: version 3.5.1

Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration:
GPU 0: Tesla M60
GPU 1: Tesla M60
GPU 2: Tesla M60
GPU 3: Tesla M60

Nvidia driver version: 455.32.00
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.2
[pip3] torch==1.9.0.dev20210330+cu111
[pip3] torchtext==0.6.0
[pip3] torchvision==0.10.0.dev20210330+cu111
[conda] Could not collect

 - PyTorch Version (e.g., 1.0):
 - OS (e.g., Linux):
 - How you installed PyTorch (`conda`, `pip`, source):
 - Build command you used (if compiling from source):
 - Python version:
 - CUDA/cuDNN version:
 - GPU models and configuration:
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->


cc @ngimel
Repository: rust
Issue: Signature mismatch in __wasilibc_find_relpath
Labels: O-wasm

In https://github.com/rust-lang/rust/pull/67267, @alexcrichton indicated that the signature of `__wasilibc_find_relpath` had changed upstream, and that PR was merged changing the signature from a 4-argument version to a 2-argument version.

I'm not 100% sure what "upstream" means in this context, but I had previously thought it was wasi-libc from the `WebAssembly` repo. It does seem to be the case that until recently, `WebAssembly/wasi-libc` had a 2-argument version of `__wasilibc_find_relpath` so that seems consistent. 

However, about 4 months ago in https://github.com/WebAssembly/wasi-libc/pull/214, @alexcrichton changed the signature of `__wasilibc_find_relpath` from a 2-argument version to a 4-argument version (among higher-level changes relating to `getcwd`/`chdir`): https://github.com/WebAssembly/wasi-libc/pull/214/files#diff-a1d7011f390a08ae599db3993ed73f49d1b52748faae3fc11d0f5a12e5e1a2edR28-R31

We have a project in which we build a rust staticlib crate using the `wasm32-wasi` target, and then link that with C code that is also built against `wasm32-wasi`. This had been working, but after updating rust to 1.50.0 (from a much older version) it is now broken with the following final (llvm-11) linker error:
```
wasm-ld: warning: function signature mismatch: __wasilibc_find_relpath
     >>> defined as (i32, i32) -> i32 in /build/example/libexample.a(std-0bc94da15b7c3ad9.std.553gu1ty-cgu.0.rcgu.o)
     >>> defined as (i32, i32, i32, i32) -> i32 in /opt/wasi-sdk/share/sysroot/lib/wasm32-wasi/libc.a(preopens.o)
```

If "upstream" means what I think it does, I think the rust signature of `__wasilibc_find_relpath` now no longer matches the current wasi-libc version.
Repository: pytorch
Issue: test_quantize_fx.py test_resnet_18_dpp test failure
Labels: oncall: quantization,low priority,triaged,module: fx

The `test_resnet18_ddp` was always skipped due to an error with the `@skip_if_not_multigpu` distributed decorator:

Test location:
https://github.com/pytorch/pytorch/blob/master/test/quantization/test_quantize_fx.py#L3891

Test command:
`pytest -vs test/quantization/test_quantize_fx.py -k test_resnet18_ddp`

When the decorator was fixed in https://github.com/pytorch/pytorch/pull/54916, the test uses a few variables that are not defined and is failing. I am creating this issue to track this test and whether it should be removed or updated.

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel @ezyang @SherlockNoMad @EikanWang @wenzhe-nrv @dzhulgakov
Repository: TypeScript
Issue: JSDoc @param and @returns types cannot access typeof other @params
Labels: Bug,Domain: JSDoc

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

JSDoc param return typeof visibility

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?useJavaScript=true#code/PQKhCgAIUgBAHAhgJ0QW0gbwM4BdkCWAdgOaQA+kRArmgEYCmyFWkAHgFxW2PMC+LTJACeXAOQALBgBtpAezGQ+AxFBgIU6LLmHwGcgGaRELbMPpzpAbQC6AumrjIGuasiLYsVnXsPGANJA++kZ0dmrA4AbURADGuARyRJBoiADWDAAq1PDSDAAUiIF0AJRYUJCVzq7ukFZFkGEA3OB84EA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
/**
 * @param {string | number | { x: number } | { y: 'hello' }} a
 * @param {typeof a | symbol[]} b
 * @returns {[typeof a, typeof b]}
 */
function makeTuple(a, b) {
    return [a, b];
}
```

### 🙁 Actual behavior

Cannot find name 'a' / 'b'

### 🙂 Expected behavior

Should work, the same way that it works in TS:

```ts
function makeTuple(a: string | number | { x: number } | { y: 'hello' }, b: typeof a): [typeof a, typeof b] {
    return [a, b];
}
```
Repository: node
Issue: writeHeapSnapshot causes Segmentation fault
Labels: v8 module

v14.16.0:
Linux scheduler-deployment-c477958d6-v897r 5.4.95-42.163.amzn2.x86_64 #1 SMP Thu Feb 4 12:50:05 UTC 2021 x86_64 Linux:
v8:

### What steps will reproduce the bug?

```
const { writeHeapSnapshot } = require('v8');
function dump() {
    const fileName = '/var/log/' + Date.now() + '.heapsnapshot';
    console.info('Writing heapsnapshot to: ' + fileName);
    writeHeapSnapshot(fileName);
}
dump();

setInterval(function () {
    dump();
}, 1000 * 60 * 60);
```

### How often does it reproduce? Is there a required condition?
Happens everytime

### What is the expected behavior?
Write a heapsnapshot

### What do you see instead?

Segmentation fault

### Additional information

The nodejs code is  running inside a container running on AWS EKS Kubernetes.  Not sure if relevant
Repository: pytorch
Issue: Accept objects with `__float__` wherever regular `float`s are accepted
Labels: feature,triaged,module: half

## 🚀 Feature
Enable passing other float-like objects in all API functions which accept regular `float`s.

## Motivation
I'm writing a physics library backed by PyTorch, and for the module on units I'm using exact arithmetic with fractions, decimals, etc. At some point I have to to apply (e.g. multiply, add, etc.) these exact number representations to tensors, which carry the data, but as `torch` stands, I need to explicitly convert to a `float` everywhere I do that.

## Pitch
Python defines the magic method `__float__` to signify that custom objects should be treated as floats without being subclasses of `float`. There are such classes already in the standard library (e.g. `fractions.Fraction`). Furthermore, the module `numbers` defines the hierarchy of objects considered numbers of various types (e.g. complex, real, integer). On a lower level, the C API function `PyFloat_AsDouble`, which is a necessary bridge from the Python interface to the low-level tensor math operations, already fully supports the `__float__` convention. Therefore, it shouldn't be hard to allow any number-like objects in place of regular floats, while it will enable combining exact arithmetic for some parts of a calculation with fast floating-point operations for others.

## Alternatives
I know I can use `__torch_function__` and go through the arguments every time to make sure all `number.Real`s (but not `numbers.Integral`s) are converted to `float`, but this is a) slow because it is in Python and b) requires explicit knowledge of what arguments in what positions are floats, or else I need to check everything. On the other hand, this information is already present for the C++-side type-checking and conversion in PyTorch, and it will be much easier to apply the logic in a centralised manner there.

Thank you for the consideration, and if you think this is a good idea (and you give me some pointers on what exactly needs to be changed) I'd be willing to have a go at a "solution".
Repository: godot
Issue: Editable Children - Material
Labels: discussion,topic:editor,usability

Godot  Version:  3.3 RC7 (known since earlier versions though)

OS/Specs: Win10 64 bit, ryzen r7 1700x, rtx 3070


Issue:
Setting "editable children" to true sets the material of it's children to "copies" of their original materials and removes the "local to scene" setting. 

Steps to reproduce:
For example, i use specific shader materials on sprites and use a script to change the values of the shader in runtime, specific for every copy of a scene. Each time i change something about the existing setup, every scene i tweaked after instancing, i have to manually go and reset the material of every sprite to its original material with "local to scene" setting enabled, otherwise the shaders get wrong uniforms. 

Pretty annoying, creates wierd bugs and a lot of unnessessary work.
Repository: TypeScript
Issue: JSDoc for file/directory autocompletion
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

directory autocompletion
file autocompletion
path autocompletion
path intellisense
cwd autocompletion

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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, new syntax sugar for JS, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

An new JSDoc like `/* @ts-ignore */` for directory/file autocompletion for an folder (e.g. default: cwd)
e.g.:
Plugin Options:
```typescript
interface PluginOptions {
  /* @ts-path-autocompletion (optional define path; default: cwd) */
  file: string
}
```

## 📃 Motivating Example

It can help to choose the path instead of typing it.
And maybe warn if the path does not exist. (Disabling would be handy for files and folders that are still being created)

## 💻 Use Cases

IntelliSense for an path in another folder for e.g. webpack plugin options.