sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: (3D renderer) Lights are visible through all objects with a material with Clearcoat enabled
Labels: bug,topic:rendering,topic:3d

### Tested versions

Found in v4.2.1.stable.official [b09f793f5]
and v4.3.stable.steam [77dcf97d8]

### System information

Godot v4.2.1.stable - Windows 11 (22621.2861) - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.4633) - 11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz (16 Threads)

**Update** January 9 2025 system information,
Godot 4.3.stable.steam - Windows 11 (22631) - nVIDIA GeForce RTX 4070 Super (32.0.15.6636)

### Issue description

Lights are visible through objects with a material with Clearcoat enabled. It looks like a lens flare with a black point center, and it flickers between visible and invisible every frame that the camera is moved. Changing the Glow parameters affects how the artifact appears.

With a camera parameters with auto-exposure enabled it will cause the auto-exposure to jump all over the place to compensate for the bright spot.

![Screenshot 2023-12-26 125824](https://github.com/godotengine/godot/assets/87274781/465504c9-a1e7-43fa-9a8c-cd8fe0a2fa7c)


https://github.com/godotengine/godot/assets/87274781/1b3a53e8-19b6-4e01-b564-8a212215c414



### Steps to reproduce

- Make a new project
- 3D scene, with the default environment on, Glow on.
- Add a mesh instance in the scene, cube, with a standard material, enable Clearcoat.
- Add an OmniLight to the scene and move it away from the mesh.
- View the mesh with the light behind it (occluded). Moving the camera around shows the flicker.

### Minimal reproduction project (MRP)

[MRP](https://github.com/user-attachments/files/18364442/MRP.zip)
Repository: pytorch
Issue: PyTorch Distributed Elastic Launch Segmentation Fault with Python 3.12
Labels: oncall: distributed,module: crash,module: elastic

### 🐛 Describe the bug

With Python 3.12, using torch.distributed elastic_launch results in segmentation fault. Python 3.11 with the same code works.
```python
import torch.distributed.launcher as pet
import uuid
import tempfile
import os


def get_launch_config(world_size: int, rdzv_endpoint: str) -> pet.LaunchConfig:
    return pet.LaunchConfig(
        min_nodes=1,
        max_nodes=1,
        nproc_per_node=world_size,
        run_id=str(uuid.uuid4()),
        rdzv_backend="c10d",
        rdzv_endpoint=rdzv_endpoint,
        rdzv_configs={"store_type": "file"},
        start_method="spawn",
        monitor_interval=1,
        max_restarts=0,
    )

def entrypoint():
    print("Here!")


if __name__ == '__main__':
    with tempfile.TemporaryDirectory() as tmpdir:
        launch_config = get_launch_config(2, os.path.join(tmpdir, "rdzv"))
        pet.elastic_launch(launch_config, entrypoint=entrypoint)()
```

### Versions

[conda] numpy                     1.26.2                   pypi_0    pypi
[conda] torch                     2.3.0.dev20231218+cu121          pypi_0    pypi
[conda] torchmetrics              1.0.3                    pypi_0    pypi
[conda] torchrec                  0.5.0.dev20231218+cu121          pypi_0    pypi

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @dzhulgakov
Repository: godot
Issue: AnimationTree does not respect the on/off status of the RESET animation (possible regression)
Labels: needs testing,topic:animation

### Tested versions

- Tested in v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Ubuntu 23.10 23.10 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Ti (nvidia; 535.129.03) - 12th Gen Intel(R) Core(TM) i9-12900F (24 Threads)

### Issue description

When a track exists in the RESET animation and is disabled, it is used when an `AnimationTree` is active.

This was raised as an issue (for all animations) in issue #25537 and fixed in PR #62337 - however, this seems to only fix it for animations *other* than RESET.

An example of this can be seen in the attached video. You can see that the animation tracks for the mesh size property are disabled in both the RESET animation and the anim1 animation. Once the `AnimationTree` is made active, however, the disabled mesh size track from the RESET animation is executed, and the disabled mesh size track from the anim1 animation is ignored.

This leads me to think either a regression has occurred or that the original fix is in some way not applying to the RESET animation.

https://github.com/godotengine/godot/assets/49003204/ad1c32b3-80d0-47a4-a39a-0b02e16b1e68




### Steps to reproduce

- Clone the attached MRP
- Check the `RESET` and `anim1` animations of the `AnimationPlayer` to verify the mesh size property of `MeshInstance3D2` is not changed
- Stop any `AnimationPlayer` animations and make the `AnimationTree` node active to see the mesh size property change according to the disabled track in the `RESET` animation

### Minimal reproduction project (MRP)

https://github.com/RobTheFiveNine/godot-animationtree-track-reset-bug
Repository: PowerToys
Issue: PowerRename not renaming, no error returned
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.76.2

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

PowerRename

### Steps to reproduce

* Open File Explorer on Windows 11
* Navigate to folder within external drive
* Highlight files named in UPPER CASE (I selected 5-20 files at a time depending on what was in the folder)
* Open PowerRename and select Capitalize Each Word
* Apply or Apply and close

### ✔️ Expected Behavior

Files renamed according to user input OR files not renamed & PowerRename throwing an error 

### ❌ Actual Behavior

No change in filenames, no feedback from PowerRename

### Other Software

Edition	Windows 11 Home
Version	23H2
Installed on	‎07/‎11/‎2023
OS build	22631.2861
Experience	Windows Feature Experience Pack 1000.22681.1000.0
Repository: flutter
Issue: [Windows] Move `FlutterWindow` mocking to `WindowsProcTable` 
Labels: platform-windows,a: desktop,P3,team-windows,triaged-windows

# Background

The [`FlutterWindow`](https://github.com/flutter/engine/blob/main/shell/platform/windows/flutter_window.h) is one of the fundamental types of the Windows embedder. It listens to the Windows event loop, processes keyboard events, handles IME composition, accessibility, and more.

On top of all of this, it is also used to mock win32 APIs:

* [x] [Get DWM composition status](https://github.com/flutter/engine/blob/38b9f3f96ff6aacb74df428aad04f3cfffe50ab9/shell/platform/windows/flutter_window.cc#L375-L385) (https://github.com/flutter/engine/pull/49397)
* [x] [Flush DWM](https://github.com/flutter/engine/blob/38b9f3f96ff6aacb74df428aad04f3cfffe50ab9/shell/platform/windows/flutter_window.cc#L188-L192) (https://github.com/flutter/engine/pull/49398)
* [ ] [Peek](https://github.com/flutter/engine/blob/38b9f3f96ff6aacb74df428aad04f3cfffe50ab9/shell/platform/windows/flutter_window.cc#L485-L491) and [send](https://github.com/flutter/engine/blob/38b9f3f96ff6aacb74df428aad04f3cfffe50ab9/shell/platform/windows/flutter_window.cc#L497-L501) win32 messages
* [ ] [Map virtual key](https://github.com/flutter/engine/blob/38b9f3f96ff6aacb74df428aad04f3cfffe50ab9/shell/platform/windows/flutter_window.cc#L493-L495)
* [ ] [Default window procedure](https://github.com/flutter/engine/blob/38b9f3f96ff6aacb74df428aad04f3cfffe50ab9/shell/platform/windows/flutter_window.cc#L947-L952)

These are debatable candidates:

* [ ] [Clear and present bitmaps](https://github.com/flutter/engine/blob/38b9f3f96ff6aacb74df428aad04f3cfffe50ab9/shell/platform/windows/flutter_window.cc#L317-L340)

# Solution

The `WindowsProcTable` was introduced to allow mocking win32 APIs. `FlutterWindow` methods that exist for mocking purposes should be moved to the `WindowsProcTable`.
Repository: angular
Issue: Provide the ability to synchronously track signal changes
Labels: area: core,core: reactivity,cross-cutting: signals

### Which @angular/* package(s) are relevant/related to the feature request?

core

### Description

There are cases when we want to (synchronously) track all value changes of a signal. For instance, there is a community plugin for SignalStore that allows the connection with the Redux Devtools extension: https://github.com/angular-architects/ngrx-toolkit?tab=readme-ov-file#devtools-withdevtools

This plugin provides the ability to set the label that will be displayed in the devtools when patching the SignalStore state:

```ts
patchState('set user', store, { user: 'Marko' });
```

However, if we call `patchState` multiple times in the same tick:

```ts
patchState('set user', store, { user: 'Marko' });
patchState('reset query', store, { query: '' });
```

Only the last action will be logged in the devtools because Angular's effect will 'emit' only once.

Currently, there is no way to solve this limitation / display multiple state changes that happen in the same tick.


### Proposed solution

Core APIs should be flexible enough to cover this scenario. For example in Vue, they provide three different types of the `watchEffect` function that is equivalent to `effect` in Angular:

- `watchEffect`
- `watchPostEffect`
- `watchSyncEffect` <= Redux Devtools plugin needs this one

It's also possible to provide different flush timing to `watchEffect` function:

```ts
const count = ref(0)

watchEffect(() => console.log(count.value), { flush: 'sync' });
// equivalent to:
watchSyncEffect(() => console.log(count.value));
```

More info about Vue effects is available at the following link: https://vuejs.org/api/reactivity-core.html#watcheffect

There are several ways to provide this functionality:

1. Expose (internal) APIs that can be used by framework consumers to create watchers/custom effects that suit their needs.
2. Provide the `syncEffect` function similar to `watchSyncEffect` from Vue.
3. Provide the ability to pass the custom 'scheduler'/flush timing to the `effect` function:

```ts
const count = signal(0);

// similar to Vue:
effect(() => console.log(count()), { flush: 'sync' });
// or more extensible solution:
effect(() => console.log(count()), { scheduler: syncScheduler });
```


### Alternatives considered

Currently, there is no way to achieve this behavior with existing public APIs.
Repository: vscode
Issue: `DEL` appearing after dead key along with Ctrl key actions
Labels: keybindings

<!-- ⚠️⚠️ 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.86.0-insider
- OS Version: Windows_NT x64 10.0.19044

Steps to Reproduce (similar to #165982):

1. Copy a word to clipboard
2. Just press dead key like `'` (for layout "English (USA, International)"), so nothing is output
3. Paste the word with Ctrl+V
4. Press Ctrl+Backspace
5. Type a character like space
6. Now, there's a square with text `DEL` inside (and the typed character after it)
Repository: vscode
Issue: Improve onboarding process after initial install depending on the experience of the user
Labels: feature-request,getting-started

I think the current onboarding process on the welcome page is too lengthy for experienced vs code users.
Once you are experienced with VS Code you probably already have a working configuration, very likely also already synced to the Microsoft or Github Account. 

So I think for experienced users, the welcome page contains too many steps that are in the way of just starting to write code.

On the other hand, totally new users of course might need quite a lot of guidance which is served in an OK manner by the current welcome page.

So I'd suggest that the welcome page in future asks the user in only one short sentence how experienced the user is (two options should be selectable: "I have experience working with VS Code" and "I am new to VS Code" .
If the user clicks on "I am new to VS Code", the old welcome page.
If the user clicks the other option, he only is asked whether to sync settings for VS Code from an online account (not mandatory, user should be able to cancel that process at any point).
If the user confirms that setting should be synced, the same process that currently starts after clicking the "user" icon in vs Code and then clicking the sync-settings menu item, should start
Repository: next.js
Issue: `ResolvedMetadata` is incompatible with `Metadata`
Labels: bug,TypeScript

### Link to the code that reproduces this issue

https://github.com/Arctomachine/resolved-metadata-bug

### To Reproduce

1. Run build, check console for error
2. Optionally run dev to verify that everything works and it is only type error

### Current vs. Expected behavior

When inheriting metadata from parent, build will fail with error because `ResolvedMetadata` is not compatible with `Metadata`. Should be able to return parent metadata without errors.
Also need to ensure that it is possible to do it at any given level, from root `Metadata` to its leaf props.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
Binaries:
  Node: 20.2.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.0.5-canary.27
  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)

Metadata (metadata, generateMetadata, next/head), TypeScript (plugin, built-in types)

### Additional context

Identical problem already happened in past in different props of `Metadata`:
#49406
#49316

Error happens inside .next folder, which is regenerated on subsequent build runs, so it is impossible to workaround it with @ts-ignore or by commenting out problematic section
```
.next/types/app/test/page.ts:32:15
Type error: Type 'OmitWithTag<ResolvingMetadata, keyof PageProps, "generateMetadata">' does not satisfy the constraint '{ [x: string]: never; }'.
  Property 'then' is incompatible with index signature.
    Type '<TResult1 = ResolvedMetadata, TResult2 = never>(onfulfilled?: (value: ResolvedMetadata) => TResult1 | PromiseLike<TResult1>, onrejected?: (reason: any) => TResult2 | PromiseLike<...>) => Promise<...>' is not assignable
 to type 'never'.

  30 | // Check the arguments and return type of the generateMetadata function
  31 | if ('generateMetadata' in entry) {
> 32 |   checkFields<Diff<PageProps, FirstArg<MaybeField<TEntry, 'generateMetadata'>>, 'generateMetadata'>>()
     |               ^
  33 |   checkFields<Diff<ResolvingMetadata, SecondArg<MaybeField<TEntry, 'generateMetadata'>>, 'generateMetadata'>>()
  34 | }
  35 |
```
Repository: rust
Issue: Vague error message with elided lifetime in impl block
Labels: A-diagnostics,T-compiler,D-newcomer-roadblock,D-terse

### Code

```Rust
struct Borrow<'a, T>(&'a T);

impl<T> Borrow<'_, T> {
    pub fn new(t: &T) -> Self {
        Self(t)
    }
}
```


### Current output

```Shell
error: lifetime may not live long enough
 --> src/main.rs:7:9
  |
6 |     pub fn new(t: &T) -> Self {
  |                   -      ---- return type is Borrow<'2, T>
  |                   |
  |                   let's call the lifetime of this reference `'1`
7 |         Self(t)
  |         ^^^^^^^ associated function was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
```


### Desired output

```Shell
The original output with the addition of something like:
impl<T> Borrow<'_, T> {
                ^ Let's call this elided lifetime '2

help: consider explicitly naming the lifetime:
      impl<'a, T> Borrow<'a, T> {
```


### Rationale and extra context

In this error message it's not clear that the `'2` lifetime comes from the `'_` at the `impl` block definition, and the error does not suggest that that explicitly naming the lifetime might fix the problem.

### Other cases

_No response_

### Anything else?


If adding these changes seems like a desirable change, I would be happy to prepare a PR. I've never contributed to the compiler before, so some pointers on where to start looking to make a change would be appreciated :)
Repository: rust
Issue: Unsupported flags for mold during lto
Labels: A-linkage,O-macos,A-diagnostics,T-compiler,C-feature-request,C-bug

Greetings. According to [this](https://doc.rust-lang.org/rustc/linker-plugin-lto.html) doc, I tried to perform cross-language lto across C/C++ and Rust with mold as the linker. However, I found that existing rustc only supports lld.

The command I ran is:

```
RUSTFLAGS="-Clinker-plugin-lto -Clinker=clang -Clink-arg=-fuse-ld=mold" cargo build --release
```

However, an error was thrown:

```
mold: unknown command line option: -plugin-opt=O0
```

After some investigation, I found this problem is caused by the code at [here](https://github.com/rust-lang/rust/blob/2df6406b886757a3c1475957660a3a4ae6c786de/compiler/rustc_codegen_ssa/src/back/linker.rs#L293) :
```rust
        self.linker_args(&[
            &format!("-plugin-opt={opt_level}"),
            &format!("-plugin-opt=mcpu={}", self.target_cpu),
        ]);
```

These flags assume users only use lld as the linker. However, mold does not support these flags, see [here](https://github.com/rui314/mold/blob/main/docs/mold.md).

Also, this problem happened on Macos, see [here](https://github.com/rust-lang/rust/issues/60059).

**Could we support more linkers during the linker-plugin-lto? Or we can make users override these flags?**
```[tasklist]
### Tasks
```
Repository: flutter
Issue: GoogleMap marker's tappable area is misplaced on the web
Labels: p: maps,platform-web,package,has reproducible steps,P2,team-web,triaged-web,found in release: 3.16,found in release: 3.18

### Steps to reproduce

I'm facing a problem with custom GoogleMap markers. The markers are rendered in the right place, but their tappable area is displaced - it can be above, below, left or right to the marker itself (as you can see on the screenshot).

It seems to be related to the previous issue:
#https://github.com/flutter/flutter/issues/126946

I have a web app with 'GoogleMap' inside 'FittedBox' (actually it is `ResponsiveScaledBox` from [responsive_framework](https://github.com/Codelessly/ResponsiveFramework/issues/166) package, but it is based on `FittedBox`). If I remove `FittedBox` all is rendered correctly.

### Expected results

Tappable area of marker in the right place

### Actual results

Tappable area is misplaced.

### Code sample

To reproduce you need to place `GoogleMap` inside `FittedBox` and add some custom markers to it (in my case I convert `.svg` file to `BitmapDescriptor`.


### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

<img width="123" alt="Снимок экрана 2023-12-26 в 22 33 53" src="https://github.com/flutter/flutter/assets/82471392/298575c8-3ccc-49bd-a933-99b4ec0e7f0b">


</details>


### Logs

_No response_

### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.16.5, on macOS 14.1.2 23B92 darwin-arm64, locale ru-RU)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 15.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.3)
[✓] IntelliJ IDEA Ultimate Edition (version 2023.3)
[✓] IntelliJ IDEA Community Edition (version 2022.2)
[✓] VS Code (version 1.85.1)
[✓] Connected device (3 available)
[✓] Network resources

• No issues found!
```

</details>
Repository: godot
Issue: DirectionalLight3D angular distance shadows blurring based on absolute zero position
Labels: bug,topic:rendering,topic:3d

### Tested versions

-Reproducible in: v4.2.1.stable.official [b09f793f5], v4.1.3.stable.official [f06b6836a]

### System information

Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; 31.0.15.4633) - 11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz (8 Threads)

### Issue description

The "Angular Distance" property of "DirectionalLight3D" seems to be dependant on absolute zero position of the world rather than dependant on global position of the camera, therefore as the camera moves around through the world with "Angular Distance" property enabled issues with excessive shadow blurring begin to show, the issues are more visible the further away the camera gets from the absolute zero position of the world.

I've put together a very simple project that demonstrates the issue, on the left side one viewport is showing a camera that's close to the absolute zero position, on the right side a viewport showing practically the same scene but moved very far away from the absolute zero position.
![directional_shadow_issue](https://github.com/godotengine/godot/assets/100485785/c00562c5-898b-433f-b62f-76eef1660baa)

The issue is that both of these scenes should have no difference in how shadows behave in them, yet there is a significant difference, and it only gets worse the further away the camera is from the absolute zero position.

### Steps to reproduce

The project file I attached should demonstrate in a very obvious way what is not working (the viewports are setup in such way that checking them in the 2D preview tab can show the issue without needing to compile it)

All it takes to reproduce from scratch is to:
- create a new 3d scene
- put up a DirectionalLight3D, enable shadows and set "angular distance" property to 0.5 or higher while keeping "blur" at 1 or higher
- create a big 3d plane mesh as a ground and cover a HUGE area with it to have something to cast a shadow onto
- create a camera3D and attach a cube mesh to it, stretch it until it's tall enough to show the "angular distance" effect clearly
- select the camera3D from the node tree and switch to 2D preview within the editor
- as you are checking what the shadow looks like form the in-game camera's perspective via the 2D preview mode change the position of the camera via the node property menu
- if you notice a drastic and clearly undesirable difference in the way shadows look when moving the camera around then you have found the issue (if not, you are not moving the camera far away enough from the absolute zero position)

### Minimal reproduction project (MRP)


[DirectionalLight3D issue demo.zip](https://github.com/godotengine/godot/files/13775092/DirectionalLight3D.issue.demo.zip)