sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Add an app filter to override awake's usual behaviour
Labels: Idea-Enhancement,Product-Awake

### Description of the new feature / enhancement

Add a box where apps can be added to allow awake to customize the behaviour when that app is open. You can select an app, then set it to any of the existing awake statuses, so that the powertoy automatically turns on or off.

### Scenario when this would be used?

This functionality would be useful to activate when a program is downloading or processing something, for example if Blender is rendering a scene i don't want the computer to go to suspension or to turn off the screen like it usually does.

### Supporting information

_No response_
Repository: go
Issue: cmd/asm,cmd/compile: add support for shadow stack
Labels: NeedsInvestigation,compiler/runtime

X86_64 CPUs can support  Shadow Stack (SHSTK). SHSTK helps to mitigate against Return Oriented Programming (ROP) expoits, as well as others that target a process's call stack.

On linux binaries need to be marked with a note section `.note.gnu.property` marking support for `GNU_PROPERTY_X86_FEATURE_1_SHSTK` in order to support SHSTK. I believe Windows also supports SHSTK but have no knowledge of how.

Go should ideally support SHSTK on Linux and add the note section showing it does support it.  Provided Go does not change the stack I believe it should be sufficient for Go to mark the binaries it generates.

https://github.com/golang/go/issues/66054  is for the other half of Control-flow Enforcement Technology (CET).
Repository: pytorch
Issue: Automatically bind all DispatchKey to Python
Labels: triaged,module: dispatch,internal ramp-up task

It gets a bit annoying to use a DispatchKey that is not bound to Python in the current version of PyTorch
Repository: excalidraw
Issue: Incompatible with next React version
Labels: package:excalidraw

The Excalidraw bundles `react/jsx-runtime`, but not `react` itself. This means that if a new React version changes the interface between jsx and react, it'll break.

You can see this by searching for `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` in 
https://unpkg.com/@excalidraw/excalidraw@0.17.5/dist/excalidraw.production.min.js
That internal was renamed in https://github.com/facebook/react/commit/f6131653570bbbf62d642ba9343b9cd0ab1ae97c

What should be done here is to configure the Excalidraw build such that `react/jsx-runtime` is not bundled and remain a `require` just like `react` or `react-dom`.
Repository: deno
Issue: lsp - Opening remote document with x-typescript-types causes type checking to fail
Labels: bug,lsp

              Seems like a small bug where we don't take into account x-typescript-types for remote open documents?

_Originally posted by @dsherret in https://github.com/denoland/deno/pull/23374#discussion_r1566295929_

Reproduction steps:

1. Setup
   ```
   // deno.json
   {
     "vendor": true
   }
   // main.ts
   import * as test from "https://esm.sh/react@18.2.0";

   console.log(test.Children);
   ```
2. Cache everything and observe type checking and go to definition is working
3. Open up `vendor/esm.sh/#react@18.2.0_9a31e.js` so it's an open document and observe type checking is no longer working for the `test` import.
Repository: bitcoin
Issue: utils: wallet_dump can create a `database` directory, cross-pollinating records
Labels: Wallet

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I created a large directory with legacy wallet dat files for testing #26606. Ran into a weird issue where the output mismatches, but after investigating deeper, this was not due to a bug in that PR.

So I created a script that iterates over all wallets, dumps them with the internal bdb and external bdb, diffs the textual output, stopping on the first wallet which mismatches. Mind that the wallets are loose `.dat` files, not themselves subdirectories.
```sh
#!/bin/bash
set -e
DATADIR="$HOME/.../2024-04-testwallets"
for WALLET in a.dat b.dat c.dat d.dat ...; do
    echo $WALLET
    rm -f /tmp/dump /tmp/dump2
    src/bitcoin-wallet -datadir="$DATADIR" -withinternalbdb -wallet="$WALLET" -dumpfile=/tmp/dump dump
    src/bitcoin-wallet -datadir="$DATADIR" -wallet="$WALLET" -dumpfile=/tmp/dump2 dump

    diff -q /tmp/dump /tmp/dump2

    ### Uncomment to following to make it work:
    # rm -rf $DATADIR/database. 
done
rm -f /tmp/dump /tmp/dump2
```
So far so good. 

However, I was seeing some huge divergences. Not small differences that could be explained to differences in interpretation, but e.g. the output would have wildly different `blockheight`. A kind of cross-pollination.

What it turned out to be is that the `bitcoin-wallet dump` leaves behind a `database/` subdirectory on close containing log files (`log.0000000001` etc). When opening the next wallet in the same directory, this subdirectory is used, and affects the dumped contents of the new wallet.

Deleting the `database` directory between wallets solves the problem. If this is still worth fixing, the wallet should probably compact after close to incorporate the log files. You wouldn't expect modification on a read-only operation in the first place, but I suppose this is due to an inherent bdb limitation.


### Expected behaviour

Successively dumped wallets don't affect each other.

### Steps to reproduce

See script in "current behavior".

### Relevant log output

_No response_

### How did you obtain Bitcoin Core

Compiled from source

### What version of Bitcoin Core are you using?

7f8d4c963c6a12da0e8df462a3f25ccda4a39a62 (#26606)

### Operating system and version

Ubuntu 24.04

### Machine specifications

_No response_
Repository: pytorch
Issue: [C10D] Standardize torch distributed launcher interface
Labels: oncall: distributed



Quoting @zdevito from the thread on #123992 
"I think it makes sense to eventually have a specification for what a particular launcher is required to provide to use torch distributed written in one place in the docs. It would say something like the following environment variables need to be set (RANK, SIZE, LOCAL_RANK, LOCAL_SIZE, TCP_STORE_ADDR, etc.). Then when we initialize torch distributed if a launcher launched without matching spec we could warn today and error tomorrow. That way we would start to encourage all launchers to become consistent in how they inform torch distributed about what is happening."

Basically, 
1) find a canonical place to document this info
2) add a warning if some of it is missing at runtime

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @yf225 @chauhang
Repository: vscode
Issue: Expand source files in explorer (Combined outline/Project explorer)
Labels: feature-request,outline

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
One of the biggest things I miss in VSCode as compared to regular visual studio (and a few other IDEs), is the ability to expand source files in the project explorer to get the file's outline, and quickly jump between classes and methods in multiple source files. It'd be really nice to have this functionality in VSCode.
Repository: node
Issue: Perf Issue with passing CA certs in Agent Options for HTTPS calls vs NODE_EXTRA_CA_CERTS
Labels: https,performance

### Version

18.x

### Platform

Ubuntu, Mac

### Subsystem

_No response_

### What steps will reproduce the bug?

`addCACert()` has bottleneck when HTTPS endpoint is called with `https.agent.ca` option using `https`, when we switch to using `NODE_EXTRA_CA_CERTS` environment variable, we do not see `addCACert()` bottleneck.

With `agent.ca` options pointing to CA certs

```js
const https = require('https');
const fs = require('fs');

// Read the CA certificate file (replace 'ca.pem' with your actual CA certificate file path)
const caCert = fs.readFileSync('ca.pem');

// Create an agent with the CA certificate
const agent = new https.Agent({
  ca: caCert
});

function callHttpsService(url) {
    https.get(url, { agent: agent }, (res) => {
        let data = '';

        // A chunk of data has been received.
        res.on('data', (chunk) => {
            data += chunk;
        });

        // The whole response has been received. Print out the result.
        res.on('end', () => {
            console.log(data);
        });

    }).on("error", (err) => {
        console.log("Error: " + err.message);
    });
}

callHttpsService('https://example.com');
```

<img width="629" alt="image-2024-03-14-18-09-42-261" src="https://github.com/nodejs/node/assets/6810685/40b568ec-5cfa-4111-8ea9-6e5cf97dfe5f">

With `NODE_EXTRA_CA_CERTS` env variable pointing to CA certs

```shell
export NODE_EXTRA_CA_CERTS=/path/to/cert.pem && node index.js
```
```js
// index.js
const https = require('https');

function callHttpsService(url) {
    https.get(url, { agent: agent }, (res) => {
        let data = '';

        // A chunk of data has been received.
        res.on('data', (chunk) => {
            data += chunk;
        });

        // The whole response has been received. Print out the result.
        res.on('end', () => {
            console.log(data);
        });

    }).on("error", (err) => {
        console.log("Error: " + err.message);
    });
}

callHttpsService('https://example.com');
```

<img width="660" alt="image-2024-03-14-18-10-44-663" src="https://github.com/nodejs/node/assets/6810685/4cf0c26b-bd05-47b5-8a1b-88aec3a84795">

### How often does it reproduce? Is there a required condition?

This is introduced in Node 16.x and seen in Node 18.x & Node 20.x. For every request.

### What is the expected behavior? Why is that the expected behavior?

<img width="660" alt="image-2024-03-14-18-10-44-663" src="https://github.com/nodejs/node/assets/6810685/2af1501d-d55e-4676-9ac5-976fb1ecf886">

### What do you see instead?

<img width="629" alt="image-2024-03-14-18-09-42-261" src="https://github.com/nodejs/node/assets/6810685/7935fcbb-656e-41f7-b21b-7423e7fda505">

### Additional information

_No response_
Repository: vscode
Issue: File watcher problems on Mac
Labels: bug,file-watcher,confirmation-pending

Occasionally VS Code on Mac gets in a state for me where the mechanism used to update edit buffers when the on-disk file is modified stops working. The problem applies to all files, and it doesn't matter whether I have previously edited the file or not.

**What I expect:**
- I open a file in a VS Code buffer
- I change that file using a command line tool
- The changes are reflected in the VS Code edit buffer

**What I see (once in this state):**
- The changes aren't reflected in the VS Code edit buffer until I close and re-open the file

Once it is in this state it remains broken until I close and reopen the workspace. 

I presume you are using some kind of file watcher daemon and the daemon dies. Maybe you can direct me to a window where I can find the logs to help you further debug this?

I don't know what triggers this -- I only observe it when I do a command line git operation like `git checkout <file>` that changes a file on disk.

I have auto-save on with a 100 msec delay.

I should mention that the workspace I tend to use (almost exclusively) is my checkout of the cpython repo, which is fairly large  but not excessively so (5000 files under git control, and I have over 25,000 files total in that repo). My home directory is, let me say, rather much larger.

This is a Mac M3 running macOS Sonoma 14.4.1. In case it matters for the watcher, I am using a Dropbox client.

I'll gladly provide more information if you have subsequent questions, but it may take days before the problem pops up again.
Repository: godot
Issue: `is_on_floor` delayed by a frame while already touching floor by `safe_margin`
Labels: topic:physics,needs testing

### Tested versions

v4.2.1.stable.official.b09f793f5

### System information

Godot v4.2.1.stable - Ubuntu 22.04.4 LTS 22.04 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 () - AMD Ryzen 7 7800X3D 8-Core Processor (16 Threads)

### Issue description

If `CharacterBody2D` is already touching the floor by `safe_margin` after `move_and_slide()` is called, collision won't be reported until next call to `move_and_slide()`.

It leads to very counterintuitive behavior. Imagine you give player a dash ability but it can be done only while not on floor. Dash sets vertical speed and gravity to 0. With a frame-perfect input player can dash while actually already touching the floor. `is_on_floor()` returns `false` so dash is possible but in the next frame magically `is_on_floor()` reports true even though there was no gravity nor vertical velocity so there is no reason to suddenly collide with the floor.

### Steps to reproduce

Create some `StaticBody2D` and above it place a `CharacterBody2D` with following script:

```
extends CharacterBody2D

var touched = false

func _ready():
	velocity.y = 8

func _physics_process(delta):
	if touched:
		return
		
	var diff = velocity * delta
	var expected_pos = position + diff
	
	prints("BEFORE:", "floor:", is_on_floor(), "position:", position, "expected_pos:", expected_pos, "velocity:", velocity)
	touched = move_and_slide()
	prints(touched)
	prints("AFTER:", "floor:", is_on_floor(), "position:", position, "expected_pos:", expected_pos, "velocity:", velocity)
```

At the very end of output you can see something like:

```
BEFORE: floor: false position: (400, 169.8665) expected_pos: (400, 169.9998) velocity: (0, 8)
false
AFTER: floor: false position: (400, 169.9998) expected_pos: (400, 169.9998) velocity: (0, 8)
BEFORE: floor: false position: (400, 169.9998) expected_pos: (400, 170.1332) velocity: (0, 8)
true
AFTER: floor: true position: (400, 169.9998) expected_pos: (400, 170.1332) velocity: (0, 0)
```

The one before last `move_and_slide()` call moves the body so it is already closer than `safe_margin` to `StaticBody` but the collision was not reported until the very last call to `move_and_slide()`. Last call does not move the body but actually reports the collision.

### Minimal reproduction project (MRP)

[example.zip](https://github.com/godotengine/godot/files/14984420/example.zip)
Repository: godot
Issue: No TileSet atlas source with id -1.
Labels: bug,needs testing,topic:2d

### Tested versions

Godot 4.2.1 - Stable.

### System information

Windows 11, Godot 4.2.1-Stable. Vulkan, Mobile.

### Issue description

I made a world generator using a tile map, but oddly it keeps crashing with this error: 
E 0:00:25:0323   get_source: No TileSet atlas source with id -1.
  <C++ Error>    Condition "!sources.has(p_source_id)" is true. Returning: nullptr
  <C++ Source>   scene/resources/tile_set.cpp:549 @ get_source()

This error happens at complete random times when I walk around. Note: I made it generate more tiles when the player walks and erase the tiles too far from the player for optimization on mobile.

This world generator works great until this error crashes the game.

I do not use any plugins or modified versions of Godot.

### Steps to reproduce

Uncertain. The issue may be part of the erase_cell() function or set_cell().

### Minimal reproduction project (MRP)

None.
Repository: go
Issue: proposal: runtime: an http.Handler that implements 'go tool trace' in process
Labels: Proposal

For applications that already include a web server and generate event traces (e.g. gopls), it is convenient for the developer to be able to collect and view a trace of events from within the application itself. Unfortunately, the event trace viewer is currently only available through the 'go tool trace' command, which opens its own web server, complicating the integration and management of processes and lifetimes.

This proposal requests a package, maintained by the runtime team, that provides an http.Handler that can be added to the application's ServeMux to allow the developer to view event traces within the existing server.

Related:
- https://github.com/golang/go/issues/63185

@mknyszek
Repository: pytorch
Issue: Equality between SymBool is extremely busted
Labels: triaged,oncall: pt2,module: dynamic shapes

### 🐛 Describe the bug

At minimum need

```
diff --git a/torch/fx/experimental/symbolic_shapes.py b/torch/fx/experimental/symbolic_shapes.py
index b634f6e3139..a257a396f8b 100644
--- a/torch/fx/experimental/symbolic_shapes.py
+++ b/torch/fx/experimental/symbolic_shapes.py
@@ -276,6 +276,8 @@ def _canonicalize_bool_expr_impl(expr: SympyBoolean) -> SympyBoolean:
         t = opposite[type(expr)]
     else:
         assert isinstance(expr, (sympy.Lt, sympy.Le, sympy.Eq, sympy.Ne))
+        if not expr.lhs.is_number:
+            return expr
         lhs = expr.lhs - expr.rhs
         t = type(expr)
     rhs = 0
diff --git a/torch/utils/_sympy/value_ranges.py b/torch/utils/_sympy/value_ranges.py
index a056db6dbb9..3df65df0107 100644
--- a/torch/utils/_sympy/value_ranges.py
+++ b/torch/utils/_sympy/value_ranges.py
@@ -388,7 +388,7 @@ class SymPyValueRangeAnalysis:
         b = ValueRanges.wrap(b)
         if a.is_singleton() and b.is_singleton() and a.lower == b.lower:
             return ValueRanges.wrap(sympy.true)
-        elif a.lower > b.upper or b.lower > a.upper:  # ranges disjoint
+        elif not a.is_bool and (a.lower > b.upper or b.lower > a.upper):  # ranges disjoint
             return ValueRanges.wrap(sympy.false)
         return ValueRanges(sympy.false, sympy.true)
 
```

which gets you to

```
  File "/data/users/ezyang/a/pytorch/torch/fx/experimental/sym_node.py", line 398, in expect_true
    return self.shape_env.defer_runtime_assert(
  File "/data/users/ezyang/a/pytorch/torch/fx/experimental/recording.py", line 235, in wrapper
    return fn(*args, **kwargs)
  File "/data/users/ezyang/a/pytorch/torch/fx/experimental/symbolic_shapes.py", line 4410, in defer_runtime_assert
    self._maybe_guard_rel(expr)
  File "/data/users/ezyang/a/pytorch/torch/fx/experimental/symbolic_shapes.py", line 3998, in _maybe_guard_rel
    self._refine_ranges(expr)
  File "/data/users/ezyang/a/pytorch/torch/fx/experimental/symbolic_shapes.py", line 4453, in _refine_ranges
    r = try_solve(expr, symbol)
  File "/data/users/ezyang/a/pytorch/torch/utils/_sympy/solve.py", line 83, in try_solve
    trial = _try_isolate_lhs(e, thing, floordiv_inequality=floordiv_inequality)
  File "/data/users/ezyang/a/pytorch/torch/utils/_sympy/solve.py", line 109, in _try_isolate_lhs
    e = op(expr.lhs - lhs_not_thing, expr.rhs - lhs_not_thing)  # type: ignore[attr-defined]
torch._dynamo.exc.BackendCompilerFailed: backend='inductor' raised:
TypeError: unsupported operand type(s) for -: 'Equality' and 'int'
```

cc @gchanan @zou3519 @kadeng @msaroufim @bdhirsh @anijain2305 @chauhang @lezcano 

### Versions

main
Repository: deno
Issue: Exception thrown by WebAssembly in async function causes Deno to hang forever
Labels: bug,deno_core

Version: Deno 1.41.3

Reproduction: https://github.com/kylebarron/wasm-bindgen-deno-test

This exports a simple function `panic_async`. If you call this with `await wasm.panic_async();`,
the future never resolves and the REPL hangs forever:

<img width="448" alt="image" src="https://github.com/denoland/deno/assets/15164633/92244b44-7607-4424-b16b-36ccb50e0ccf">


Note that if you call the function without `await` then you do get an `Uncaught RuntimeError`

```
> wasm.panic_async();
Promise { <pending> }
Uncaught RuntimeError: unreachable
    at <anonymous> (file:///Users/kyle/tmp/wasm-bindgen-deno-test/wasm-bindgen-deno-test/pkg/wasm_bindgen_deno_test_bg.wasm:1:10804)
    at <anonymous> (file:///Users/kyle/tmp/wasm-bindgen-deno-test/wasm-bindgen-deno-test/pkg/wasm_bindgen_deno_test_bg.wasm:1:16086)
    at <anonymous> (file:///Users/kyle/tmp/wasm-bindgen-deno-test/wasm-bindgen-deno-test/pkg/wasm_bindgen_deno_test_bg.wasm:1:12546)
    at <anonymous> (file:///Users/kyle/tmp/wasm-bindgen-deno-test/wasm-bindgen-deno-test/pkg/wasm_bindgen_deno_test_bg.wasm:1:8885)
    at <anonymous> (file:///Users/kyle/tmp/wasm-bindgen-deno-test/wasm-bindgen-deno-test/pkg/wasm_bindgen_deno_test_bg.wasm:1:16497)
    at __wbg_adapter_16 (file:///Users/kyle/tmp/wasm-bindgen-deno-test/wasm-bindgen-deno-test/pkg/wasm_bindgen_deno_test.js:81:10)
    at real (file:///Users/kyle/tmp/wasm-bindgen-deno-test/wasm-bindgen-deno-test/pkg/wasm_bindgen_deno_test.js:66:20)
    at ext:core/01_core.js:303:9
    at eventLoopTick (ext:core/01_core.js:169:7)
```

So I assume what's happening here is that constructing the future errors and then there's nothing to `await`, or something like that. 

For contrast, running this in Node crashes the process:

<img width="767" alt="image" src="https://github.com/denoland/deno/assets/15164633/90f73c15-54d7-497c-867c-267215a2cf1b">


To reproduce:

```
wasm-pack build --target web
```

Then inside Deno:

```js
const wasm = await import("./pkg/wasm_bindgen_deno_test.js");
let _ = await wasm.default();
await wasm.panic_async();
```
Repository: PowerToys
Issue: Bug occurrence
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.78.0.0

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

Always on Top

### Steps to reproduce

[2024-04-16.txt](https://github.com/microsoft/PowerToys/files/14985113/2024-04-16.txt)


### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: TypeScript
Issue: `const enum` references in the body of nodes with grammar errors are not inlined
Labels: Bug,Help Wanted

### Acknowledgement

- [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Comment

Which results in output that's more broken than the input.

For example,
```ts
const enum A {
    a = 1,
    b = 2
}

A.a;

return {
    f() {
        return A.a;
    }
}
```

A top-level `return` is a grammar error, but is valid in old-style cjs modules at runtime, so is actually a vaguely reasonable grammar error to `//@ts-ignore`. The issue, however, is that the const enum reference within the body of that return statement -`A.a` is left as-is rather than being inlined, so at runtime it refers to something which does not exist.

This doesn't seem to be in any way intentional - this is a side effect of `getConstantValue` in the checker only using a cached `resolvedSymbol`, rather than ensuring one is available by checking/resolving the access expression first (which is also an issue for emit done before a full checker walk).
Repository: rust
Issue: rustdoc: support RTN once its syntax is somewhat finalized 
Labels: T-rustdoc,P-low,C-bug,S-blocked,F-return_type_notation

**This is blocked by T-lang's decision on the final syntax of RTN!**

---

Source:

```rs
#![feature(return_type_notation)]

pub fn f<T: Trait<f(): Copy>>() {}

pub trait Trait { fn f() -> impl Clone; }
```

Current rendered output of `f` (local scenario, HIR-based cleaning):

```rs
pub fn f<T: Trait<f: Copy>>()
```

Current rendered output of `f` (inlined cross-crate re-export scenario, rustc_middle::ty-based cleaning):

```rs
pub fn f<T>()
where
    T: Trait,
    impl Clone: Copy,
```