sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: node.duplicate() does not resolve exported node properties
Labels: topic:core,documentation

### Godot version

v4.0.3.stable.mono.official [5222a99f5]

### System information

Windows 10, Godot 4.0.3.stable, Vulken (Forward+)

### Issue description

If a script has an exported node property, eg `@export var node : Node` pointing to a child node, when duplicated, the duplicate of said script will still point to the original node.

The ideal or expected behaviour would be:
If the exported node points to a child of the object, its duplicate should point the equivalent child of the duplicated object (the underlying NodePath does not change)
If the exported node does **not** point to a child of the object, its duplicate should target the same node as the original (the underlying NodePath will be different)

Currently, the behaviour is always the latter. This causes particular problems if you're assembling game elements procedurally; to give an example, a procedurally generated mob character might be assembled once and then duplicated as needed, an approach that will currently fall apart in very unpredictable ways if any part of said mob uses exported Node properties.

### Steps to reproduce

Have a script with an exported node property
Call duplicate() on an instance of said script
Check the node path

### Minimal reproduction project

[DuplicateExportedNodeBug.zip](https://github.com/godotengine/godot/files/11708921/DuplicateExportedNodeBug.zip)

Open in the editor and run the scene; check the paths printed in the Output window.
Repository: deno
Issue: Npm dependencies should warn about implicit version
Labels: suggestion,lsp

Same as url dependencies, and it should have a code action to update to the redirected specifier as well
![image](https://github.com/denoland/deno/assets/22427111/20bb5ec6-a006-43bb-8da7-5ce65388a336)
Repository: TypeScript
Issue: ES6 Class: `asserts this is Type` raises error when variable containing instance is type narrowed
Labels: Help Wanted,Possible Improvement

# Bug Report

### 🔎 Search Terms

* Error: "Assertions require every name in the call target to be declared with an explicit type annotation"
* Assertation function as class method
* Type narrowing class and then calling assertation method

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about this

### ⏯ Playground Link
[Playground link with relevant code](https://www.typescriptlang.org/play?#code/MYGwhgzhAECyCeBhcVoG8CwAoAkABwFcAjEAS2GkggFMAnAFwEkIFkqAKASgC5Ko76MegAtSMMXCQoYmXDlIAzaOwCE7ERNIA7CPTBbg1APZLW0zp3TYcNkbSMB3aFupOAorXu12Acg0wHSGcjemgTaHp4PGpJNigfTgBuaxwAX2t0rEzsYCMdUIBbMHgiajMqXnLUAB9oAi0AE2oFbWoG6ABeZ1dY6S5krGxFZSKSsqkqS1kcAHoZ6AAVURgFMFIQANIRaDovbms56ABBfgZSPJhaagBHAlIrnYA3OnhnMAKY7QjhGOAwEBAETAtAA5tRQvQjNBStAmqBgW1oA4tsJKFodgAPPBkYBbCJRGL6LQhMD0c5aAB07AATAB2WkAVk41lGpSqEApVAEzHZ-WwB3mACECKFhg4YhBSAVsa8qKQQejIZRuk5HsDSGASDFkSIjCLvjEjHgyXl-lt4AAaaBbHwrVr7Qa4Q7+aBkFxIoy0ADWMFKfwINCRMWEYGeb08jkRIhikWi33sBBBqOj1qUulJ1A+WlCmqMz2suXysOa2i21BA8HZlQmqC6rPGcQgiWgAsWy2gtDWNBgxJ2EdoT2oiuEeqT1votp2t1IapAQ4hUJTLVouko9HomeN1iaLS0ZYr7M5pyYLBrED5WX5WCAA)

### 💻 Code

<!-- Please post the relevant code sample here as well. This code and the Playground code should be the same, do not use separate examples -->
```ts
class MyClass {
	public assertIsMyClass(): asserts this is MyClass {
		if (!(this instanceof MyClass)) {
			throw new Error('this was not of type MyClass');
		}
	}
}

const maybeMyClass: MyClass | undefined = new MyClass();

if (maybeMyClass) {
	// This fails with error:
	// Assertions require every name in the call target to be declared with an explicit type annotation.(2775)
	maybeMyClass.assertIsMyClass();

	// But if we simply assign to a new variable without the optionality, it's fine:

	// this line works because we have narrowed the type through the if statement above
	const definitelyMyClass: MyClass = maybeMyClass; 
	// This raises no error even though it's equivalent to the first attempt
	definitelyMyClass.assertIsMyClass();
}
```

### 🙁 Actual behavior

Calling the class method assertation function raises error: "Assertions require every name in the call target to be declared with an explicit type annotation.(2775)"

### 🙂 Expected behavior

It should pass validation and narrow to the type given in the assertation.
This is because it will have this behavior if you simply assign to a new variable with a new type annotation (but which is equivalent to the narrowed type at that point).
Repository: next.js
Issue: Importing CSS file from an async component results in invalid script tags
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: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Mon Apr 24 20:53:44 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T8103
    Binaries:
      Node: 18.15.0
      npm: 9.5.0
      Yarn: 3.5.1
      pnpm: 8.6.1
    Relevant packages:
      next: 13.4.5-canary.9
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/danmartens/next-error-repro

### To Reproduce

I tried to create as minimal of a reproduction as possible. Instructions are in the repository, but basically you can run `pnpm install` and then `node test.mjs broken` to see the reproduction. That script will build the app and then repeatedly visit the broken URL via Puppeteer.

It only happens about 4-6% in the app I'm working on, but I was able to get it to happen basically 100% of the time by playing around with it for a while. The issue seems to be related to some sort of race condition, so you may have to increase the delay value in `src/app/broken/test-1/layout.tsx` to reproduce the issue. On my machine, I start to see failures with a 3ms delay and the error rate reaches ~100% with a 6ms or greater delay.

### Describe the Bug

When an async component that imports CSS renders within an async page component with an adjacent `loading.tsx` and an async layout component with `export const revalidate = 0;`, Next will generate invalid script tags for importing the CSS if the request takes longer than a certain amount of time. The script tags look like this and are always the last element before the `</body>` tag:

```html
<script>B:1","S:1",[["/_next/static/css/ef46db3751d8e999.css","next"]])</script>
```

### Expected Behavior

All `<script>` tags should contain valid JavaScript.

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

_No response_

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

_No response_
Repository: electron
Issue: macOS Sonoma Screen Shaeing picker integration
Labels: enhancement :sparkles:,macos sonoma

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

There's a new API in macOS Sonoma that allows selecting a window to share directly from it's title bar:

![0C855D25-D652-471F-A410-DE95C87027C3](https://github.com/electron/electron/assets/7311462/d31b4c11-7c1c-46c0-9d62-39c2d384658e)


### Proposed Solution

It would be great to have integration API that allows using this macOS feature 

### Alternatives Considered

There are no alternatives 

### Additional Information

It is called Screen Sharing Picker
Repository: godot
Issue: Editor does not grab focus from fullscreen game upon script error
Labels: bug,topic:editor,confirmed

### Godot version

4.0.3 stable [5222a99f5]

### System information

Windows 10 - Godot v4.0.3.stable - Vulkan (Forward+)

### Issue description

The bug results in your debug window not rendering anything and appearing to crash. It also messes with alt-tabbing; you can still alt-tab, but the window will still be over whatever window you've alt tabbed to. The crash also takes a while to close by itself and doesn't go white like crashes usually do. Important note! This only works when launch in fullscreen mode is set. It should just take you to the code editor like it does when not in fullscreen mode

Video of Bug:

https://github.com/godotengine/godot/assets/136120846/7b5f9d23-0986-4629-b4a3-d0ff95107312

A few notes:
I recorded this using OBS display capture. It recorded slightly differently then what i was seeing. I was seeing the default grey colour you get from empty scenes. but OBS recorded black.
When you see the cursor switch from the loading symbol to the typing cursor that's me Alt-Tabbing in and out of the window. It stays grey in my view, and stays black in OBS's.
There are no reports from Godot whatsoever; besides it saying debug closed.


### Steps to reproduce

The easiest way to do it is:

1. go to "Project > Project Settings > Display > Window > Size" and set mode to Fullscreen
2. make a scene (any node)
3. give the node a script
4. copy paste this in there then hit play:

```gdscript
extends Node

func _ready():
	var variable = Vector2.ZERO
	process_mode = variable
```

### Minimal reproduction project

N/A
Repository: flutter
Issue: Golden diff in `ExternalTextureTests_testMediaSurface` (Android test)
Labels: a: tests,platform-android,engine,P2,c: flake,team-android,triaged-android

During one of the dart rolls, a golden diff appeared in one of the Android-specific tests. I approved it to unblock the tree, but someone in the know should do a proper triage.

https://flutter-engine-gold.skia.org/search?issue=42702&crs=github&patchsets=1&corpus=flutter-engine
Repository: flutter
Issue: Autosubmit bot is not submitting PRs with a skipped third party deps scan
Labels: team-infra,P2,triaged-infra

See this skia autoroll for an example, which has been sitting for 2 days: https://github.com/flutter/engine/pull/42650

All other checks passed, but the third party deps scan is skipped
Repository: flutter
Issue: web engine fallback for the asset manifest is outdated
Labels: tool,engine,a: assets,platform-web,P2,team-web,triaged-web

[lib/web_ui/lib/src/engine/assets.dart](https://github.com/flutter/engine/blob/0d8d295c411974570290ea8cef7a6a8758b27cf1/lib/web_ui/lib/src/engine/assets.dart) has some [code](https://github.com/flutter/engine/blob/0d8d295c411974570290ea8cef7a6a8758b27cf1/lib/web_ui/lib/src/engine/assets.dart#L105-L108) that intercepts 404 responses for requests for the asset manifest and instead returns an empty [asset manifest](https://api.flutter.dev/flutter/services/AssetManifest-class.html) as a fallback. Using a fallback here is understandable--we do not want to give up on trying to load an asset just because the request for the asset manifest failed. Although Flutter wouldn't be able to find out what variants of an asset exists in such a scenario, there is a good chance that the main asset still exists (though it is possible that an asset _only_ has variants, in which case the request for the asset would still fail).

However, this code looks for requests for `AssetManifest.json`, which is outdated since https://github.com/flutter/flutter/pull/122505. This should be updated to the current name soon (`AssetManifest.bin` as of https://github.com/flutter/flutter/pull/128529).
Repository: vscode
Issue: Cannot sign into GitHub when running elevated
Labels: bug,authentication

<!-- ⚠️⚠️ 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/No

<!-- 🪓 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. -->

Version: 1.79.0 (user setup)
Commit: b380da4ef1ee00e224a15c1d4d9793e27c2b6302
Date: 2023-06-07T14:26:35.552Z
Electron: 22.5.5
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Windows_NT x64 10.0.23475

Steps to Reproduce:

1. Start VS Code from an elevated (run as administrator) prompt
2. Get prompted to log into GitHub to use the Copilot extension
3. Go through the Auth dance
4. Get this:

![image](https://github.com/microsoft/vscode/assets/1487073/7251f430-c93b-4b34-aa97-3bb3fa7ac755)

And then authentication fails.
Repository: godot
Issue: Infinite object growth with input activity (c# mono)
Labels: documentation,topic:dotnet

### Godot version

v4.0.3 stable mono official [5222a99f5]

### System information

Windows 11 pro 22H2, Godot 4.0.3 stable mono, Vulkan, NVidia 3080, AMD Ryzen 9

### Issue description

If the following node method is overridden in a C# script, the number of objects (visible in the debug performance monitor) grows with each input activity. 

### Steps to reproduce

`public override void _Input(InputEvent @event)
{
    base._Input(@event);
}`

The growth stagnates as soon as there is no more activity and grows again when there is input activity again. The growth is independent of the type of input (keyboard, joypad, etc). The number of objects grows as long as input activity is present. I could easily create 4k in 5min.

I tested this behaviour with a fresh project and an empty scene (only a node). A C# script was added to the node. Even without the script, the debugger shows almost 1k objects.

![Godot4-LargeNumberOfObjects_c](https://github.com/godotengine/godot/assets/134631577/f5d3fa1b-dc97-4765-ba73-8f46c17eb81a)


### Minimal reproduction project

[project.zip](https://github.com/godotengine/godot/files/11710260/project.zip)
Repository: pytorch
Issue: [feature request] Native method for iterating Python items of tensors: `iteritems()` and a new `tensor.item(i, j, k, ...)` method
Labels: feature,triaged,module: python frontend

### 🚀 The feature, motivation and pitch

without having to call `.item()`. OP: https://github.com/pytorch/pytorch/pull/103339#discussion_r1224826554

so this is needed for 1d tensors, although could be useful in the future in other contexts if string arrays are supported: https://github.com/pytorch/pytorch/issues/101699

Only relevant for large tensors/loops, where materializing a python list first takes too many python objects

Related on slow item indexing: https://github.com/pytorch/pytorch/issues/29973 and proposal of `tensor.item(i, j, k, ...)` fast indexing method returning Python int/float objects without `tensor[i, j, k, ...].item()` first creating an extra tensor object and only then upacking it

Related on supporting `memoryview` on tensors: https://github.com/pytorch/pytorch/issues/43949, then this method could be implemented by simply returning memoryview which supports iteration in python

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD
Repository: TypeScript
Issue: Dual ESM/CJS emit with tsc
Labels: Suggestion,In Discussion

#54546 explored one approach of enabling dual ESM/CJS emit for packages with tsc alone. The idea was that instead of determining the module format of .ts files by looking for package.json files in its ancestor directories, we would look for them starting at the directory where that file’s `.js` output would be emitted (a subdirectory of `outDir`). That way, two tsconfig files could point to two different output directories, each pre-seeded with a package.json files that set the module format for the output generated by that tsconfig.

This approach has two main downsides:

1. It’s annoying to have to commit package.json files into your output directory while gitignoring everything else. Additionally, if used in combination with other tools (e.g. tsc for declaration emit but rollup for JS emit), other tools might wipe the output directory, deleting your package.json.
2. Thinking about the implications for projects that aren’t doing dual emit, if we determine the module format based only on the output file structure, we potentially fail to analyze the behavior of ts-node, or a bundler that cares about package.json `"type"`. This can be a problem if a project compiles with tsc for publishing, but runs input .ts files directly during development (which is a scenario I think we should make a habit of considering). Ideally, we want a solution that ensures the module format of the output _agrees_ with that of the input, unless the output format is being intentionally changed by config (presumably for purposes of dual emitting).

I think both of these can be solved by doing two things:

1. Introduce a compiler option that allows a package.json with `{ "type": "module" }` or `{ "type": "commonjs" }` (or blank, whatever) into the `outDir`, and use this config setting (instead of what’s already present in the `outDir`) to determine the module format of input files at a higher priority than any package.json files in a directory higher than `outDir`. This solves problem (1) above—no need to pre-seed or commit files in your build directory.
2. Whenever a package.json in a _subfolder_ of the common source directory / `rootDir` that affects the computed module format of a file is seen, emit that package.json (or a stub of it with just `"type"`?) into the corresponding subfolder within `outDir`. This solves (2), and actually solves an issue that exists today, where tsc output can be invalid for Node without manually copying a package.json that occurs inside `rootDir`. (@rbuckton mentioned this in team chat one time, but it didn’t get much discussion.)

Emitting package.json files would be new territory for us, but I think it’s worth it for the problems it solves.
Repository: pytorch
Issue: Add a requirements.txt for windows pip packages
Labels: triaged,module: devx

**Goal**: Enable pytorch devs to add/update pip packages for windows builds and tests in a single PR

### Context
Today, if you're introducing a PR that takes a dependency on a new python package, for Windows you need to:
1. Add a manual, temporary pip install somewhere in the workflow so that your PR passes
2. Create a test-infra PR that adds that pip package to the AMI here: https://github.com/pytorch/test-infra/blob/main/aws/ami/windows/scripts/Installers/Install-Pip-Dependencies.ps1
3. Remove the manual pip install line from step 1

That's pretty tedious

### The Ask
Instead we should do the following:

1. Define a dedicated requirements.txt file for windows in python/python, following the pattern used for https://github.com/pytorch/pytorch/blob/main/.github/requirements/pip-requirements-macOS.txt
3. In that [ps1 file](https://github.com/pytorch/test-infra/blob/main/aws/ami/windows/scripts/Installers/Install-Pip-Dependencies.ps1), download the req.txt file from the prev step (you'll need to get it from the py/py repo) and install the packages it specifies. 
4. In the windows build & test workflows, we also always install packages from the requirements.txt file if they’re not already installed.

### Benefits
1. This would make future installations/upgrades easy by putting all the package changes in a single folder
2. We have dependencies defined in one place 
3. We have safe guard in case the dependencies are not found in the AMI (which is expected for a small time window when a new package/upgrade is freshly added)

cc @kit1980 @huydhn @clee2000
Repository: godot
Issue: Collision Detection Edge Case with BoxShape colliding with a RectangularConvexPolygonShape3D
Labels: bug,topic:physics,topic:3d

### Godot version

4.0.2 Stable

### System information

Windows 10; AMD Ryzen 7 3700X 8-Core Processor 3.60 GHz

### Issue description

I found this critical edge case with BoxShape colliding with a RectangularConvexPolygonShape3D. It's almost as if it sometimes decides to ignore the shape and just goes straight to the one underneath. I've encountered this issue before but assumed it was my fault. Here, I was able to isolate it and it even happens with the most basic character controller provided by the engine, so I know for a fact it isn't my fault.

I can't provide much insight as to why this is broken, I just know that it is.

Video of the issue: https://youtu.be/bYk8O5thBeY

### Steps to reproduce

1.) Download MRP
2.) Click "Play"
3.) Walk forward. You can also go on the opposite side of the map where there is a mirrored shape that is identical to the shape that has collision issues. The other one works fine. Also try jumping on the less thick part of the broken shape, you might get stuck.

### Minimal reproduction project

[ConvexPolygonShape3DBug.zip](https://github.com/godotengine/godot/files/11710512/ConvexPolygonShape3DBug.zip)
Repository: rust
Issue: `let x = x` stack allocation on printing `Vec<T>`
Labels: I-slow,T-compiler,C-bug

The following code:
```rust
#[no_mangle]
pub fn awa(x: Vec<u16>) {
    let x = x;
    println!("{x:#?}");
}
```
[godbolt](https://rust.godbolt.org/z/WdrTrEan5)

Has an unnecessary allocation due to the redundant redefinition of `x`, even in release mode, causing an ~5% performance deficit.

`rustc --version --verbose`:
```
rustc 1.72.0-nightly (101fa903b 2023-06-04)
binary: rustc
commit-hash: 101fa903bb9209d270086da279247625a2869211
commit-date: 2023-06-04
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.4
```
Repository: next.js
Issue: Top level await breaks edge route
Labels: bug,Runtime

### Verify canary release

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

### Provide environment information

```bash
--> pnpm next info

    Operating System:
      Platform: linux
      Arch: x64
      Version: #165-Ubuntu SMP Tue Apr 18 08:53:12 UTC 2023
    Binaries:
      Node: 18.12.1
      npm: 9.5.1
      Yarn: 1.22.19
      pnpm: 8.3.1
    Relevant packages:
      next: 13.4.5-canary.9
      eslint-config-next: 13.4.4
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
```
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/rawsh/next-edge-top-level-await

### To Reproduce

Use any value with top level await in an edge function

### Describe the Bug

```
Error: The Edge Function "pages/api/test" must export a `default` function
```

### Expected Behavior

Top level await should work in an edge function

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

_No response_

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

_No response_