sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Unit test flake, "Decorations and editing > delete > non-collapsed dec"
Labels: unit-test-failure

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=277122&view=logs&j=55ac390b-ffb1-50ea-3650-525dd9a3fd80&t=c01b9029-2b08-503e-eba8-b45cf5956c33

```
  1) Decorations and editing
       delete
         non-collapsed dec
           edit.start == range.start && edit.end < range.end:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (vs/editor/test/common/model/modelDecorations.test)
      at process.processImmediate (node:internal/timers:478:21)
```
Repository: PowerToys
Issue: An unhandled exception occured in Command Not Found utility causing PowerShell process to stop working
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.81.1

### Installation method

WinGet

### Running as admin

No

### Area(s) with issue?

Command not found

### Steps to reproduce

1. Open Windows Terminal (pwsh as default profile)
2. Getting the unhandled exception right away causing PowerShell to exit

![image](https://github.com/microsoft/PowerToys/assets/89489853/ffc3b2e2-b6de-469c-8d4f-472fc5207a24)
[PowerToysReport_2024-06-05-19-31-44.zip](https://github.com/user-attachments/files/15594942/PowerToysReport_2024-06-05-19-31-44.zip)



### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: next.js
Issue: CJS module package code that contains "typeof window === 'undefined'" checks are not excluded from app router client builds
Labels: bug,SWC,Webpack

### Link to the code that reproduces this issue

https://github.com/adanperez/nextjs-cjs-package-bug

### To Reproduce

1. Start the application after installing. `yarn dev`
2. Navigate to http://localhost:3000/cjs

### Current vs. Expected behavior

Next.js seems to be including server code when compiling the client code for the browser.

For a CJS module package used on an app router page, the Next.js build is ignoring the `typeof window === 'undefined'` check when compiling the client code.  In this case it is trying to add `node:` prefixed packages that `undici` is using.
The `undici` code should only be referenced  in the server code and not in the client code.

You will see the following node prefix import error if you go to http://localhost:3000/cjs where that package is being used.

```
Build Error
Failed to compile

node:assert
Module build failed: UnhandledSchemeError: Reading from "node:assert" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.
```

If you have that samne CJS module package code local to the project in the `src` directory, it will work as expected. 
 It will not include the `undici` code path. See http://localhost:3000/local. (you may have to restart the app if you triggered the bug from the other link)

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.12.2
  npm: 10.5.0
  Yarn: 1.22.19
  pnpm: 8.15.1
Relevant Packages:
  next: 14.3.0-canary.65
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


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

SWC, Webpack

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

next dev (local), next build (local)

### Additional context

I've also tested on Next.js [v15.0.0-canary.12](https://github.com/vercel/next.js/releases/tag/v15.0.0-canary.12) with latest React 19 RC which yields the same error.
Repository: rust
Issue: Tracking Issue for `mixed_integer_ops_unsigned_sub`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(mixed_integer_ops_unsigned_sub)]`

This is a tracking issue for https://github.com/rust-lang/libs-team/issues/386

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
impl uX {
    pub const fn checked_sub_signed(self, iX) -> Option<Self>;
    pub const fn overflowing_sub_signed(self, iX) -> (Self, bool);
    pub const fn saturating_sub_signed(self, iX) -> Self;
    pub const fn wrapping_sub_signed(self, iX) -> Self;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] ACP: https://github.com/rust-lang/libs-team/issues/386
- [ ] Implementation: https://github.com/rust-lang/rust/pull/126046
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: pytorch
Issue: Handling reasoning about rationals in symbolic shapes
Labels: triaged,module: dynamic shapes

### 🐛 Describe the bug

In an early version of https://github.com/pytorch/pytorch/pull/126905 I attempted to add asserts to our sympy functions. Specifically, for sympy functions that expected to receive integer inputs (like IntTrueDiv), I asserted that the inputs `is_integer`. Because our fragment of Sympy reasoning follows Python int/float promotion rules (and in particular, there is no data dependence about it), in principle it should be possible to always accurately tell if any given expression is integral or not.

However, there are some cases where we end up generating rational expressions in reasoning. The easiest way to end up with rationals is when you use builtin Sympy division, which aggressively distributes division across addition:

```
>>> import sympy
>>> from sympy.abc import x, y
>>> (x + y) / 2
x/2 + y/2
```

When simplifications involving rationals happen, it is easy to lose track that a larger quantity `is_integer` (and sympy's assumption system is rather weak, so it only does superficial reasoning). In the example above, if x + y is divisible by 2, then `x/2 + y/2` is integral, but Sympy would never be able to tell you this.

I always thought rationals were an unexpected and unwelcome style of simplification that I was happy to obliterate from Sympy. And I have mostly eliminated it in https://github.com/pytorch/pytorch/pull/126905  However, the offline solver makes use of sympy's inequality solver, which does not support custom functions (https://github.com/sympy/sympy/issues/26632), and so the offline solver rewrites FloorDiv into sympy division so that it can make use of it. This means rationals can show up, and in particular, means that I can't really do any `is_integer` asserts.

This issue is to track what we should do about this. We appear to be internally split about it. @lezcano strongly favors stringent invariants, but @avikchaudhuri says:

> Hmm, seems hard to do reasoning on ints without allowing rationals. Feels like rationals are to ints what complex numbers are to reals...

> Is there a flag we could turn off to temporarily avoid these assertions, understanding that we might allow intermediate rationals to show up, and later check that the solutions would be integers?

One possibility is certainly to have some sort of context manager that turns off the assertions in some context, and enable this context manager in the offline solver. I'm not sure if anyone has better ideas.

### Versions

main
Repository: rust
Issue: Bug when using `.flatten()` method that has `Item = &'a T` when calling async function inside loop
Labels: A-diagnostics,A-trait-system,C-bug,A-async-await,AsyncAwait-Triaged,D-confusing,A-auto-traits

<!--
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: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f560d75b3eb32ab6d2e0e51590b0337f

I expected to see this happen: code compiles

Instead, this happened: `error: implementation of std::marker::Send is not general enough`

### Meta
`rustc --version --verbose`:
```
rustc 1.77.1 (7cf61ebde 2024-03-27)
binary: rustc
commit-hash: 7cf61ebde7b22796c69757901dd346d0fe70bd97
commit-date: 2024-03-27
host: x86_64-unknown-linux-gnu
release: 1.77.1
LLVM version: 17.0.6
```
Bug exists on `beta` and `nightly` versions also.

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
error: implementation of `std::marker::Send` is not general enough
  --> src/main.rs:63:5
   |
63 |     tokio::spawn(join_with_cancellation(f, cancellation.clone()));
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `std::marker::Send` is not general enough
   |
   = note: `std::marker::Send` would have to be implemented for the type `&CancellationToken`
   = note: ...but `std::marker::Send` is actually implemented for the type `&'0 CancellationToken`, for some specific lifetime `'0`

```

</p>
</details>

I have working example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=19183aa875e3dadf501f3b6bdfb61ce4.

It seems like the reason is combination of `.flatten()` method that has `Item = &'a T` when calling async function inside loop. If you try to remove `.await` from the line 33, it compiles. If you try to remove `.flatten()` as in second link - it compiles.

Also, the error seems kinda random. The pattern is as follows:
```
   = note: ...but `std::marker::Send` is actually implemented for the type `&'0 T`, for some specific lifetime `'0`
```
But every time I change the code, the compiler shows another `T` type in error hint.
Repository: flutter
Issue: ScrollView is not used in `Carousel`
Labels: c: new feature,framework,f: material design,f: scrolling,c: proposal,P3,team-design,triaged-design

### Use case

Might be useful when Carousel direction is vertical.

### Proposal

Use a `CustomScrollView` instead of `Scrollable` + `Viewport`.

More info in the PR comment: https://github.com/flutter/flutter/pull/148094#discussion_r1625120700
Repository: vscode
Issue: Improve Diff by shifting to connect two diffs
Labels: feature-request,diff-editor

[Example](https://microsoft.github.io/monaco-editor/playground.html?source=v0.49.0#XQAAAAKHBgAAAAAAAABBqQkHQ5NjdMjwa-jY7SIQ9S7DNlzs5W-mwj0fe1ZCDRFc9ws9XQE0SJE1jc2VKxhaLFIw9vEWSxW3yscw_j9JRgmSatbNyrNa50VLHWwDOn0YI7IfU0xJ0CGYU1vRtgnKPmZzQcQ1F9I-F9YcvQUj8HivueDk6xk10aTwo3x9G8PT6SxCHXeIPv6QeK7mnUrHiBYQEDPm0gfiSC89xDkwA_9bRgyKdtjk3nU13f4X9OunvJtK6VqNMEZSFjJBHmxGubzkKkKHqREyB0xGQVj3jljXI1X1rugWvbwE3la2iLho9pDPNeWRsgw8cKaO66f9Uk3AfyCvhIDw5QA00VjeEk6InxMGrFueJvwyGWX283JhHElXGl4kcRqMFuqneqMVapvpFLF0d470jxfJ_zuRfB_JmhTcnyOSZquyOU-I6EOT8EhrhZcP1zNNdB2g3Uz84rNLVQ7kyGTyCHCGd7DR8gZXQJ0rTk0i3i_oumVyhshKygqZF3pZAbSS5fjJOEY7XK-4bXi6XO1vLhj98sfc88rlqAZV8McG69j3rTKoSvHOhj7M3j5P0AEgFCrIXf1rtUzpyF5OVIWTqbQ0sEsxrzi2r1FL552E3et4VhDnPKJdpED-as30l4NgoVpWlug_42pFMcJLEaVEjF92VdE7DXvvQXWh_NfokRNlRU8llqCyv3M0nA66KWzUP-lpsjzJ5fUVLrGd2V0idN9iR_ijVakqMyFok_lXzo_KtnoKJOGRJ93nlWYipOVgDf_nAocf)

![image](https://github.com/microsoft/vscode/assets/2931520/e5f564fa-5d82-413f-bc23-aaa960f2e9b7)
Repository: godot
Issue: Script Create Dialog spams invalid classes into templates Dictionary
Labels: bug,topic:editor

### Tested versions

4.3 beta1 and earlier

### System information

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

### Issue description

When creating a script, you are given an option to use a script template:
![image](https://github.com/godotengine/godot/assets/2223172/a1273f99-4b47-4f81-8aa1-22ac74f66cf3)
The dialog remembers what template you selected for each class. The problem is that it's stored every time the Inherits field is modified, so e.g. if you manually type Node, templates will be remembered for "N", "No", "Nod" and "Node".

https://github.com/godotengine/godot/assets/2223172/ef531f5a-82d2-4763-a959-918d710be988

Normally you won't see it, because the template cache is supposed to be hidden, however #92814
Though even if hidden, that's still wrong. The template should be remembered when accepting the dialog, not on every class name change.

### Steps to reproduce

1. Open dialog to create new script
2. Enable Template
3. Type anything in Inherits field
4. (until #92814 is fixed) Open Editor -> Editor Settings check `metadata/script_setup_templates_dictionary` property

### Minimal reproduction project (MRP)

N/A
Repository: pytorch
Issue: [Inductor] Fusion of Tiled Point-Wise and Reduction Operators
Labels: triaged,oncall: pt2,module: inductor,module: float8

### 🚀 The feature, motivation and pitch

Repro of the issue:
```
    def test(x):
        y = torch.sum(x)
        z = x / 10.0
        z_t = z.t().contiguous().t()
        return y, z, z_t
```

We expect the first-level reduction of `sum` and `(x + x.t())` to be fused into one operator. 

However, these two ops currently can't fuse due to `invalid tiling`. Assuming the shape of x is 4096x4096. In inductor the first reduction will be split to 2 layers to be more efficient. First layer reduce [4096 x 4096] to [X] and the second layer reduce [X] to [1]. When inductor decide X, it does not realize that picking 4096 would make it possible to fuse the first layer reduction with the following pointwise op. In this case, inductor picks X other than 4096 (512 here). 



### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @anijain2305 @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @yanbing-j @vkuzo @albanD @msaroufim @bdhirsh
Repository: pytorch
Issue: Improve debugability of warnings/errors "Triggered internally at"
Labels: module: autograd,module: error checking,triaged,actionable

### 🚀 The feature, motivation and pitch

Pytorch has a horrible habit of obfuscating warnings/errors by making them lazy, deferring and implementing them in the C++ code base. Even the usual python trick of making warnings raise exceptions (`warnings.filterwarnings("error")`) doesn't help in this case. Too often, the user is confronted with something along the lines of:

```
.../site-packages/torch/autograd/graph.py:744: UserWarning: Somebody added this warning, presumably to
warn you about something going wrong in your code. This problem might be making your training slow or
inaccurate. Or it might just be a false warning, lol. Oh and here is some contextual information that
might make sense in a C++ context, but is almost useless for somebody who is using torch from python.
(Triggered internally at torch/good_luck.cpp:9001.)
  return Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
```

See [this issue search query](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+%22Triggered+internally+at%22+%22Calls+into+the+C%2B%2B+engine+to+run+the+backward+pass%22) for an approximate list of users running into such issues. This problem has almost become normalized to the point where people are conditioned to ignore the warnings emitted by pytorch (and I honestly can't blame them too much).

It seems that there are at least **some** mechanisms for determining and printing the actual traceback of the problem (like the `Traceback of forward call that caused the error:` message in anomaly detection mode). However this only works in specific cases, where the traceback was intentionally included by the C++ developer adding this particular warning. Ideally, I'd like to see something similar for all/most invocations of `TORCH_WARN`, possibly only enabled when some config option or environment variable is set.

### Alternatives

Accept the status quo (annoying, virtually undebuggable warnings with potential performance and correctness implications). It is still theoretically possible to debug these issues by essentially doing a binary search of the user's code (delete/stub out half of the code, run the code and hope that the warning disappears, etc), but this is an insanely annoying process. Especially if the warning is caused by some non-trivial combination of multiple pieces of code/features (amp, ddp, jit, etc) or by code in external libraries (timm, lightning, fairscale, etc).

### Additional context

_No response_

cc @ezyang @albanD @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @malfet
Repository: go
Issue: proposal: debug/buildinfo: export errNotGoExe
Labels: Proposal,NeedsInvestigation,FeatureRequest,GoCommand

### Go version

go1.23-9b43bfbc51

### Output of `go env` in your module/workspace:

```shell
N/A
```


### What did you do?

Resorted to `//go:linkname` tricks to get at this value. ([link](https://github.com/quay/claircore/blob/b6aa2499299f78a8c166e160ae44fa780f1b8158/gobin/exe.go#L19-L20))

### What did you see happen?

N/A

### What did you expect to see?

Without exporting `buildinfo.errNotGoExe`, a user must effectively re-implement the `debug/buildinfo` package to determine if an executable is a Go executable and if so, read data to hand to `runtime/debug.ParseBuildInfo`. If the user doesn't want to copy the logic that decodes the `.go.buildinfo` (or equivalent) section, the executable ends up needing to be parsed twice to check for the section and magic string.[^1] Additionally, a user would be unable to use the `internal/saferio` helper.

Returning an exported error (or an error that evaluates correctly to a sentinel error with `errors.Is`) allows a caller to distinguish between a file that _should_ have valid build info (`!errors.Is(err, buildinfo.errNotGoExe)`) and a file that's not expected to (`errors.Is(err, buildinfo.errNotGoExe)`) when the process can't "know" that a-priori.

[^1]: Because sections may be compressed, something like a bitstring search over the file isn't a reliable rule-in/rule-out criteria. To look for a Go-specific section (like `.go.buildinfo` or `.note.go.buildid` in the case of ELF) requires parsing the binary and throwing that work away to have `debug/buildinfo` parse it again.
Repository: godot
Issue: PackedByteArray resource compression not triggered by sub-resources
Labels: bug,topic:core

### Tested versions

- Reproducible in 4.3 beta 1 and master 96a386f3c424af96d950ee5098b4b0e4907c9508
- 

### System information

Godot v4.3.beta.mono (e2e6a4d2b) - Debian GNU/Linux trixie/sid trixie - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 Ti (nvidia) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

### Issue description

The release notes mention PackedByteArray encoding in text resources (https://godotengine.org/article/dev-snapshot-godot-4-3-beta-1/#packedbytearrays-saved-with-base64-encoding), but it doesn't activate for me in certain cases.

I'm not sure this is easy to do without a `@tool` script which can create nested sub-resources with large data arrays, but that's what I was doing when I ran into this. I.e. I have in-editor scripts that generate Images based on chunks of data and store them in fields of nodes of the scene. 

It seems from examining the code that https://github.com/godotengine/godot/pull/90889 may be responsible (and may go away later, according to https://github.com/godotengine/godot/pull/90889#pullrequestreview-2017569945). It tries to avoid resource incompatibility situations by only triggering compression for large-ish arrays, but contents of variants embedded in sub-resources are not scanned directly, thus missing large arrays that may still be part of the same .tscn file.


### Steps to reproduce

To repro: 
- open the project in the editor
- look at the 3D view
- confirm a sprite appears
- save the project
- check the `fmt_test.tscn` file on disk. Should be much less than 14 megs in size.


### Minimal reproduction project (MRP)

[fmttest.zip](https://github.com/user-attachments/files/15596874/fmttest.zip)
Repository: pytorch
Issue: [user empathy day 2][based] torch.compile issues
Labels: triaged,oncall: pt2,module: dynamo,module: startup-tracing-compile,empathy-day,dynamo-user-empathy-day,dynamo-triage-june2024

### 🐛 Describe the bug

## Pytorch-eager

Time = 2.8532286300323904 seconds for 10 iterations



## Torch.compile backend=eager

Observations
* One frame is getting recompiled and almost never ends. Question - why is Dynamo not giving up on that frame?
torch/_dynamo/symbolic_convert.py:774] [49/974]
* Perf is way too bad, mostly due to recompilation

Time = 35.62640808802098 seconds for 10 iterations
Verdict - Does not work

Other fixes
* Warn once for 
https://github.com/pytorch/pytorch/issues/128060 

/home/anijain/local/miniconda3/envs/user_empathy_day2/lib/python3.10/site-packages/torch/_dynamo/variables/functions.py:661: UserWarning: Graph break due to unsupported builtin flash_attn_2_cuda.PyCapsule.fwd_kvcache. This function is either a Python builtin (e.g. _warnings.warn) or a third-party C/C++ Python extension (perhaps created with pybind). If it is a Python builtin, please file an issue on GitHub so the PyTorch team can add support for it and see the next case for a workaround. If it is a third-party C/C++ Python extension, please either wrap it into a PyTorch-understood custom operator (see https://pytorch.org/docs/main/notes/custom_operators.html for more details) or, if it is traceable, use torch.compiler.allow_in_graph.
  warnings.warn(msg)





**torch.compile with backend=aot_eager**

* Fails - https://www.internalfb.com/phabricator/paste/view/P1397185414




### Error logs

_No response_

### Minified repro

_No response_

### Versions

NA

cc @ezyang @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @oulgen @jamesjwu @aorenste @laithsakka @bdhirsh @msaroufim