sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: CupertinoApp don't get the correct system font in Arabic Language [IOS]
Labels: platform-ios,engine,a: internationalization,a: typography,has reproducible steps,P2,team-ios,triaged-ios,found in release: 3.19,found in release: 3.20

### Steps to reproduce

run the provided code.

### Expected results

should get the right font family when writing Arabic text

### Actual results

the Arabic letters & Numbers doesn't match the ios system font.

### Code sample

<details open><summary>Code sample</summary>

```dart
import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(const CupertinoApp(
    locale: Locale('ar'),
    localizationsDelegates: [DefaultMaterialLocalizations.delegate],
    home: MyHomePage(),
  ));
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key});

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: SafeArea(
        child: Center(
          child: Column(
            children: <Widget>[
              Text(
                '١١:٤٠',
                style: TextStyle(
                  fontFamily: CupertinoThemeData().textTheme.textStyle.fontFamily,
                  fontSize: 60,
                ),
              ),
              Text(
                'تجربة',
                style: TextStyle(
                  fontFamily: CupertinoThemeData().textTheme.textStyle.fontFamily,
                  fontSize: 60,
                ),
              ),
            ],
          ),
        ),
      ),
      // This trailing comma makes auto-formatting nicer for build methods.
    );
  }
}


```

</details>


### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

| Reminder app             |  Flutter app |
:-------------------------:|:-------------------------:
![Screenshot 2024-02-26 at 11 41 00 AM](https://github.com/flutter/flutter/assets/95232508/3fe25f36-bf6c-4d53-842b-7ee6a0add000)|![Screenshot 2024-02-26 at 11 42 44 AM](https://github.com/flutter/flutter/assets/95232508/2a3ced6c-d8b5-4e4a-a69e-6d034165f77b)


</details>



### Logs

N/A

### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
[✓] Flutter (Channel stable, 3.19.1, on macOS 13.5.2 22G91 darwin-arm64, locale en-EG)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 15.1)
[✓] Chrome - develop for the web
[!] Android Studio (version unknown)
    ✗ Unable to determine Android Studio version.
    ✗ Unable to find bundled Java version.
[✓] VS Code (version 1.86.2)
[✓] Connected device (2 available)
[✓] Network resources
```

</details>
Repository: PowerToys
Issue: Anywhere Text Finder    and    Image Text Finder
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

Whenever I use any browser, there is always a text finder (which we usually enable by Ctrl. + F ) that finds any text on the web page. 
But I think that this feature should be for everywhere and it's lacking on Windows, it would be beneficial if you add it to the Powertoys. 

### Scenario when this would be used?

There should be the same shortcut Ctrl+F . as it's not in use in Windows for any other feature right now.

### Supporting information

We should be able to find the text from any software on the computer as we can find any text on the browser on any web app.

One more feature that I think even Browsers are lacking is the image text finder, where we would be able to find text from an image. You can also add this feature for images, where we would be able to find the text from an image.

Both the features discussed here are:

- Anywhere Text Finder
- Image Text Finder

If you add this , It would be really helpful for everyone.
Repository: pytorch
Issue: `torch.set_default_tensor_type() is deprecated as of PyTorch 2.1` appearing in logs even when not using this function
Labels: module: docs,module: error checking,triaged,module: deprecation

### 📚 The doc issue

I keep seeing this in my logs:
```
UserWarning: torch.set_default_tensor_type() is deprecated as of PyTorch 2.1, please use torch.set_default_dtype() and torch.set_default_device() as alternatives. (Triggered internally at /mnt/code/pytorch/torch/csrc/tensor/python_tensor.cpp:446.)
```

even though I am not directly calling this function. This is nit but it is spamming my logs and I shouldn't be seeing this warning at all since I'm not using this function. Can we fix this?

cc @svekars @brycebortree @malfet
Repository: pytorch
Issue: Functionalization of `as_strided` disregards its base tensor storage.
Labels: triaged,module: functionalization

### 🐛 Describe the bug

In the program below, I try to **retrieve the original tensor** by calling `as_strided`, after creating a view with **different `storage_offset`**. In theory, it should work, given that `y` is a view of `x`.

```python
import torch
import torch._lazy.ts_backend

torch._lazy.ts_backend.init()

def foo(x):
    y = x[2:]
    return y.as_strided((10,), (1,), 0)

x = torch.arange(10)
print(foo(x))
# tensor([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

Lx = x.to("lazy")
print(foo(Lx))
# See error below.
```

```python
Traceback (most recent call last):
  File "examples/bug.py", line 14, in <module>
    print(foo(Lx))
  File "torch/_tensor.py", line 463, in __repr__
    return torch._tensor_str._str(self, tensor_contents=tensor_contents)
  File "torch/_tensor_str.py", line 677, in _str
    return _str_intern(self, tensor_contents=tensor_contents)
  File "torch/_tensor_str.py", line 432, in _str_intern
    self = self.to("cpu")
RuntimeError: The following operation failed in the TorchScript interpreter.
Traceback of TorchScript (most recent call last):
RuntimeError: setStorage: sizes [10], strides [1], storage offset 0, and itemsize 8 requiring a storage size of 80 are out of bounds for storage of size 64
```

From the error above, we can clearly see that `as_strided` is only considering the storage of the input tensor. Since the lazy backend uses `FunctionalTensorWrapper`, the view aspects are controlled by it. The real tensor (wrapped one) is unaware of such a thing.

### Versions

PyTorch version: 2.3.0a0+gited6660e

cc @miladm @lezcano @ezyang @bdhirsh @alanwaketan
Repository: deno
Issue: Support global type augmentation in JSR
Labels: feat,jsr

Will fill this out when I get time.
Repository: excalidraw
Issue: Layers
Labels: enhancement

Hi,

Could we add layers to Excalidraw for organizing objects? Being able to show or hide these layers would make it perfect for step-by-step presentations, offering more control than typical slides by grouping elements for each topic or chapter.

Best regards,
PetrasL
Repository: rust
Issue: "--emit asm" uses different syntax than `asm!` on x86
Labels: C-enhancement,A-inline-assembly,T-compiler,A-contributor-roadblock

Rust inline assembly expects to be written like this:
```
    crate::arch::asm!(
        "movntps [{mem_addr}], {a}",
        mem_addr = in(reg) mem_addr,
        a = in(xmm_reg) a,
    );
```
However, when dumping the output assembly via `--emit asm`, it looks like this:
```
	movntps	%xmm0, (%rdi)
```
Operand order is swapped, and it's using `(%name)` instead of `[name]`. I guess one is AT&T syntax and one is Intel syntax.

Would be good if Rust could be consistent with its own inline asm syntax. :)
Repository: godot
Issue: Editor 3d view: Unchecking "Perspective > View Environment" does not disable camera attributes
Labels: enhancement,discussion,topic:editor,topic:3d

### Tested versions

- Reproducible in: v4.2.1.stable.official [b09f793f5]

### System information

Windows 10 - Godot v4.2.1.stable.official - Vulkan (Forward+) - NVIDIA GeForce RTX 3060 Laptop GPU  - AMD Ryzen 7 5800H with Radeon Graphics 3.20GHz

### Issue description

- The WorldEnvironment node allows to set "Camera Attributes"
- The editor 3d viewport allows to hide the effects of the WorldEnvironment node by unchecking "Perspective > View Environment"
- When unchecking "Perspective > View Environment", camera attributes still are in effect

IMO, the camera attributes should be deactivated as well. 

Having the camera attributes activated at all times makes scene editing harder. This either forces the user to split up the scene just because of the WorldEnvironment, or to delete + re-add the WorldEnvironment while editing the scene. 

This issue makes the Camera Attributes on the WorldEnvironment node less useful than it could be.


I am aware that CameraAttributes can be set on cameras directly.

### Steps to reproduce

1. Create 3d scene
2. Add WorldEnvironment node
3. Set camera attributes. E.g. DOF Blur
4. In the editor, uncheck "Perspective > View Environment"
5. Observe: Camera Attributes are still in effect

### Minimal reproduction project (MRP)

[environment-camera.zip](https://github.com/godotengine/godot/files/14397037/environment-camera.zip)
Repository: vscode
Issue: Fontconfig charset edit does not apply in vscode
Labels: bug,upstream,linux,font-rendering,confirmation-pending

<!-- ⚠️⚠️ 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

<!-- 🪓 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.87.0-insider, 
  Commit: c11a2dd4d52e38cb92b8c464f47a7b02bb7c8762
- OS Version: NixOS

Steps to Reproduce:

I use this section in fontconfig:

```xml
	<match target="font">
		<test name="family" compare="not_eq">
			<string>Symbols Nerd Font</string>
		</test>
		<edit name="charset" mode="assign">
			<minus>
				<name>charset</name>
				<charset>
					<range>
						<int>0xE000</int>
						<int>0xFD46</int>
					</range>
				</charset>
			</minus>
		</edit>
	</match>
```

which deletes a range of code points from a fonts' charset, and then with:

```xml
	<alias>
		<family>Iosevka Term</family>
		<prefer>
			<family>Iosevka Term</family>
			<family>Symbols Nerd Font</family>
		</prefer>
	</alias>
```

I can delegate that range to Nerd Font. This way I can use Nerd Font symbols without patching font files. This works perfectly in other terminal emulators such as alacritty, but it doesn't work in the integrated terminal of vscode.

Might be a limitation of electron. I do notice the same behavior in chrome, firefox, and konsole. But other applications like gedit, alacritty, etc. handles this perfectly.
Repository: TypeScript
Issue: Improve "'await' has no effect on the type of this expression" hints in JavaScript when extending Promise
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

'await' has no effect on the type of this expression, 80007, extends, promise

### ✅ Viability Checklist

- [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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Consider the following JavaScript code:
```
class MyPromise extends Promise {
}

async function main() {
    const promise = new Promise()
    await promise

    const myPromise = new MyPromise()
    await myPromise
}
```

There is a potentially avoidable hint for the subclassed Promise. The original Promise has the flag `TypeFlags.Any` and the subclassed one has `TypeFlags.Object`.

![image](https://github.com/microsoft/TypeScript/assets/2276355/e20bad8d-e68b-465b-a59e-daa2b3756ef1)

These are possibly related:
https://github.com/microsoft/TypeScript/issues/45427
https://github.com/microsoft/TypeScript/issues/56978

### 📃 Motivating Example

In Visual Studio Code using the Quick Fix… feature to remove the `await` keyword can break existing code.

### 💻 Use Cases

1. To prevent incorrect hints.
2. Hints are incorrect.
3. Ignoring hints or disabling the "TypeScript and JavaScript Language Features" extension.
Repository: tauri
Issue: [bug] Permissions are not remembered for a webview
Labels: type: bug,platform: macOS,status: needs triage

### Describe the bug

I am working on an app that needs to record audio from the user's microphone. I added the required permissions in Info.plist  and once I hit record for the first part two dialogs open. The first one I assume is an application level one and the other one is within the webview. I can basically hit record as many times as I want and permissions are not requested again but if I quit the app and I open it again the first dialog (the application level one) doens't appear but the webview one appears again. 

I am using Tauri V2 and it doesn't matter wether I am in dev or in a build.

System: MacOS with M1 chip

TLDR: Microphone permissions for the webview are requested everytime I quit the app.

<img width="294" alt="image" src="https://github.com/tauri-apps/tauri/assets/25539637/7cb7c937-33f6-4ff6-846a-82d728ce1b43">


### Reproduction

https://github.com/AlexMenor/tauri-mic-permissions-issue

### Expected behavior

Prompt should only be opened once (and ideally only the application level one)

### Full `tauri info` output

```text
[✔] Environment
    - OS: Mac OS 14.2.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 20.11.0
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.2
    - tauri-build [RUST]: 2.0.0-beta.1
    - wry [RUST]: 0.35.2
    - tao [RUST]: 0.25.0
    - @tauri-apps/api [NPM]: 2.0.0-beta.0
    - @tauri-apps/cli [NPM]: 2.0.0-beta.1

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: TypeScript
Issue: Expose design-time type information in TC39 decorator metadata when `emitDecoratorMetadata: true`
Labels: Suggestion,Needs Proposal

### 🔍 Search Terms

decorators, metadata, emitDecoratorMetadata, "TC39 decorators", "type information", reflect-metadata

### ✅ Viability Checklist

- [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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

I want to be able to have design-time type information at runtime after the implementation of the new TC39 decorators system.

After the implementation of the [TC39 decorators](https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#decorators) in Typescript 5.0 the ability to emit design-time type information has been lost unless we keep using the experimental (legacy) decorators system.

The suggestion is to allow to use `emitDecoratorMetadata: true` with `experimentalDecorators: false`. The idea is to expose the same metadata that it was being exposed to `Reflect.metadata("design:type", type)` with the legacy decorators, to the [new metadata system proposed by TC39](https://github.com/tc39/proposal-decorator-metadata) that has been implemented in [Typescript 5.2](https://devblogs.microsoft.com/typescript/announcing-typescript-5-2/#decorator-metadata).

So, instead of using the obsolete `reflect-metadata` like `Reflect.getMetadata('design:type', target, property)`, we can get the same info by doing something like `SomeClass[Symbol.metadata]["design:type"]`.

### 📃 Motivating Example

After the decorators change, many existing and widely used libraries will have problems implementing their behaviors without type information at runtime: [type-graphql](https://github.com/MichalLytek/type-graphql), [inversify](https://inversify.io/), Angular 2,... or any other library which depends on `reflect-metadata`.

### 💻 Use Cases

As explained in the "Motivating Example", there are several existing use cases that require some kind of design-time type information at runtime. My suggestion is to use more or less the same approach you used with the experimental decorators, but with the standard ones. But I will mostly agree to any other approach that makes this information available at runtime.

For now, the workaround is to keep using the experimental decorators and the `reflect-metadata` library (or compatible). But I think it is worth giving the standard ones the same ability to expose this info.
Repository: bitcoin
Issue: Bitcoin OpenRPC Specification
Labels: Feature

### Please describe the feature you'd like to see added.

[OpenRPC](https://open-rpc.org/) is a (human and) machine-readable, programming language-agnostic [JSON-RPC](https://www.jsonrpc.org/) API interface description standard.

### Is your feature related to a problem, if so please describe it.

Having such a document could facilitate e.g. specification driven development, interactive documentation, code generation (documentation / clients), and automation of test cases.

### Describe the solution you'd like

Generate the specification file automatically from [src/rpc](https://github.com/bitcoin/bitcoin/tree/master/src/rpc) documentation.

### Describe any alternatives you've considered

Write the specification "by hand" and update it manually.

### Please leave any additional context


Ideally, Bitcoin core should switch to JSON-RPC version 2.0 (OpenRPC builds on top of JSON-RPC 2.0). In practice, we can still use OpenRPC generated clients as long as the missing `"jsonrpc": "2.0"` is ignored.
 JSON-RPC 2.0 was implemented in implemented in #27101 and #30238.
Repository: material-ui
Issue: [link] Style for external links target="_blank"
Labels: new feature,waiting for 👍,component: link

### Summary

It seems common to differentiate the UI of links that open a new tab from those that work inside the same tab. Maybe it's something to have built into the Link component.

### Examples

| Next.js | WorkOS | Radix | Material UI's docs |
|--------|--------|--------|--------|
| <img width="258" alt="Screenshot 2023-08-05 at 18 28 55" src="https://github.com/mui/material-ui/assets/3165635/16075dd2-aa46-42b1-aba6-f2fc0d108670"> | <img width="165" alt="Screenshot 2023-08-05 at 18 28 29" src="https://github.com/mui/material-ui/assets/3165635/3d7ca450-3fdb-43b5-9538-67a4e33e375e"> | <img width="171" alt="Screenshot 2023-08-05 at 18 28 05" src="https://github.com/mui/material-ui/assets/3165635/98027dea-4476-46fc-911c-f8eba706775b"> | <img width="182" alt="SCR-20240225-rxda" src="https://github.com/mui/material-ui/assets/3165635/cc04d507-4443-42a3-883d-8abb7140c001"> |
Repository: godot
Issue: TopLevel + MouseFilter::PASS doesn't propagate gui_input events to parent
Labels: enhancement,documentation

### Tested versions

GoDot v4.2.1.stable.official [b09f793f5]

### System information

MacOS 14.1.1 - Vulkan API 1.2.231 - Forward+ - Apple M1 Max

### Issue description

Mouse events in `gui_input` don't propagate to parent when child has `Top Level` set to true.

### Steps to reproduce

1. create parent
2. add child to parent
3. set child to top level and mouse filter to pass
4. observe gui_input events in parent area

### Minimal reproduction project (MRP)

[bug.zip](https://github.com/godotengine/godot/files/14397582/bug.zip)
Repository: godot
Issue: Warning ITMS-90999 when uploading to Apple TestFlight with Godot 4.3.dev3
Labels: bug,platform:ios,topic:thirdparty,topic:dotnet

### Tested versions

Reproducible: 4.3.dev3 (I use this version because 4.2 and 4.2.1 trigger an error ITMS-90426 which was fixed)
Not reproducible in: 3.5.2

### System information

macOS Ventura 13.5.11

### Issue description

After uploading a Godot app made with 4.3.dev3 to Apple TestFlight, you'll get an email saying:

"ITMS-90999: Invalid executable - The executable in “[APPNAME].app/Frameworks/[APPNAME].framework” contains multiple segments with the executable permission bit set when it should only contain one."

Btw I have XCode version (15.1)

### Steps to reproduce

Open the any project with Godot  4.3.dev3
Export to iOS
Archive with XCode and upload it to TestFlight/AppStore
After some minutes you'll receive an ITMS-90999 warning on your email.
**Keep in mind that building locally will result in a fully functional app**, this warning only shows up when Apple process the app bundle.

### Minimal reproduction project (MRP)

[ITMS-90999.zip](https://github.com/godotengine/godot/files/14397703/ITMS-90999.zip)
Repository: godot
Issue: SurfaceTool generate_normals seems broken
Labels: bug,confirmed,topic:import,topic:3d

### Tested versions

4.2.1.stable.official

### System information

Windows 10

### Issue description

Having godot generate the normals from loaded meshes seems to produce terrible outputs.
In the example below I just loaded an `ArrayMesh`, tossed it to `SurfaceTool` as surface arrays and called commit after generating normals, no changes were made.

Left side the mesh loaded directly to a `MeshInstance3D`, on the right the one that went through the `SurfaceTool`, the issue is quite noticeable on he arms

![image](https://github.com/godotengine/godot/assets/106078/6a014cdf-1194-4a2b-9ff6-2d0178a1e214)

[EDIT]

On further inspection, it doesn't seem to be something related to normals themselves, tested manually creating the normals and the result was the same, tested the exact same code that creates normals manually on Godot 3 and it seems to work just fine.

![image](https://github.com/godotengine/godot/assets/106078/d9ad52a8-3650-45c2-a439-f387e679892a)


### Steps to reproduce

Read above

### Minimal reproduction project (MRP)

[generate_noormals.zip](https://github.com/godotengine/godot/files/14397758/generate_noormals.zip)