sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Text jump when using autowrap and switching to a certain script
Labels: bug,topic:editor,usability

### Godot version

4.2 beta5

### System information

Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 (NVIDIA; 30.0.15.1403) - Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 Threads)

### Issue description


https://github.com/godotengine/godot/assets/2223172/7ae6016d-928f-4ea1-be49-c40a9ed71ad9



### Steps to reproduce

1. Open a script with lots of long text
2. Enable autowrap
3. Switch to another script and back

### Minimal reproduction project

https://github.com/KoBeWi/Metroidvania-System/blob/master/SampleProject/Maps/DiceRoom.tscn
The video was recorded in this scene's script, which is inside Dice node. The bug may or may not occur depending on your script editor's width.
Repository: godot
Issue: _init not working properly when objects are created thru a for loop, and the _init parameters are assigned on that same loop.
Labels: discussion,topic:gdscript

### Godot version

v4.1.3.stable.official.f06b6836a

### System information

Godot v4.1.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated Radeon RX550/550 Series (Advanced Micro Devices, Inc.; 31.0.21031.1005) - AMD Ryzen 5 1600 Six-Core Processor (12 Threads)

### Issue description

When creating class objects and setting values inside a for loop. and passing these values to a constructor on the next iteration to the next object, these values end up null even tho they had a value set for them before being passed on.

### Steps to reproduce

Use a for loop to create at least two objects > make the second object have a constructor that needs the previous object > assign the first object to a variable in the first iteration before creating the second object > print the constructor value inside the second object and it returns null.

### Minimal reproduction project

Create a Node and attach a script with this code:

```gdscript
extends Node

var a : Node

var array = [
	Node.new(),
	ConstructorObject.new(a)
]

func _ready():
	for object in array:
		self.add_child(object)
		print(a)
		self.set("a", Node.new())
		print(a)
```

Then create another script with this code:

```gdscript
extends Node
class_name ConstructorObject

var a : Node
func _init(_a : Node):
	a = _a

func _physics_process(delta):
	print(a)
```

You will see that the first print will be null, since you didn't set **a** yet, and the next print will have it set to a new Node. The second iteration of the loop will print Node two times, meaning that it did got set on the first iteration. The ConstructorObject will receive **a** with a Node value, but it will print null instead.

_Bugsquad edit:_ Fixed formatting.
Repository: TypeScript
Issue: [ServerErrors][JavaScript] 5.4.0-dev.20231112
Labels: Needs Investigation

The following errors were reported by 5.4.0-dev.20231112
[Pipeline that generated this bug](https://typescript.visualstudio.com/TypeScript/_build?definitionId=48)
[Logs for the pipeline run](https://typescript.visualstudio.com/TypeScript/_build/results?buildId=158558)
[File that generated the pipeline](https://github.com/microsoft/typescript-error-deltas/blob/main/azure-pipelines-gitTests.yml)

This run considered 200 popular TS repos from GH (after skipping the top 0).

<details>
<summary>Successfully analyzed 195 of 200 visited repos</summary>

| Outcome | Count |
|---------|-------|
| Detected interesting changes | 5 |
| Detected no interesting changes | 190 |
| Unknown failure | 5 |

</details>

## Investigation Status
| Repo | Errors | Outcome |
|------|--------|---------|
|!1136d696a399f90bb2119a23c1547ad6|1| |
|!9f244c2434b95768840a9619d1ae012c|1| |
|05dc022b77792efd84491358bf4bf0af|1| |
|82e06099adfc7f5d6f601b429f948a70|1| |
|c61b266ca8c44d0af3e32e589998edeb|1| |
Repository: flutter
Issue: [CAMERA_WEB] Exporting and Importing cameras metadata.
Labels: platform-web,p: camera,c: proposal,P3,team-web,triaged-web

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

Hi! 

Web implementation of availableCameras() method in CAMERA_WEB library queries all device's available cameras every time it's called. So every first attempt to use a camera after a web application start requires about 10+ seconds of user wait time before camera become operational. It would be good to have an option to save camera metadata locally on device and reuse it on every application start to reduce time for camera initialization. 

PS. This is the peculiarity of  CAMERA_WEB implementation. Camera_IO doesn't experience such issue.

Thanks!

### Proposal

There is two classes responsible for camera initialization in CAMERA WEB:  CameraDescription and CameraMetadata
 CameraDescription is returned from availableCameras() and could be stored.
CameraMetadata is not returned from availableCameras() ;
CameraDescription could not be reinitialized from stored values as it requires CameraMetadata to be available and run of  availableCameras() every application start apparently.

The proposal is to make a way (any possible) to store CameraDescription and CameraMetadata and the way (any possible) to reinstate  Camera class using stored data to eliminate camera initialization waiting time.

My proposal is to add a method that returns a data required for camera class reinstate, add optional value to availableCameras() that accept this data and initialize cameras based on previous initialization data without querying them every time an application starts.
Repository: godot
Issue: GDScript Editor Nesting bug
Labels: bug,topic:editor

### Godot version

4.1.3-Stable

### System information

Windows 10

### Issue description

GDScript editor nesting isn't working always correctly. When I want to collabse a function it sometimes collabses the next funtions """ comments with it. Annoying little bug, and I think it is because I use space in

### Steps to reproduce

(Image 1) First I have this stupidly simple function which nulls my values. I can collabse everything (lines 51, 59, and 64) correctly except line 54 which is func clearNPC(). If I collabse it, image 2 will occur. If I collabse line 59 first, then Image 3 happens. This happens because I start the comment line with empty space. If I remove the spaces in the beginning of the line 62, collabse continue to work normally.


![1](https://github.com/godotengine/godot/assets/5145163/2a7a2e63-61b4-41e5-8f39-7cd54fb55676)
![2](https://github.com/godotengine/godot/assets/5145163/4533a39c-6370-4e57-927b-a089594ee04f)
![3](https://github.com/godotengine/godot/assets/5145163/466f7354-d25e-4542-a8c1-6181ebc0f42d)


### Minimal reproduction project

N/A
Repository: godot
Issue: GPUParticles2D particles no longer move with consistent velocity
Labels: bug,confirmed,topic:particles

### Godot version

v4.2.beta5.official [4c96e9676]

### System information

Godot v4.2.beta5 - Windows 10.0.19044 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 970 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz (16 Threads)

### Issue description

GPUParticles2D with Disable Z enabled no longer move at a consistent velocity in 2D. In 3.5 these settings ensure particles move consistently over their lifetime, but in 4.x they appear to ignore Disable Z and move into the background or ignore the initial velocity parameters.

Comparison video (4.2 on top, 3.5.2 on bottom)

https://github.com/godotengine/godot/assets/3820082/3fb9c1b2-f725-4ee7-8162-7063e87170f7



### Steps to reproduce

Attempt to create a GPUParticles2D with consistent movement by using Disable Z, Initial Velocity Min+Max 50, Spread 180. Particles appear to travel along Z anyway.

### Minimal reproduction project

N/A
Repository: stable-diffusion-webui
Issue: [Bug]: ModuleNotFoundError: No module named 'pandas._libs.tslibs.strptime'.
Labels: bug-report

### Is there an existing issue for this?

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

### What happened?

when I run webui-user.bat with COMMANDLINE_ARGS added with --lowvram -- precision full --no-half --skip-torch-cuda-test. The older version of this works. But yesterday I git clone the new version. It appear the ModuleNotFoundError: No module named 'pandas._libs.tslibs.strptime'.

### Steps to reproduce the problem

No idea

### What should have happened?

No idea.

### Sysinfo

NA

### What browsers do you use to access the UI ?

Google Chrome

### Console logs

```Shell
NA, as not even reach the stage of browser acccess.
```


### Additional information

NA
Repository: PowerToys
Issue: "Cycle between windows snapped to the same zone" (e.g. Win + PgUp) stops working after sleep
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.75.1

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

FancyZones

### Steps to reproduce

Use any template. Snap two or more windows to the same zone. Then Win + PgUp/PgDn work as expected.
Suspend computer in the usual way (e.g. press power button so it goes into Sleep, or allow power settings to put the computer in Sleep)
Wake computer (e.g. press power button)
Go back to window in the aforementioned zone.
Try Win + PgUp or Win + PgDn

### ✔️ Expected Behavior

Cycles between windows snapped to that zone like it did before the computer suspended.

### ❌ Actual Behavior

Nothing happens. It doesn't switch to the other window(s).

### Other Software

_No response_
Repository: rust
Issue: thread panic handling broken on x32
Labels: A-runtime,A-LLVM,C-bug,O-x32

<!--
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::thread;
fn main() {
    let thread = thread::spawn(move || -> () {
        panic!();
    });
    println!("{:?}",thread.join());
}
```

When building the above program for x86_64-unknown-linux-gnu and running it I get

```
thread '<unnamed>' panicked at src/main.rs:4:9:
explicit panic
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Err(Any { .. })
```

However when building for x86_64-unknown-linux-gnux32 and running it I get.

```
thread '<unnamed>' panicked at src/main.rs:4:9:
explicit panic
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: Rust cannot catch foreign exceptions
Aborted
```

### Meta
I have tested building natively with the compiler from Debian and cross building with a nightly compiler from rustup (since rust upstream don't provide a native compiler on x32).

`rustc --version --verbose`: (debian compiler)
```
rustc 1.70.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnux32
release: 1.70.0
LLVM version: 16.0.6
```

`rustc --version --verbose`: (rustup compiler)
```
rustc 1.76.0-nightly (2c1b65ee1 2023-11-11)
binary: rustc
commit-hash: 2c1b65ee1431f8d3fe2142e821eb13c623bbf8a0
commit-date: 2023-11-11
host: x86_64-unknown-linux-gnu
release: 1.76.0-nightly
LLVM version: 17.0.4
```

Note that when building with the rustup compiler I had to manually specify the linker. using the following in .cargo/config.toml

    [target.x86_64-unknown-linux-gnux32]
    linker = "x86_64-linux-gnux32-gcc
Repository: pytorch
Issue: [PTD] Logging Improvements Main Task
Labels: oncall: distributed,triaged,module: c10d

We should improve the logging system in PyTorch distributed. In particular there're multiple issues in our current distributed logging system, reported by @stas00 (thanks!): 1. INFO logs silently turned on if a third-party library use INFO (i.e. results in logs from NCCL and torch.distributed dominates the console), `torch.distrbuted` log system should be componentized and not silently override by user program, unless a explicit override provided. 2. Several distributed logs are mainly use DEBUG purposes but we made at INFO level 3. our traceback seems have some regression that does not show the root cause failure at last 4. how to ensure serialized tracebacks and print atomically. Here I listed some tasks we should focus on to ensure a better logging experience:

```[tasklist]
### Tasks
- [ ] https://github.com/pytorch/pytorch/issues/113544
- [ ] https://github.com/pytorch/pytorch/issues/113545
- [ ] https://github.com/pytorch/pytorch/issues/113546
- [ ] Introduce different logging mode for distributed logger: 1. LOG_ONCE (rank0 log only) 2. LOG_ALL
- [ ] Provide a way to prevent interleaved prints/logs (i.e. mutex or semphore)
- [ ] offer a way to dump logs to a folder where each rank has its own log file
- [ ] https://github.com/pytorch/pytorch/issues/117383
```

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @fduwjj @wz337 @tianyu-l @wconstab @yf225 @kiukchung @lucasllc @d4l3k
Repository: pytorch
Issue: P0: Improve failure trace back when crashed to identify the cause of a crash and the ranks that the crash, output the real traceback at last.
Labels: triaged,module: c10d,module: elastic

We should make sure our launcher crash respects the root cause failure rank and print the crashed message at last, not sth that user scroll back and see the real failures. The current behavior is that the last message is sth un-related that user have to look into the real crash that happened before 

prior to 2.0 it seems we offer that functionality but now seems we regressed this feature.

cc @dzhulgakov
Repository: PowerToys
Issue: 更改左边模块列表显示情况，仪表盘中已禁用模块在左边列表取消显示
Labels: Needs-Triage

### Description of the new feature / enhancement

希望左边模块列表的显示和仪表盘中的模块启用情况对应，只显示已启用的模块，禁用的模块不显示。如下图所示

<img width="500" alt="image" src="https://github.com/microsoft/PowerToys/assets/62595825/e472f8b0-df78-4b29-b1e0-90d398218000">

⬇

<img width="500" alt="image" src="https://github.com/microsoft/PowerToys/assets/62595825/16657174-4030-490b-a1f1-943c23e6ddbf">


### Scenario when this would be used?

在仪表盘中禁用了一些用不到的模块，但在左边模块列表里还是显示，目前模块量比较多，这种情况下还显示已禁用的模块，不方便寻找启用的模块并对其进行设置。
希望能改成如果所示的效果，禁用的模块不显示在左侧列表，这样更整洁一些。

<img width="500" alt="image" src="https://github.com/microsoft/PowerToys/assets/62595825/e472f8b0-df78-4b29-b1e0-90d398218000">

⬇

<img width="500" alt="image" src="https://github.com/microsoft/PowerToys/assets/62595825/16657174-4030-490b-a1f1-943c23e6ddbf">

### Supporting information

_No response_
Repository: go
Issue: proposal: slices: add Push
Labels: Proposal

**Motivation:**
Appending a new element to a slice is probably the most common slice operation.
The semantics of the append operator might lead to unwanted bugs due to the return parameter.
Consider the following code:
```
anotherSlice := append(existingSlice, ...entries)
```
When assigning to a variable different from the source slice, anotherSlice might or might not end up pointing to the same array as in existingSlice. 
Since append is such a common operation in Go, it's very easy to miss this nuance and run into a strange bug with some elements "disappearing" from the slice due to another slice holding a pointer to the same array. This issue is very hard to debug. 
While there is a [linter](https://go-critic.com/overview#appendassign) in gocritic that tackles the exact same problem, it'd be more efficient to exclude this problem on the language level

**Solution:**
We can improve the situation by introducing a new function for "just appending" to the slice
```
func Push[S ~[]E, E any](src *S, newElements ...E) {
	*src = append(*src, newElements...)
}
```
Then, you can use it like this:
```
Push(&existingSlice, entries)
```
This solution has the following benefits:
* With this API one cannot accidentally have two slices owning the same backing array(i.e.  The user would have to explicitly declare a new slice, copy the content of `existingSlice` and only then append what they intended to)
* works for any slice including nil slices
* this doesn't break any backward compatibility since `append` is still available as an operator
* Slice grow is hidden from the developer. Hence, one does not need to think about resource ownership with this API
Repository: rust
Issue: TAIT decision on "may not define may guide inference"
Labels: T-lang,A-impl-trait,F-type_alias_impl_trait

Nominating for T-lang to decide whether the following rule should hold for the stabilization of TAIT:

> The compiler is allowed to rely on whether or not an item is allowed to define the hidden type of an opaque type to guide inference.

If this rule is adopted, then after TAIT is stabilized, it will not be possible in a fully backward compatible way to later change the rules that determine whether or not an item is allowed to define the hidden type in such a way that an item in existing code that uses an opaque type could switch (without any code changes) from being not allowed to define its hidden type to being allowed to define it.

**For the purposes of this question, please set aside how we know whether an item is allowed to define the hidden type; this question is invariant to the details of that.**

This rule is of particular importance to the new trait solver.

For example, consider:

```rust
pub trait Trait {
    fn method(&self) {
        println!("Trait::method");
    }
}
impl<T> Trait for T {}

pub struct X<T>(T);
impl X<()> {
    pub fn method(&self) {
        println!("X<()>::method");
    }
}

pub type Tait = impl Trait;

// Defines the hidden type of `Tait`.
pub fn new() -> X<Tait> {
    X(())
}

// Whether or not `foo` may define the hidden type of `Tait` may
// determine how the call to `method` is resolved.
pub fn foo() {
    let x = new();
    // If `foo` may define the hidden type, this may print:
    //
    //     X<()>::method
    //
    // Otherwise, it will print:
    //
    //     Trait::method
    //
    x.method();
}

fn main() {
    foo();
}
```

Please set aside how we know that `new` is allowed to define the hidden type and how we determine whether or not `foo` is allowed to do so.  There are many ways this could be notated, and the question here is orthogonal to that.  In this issue, we're only asking, whatever we decide, is the compiler allowed to rely on this to guide inference?

This rule was described and proposed in the 2023-11-08 T-lang Mini-TAIT design meeting ([minutes](https://hackmd.io/CDj92gZdTzilDWORdKhLQA)): rust-lang/lang-team#233.
Repository: pytorch
Issue: CUDA extension error message doesn't look correct
Labels: module: cpp-extensions,module: cuda,triaged

### 🚀 The feature, motivation and pitch

https://github.com/pytorch/pytorch/blob/b910d9eaa68f1fc16da779b9be116fd1edef8703/torch/utils/cpp_extension.py#L404-L416

Imagine when cuda major version and torch_cuda major version are different, user will only receive an error message saying **"setuptools>=49.4.0 is required"** while their actual setuptools version is already satisfied. 

I'm not sure how this works exactly. I got `cuda_ver` being a string without attribute "major". When there is a mismatch of cuda toolkit versions, this error message is raised.

### Alternatives

I think the error message below in the code base looks much better

```python
CUDA_MISMATCH_WARN.format(cuda_str_version, torch.version.cuda)
```

### Additional context

Can we also provide an environment flag to bypass this check?

https://github.com/pytorch/pytorch/blob/b910d9eaa68f1fc16da779b9be116fd1edef8703/torch/utils/cpp_extension.py#L409-L415


cc @malfet @zou3519 @ptrblck @eqy @crcrpar @atalman
Repository: pytorch
Issue: 2.1.0 export module：Why can't export() capture reverse graphs?
Labels: triaged,export-triage-review,oncall: export

### 🚀 The feature, motivation and pitch

I noticed that your ExportBackwardSignature is None in the document, so I tried a non-None scenario, but an error was reported.
I define a simple process of defining model-training-gradient reverse update into a train function and use export(train, input_tuple), but cannot capture graphs. 
Does the export module have the function of capturing reverse graphs?

### Alternatives

_No response_

### Additional context

_No response_

cc @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4
Repository: next.js
Issue: next/dynamic: importing named exports in a server component throws an error
Labels: bug,Lazy Loading

### Link to the code that reproduces this issue

https://github.com/raphaelbadia/next-dynamic-server-component-error

### To Reproduce

1. Start the application in development
2. open localhost:3000

### Current vs. Expected behavior

I expect the client component to load without error and the website to show the string "ClientComponent"


> **Unhandled Runtime Error**
Error: Could not find the module "/private/tmp/dynamic-failure/app/Client.tsx#ClientComponent#default" in the React Client Manifest. This is probably a bug in the React Server Components bundler.

### 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: x64
  Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:46 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6020
Binaries:
  Node: 18.18.2
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.9.2
Relevant Packages:
  next: 14.0.3-canary.5
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Dynamic imports (next/dynamic)

### Additional context

_No response_
Repository: rust
Issue: Decision on "must define before use" for opaque types
Labels: T-lang,A-impl-trait,F-type_alias_impl_trait

Nominating for T-lang to decide whether the following rule should hold for opaque types:

> If the body of an item that may define the hidden type of some opaque does define that hidden type, it must do so syntactically *before* using the opaque type in a non-defining way.

This restriction is called "must define before use."

Consider:

```rust
use core::convert::identity;

struct I;
struct IShow;
impl I { fn show(&self) -> IShow { IShow } }

struct OnIShow;
trait OnI { fn show(&self) -> OnIShow { OnIShow } }
impl OnI for I {}

fn test(n: bool) -> impl OnI {
    let true = n else { loop {} };
    let x = test(!n); //~ NOTE this is the opaque type
    let _: OnIShow = x.show(); //~ NOTE this is a non-defining use
    //~^ ERROR if the body registers a hidden type for the opaque, it
    //         must do so *before* using it opaquely
    let _: IShow = identity::<I>(x).show();
    //~^ NOTE this registers a hidden type for the opaque, but does so
    //        too late
    loop {}
}

fn main() {}
```

Because the code above works today, this would be a breaking change for RPIT.