sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: os: TestGetwdDeepWithPWDSet failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "os" && test == "TestGetwdDeepWithPWDSet"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8732062106131155793)):

    === RUN   TestGetwdDeepWithPWDSet
        getwd_unix_test.go:57:  $PWD len: 253
        getwd_unix_test.go:61: Getwd len: 253
        getwd_unix_test.go:57:  $PWD len: 454
        getwd_unix_test.go:61: Getwd len: 454
        getwd_unix_test.go:57:  $PWD len: 655
        getwd_unix_test.go:61: Getwd len: 655
        getwd_unix_test.go:57:  $PWD len: 856
        getwd_unix_test.go:61: Getwd len: 856
        getwd_unix_test.go:57:  $PWD len: 1057
        getwd_unix_test.go:61: Getwd len: 0
        getwd_unix_test.go:69: getwd: file name too long
    --- FAIL: TestGetwdDeepWithPWDSet (0.00s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: react
Issue: [DevTools Bug]: Component flashing many times but profiler says it was rendered once
Labels: Type: Bug,Status: Unconfirmed,Component: Developer Tools

### Website or app

https://berrotools.vercel.app/signin

### Repro steps

- Access the website https://berrotools.vercel.app/signin, you'll see a sign in form.
- Open the DevTools, go to the Profiler tab and start profiling.
- Focus the e-mail input and start typing any letter, should not be a valid e-mail so the error label will show. You'll see the error message flashing as long as you type.
- Stop the profiling.
- Check the profiling results, you'll see that the error message was rendered once, if you have typed random letters. The problem is, why did it flash many times?

If the website doesn't work try cloning and running the project located at https://github.com/rhberro/berrotools.

Thank you in advance!

### How often does this bug happen?

Every time

### DevTools package (automated)

_No response_

### DevTools version (automated)

6.0.1-c7c68ef842

### Error message (automated)

_No response_

### Error call stack (automated)

_No response_

### Error component stack (automated)

_No response_

### GitHub query string (automated)

_No response_
Repository: godot
Issue: SubViewport with transparent background results in premultiplied alpha colors in viewport texture
Labels: bug,topic:rendering,topic:gui

### Tested versions

Reproducible in 4.3.stable

### System information

Godot v4.3.stable - macOS 15.1.1 - Vulkan (Mobile)

### Issue description

Using a subviewport with the transparent background option results in colors in the viewport texture being premultiplied with the blending alpha. This means semi-transparent pixels will become darker in color if rendered with a material (like the default CanvasItem material) that assumes the colors not to be premultiplied with the alpha. This is consistent across Compatibility, Mobile and Forward + renderers for me.

There are multiple other issues like https://github.com/godotengine/godot/issues/88603 https://github.com/godotengine/godot/issues/91828 that seem related, but they contain some contradictory information like the issue being exclusive to Forward+ or related to sRGB conversion, and they are marked as requiring more testing to confirm the issue. These issues could probably be consolidated into one.


### Steps to reproduce

- Add a subviewport container to your scene to display a viewport texture
- Add subviewport in the container and set it to have transparent background
- Add a TextureRect in the subviewport and change the modulate of it to make it semi-transparent
- Copy the TextureRect and place in outside the subviewport container to compare
- Observe that the two TextureRects do not look the same and the one rendered via the subviewport is darker.

![Image](https://github.com/user-attachments/assets/812c70a0-eebc-491b-809c-324392e03eee)

- To see that the issue seems to be alpha premultiplication you can add a second TextureRect to your scene, and assign the viewport texture to it as well. Now, assign a new CanvasItem material to this texture rect, and change only its blend mode to use premultiplied alpha. Observe that the colors here seem to be correct again. 

![Image](https://github.com/user-attachments/assets/1e5e8267-f103-4f10-b839-02ea0731404d)

In other words you can compensate for this by creating a material that uses premultiplied alpha to show your viewport texture. However, this is not very obvious, and it might suffer from precision loss if color values are multiplied back/forth using the alpha. There's also the issue with this approach that if this is fixed/changed and the viewport texture colors stop being premultiplied this fix will make the colors incorrect again.

If changing/fixing this would be considered breaking compatibility too much a more conservative option could be to add information about that the viewport texture uses premultiplied alpha for transparent background viewports to the [documentation](https://docs.godotengine.org/en/stable/classes/class_viewporttexture.html#class-viewporttexture). And maybe change the material used for the default SubViewportContainer to use premultiplied alpha to show blended colors in transparent viewports correctly.

### Minimal reproduction project (MRP)

[viewporttransparency.zip](https://github.com/user-attachments/files/17922231/viewporttransparency.zip)
Repository: PowerToys
Issue: Font size increaser and decreser
Labels: Needs-Triage

### Description of the new feature / enhancement

Size increaser and decreser

### Scenario when this would be used?

Size increaser and decreser

### Supporting information

_No response_
Repository: storybook
Issue: [Bug]: 8.4.5 Hangs on initial launch requires full reload
Labels: bug,builder-vite

### Describe the bug

Upgraded from 8.3.6 to 8.4.5, No additional updates to the code base.

Browser opens, Storybook frame renders (Sidebar Nav & Component list), but the actual components/docs are NOT visible.

No build errors. Haven't been able to repro in a fresh repo, hence not providing a link to one.

![Image](https://github.com/user-attachments/assets/66947f96-3539-4ebc-ba43-004ecf0609ba)




### Reproduction link

https://github.com/pvisciano-pcty?tab=repositories

### Reproduction steps

`npm run storybook`
`"storybook": "storybook dev -p 6006",`

Expected : Storybook launches and components are visible
Actual : Browser opens, Storybook frame renders (Sidebar Nav & Component list), but the actual components/docs are not visible. Couple of 404s in the network tab. A full browser refresh clears the error and you are able to view the components. This only happens on initial launch 

![Image](https://github.com/user-attachments/assets/d566c0d2-34f5-4b52-a3c3-4bc93da69529)
 

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.5
    CPU: (10) arm64 Apple M1 Pro
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.10.0 - /usr/local/bin/node
    npm: 10.2.3 - /usr/local/bin/npm <----- active
  Browsers:
    Chrome: 131.0.6778.86
    Safari: 17.5
```

### Additional context

_No response_
Repository: rust
Issue: rustdoc: Please use sticky headers for impl blocks
Labels: C-enhancement,A-rustdoc-ui,T-rustdoc-frontend

If you have a long rustdoc page with different `impl` blocks for the same type, such as https://doc.rust-lang.org/1.82.0/std/primitive.slice.html , each of which has various methods, it's really easy to lose track of which `impl` block a method is in.

I'd love to see rustdoc use "sticky" headings for impl blocks, which stay visible while scrolling through the contents of the impl block, and scroll away when past that impl block. This should be possible with a bit of CSS (no JavaScript required).

This came up when discussing some methods we wanted to add to `[MaybeUninit<T>]`.
Repository: rust
Issue: Channel used for emitting diagnostic from codegen threads is not guaranteed to be fully drained when compilation session is aborted
Labels: A-testsuite,T-compiler,C-bug,E-needs-investigation

> AFAIK, the channel used for emitting diagnostic from codegen threads is not guaranteed to be fully drained when compilation session is aborted. 

 _Originally posted by @tmiasko in [#82886](https://github.com/rust-lang/rust/issues/82886#issuecomment-792944737)_

This may have lead to e.g. #82886.
Repository: next.js
Issue: Nested parallel routes not unmounted when navigating back using router.back after a hard refresh
Labels: bug

### 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 11 Pro
  Available memory (MB): 16329
  Available CPU cores: 6
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 15.0.4-canary.28 // Latest available version is detected (15.0.4-canary.28).
  eslint-config-next: 14.2.13
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.6.2
Next.js Config:
  output: N/A
```


### Which example does this report relate to?

https://github.com/rexfordessilfie/next-tabs

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

When navigating through the application, the following sequence of actions leads to the sub-a route being mounted:

1. Starting from the root, navigate to tab-a.
2. Then, navigate to sub-a under tab-a.
3. Perform a hard reload of the page.
4. Use the browser back button (or router.back()) to return to tab-a.

### Expected Behavior

Upon navigating back to tab-a, the sub-a route should be unmounted, and the view should correctly reflect the state of tab-a.

### To Reproduce

1. Navigate to root.
2. Navigate to tab-a.
3. Navigate to sub-a.
4. Hard reload the page (Ctrl + R or Command + R).
5. Use the browser back button (or router.back()).
6. Observe that the sub-a route remains mounted under tab-a.
Repository: langchain
Issue: langchain.agents.openai_assistant.base method parameters don't allow response_format
Labels: 🤖:bug

### Checked other resources

- [X] I added a very descriptive title to this issue.
- [X] I searched the LangChain documentation with the integrated search.
- [X] I used the GitHub search to find a similar question and didn't find it.
- [X] I am sure that this is a bug in LangChain rather than my code.
- [X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

### Example Code

Methods such as the following, from langchain.agents.openai_assistant.base do not accept 'response_format' for json schemas:
```python
    def _create_thread_and_run(self, input: dict, thread: dict) -> Any:
        params = {
            k: v
            for k, v in input.items()
            if k in ("instructions", "model", "tools", "run_metadata")
        }
        run = self.client.beta.threads.create_and_run(
            assistant_id=self.assistant_id,
            thread=thread,
            **params,
        )
        return run

### Error Message and Stack Trace (if applicable)

There's no exception; it just filters out response_format as it's not in the accepted list. openai clients and method such as "create_and_run" accept this parameter, so you shouldn't be filtering it.

### Description

I'm trying to submit response_format as one of my input parameters, but your code explicitly filters it out as per the example code from langchain.openai_assistant.base.

When I edit your code to accept response_format everything works fine, as it's (now) an accepted parameter to openai assistants and the openai client library code. I understand this is relatively new, so I'm figuring you just have to update your code to reflect that it's now valid.

### System Info

not applicable
Repository: deno
Issue: No Autocomplete featuire 
Labels: needs info

Version: Deno latest

There is no autocomplete feature for packages... Please fix it... 

```json
{
  "tasks": {
    "dev": "deno run --watch main.ts"
  },
  "imports": {
    "@std/assert": "jsr:@std/assert@1",
    "mongoose": "npm:mongoose@^8.8.3"
  },
  "fmt": {
    "indentWidth": 2,
    "useTabs": false,
    "semiColons": false
  }
}
```

My MongoDB package is installed but in my editor autocomplete is not working.. I mean no autocomplete suggestion  in Deno please add this feature
Repository: pytorch
Issue: Marking integer inputs to a compiled region requires `torch._dynamo.assume_static_by_default = True`
Labels: triaged,oncall: pt2,module: dynamic shapes

From some discussion with @drisspg after looking https://github.com/pytorch/pytorch/issues/141486#issuecomment-2501574320.

Here is a slightly modified repro:

```
import torch
from torch.nn.attention.flex_attention import create_block_mask, flex_attention
flex_attention_compile = torch.compile(flex_attention, fullgraph=True)
fast_create = torch.compile(create_block_mask, fullgraph=True)
B = 1
S = 10_000
H = 8
D = 16
def sliding_window_mask(window_size: int):
    def mask_fn(b, h, q_idx, kv_idx):
        return (q_idx - kv_idx <= window_size // 2) & (kv_idx - q_idx <= window_size // 2)
    return mask_fn
mask_mod = sliding_window_mask(1024)
xs = [torch.randn(B, H, i, D, dtype=torch.float16, device="cuda", requires_grad=True) for i in range(10_000, 100_000, 1_000)]
# Warmpup
#block_mask = fast_create(mask_mod, B=None, H=None, Q_LEN=S, KV_LEN=S, device="cuda")
#torch._dynamo.mark_dynamic(xs[0], -2)
#flex_attention_compile(xs[0], xs[0], xs[0], block_mask=block_mask)
from pathlib import Path
torch.cuda.synchronize()
# with profiler(Path("user_2.json")):
from contextlib import nullcontext
with nullcontext():
    for x in xs:
        block_mask = fast_create(mask_mod, B=None, H=None, Q_LEN=x.size(-2), KV_LEN=x.size(-2), device="cuda")
        out = flex_attention_compile(x, x, x, block_mask=block_mask)
        bwd = out.sum().backward()
```

Running with `TORCH_LOGS="recompiles"` gives you an initial recompile with this message:
```
    triggered by the following guard failure(s):
    - 0/0: L['Q_LEN'] == 10000
```

What's happening is that:

(1) even though we mark `x.size(2)` has having a dynamic shape, we end up passing it **directly** as an input to the compiled region (`block_mask`)

(2) We don't have a way (that I could find) to mark specific integer inputs to a compiled region as dynamic. I found `torch._dynamo.assume_static_by_default=True`, but this flag looks deprecated, and also applies to all inputs. Do we have, or do we want to add, a way to mark integer inputs on an int-by-int basis?

One side note from talking to @drisspg is that it would be very nice if in eager mode, calling `Q_LEN=x.size(-2)` "remembered" that `Q_LEN` is now dynamic as well, without the user needing to do extra work to tell the compiler about the dynamism though. This would require doing the provenance tracking in eager though, which will have a performance cost.

cc @chauhang @penguinwu @ezyang @bobrenjc93
Repository: pytorch
Issue: FX graph cache does not do provenance tracking for inductor guards
Labels: triaged,oncall: pt2,module: inductor

Given the below repro, if I run it with `TORCHINDUCTOR_FX_GRAPH_CACHE=0 TORCH_LOGS="+recompiles"`, I get a recompile due to a shape guard that tells me about inductor recompiling on 32 bit indexing:
```
DEBUG: Recompiling function create_block_mask in /home/hirsheybar/.conda/envs/torchtune/lib/python3.11/site-packages/torch/nn/attention/flex_attention.py:810
    triggered by the following guard failure(s):
    - 0/0: L['BLOCK_SIZE']**2*(((L['BLOCK_SIZE'] + L['Q_LEN'] - 1)//L['BLOCK_SIZE']))*(((L['BLOCK_SIZE'] + L['KV_LEN'] - 1)//L['BLOCK_SIZE'])) < 2147483648  # (_inductor/codegen/simd.py:1227 in can_use_32bit_indexing)
```

If I run it with an FX graph cache hit, though (running multiple times without the env var to skip caching), we lose the nice provenance tracking of the guard. It would be nice if the source information of the guard was included in the FX graph cache, so we could include it in the recompile reason:
```
DEBUG: Recompiling function create_block_mask in /home/hirsheybar/.conda/envs/torchtune/lib/python3.11/site-packages/torch/nn/attention/flex_attention.py:810
    triggered by the following guard failure(s):
    - 0/0: L['BLOCK_SIZE']**2*(((L['BLOCK_SIZE'] + L['Q_LEN'] - 1)//L['BLOCK_SIZE']))*(((L['BLOCK_SIZE'] + L['KV_LEN'] - 1)//L['BLOCK_SIZE'])) < 2147483648  # (<string>:1 in <module>)
```

repro code:
```
import torch
from torch.nn.attention.flex_attention import create_block_mask, flex_attention
flex_attention_compile = torch.compile(flex_attention, fullgraph=True)
fast_create = torch.compile(create_block_mask, fullgraph=True, dynamic=True)
B = 1
S = 10_000
H = 8
D = 16
def sliding_window_mask(window_size: int):
    def mask_fn(b, h, q_idx, kv_idx):
        return (q_idx - kv_idx <= window_size // 2) & (kv_idx - q_idx <= window_size // 2)
    return mask_fn
mask_mod = sliding_window_mask(1024)
xs = [torch.randn(B, H, i, D, dtype=torch.float16, device="cuda", requires_grad=True) for i in range(10_000, 100_000, 1_000)]
from pathlib import Path
torch.cuda.synchronize()
from contextlib import nullcontext
with nullcontext():
    for x in xs:
        torch._dynamo.mark_dynamic(x, 2)
        block_mask = fast_create(mask_mod, B=None, H=None, Q_LEN=x.size(-2), KV_LEN=x.size(-2), device="cuda")
        out = flex_attention_compile(x, x, x, block_mask=block_mask)
        bwd = out.sum().backward()
```

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @aakhundov @drisspg
Repository: flutter
Issue: ColorScheme onInverseSurface does not follow M3 specification.
Labels: framework,f: material design,a: fidelity,P2,team-design,triaged-design

### Steps to reproduce

`ColorScheme` incorrectly defines [`onInverseSurface`](https://api.flutter.dev/flutter/material/ColorScheme/onInverseSurface.html) as the property to configure the "Inverse On Surface" color role.  This is confusing when comparing Flutter configurations against M3 specifications.


### Expected results

`inverseOnSurface` should be used consistently within Flutter assets to refer to the "Inverse On Surface" color role.



### Actual results

**Compliant**

* `MaterialDynamicColors` uses [`inverseOnSurface`](https://api.flutter.dev/flutter/package-material_color_utilities_dynamiccolor_material_dynamic_colors/MaterialDynamicColors/inverseOnSurface.html)
* `DynamicScheme` uses [`inverseOnSurface`](https://api.flutter.dev/flutter/package-material_color_utilities_dynamiccolor_dynamic_scheme/DynamicScheme/inverseOnSurface.html)
* `Scheme` (deprecated) uses [`inverseOnSurface`](https://api.flutter.dev/flutter/package-material_color_utilities_scheme_scheme/Scheme/inverseOnSurface.html)

**Non-compliant**

* `ColorScheme` uses [`onInverseSurface`](https://api.flutter.dev/flutter/material/ColorScheme/onInverseSurface.html)


### Code sample

n/a

### Screenshots or Video

[M3 Color roles - Inverse colors](https://m3.material.io/styles/color/roles#7fc6b47e-db22-4e98-8359-7649a099e4a1)
![PixelSnap 2024-11-26 at 12 37 41@2x](https://github.com/user-attachments/assets/4c3be23e-92ff-4c91-962a-7269ed59363a)


### Logs

n/a

### Flutter Doctor output

n/a
Repository: godot
Issue: Reflection probes ambient lighting does not conserve energy when probes overlap.
Labels: bug,topic:rendering

### Tested versions

v4.3.stable.official [77dcf97d8]

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 32.0.15.6094) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

It looks like instead of blending the ambient lighting all probes apply their ambient lighting equally. The more overlapping probes in a particular area, the brighter or darker this area gets (depending on the environment). I found this while testing #61416, placing a smaller "detail" probe in a room which already had a main probe. That PR shows the effect much more prominently.

The setup of these probes may seem really dubious, but it's representative of a common workflow where you nest reflection probes. Commonly one probe would be placed covering an entire space, and subsequent smaller probes are used to resolve reflection inaccuracies, often resulting in a setup with several overlapping probes. This is very relevant for #89408 because that PR makes this workflow feasible in Godot.

**4.3 stable:**
![Image](https://github.com/user-attachments/assets/8fde888a-dc3f-4648-989f-ea5fc1a206fd)

**In Calinou's PR:**
![Image](https://github.com/user-attachments/assets/52d93d2c-0809-4be8-adc3-d96dfa40e128)

**4.3 MRP:**
Notice how in this case overlapping dark spots get even darker.
![Image](https://github.com/user-attachments/assets/5f86db1f-32ec-4412-8c02-6b313343473d)

The MRP is set up with one main probe, covering the entire space, and a bunch of tiny probes placed close to the back wall.
A secondary structure just has a main probe and a smaller probe representing what an artist might place to get more accurate reflections on a mesh that's a bit too far away from that main probes capture point. In this case I've placed that secondary probe deliberately very close to the main probe, so that the ambient lighting it captures should in principle be the same.

The expected behavior would be more or less constant ambient lighting. The captured lighting from these probes should be similar enough (since they're all placed in close proximity of each other) to allow them to blend much more subtly.

### Steps to reproduce

Place several overlapping reflection probes.

### Minimal reproduction project (MRP)

[reflection_probe_energy_conservation.zip](https://github.com/user-attachments/files/17924638/reflection_probe_energy_conservation.zip)
Repository: deno
Issue: Support tsconfig.json
Labels: suggestion

It would be convenient if deno could be pick up an existing repo, and be compatible with the tsconfig.json files, to ease the gradual migration.

This is in many ways similar to the package.json compat, where deno favors the package.json if present, which made big improvements to the incremental adoption story.