sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: svelte
Issue: Use ContextKey<T> to type setContext, getContext and hasContext
Labels: feature request,types / typescript

### Describe the problem

Currently `getContext` returns `unknown` if no explicit type is provided.
<img width="246" alt="image" src="https://github.com/sveltejs/svelte/assets/29802592/6a43ce63-2277-466e-b399-943d726751b1">


### Describe the proposed solution

Taking inspiration from [`svelte-typed-context`](https://www.npmjs.com/package/svelte-typed-context), `getContext` can accept an ~~`InjectionKey<T>`~~`ContextKey<T>` and return `T`:
<img width="329" alt="image" src="https://github.com/sveltejs/svelte/assets/29802592/f0184feb-031f-41ac-bd13-606769af1c00">

This will improve type safety ~~and can be done in a backwards compatible way~~.

The implementation would be just to add a new signature to `getContext`, `setContext` and `hasContext`
```ts
export interface ContextKey<T = unknown> { }
export function setContext<T>(key: ContextKey<T>, context: T): void
// getContext ...
// hasContext ...
// check for full implementation here:
// https://github.com/KamenKolev/svelte-typed-context/blob/master/index.ts
// (published npm package does not include `hasContext`, so install only from github)
```


### Alternatives considered

-

### Importance

nice to have

#### Search terms

typed context inject provide
Repository: godot
Issue: "convert_text_resources_to_binary_on_export" breaks "EditorExportPlugin._export_file"
Labels: bug,topic:export

### Godot version

3.5, 3.5.2, 3.6 beta2

### System information

Windows 10

### Issue description

When ProjectSettings `editor/convert_text_resources_to_binary_on_export` is enabled, [EditorExportPlugin._export_file](https://docs.godotengine.org/en/3.6/classes/class_editorexportplugin.html#class-editorexportplugin-method-export-file) won't be called for any PackedScene.

Related issue: https://github.com/godotengine/godot/issues/67844 (a more serious issue, which makes EditorExportPlugin not working half of the time.)

This is fixed in Godot 4.1.beta2, meaning the behavior is the same, no matter `editor/convert_text_resources_to_binary_on_export` is enabled or not. Although some other file types are missing in 4.1.beat2, but not in 3.6.beta2.

Also, `editor/convert_text_resources_to_binary_on_export` is documented in 4.x, but not in 3.6.beta2.

### Steps to reproduce

1. download the minimal reproduction project.

2. disable `editor/convert_text_resources_to_binary_on_export` in project settings.
3. export for any platform.
4. see output, _export_file is called for `.tscn`, `.tres`, .`ogv`, .`otf`, `.shader` files. 

5. enable `editor/convert_text_resources_to_binary_on_export` in project settings.
6. export for any platform.
7. see output, only `.ogv`, `.otf`, `.shader`. 


### Minimal reproduction project

[EditorExportPluginBug.zip](https://github.com/godotengine/godot/files/11991410/EditorExportPluginBug.zip)
Repository: godot
Issue: KinematicBody2D Shake on Collision with another KinematicBody2D
Labels: bug,topic:physics,needs testing

### Godot version

4.1

### System information

Godot v4.1.stable - Windows 10.0.19045 - OpenGL (Compatibility) - GeForce GT 630M () - Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz (8 Threads)

### Issue description

Inside one of my 2D level scenes, I have two players (each an instance of the same scene). One of the players has inverted controls while the other one has normal controls. If both of the players collide, they create a shake and seem to not collide (see the video below). This is unpredictable and happens on all sides but when the top and bottom sides collide.

https://github.com/godotengine/godot/assets/111152655/58971f09-b474-46ff-8527-0bef13085906


### Steps to reproduce

Using my minimal reproduction product, follow these steps:

1. Open Godot specifying OpenGL3 rendering device: ```>>> C:/path/to/godot --rendering-driver opengl3```
2. Open minimal reproduction product
3. Run ```level.tscn``` (make sure you are using Compatibility rendering driver)

### Minimal reproduction project

[shake_issue.zip](https://github.com/godotengine/godot/files/11992301/shake_issue.zip)
Repository: godot
Issue: The Movie Maker button tooltip isn't grammatically correct
Labels: discussion,topic:editor

### Godot version

4.1.stable

### System information

Godot v4.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 with Max-Q Design (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 Threads)

### Issue description

Not sure if this counts as an "issue" or not. The Movie Maker tooltip contains the text: `"The project will run at stable FPS..."` Shouldn't it be `"The project will run at a stable frame rate"`? 

![image](https://github.com/godotengine/godot/assets/89754713/776388d4-0778-43b7-b26c-f4223a69f7e4)

### Steps to reproduce

Hover over the movie maker button in the editor.

### Minimal reproduction project

N/A
Repository: stable-diffusion-webui
Issue: [Feature Request]: filename pattern control for created files in batch operations
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Several locations in the UI allow for batch operations on directories of image files. It would be useful to have a text field where the filename creation pattern could be specified. Something like how **ffmpeg** allows passing of **printf format strings** ought to be familiar to many. 

Currently, for example, the **Batch from Directory** UI on the **Extras** tab adds a "-0000" to the end of the source filename, which for my preferences is undesirable. 

It would be more flexible if the end-user could supply a filename pattern, something like "test23_%04d" would generate filenames starting with "test23_" and then have 4 digits for the  frame/file number, with leading zeros.

I recall that selecting the output file format is already located in the **Settings** Tab, so in my example here I am not supplying the created file's extension. Considering end-users already set the output file format in the **Settings** Tab, that might be an option to consider, locating these output filenames at that same location in the **Settings** Tab, and perhaps put a text note on the various Batch UIs that filename creation control is available on the **Settings*** Tab.

### Proposed workflow

1. Go to **ControlNet's Batch Tab**, or the I**mg2Img Tab's Batch Tab**, or the **Extra Tab's Batch from Directory Tab**, etc... (or just go to the single location on the **Settings** Tab to set this same purposed Output format string for use on these various other tabs.)
2. In addition to a text field to specify the Output directory for the Batch operation, one many _optionally_ fill out an Output Filename Pattern.
3. The rest of the UI an operations remain unaltered. Triggering the Batch operation now uses the _optional_ end-user given filename pattern when generating batch outputs.

Using something like the C Language's printf format string is somewhat common, ffmpeg does it, and I seem to recall it being used in other media software to provide the output filename pattern for a series of files. Reference if you need a refresher: https://www.tutorialspoint.com/c_standard_library/c_function_printf.htm


### Additional information

_No response_
Repository: deno
Issue: Deno OpenKv in Remix
Labels: ext/kv

I was lucky enough to try out Deno OpenKv on deno deploy's beta. But I ran into some issues when attempting to use Remix with it. It works fine if I want to consistently open and close the connection and with some effort I was able to put together a Kv class that I could use to open the connection and use it without issue. I came across something strange with my setup for atomic in particular though.


```ts
// db.server.ts
export class Kv {
	db: DenoKv | undefined;
	ready = false;
	retries: number;
	constructor(retries = 3) {
		Deno.openKv().then(connection => {
			this.db = connection;
			this.ready = true;
		});
		this.retries = retries;
	}
	async requireConnection() {
		let attempts = 1;
		while (!this.ready && attempts <= this.retries) {
			await new Promise(resolve => setTimeout(resolve, 150 * attempts));
			attempts++;
		}
		if (this.ready) {
			return;
		}
		throw new Error("Unable to acquire database connection.");
	}
	async atomic() {
		await this.requireConnection();
		console.log(this.db);
		if (this.db === undefined)
			throw new Error("Database is ready but connection is undefined.");
		return this.db.atomic;
	}
}
const db = new Kv();
export default db;
```

```ts
     // Blogs.server.ts
    // Attempting to use my atomic Kv.atomic method like so caused errors
			res = await db.atomic().then(atomic => {
				return atomic()
					.check(getBlog)
					.delete([BlogKey, id])
					.commit();
			});
```
The error message I received was:

`TypeError: Cannot read properties of undefined (reading '#rid')`

My basic usage pattern since I have no top level await is to always call the requireConnection method and then use my database as normal with extra wrapper functions for my specific use cases. All of these worked exactly as I wanted, just not atomic. My solution to get atomic working is instead just make a method that returns a DenoKv instance rather than my class wrapper, then I can use atomic with no issues. Initially my atomic method called db.atomic() and returned that result, but I was always getting an error thrown saying something along the lines of:

`You cannot await deno atomic() please make sure to commit it` 

Even though my later usage did in fact commit. That's what made me return the db.atomic as an uncalled method, but doing so resulted in the TypeError. A lot of this code is probably far from the best solution and any other work arounds or suggestions would be appreciated, given the only constraint of no top level await. Ideally I'd like to be able to use atomic similarly to how I've described it here, or be given an option like what Prisma does where you can instantiate the new Client and call the connect method. My understanding is the connect method is attempting to connect in the background and ensures it's connected before any actual database query goes out. Perhaps that's out of scope for Deno Kv.
Repository: pytorch
Issue: MPS matmul with sliced (strided) out argument produces wrong output, may corrupt memory
Labels: triaged,module: correctness (silent),module: mps

### 🐛 Describe the bug

When using `torch.matmul` with an `out` argument that is a view that is not contiguous, the op has no change to the `out` argument instead of computing the matmul correctly. Here is a minimal example that replicates the behavior. It seems to happen consistently across many different sizes (i.e. the `256` here can be changed to something else and it still outputs zeros).

```
import torch

X = torch.randn(256,256).to("mps")
Y = torch.randn(256,256).to("mps")
Z = torch.zeros(256,2*256).to("mps")

torch.matmul(X,Y,out=Z[:,128:(128+256)])
```

Here, `torch.matmul` both outputs all zeros and does not change `Z`. Compare the behavior of the non-MPS code

```
import torch

X = torch.randn(256,256)
Y = torch.randn(256,256)
Z = torch.zeros(256,2*256)

torch.matmul(X,Y,out=Z[:,128:(128+256)])
```

which runs correctly and produces a non-zero output.

After doing this, I sometimes get segfaults in my program, which suggests that this is also corrupting memory, although I am unable to find any code that consistently replicates this segfault behavior.

### Versions

Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.4 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.26.3
Libc version: N/A

Python version: 3.9.13 (main, Aug 25 2022, 18:24:45)  [Clang 12.0.0 ] (64-bit runtime)
Python platform: macOS-13.4-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M2 Max

Versions of relevant libraries:
[pip3] numpy==1.24.0
[pip3] pytorch-pretrained-bert==0.6.2
[pip3] torch==2.0.1
[pip3] torchaudio==0.13.1
[pip3] torchdata==0.6.1
[pip3] torchtext==0.15.2
[pip3] torchvision==0.13.1
[conda] htorch                    0.1                      pypi_0    pypi
[conda] numpy                     1.24.0                   pypi_0    pypi
[conda] pytorch-pretrained-bert   0.6.2                    pypi_0    pypi
[conda] torch                     2.0.1                    pypi_0    pypi
[conda] torchaudio                0.13.1                 py39_cpu    pytorch
[conda] torchdata                 0.6.1                    pypi_0    pypi
[conda] torchtext                 0.15.2                   pypi_0    pypi
[conda] torchvision               0.13.1                   pypi_0    pypi

cc @kulinseth @albanD @malfet @DenisVieriu97 @jhavukainen @razarmehr @abhudev
Repository: rust
Issue: Unclear error when trying to write high-order function accepting an `async` function that itself takes a reference
Labels: A-type-system,A-diagnostics,A-lifetimes,P-medium,C-bug,A-async-await,AsyncAwait-Triaged,D-confusing,D-terse,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 this code:

```rust
use std::future::Future;

struct X;

trait Tx {}

fn main() {
    higher_order(f_x);
    higher_order_x(f_x);

    higher_order(f_tx);
    higher_order_tx(f_tx);

    higher_order_tx_nf(f_tx_nf);
}

fn higher_order<I, FUT>(_f: fn(I) -> FUT)
where
    FUT: Future<Output = ()>,
{
}

fn higher_order_x<FUT>(_f: fn(X) -> FUT)
where
    FUT: Future<Output = ()>,
{
}

fn higher_order_tx<FUT>(_f: fn(&dyn Tx) -> FUT)
where
    FUT: Future<Output = ()>,
{
}

fn higher_order_tx_nf(_f: fn(&dyn Tx) -> ()) {}

async fn f_x(_input: X) {}

async fn f_tx(_input: &dyn Tx) {}

fn f_tx_nf(_input: &dyn Tx) {}
```

I expected the code to compile without errors

Instead, I got a compilation error only for the line `higher_order_tx(f_tx);` in `main`:
```
error[E0308]: mismatched types
  --> general/src/bin/higher_order_async.rs:12:21
   |
12 |     higher_order_tx(f_tx);
   |     --------------- ^^^^ one type is more general than the other
   |     |
   |     arguments to this function are incorrect
   |
   = note: expected fn pointer `for<'a> fn(&'a (dyn Tx + 'a)) -> _`
                 found fn item `for<'a> fn(&'a (dyn Tx + 'a)) -> impl Future<Output = ()> {f_tx}`
   = note: when the arguments and return types match, functions can be coerced to function pointers
note: function defined here
  --> general/src/bin/higher_order_async.rs:29:4
   |
29 | fn higher_order_tx<FUT>(_f: fn(&dyn Tx) -> FUT)
   |    ^^^^^^^^^^^^^^^      ----------------------
```


### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

I am using the stable version below. With the current nightly version `rustc 1.72.0-nightly (83964c156 2023-07-08)`, I get `error[E0635]: unknown feature 'proc_macro_span_shrink'`.

`rustc --version --verbose`:
```
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>
Repository: rust
Issue: Overflow evaluating requirement for an unusued type when function has generic lifetime parameters
Labels: A-type-system,C-bug,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 this code:

```rust
#![recursion_limit = "8"]

use std::ops::Mul;

fn test<'a, T: 'a>() {
    17 * Foo;
}

#[derive(Clone, Copy)]
struct Foo;

impl Mul<Foo> for u32 {
    type Output = u32;
    
    fn mul(self, other: Foo) -> u32 {
        self
    }
}

struct Wrap<T>{
    t: T,
}

impl<T: Copy> Mul<Wrap<T>> for u32 where u32: Mul<T, Output = T> {
    type Output = Wrap<T>;
    
    fn mul(self, other: Wrap<T>) -> Self::Output {
        Wrap {
            t: self * other.t,
        }
    }
}
```

I would expect this compile.

Instead, I get this error:

```
error[[E0275]](https://doc.rust-lang.org/stable/error_codes/E0275.html): overflow evaluating the requirement `u32: Mul<Wrap<_>>`
  --> src/lib.rs:6:8
   |
6  |     17 * Foo;
   |        ^
   |
   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "16"]` attribute to your crate (`playground`)
note: required for `u32` to implement `Mul<Wrap<Wrap<_>>>`
  --> src/lib.rs:25:15
   |
25 | impl<T: Copy> Mul<Wrap<T>> for u32 where u32: Mul<T, Output = T> {
   |               ^^^^^^^^^^^^     ^^^                   ---------- unsatisfied trait bound introduced here
   = note: 6 redundant requirements hidden
   = note: required for `u32` to implement `Mul<Wrap<Wrap<Wrap<Wrap<Wrap<Wrap<Wrap<Wrap<_>>>>>>>>>`

For more information about this error, try `rustc --explain E0275`.|
```
I reduced the recursion limit to make the output smaller, but this still happens with default recursion. 

The function `test` doesn't involve the type `Wrap` at all. If everything involving `Wrap` is removed then the code compiles.

If the function `test` is removed or the (unused) generic parameters are removed, then the code compiles.

In order for the bug to occur, the function `test` needs to have a lifetime parameter and another parameter which depends on that lifetime parameter (the signature `fn test<'a, 'b: 'a>()` also causes the bug). I couldn't get this to happen without using lifetimes.

Several closely related issues have been mentioned in this thread: [https://github.com/rust-lang/rust/issues/39959](https://github.com/rust-lang/rust/issues/39959). Some of the specific behavior here seems unique to this example as far as I can tell.
### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2

```
</p>
</details>
Repository: godot
Issue: Crash when using inline image of specific size in RichTextLabel within ScrollContainer
Labels: bug,crash,regression,topic:gui

### Godot version

v4.1.stable.official [970459615]

### System information

Godot v4.1.stable - Windows 10.0.19045 - Vulkan (Compatibility) - NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.1702) - AMD Ryzen 7 5800 8-Core Processor (16 Threads)

### Issue description

When creating a RichTextLabel, within a VBoxContainer together with a texture that can expand. All of this within a ScrollContainer, the game will crash if you append_text with an inline image of a specific size. The size has a three pixel crash margin in my case, probably corresponding with the size of the expandable texture. It's a hard crash, with the only error being  
_ERROR: Failed method: CanvasItem::_redraw_callback. Message queue out of memory. Message queue out of memory. Try increasing 'memory/limits/message_queue/max_size_mb' in project settings.
   at: push_callablep (core/object/message_queue.cpp:96)_
Obviously increasing the memory limits does nothing.

Here's a video of it:
[InlineImageCrash.webm](https://github.com/godotengine/godot/assets/139037401/9fc8ea7f-d3a2-40c4-bd49-88a775ad2bd9)

My best guess is that at a specific inline image size, both the texture and the RichTextLabel try to expand and then shrink at the same time, causing some funky behaviour with the ScrollContainer and breaking everything.

I also reproduced this issue in Godot 4.0.2, with all different renderers, and on a different laptop with Windows 11.

### Steps to reproduce

See the minal reproduction project. Press the crash button to crash the game, this button will every frame put an inline image of one pixel larger in the RichTextLabel until the required size is reached to crash the game. The crash happens at size 94.



### Minimal reproduction project

[RichTextLabelInlineImageCrash.zip](https://github.com/godotengine/godot/files/11994608/RichTextLabelInlineImageCrash.zip)
Repository: svelte
Issue: Allow `role="application"` as an interactive ARIA role
Labels: a11y

### Describe the problem

Unable to resolve accessibility warnings ([no-interactive-element-to-noninteractive-role](https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/no-interactive-element-to-noninteractive-role.md)) for elements that are not described by [exisiting ARIA widget roles](https://www.w3.org/TR/wai-aria-1.1/#widget_roles)

For example, the `Cropper` component from [Svelte Easy Crop](https://github.com/ValentinH/svelte-easy-crop) does match any of the other ARIA widget role descriptions.

### Describe the proposed solution

This can be resolved by also allowing `role="application"` as an interactive role.

This is allowed by [the spec](https://www.w3.org/TR/wai-aria-1.1/#application):

> When there is a need to create an element with an interaction model that is not supported by any of the WAI-ARIA `widget` roles, authors **_MAY_** give that element role `application`.

And also an see example of it out in the wild:

https://www.darins.page/articles/screen-readers-drag-drop-1#what-were-testing

### Alternatives considered

N/A

### Importance

nice to have
Repository: TypeScript
Issue: Enable `noExplicitAny` in `./tsconfig.json`.
Labels: Suggestion,Needs Proposal

## ⭐ Suggestion & 📃 Motivating Example & 💻  Use Cases

The following `.js` code, in project with a `./tsconfig.json` that has `allowJs:true`, `checkJs:true`,`noImplicitAny:true`, does not lint error:

```js
const mySet = new Set;
const myMap = new Map;
const myWeakMap = new WeakMap;
const myArray = [];
const myObj = {};
```

It would be nice to lint error for those cases when `noExplicitAny:true` is used.

## 🔍 Search Terms

* `noExplicitAny`
* TypeScript compiler API
* `./tsconfig.json`
* `allowJs`
* `checkJs`

## ✅ Viability 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, 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).