sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: [C#] Unable to assign an image to TileSetAtlasSource texture
Labels: discussion,topic:2d

### Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

### System information

Godot v4.1.1.stable.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; 31.0.15.2824) - Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz (8 Threads)

### Issue description

If you create an Image in c# and try to assign it to TileSetAtlasSource object error is being thrown stating that image size is equal to 0 when its not. The same code works perfectly fine when run in GDScript but C# version does not work.



### Steps to reproduce

C# code that throws exceptions:
```cs
Image image = Image.Create(2, 2, false, Image.Format.Rgba8);
image.Fill(new Color(1, 0, 0));
TileSetAtlasSource tileSetAtlasSource = new()
{
  Texture = ImageTexture.CreateFromImage(image)
};
```

Exact same GDScript code that works perfectly fine as it should:
```GDScript
var image: Image = Image.create(2,2, false, Image.FORMAT_RGBA8)
image.fill(Color.RED)
var tileSetAtlasSource:TileSetAtlasSource = TileSetAtlasSource.new();
tileSetAtlasSource.texture = ImageTexture.create_from_image(image)
```

The exception content is as follows:

```
E 0:00:01:0264   initialize_data: The Image width specified (0 pixels) must be greater than 0 pixels.
  <C++ Error>    Condition "p_width <= 0" is true.
  <C++ Source>   core/io/image.cpp:2155 @ initialize_data()
```

```
E 0:00:01:0269   set_image: Invalid image
  <C++ Error>    Condition "p_image.is_null() || p_image->is_empty()" is true.
  <C++ Source>   scene/resources/texture.cpp:181 @ set_image()
```



### Minimal reproduction project

N/A
Repository: PowerToys
Issue: Bug Report: PowerToys Run: Paste As Plain Text utility affects Windows clipboard formatting
Labels: Issue-Bug,Needs-Triage,Product-Advanced Paste

## PowerToys Run: Paste As Plain Text utility overwrites Windows clipboard content and removes formatting from copied text

### Microsoft PowerToys version

0.72.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Paste as Plain Text

### Bug description

The Paste As Plain Text utility in PowerToys Run alters the Windows clipboard content and removes the formatting. This causes the text to be pasted as plain text in other applications, even when using the Windows clipboard.

### Steps to reproduce

1) Copy a formatted text that has links and formats, for example this text:
Link to [FrontPage](https://wiki.c2.com/?FrontPage)

2) Paste it as a plain text using the Paste As Plain Text utility's shortcut inside PowerToys Run, for example this pasted text:
Link to FrontPage

3) Press Win + V for the Windows clipboard and paste the text again in another application.
You will see that the text is pasted as a plain text instead of a formatted text.

### ✔️ Expected Behavior

The Windows clipboard should preserve the original formatting of the copied text and paste it accordingly in other applications.

### ❌ Actual Behavior

The Windows clipboard loses the formatting of the copied text and pastes it as a plain text in other applications.

### Other Software

_No response_
Repository: next.js
Issue: Top level await (experimental) not working with Server Actions called from Client Components
Labels: bug,linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
    Binaries:
      Node: 20.5.1
      npm: 9.8.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)



### Link to the code that reproduces this issue or a replay of the bug

https://github.com/k-allagbe/my-app-canary.git

### To Reproduce

- Run "npm run dev"
- In the web page, click "Upload" to call the server action
- result: error SyntaxError: await is only valid in async functions and the top level bodies of modules


### Describe the Bug

The provided code is an example of using Top Level Await in a file containing Server Actions called from a Client Component. This is relevant because, my actions might depend on frameworks that use top level awaits.

The result shows that calling Server Actions from Client Components doesn't work when the Server Action file involves top level await.

The problem is not observed with Server Components.

### Expected Behavior

I expected to be able to call my Server Action from a Client Component even if a Top Level Await is involved in the Server Action file, because I might use some frameworks that rely on Top Level Awaits.



### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

<sub>[NEXT-1540](https://linear.app/vercel/issue/NEXT-1540/top-level-await-not-working-with-server-actions-called-from-client)</sub>
Repository: godot
Issue: `new` function of custom classes has no parameter hints
Labels: bug,topic:gdscript,topic:editor

### Godot version

v4.2.dev.custom_build [eca6f0eb5]

### System information

Windows 10, Forward+, NVIDIA GeForce GTX 1050 Ti (31.0.15.3179)

### Issue description

When creating a custom class with a custom `_init` function, creating an instance of that class does not show parameter hints like for other function calls.

Custom Class definition:
![custom_class](https://github.com/godotengine/godot/assets/10490534/9af7c0f6-2ad3-46ab-aeae-5a889bc60495)
Calling `new` incorrectly shows no parameter hints:
![custom_class_init](https://github.com/godotengine/godot/assets/10490534/04f7bc22-dd60-4385-8ac0-dd9e60bd25dd)
Calling `func1` correctly show parameter hints:
![custom_class_func](https://github.com/godotengine/godot/assets/10490534/17ca6d6e-b539-4824-b084-f3decdfb7ac1)


### Steps to reproduce

* Create a custom class like shown in Issue description.
* Attempt to create the class using `new`.
* Observe that there are no parameter hints like when calling other functions.

### Minimal reproduction project

N/A
Repository: transformers
Issue: Add MovieChat Model
Labels: New model

### Model description

MovieChat proposes a Vision Foundation model + LLM + Long short-term memory-based solution to long-range video understanding addressing computation, memory, and long-range temporal understanding challenges using transformer model tokens as a fixed amount of memory.
Project Page: https://rese1f.github.io/MovieChat/

### Open source status

- [X] The model implementation is available
- [X] The model weights are available

### Provide useful links for the implementation

Paper: https://arxiv.org/abs/2307.16449
Github: https://github.com/rese1f/MovieChat
Repository: excalidraw
Issue: [Feature Request] Enhance Frames to Function Like Rectangles in Excalidraw
Labels: frames

It would be great if Frames in Excalidraw could function similarly to rectangles. With rectangles, users can easily center drawings using the "Align" utilities. Unfortunately, such tools are not available for frames. Integrating this feature would significantly improve the user experience, especially when centering elements for slideshows.
Repository: material-ui
Issue: [Autocomplete][docs] Playground Examples are... too similar?
Labels: docs,component: autocomplete

### Duplicates

- [X] I have searched the existing issues

### Related page

https://mui.com/material-ui/react-autocomplete/#playground

### Kind of issue

Unclear explanations

### Issue description

While exploring the Autocomplete component's documentation, I noticed the playground playground section (https://mui.com/material-ui/react-autocomplete/#playground) doesn't seem to adequately demonstrate the differences between the various properties.

Most of the examples, irrespective of the selected properties, appear functionally identical. This makes it challenging to discern the unique behaviors and benefits of each property just from the playground.

I typed "as" in every one of the fields, and the same list of options was presented, even with the "includeInputInList" examples, which I would have expected to add "as" into the options list; did not appear to do anything differently from the others.

### Context 🔦

_No response_
Repository: godot
Issue: Copying and pasting styles in a `Theme` creates new ones instead of reusing them
Labels: bug,topic:editor,regression

### Godot version

4.0.dev [5444afa]

### System information

N/A

### Issue description

When copying and pasting a `StyleBox*` resource from one item to another inside a `Theme` resource, instead of making both items use the same one, it just creates a new replica of it.

### Steps to reproduce

- Create a new `Theme` resource and save it to a file.
- Give any item a `StyleBox*` resource, then copy and paste it to another one.
- Save, and then open the `Theme`'s file, and see that two different resources are in use.

### Minimal reproduction project

N/A, trivially reproducible.
Repository: rust
Issue: Tracking issue for future-incompatibility lint `elided_lifetimes_in_associated_constant`
Labels: A-lints,A-lifetimes,A-associated-items,T-compiler,C-future-incompatibility,C-tracking-issue,T-types

This is a tracking issue for the `elided_lifetimes_in_associated_constant` future-incompatibility lint.

The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our [breaking change policy guidelines](https://github.com/rust-lang/rfcs/blob/master/text/1589-rustc-bug-fix-procedure.md).

### What

The `elided_lifetimes_in_associated_constant` lint detects elided lifetimes that became erroneously allowed in associated constants after #97313.

```rust
struct Foo<'f>(&'f ());
impl Foo<'_> {
    const STR: &str = "hello, world";
}
```

They current desugar to fresh early-bound lifetimes on the parent impl, like:
```rust
struct Foo<'f>(&'f ());
impl<'__a> Foo<'_> {
    const STR: &'__a str = "hello, world";
}
```

This is in contrast to the way that elided lifetimes are treated in item-level consts (where elided lifetimes are resolved to `'static`), and this behavior was also never formally decided -- static-in-const lifetime rules do not apply to associated consts (https://github.com/rust-lang/rfcs/pull/1623#issuecomment-239559757, https://github.com/rust-lang/rust/issues/38831#issuecomment-305864245).

### Why

It was never decided what to do with elided lifetimes in consts, and it is not clear that the current behavior is optimal here. This is to stop the leaking by making sure existing elided lifetimes are fixed back to using `'static` as they were required to before version 1.64, and that new usages of elided lifetimes in consts are not introduced.

### How to fix

Replace the elided lifetimes with `'static` (or manually introduce or reference another lifetime):

```rust
struct Foo;
impl Foo {
    const STR: &'static str = "hello, world";
}
```

### Tracking

* [x] Initial implementation: #115011
* [x] https://github.com/rust-lang/rust/pull/124211
* [x] https://github.com/rust-lang/rust/pull/125258
* [ ] Make it a hard error
Repository: godot
Issue: Hang trying to close game window when debugging code
Labels: bug,topic:core,topic:editor,confirmed

### Godot version

4.2.dev3

### System information

Windows 10

### Issue description

Run your game with a breakpoint in it
When Godot reaches the breakpoint, the game window stays active instead of swapping to the debugger
If you try to close the game window (using the "X" in the top right corner of the window) the process hangs and needs to be forcefully terminated. This does not happen if you hit "stop" in the debugger

### Steps to reproduce

As above

### Minimal reproduction project

N/A
Repository: godot
Issue: Adding scene via thread doesn't produce similar result as when they are called normally 
Labels: bug

### Godot version

3.5.2

### System information

Linux

### Issue description

Result should be same 
- Either when called "Normally"
- Or called via "Thread"

Kindly check the sample project, 
3 Scenes
- world.tscn
- map.tscn
- player.tscn

Some sprites(Icon3 and Icon4) are kept hidden inside "map.tscn" scene (visible = false)
now when I load the "map.tscn" via thread and add it, those hidden sprite remains hidden
this shouldn't happen as in the _ready function of the "map.tscn" I am un-hiding (visible = true) those sprites
https://github.com/godotengine/godot/assets/32230892/9ec6ef03-2a9e-4b54-8628-838ad8157794


Also this looks strange though, "visible = true" for Icon3 and Icon4, still they are not visible.
If I toggle in the remote, it will show up
![Screenshot_20230820_061010_2](https://github.com/godotengine/godot/assets/32230892/5b3fd1a4-6c88-4db1-8aec-ef24c4cd37d4)




Actually, I was working over a multiplayer and wanted not to block the main thread when loading a level cause it sends/receives  RPC calls
So I decided to load level(map) and player and add it to the scene using thread and I came around this problem
It would be a great if you please look into this issue and provide a solution too.





### Steps to reproduce

Attached a sample project
Open and run

to run normally or via thread make comment/un-comment  in 
"world.gd", 
```
	# NORMAL CALL
#	loader()
	
	# CALL via THREAD
	thread = Thread.new()
	thread.start(self, "loader", null)
```


### Minimal reproduction project

[thread_instance_problem.zip](https://github.com/godotengine/godot/files/12386968/thread_instance_problem.zip)
Repository: tensorflow
Issue: docs: spurious favicon in template
Labels: type:docs-bug,stat:awaiting tensorflower

I can’t work out where the template for this lives, but the Tensorflow docs (at least the homepage and a couple of random pages I spot-checked) have a spurious favicon link to an image that doesn’t exist:

<pre>&lt;link href="<a href="https://www.tensorflow.org/static/en/site-assets/images/marketing/favicon.png">/static/en/site-assets/images/marketing/favicon.png</a>" rel="shortcut icon"/&gt;</pre>

This is shadowed by another `<link>` page earlier in the head and so doesn’t seem to be causing any immediate problems, but it still seems like it might be a good idea to clean it up.
Repository: TypeScript
Issue: Unreachable returns badly break return type inference
Labels: Suggestion,Awaiting More Feedback

### 🔎 Search Terms

unreachable any return

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about `let`

### ⏯ Playground Link

https://www.typescriptlang.org/play?target=7&jsx=0&ts=5.2.0-beta&allowUnreachableCode=true#code/GYVwdgxgLglg9mABMAFASgN6IPTcQBwCc58BTQgGwE9FDThy6ATRAQwGdEwQBbAI3IAoAJAVSURAA8A3FMQBeRAEZZdKCEJIZI3IgBypSRIowwpREzilOYOBNbAG0WuI1IoVMolMM6kUgBcIpIKiABEwHBwYYIAvoKgkLAIiADm6Fi6PoykLBxsYFQiYhIycooqLuqaUtI6eAZGiCZmiADWMBQUnGpuiB5e2X4QgSK9NdrxidDwSAAWGTh4Q8xsnKyFY641KvX6hsam5h1dPdvunuZDpP5BouKIVLI0Farnj3XxQA

### 💻 Code

```ts
function f(){ // properly referred as number
	let x; x = 1; return x;
	// Next line does not affect return type inference:
	x = "foo"
}
function g(){ // inferred as any
	let x; x = 1; return x;
	// Next line kills return type inference:
	return x;
}
function h(){ // inferred as any
	return 1;
	// Next line kills return type inference:
	let y; y = 1; return y;
}
```

### 🙁 Actual behavior

The types are inferred as:

```ts
declare function f(): number;
declare function g(): any;
declare function h(): any;
```

The case of `f` demonstrates that return types based on assignment to mutable variables *can* work. The unreachable assignment to `x` after return has no effect on the return type.

In the case of `g`, the return type should be unaffected - `x` is already inferred to be `number` and an extra return does not change the type of `x`.

In the case of `h`, the return type should be unaffected as well. The second return can be inferred to be `number`.

### 🙂 Expected behavior

The types should be inferred as:
```ts
declare function f(): number;
declare function g(): number;
declare function h(): number;
```

Either unreachable return statements should not affect return type or `return` should not stop type inference.

Also, the code should be flagged by the `noImplicitAny` rule.

### Additional information about the issue

possibly related to #40393
likely related to #26914

Disabling `allowUnreachableCode` does not alleviate these issues.
Repository: rust
Issue: Consistent messaging for  "addresses aren't real when compiling"
Labels: A-diagnostics,A-docs,A-const-eval

### Location

This affects the documentation of various stdlib pointer functions and also the diagnostic output of the compiler when the errors this problem generates are encountered while compiling.

### Summary

The current messaging that expresses "const-eval allocations are each kinda assigned to what amounts to their own address spaces, rather than given a random address somewhere in a unified flat address space" uses a somewhat vague "the distance between allocations is not known". Technically this is correct. However, I think it doesn't quite do justice to the model not requiring the allocations to _have_ something you could measure as a distance. It sounds a bit like a cop-out, rather than something inherently unsatisfiable in the current implementation's model.

This could be changed, but there's a few different places which should be run down and changed at once so it can remain consistent.
Repository: rust
Issue: opaque type needlessly inferred to be recursive
Labels: A-impl-trait,C-bug,F-type_alias_impl_trait,T-types

The following code should compile. However we infer two conflicting hidden types, `Opaque<A> := Opaque<A>` and `Opaque<B> := u8`, causing an error:
```rust
#![feature(type_alias_impl_trait)]
type Opaque<T> = impl Sized;
fn test<A, B>(
    arg: Vec<(Opaque<A>, u8)>,
) -> impl IntoIterator<Item = (Opaque<A>, Opaque<B>)> {
    arg
    //~^ ERROR concrete type differs from previous defining opaque type use
    //~| expected `Opaque<T>`, got `u8`
}
```

Another case to show that it is not enough to naively ignore the recursive definition, as it may have different arguments (`Opaque<'a, 'b> := Opaque<'static, 'static>`).
```rust
#![feature(type_alias_impl_trait)]

type Opaque<'a, 'b> = impl Sized + 'a + 'b;
//~^ ERROR concrete type differs from previous defining opaque type use
//~| expected `Opaque<'static, 'static>`, got `()`

// `Opaque<'a, 'b> := ()`
fn get_one<'a, 'b>() -> Opaque<'a, 'b> {}

// `Opaque<'a, 'b> := Opaque<'static, 'static>`
fn get_iter<'a, 'b>() -> impl IntoIterator<Item = Opaque<'a, 'b>> {
    Some(get_one())
}
```

Normally when we encounter an equality `Opaque<A> == Opaque<A>`, we equate substs and never register a hidden type.

The only way we infer an opaque type to be recursive in borrowck is through `replace_opaque_types_with_inference_vars` here:
https://github.com/rust-lang/rust/blob/82c5732b9ab4473c65d426866e67e8fdb23243fb/compiler/rustc_trait_selection/src/traits/project.rs#L319-L328
Repository: PowerToys
Issue: PowerRename directly extracts the currently selected content as input.
Labels: Idea-Enhancement,Product-PowerRename,Needs-Triage

### Description of the new feature / enhancement

PowerRename directly extracts the currently selected content as input.

### Scenario when this would be used?

PowerRename directly extracts the currently selected content as input.

### Supporting information

_No response_
Repository: godot
Issue: Project settings window not refreshed after an editor plugin adds/removes project setting(s)
Labels: bug,topic:editor,confirmed,topic:plugin

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated AMD Radeon RX 6700 XT (Advanced Micro Devices, Inc.; 27.20.21034.37) - AMD Ryzen 7 5700X 8-Core Processor (16 Threads)

### Issue description

When a project's settings are added or removed by an editor plugin, the changes are not visible until the project settings window is closed and reopened. I initially did not think of this as a bug, but it appears to actually be one, according to https://github.com/godotengine/godot-proposals/issues/7525#issuecomment-1685008504

### Steps to reproduce

1. Have an editor plugin add or remove project setting(s)
2. Check the "General" tab
3. No changes
4. Reopen the project settings window
5. Changes are now visible

The MRP I have attached includes a small plugin to demonstrate this bug when enabling and disabling the plugin. Take a look at the script for more details.

### Minimal reproduction project

[Project settings problem.zip](https://github.com/godotengine/godot/files/12387676/Project.settings.problem.zip)
Repository: pytorch
Issue: Appending new logs to existing tbevent files when using tensorboard
Labels: triaged,module: tensorboard

### 🚀 The feature, motivation and pitch

Use Case:
I often find myself needing to continue logging training progress to an existing event file when using tensorboard, especially when experiments are interrupted or need to be continued across multiple sessions. Currently, the SummaryWriter in PyTorch starts a new event file for each run, making it challenging to maintain a consistent log of progress, and creates multiple files in my directory.

Feature Request:
I would like to suggest adding the capability to append new logs to an existing tfevent file using the SummaryWriter. This would enable users to continue logging to a single event file across multiple runs, ensuring a seamless record of training progress.

Implementation Considerations:
While I don't have specific technical details, this feature might involve:

- Providing an option to specify an existing event file when creating a SummaryWriter instance.
- Ensuring that logs from the current run are appropriately appended to the specified event file.
- Handling potential conflicts or edge cases when appending logs.

This feature would greatly enhance the usability of the SummaryWriter and improve the logging experience for PyTorch users.


### Alternatives

_No response_

### Additional context

_No response_
Repository: PowerToys
Issue: [BUILD] Changes in gpo.h don't trigger rebuild of PoweToys.Settings project when debugging
Labels: Issue-Bug,Area-Build,Needs-Triage

### Microsoft PowerToys version

0.73.0-DEV

### Installation method

Dev build in Visual Studio

### Running as admin

None

### Area(s) with issue?

General

### Steps to reproduce

I fixed a bug I made in `/src/common/utils/gpo.h` and then build the code again in debug mode. But the changes doesn't take effect. The settings app was still crashing.

I had to delete my local clone, clone it again and then build from scratch. This happend multiple times to me and is very annoying.

xref:
- Bug I made: https://github.com/microsoft/PowerToys/pull/27468#discussion_r1298448770
- Crash: https://github.com/microsoft/PowerToys/pull/27468#issuecomment-1676307806


### ✔️ Expected Behavior

All the changes take effect and the settings ui isn't crashing anymore.

### ❌ Actual Behavior

The settings app is still crashing and it seems that some build results are not updating.

### Other Software

_No response_