sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Double-clicking to add a new node, selects in the Script Editor
Labels: bug,topic:input,topic:gui

### Godot version

v4.0.rc1.official [8843d9ad3]
v4.0.beta14.official [28a24639c]

### System information

Windows 10 22H2, Compatibility, Geforce GTX 550 Ti

### Issue description

Double-clicking, to add a new node, selects to the mouse pointer in the `Script Editor`.

### Steps to reproduce

- open the project: [issue, double click new node, selects in script editor.zip](https://github.com/godotengine/godot/files/10499582/issue.double.click.new.node.selects.in.script.editor.zip)
- open the `Script Editor`
- click on the script's first line to place the cursor there
- in the `Scene Panel`, click on the `Add Child Node` button
- double-click on a node, for example: `Node` at the top of the list
a new node was added to the `Scene Panel`

### Expected
Nothing should have changed in the `Script Editor`.

Even if the mouse was moved before the second mouse button was released. (see 3.5.1 and 3.5.2.rc2 below)

### Observed
In v4.0.beta14.official [28a24639c]
The text becomes selected on the second mouse left button down.

But in 3.5.1.stable and 3.5.2.rc2
Nothing is selected on the second mouse left button down.

But holding down the second mouse left button,
and moving the mouse, selects to the mouse position.

### When the issue doesn't occur
There are two cases where this doesn't happen.
1. When the script loads/opens, for example, the first time the `Script Editor` is opened after opening the project,
or when the script is closed and reopened.
2. When a selection is drawn in the `Script Editor`, 
and the cursor is placed by mouse left-clicking at the selection's beginning or end.

In all both cases, a blinking cursor is visible in the `Script Editor`,
but double-clicking, to add a new node, doesn't add a selection to the mouse position.

### Screen Recording
Mouse left-clicking places the cursor on the script's first line.
The `Add Child Node` button is pressed, in the `Scene` panel
`Node` is double-clicked.
A selection appears from the end of the first line to the mouse position (line 8)
The cursor is placed on the last line (12).
The `Add Child Node` button is pressed.
`Node` is double-clicked.
A selection appears from the last line to the middle of line 9.

https://user-images.githubusercontent.com/13420573/214573097-81c7ea29-6354-4930-8ae6-916345a474ca.mp4



### Minimal reproduction project

[issue, double click new node, selects in script editor.zip](https://github.com/godotengine/godot/files/10499582/issue.double.click.new.node.selects.in.script.editor.zip)
Repository: rust
Issue: unconstrained type parameter makes no suggestions as to how to fix
Labels: E-easy,A-diagnostics,T-compiler,D-papercut

### Code

```Rust
trait MyTrait {}

struct S;

impl <U> MyTrait for S {}
```


### Current output

```Shell
error[E0207]: the type parameter `U` is not constrained by the impl trait, self type, or predicates
 --> src/lib.rs:5:7
  |
5 | impl <U> MyTrait for S {}
  |       ^ unconstrained type parameter

For more information about this error, try `rustc --explain E0207`.
error: could not compile `playground` due to previous error
```


### Desired output

```Shell
error[E0207]: the type parameter `U` is not constrained by the impl trait, self type, or predicates
 --> src/lib.rs:5:7
  |
5 | impl <U> MyTrait for S {}
  |       ^ unconstrained type parameter

Either remove the type parameter (<U>) or make use of it, for example ` for S<U>`.

For more information about this error, try `rustc --explain E0207`.
error: could not compile `playground` due to previous error
```


### Rationale and extra context

If we have an unconstrained type parameter, we get an error stating that it is unconstrained, but no suggestions on what to do about it and force the user to google.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3ca555fca7f8220aaab497f87c26225b

Is there room to reduce the learning curve here with better diagnostics?

### Other cases

_No response_

### Anything else?

_No response_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"kei519"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: refactor: Categories to first class Objects
Labels: c: proposal,P3,team-news

**Description**

Currently Categories in the API are enums. This piece of the information architecture is more likely to be defined in a CMS. 

This could be achieved by having a Class Categories that contains a list of Category which are instantiated from data from the CMS. Category can have fields for id name and any other metadata.

Categories could also nominate the list or categories to display as tabs for nav.

The touch points would be:
in API:
* CategoryResponse
* NewsDataSource
* GoogleNewsTemplateClient
* BlockAction
* feed/index.dart
* All related tests

In App:
* CategoriesState and Events
* Feed widget and Bloc
* Navigation
* Notification Preferences
* NewsRepository
* NotificationRepository
* All related tests

There is a fair bit of work but the increased flexibility would improve user adoption.
Repository: rust
Issue: Use `free_aligned_sized()` on UNIX systems if available (C23)
Labels: T-libs,O-unix

See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2699.htm and quoting from there the main rationale

> Several heap allocators[1](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2699.htm#fn1) (hereafter, "allocators") expose as extensions variants of free that accept, in addition to the address of the allocation, an additional argument "reminding" the allocator of the size of that allocation. These extensions can reduce deallocation cost by 30%, allow extra security-hardening functionality, and currently ship in several implementations. We propose standardizing these functions, so that these improvements are available portably.

While not standardized yet and at least not provided by any glibc release yet, once it becomes available this seems like a free potential performance and/or safety improvement when using the default allocator as the extra information required in addition to what `free()` needs is directly available as part of the `Layout` struct.
Repository: go
Issue: x/tools/go/packages: memory hungry in parsing the github.com/go-fonts/latin-modern module packages
Labels: Performance,NeedsInvestigation,Tools

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.20rc3 linux/amd64
</pre>

The version of the `golang.org/x/tools` module is v0.5.0.

### Does this issue reproduce with the latest release?

Yes

### What did you do?

main.go:

```Go
package main

import (
	"log"
	"runtime"
	"runtime/metrics"

	"golang.org/x/tools/go/packages"

	_ "github.com/go-fonts/latin-modern/lmmath"
)

func printUsedMemory(prefix string) {
	runtime.GC()

	samples := []metrics.Sample{
		{Name: "/memory/classes/total:bytes"},
		{Name: "/memory/classes/heap/free:bytes"},
		{Name: "/memory/classes/heap/objects:bytes"},
		{Name: "/gc/heap/goal:bytes"},
	}
	metrics.Read(samples)
	
	log.Println("=========", prefix)
	for _, s := range samples {
		log.Printf("%44s %dMiB", s.Name, s.Value.Uint64()>>20)
	}
}

var allPkgs []*packages.Package

func main() {
	log.SetFlags(0)

	var configForParsing = &packages.Config{
		Mode: packages.NeedName | packages.NeedImports | packages.NeedDeps |
			packages.NeedTypes | packages.NeedExportsFile | packages.NeedFiles |
			packages.NeedCompiledGoFiles | packages.NeedTypesSizes |
			packages.NeedSyntax | packages.NeedTypesInfo,
		Tests: false,
	}

	printUsedMemory("before parsing:")

	pkgs, err := packages.Load(configForParsing, "github.com/go-fonts/latin-modern/...")
	if err != nil {
		log.Println("packages.Load (parse packages): %w", err)
		return
	}

	printUsedMemory("after parsing:")

	allPkgs = pkgs
}
```

go,mod:

```
module a.b/c

go 1.20

require golang.org/x/tools v0.5.0

require github.com/go-fonts/latin-modern v0.2.0

require (
	golang.org/x/mod v0.7.0 // indirect
	golang.org/x/sys v0.4.0 // indirect
)
```

Output:

```
========= before parsing:
                 /memory/classes/total:bytes 11MiB
             /memory/classes/heap/free:bytes 0MiB
          /memory/classes/heap/objects:bytes 0MiB
                         /gc/heap/goal:bytes 4MiB
========= after parsing:
                 /memory/classes/total:bytes 3079MiB
             /memory/classes/heap/free:bytes 1290MiB
          /memory/classes/heap/objects:bytes 1669MiB
                         /gc/heap/goal:bytes 3338MiB
```

### What did you expect to see?

About several hundred of memory consumed.

### What did you see instead?

About 3G memory consumed.

Each of the font source files only contains a `var TTF = []byte{...}` variable.
It is unexpected to use so much memory.

When parsing the packages in the `github.com/tdewolff/canvas` module,
which depends on the `github.com/go-fonts/latin-modern` module,
my computer (8G memory) hangs for virtual memory are swapped in and out frequently.

The `github.com/tdewolff/canvas` module is a relative small module.
My computer is able to parse much larger modules.
Repository: node
Issue: Worker bug: parentPort.postMessage in worker_threads
Labels: worker

### Version

v16.14.0

### Platform

Microsoft Windows NT 10.0.22000.0 x64

### Subsystem

_No response_

### What steps will reproduce the bug?

Worker Thread mixes up large json object passed from **Worker** back to the **parentPort**  (both imported from worker_threads). During the way the object (usually ~1MB large) is accidently changed (some sub-branches)).

**Workaround:** If the object is stringified in the Worker and parsed in the parent, then it works fine.

Problem:
```js
//workerCode.mjs
import {parentPort } from 'worker_threads';
console.log('sending', someJsonObject)
parentPort.postMessage(someJsonObject);

//main.mjs
import { Worker } from 'worker_threads';
const worker = new Worker('./workerCode.mjs', { });
worker.on('message', jsonObject => console.log('receiving', someJsonObject) )
```

**sending** and **receiving** object should be the same, but it is not (for some large objects with nesting subobjects, some branches are randomly replaced by completely different objects.

### How often does it reproduce? Is there a required condition?

Happens only for specific objects, not for any json object. But for the certain object it happens always.

### What is the expected behavior?

It is expected that the sender and receiver does not affect the object that is being sent.

### What do you see instead?

received object is randomly accidentally corrupted (some branches are replaced by unrelated data)

### Additional information

_No response_
Repository: godot
Issue: Cannot Load Custom Resources in Pack (pck) files
Labels: bug,topic:core,confirmed

### Godot version

4.0-stable, 4.0-RC1, 4.0-beta15

### System information

Windows 11 & Windows 10

### Issue description

In the first project `TestExport` I have a custom resource `TestResource` that contains an export for a String and int variables, as well as another script that contains an export for said custom resource that prints out the String and int vars on `_ready`. This runs fine in its own project, which I then export as a pack file called `MyPack.pck`. I then have another project `TestImport` which contains a script to load `MyPack.pck` and loads the scene in `TestExport`, this should print out the contents of `TestResource` but results in the following error when running: `Parser Error: "TestResource" was not found in the current scope.` 

Can we not have custom resources in pack files?

### Steps to reproduce

Getting the Pack File (optional if you want to reexport the pack file):

1. Open the `TestExport` project
2. Go to the top and do Project->Export...
3. In the export dialog, click on the `Windows Desktop` template on the left
4. At the bottom of the dialog, press `Export PCK/ZIP...`
5. Name the pack file `MyPack.pck`
6. Copy the pack file into the other project `TestImport/PackFiles`

Hitting the error

1. Open the `TestImport` project
2. Verify that `MyPack.pck` exists in `TestImport/PackFiles`
3. Run the project (F5)

### Minimal reproduction project

[TestExport.zip](https://github.com/godotengine/godot/files/10500978/TestExport.zip)
[TestImport.zip](https://github.com/godotengine/godot/files/10500980/TestImport.zip)
Repository: angular
Issue: Increased changed detection calls when converting Angular Components to Custom Element using `createCustomElement `
Labels: area: elements

### Which @angular/* package(s) are the source of the bug?

elements

### Is this a regression?

No

### Description

I'm currently investigating the use of Angular Elements and noticed a sharp increase in change detection calls when converting one of our components to an Angular Element.

I was able to replicate the issue in stackblitz, [for example](https://www.google.com/url?sa=D&q=https%3A%2F%2Fstackblitz.com%2Fedit%2Fangular-elements-tutorial-foxk3x%3Ffile%3Dsrc%2Fapp%2Fapp.routing.module.ts).

Notice that when navigating from "home" to "Without custom elements", which renders 50 instances of the <hello> Angular Component, only two change detections are triggered. However, when navigating from "home" to "With custom elements", which renders <hello-element> Angular Elements, a change detection is triggered for every <hello-element> instance (in this case, 50).

This has costly implications for performance as the # of change detections triggered in the parent components increase linearly with the # of child custom elements.

Is this a known issue? Is there a reason why this happens?

### Please provide a link to a minimal reproduction of the bug

https://www.google.com/url?sa=D&q=https%3A%2F%2Fstackblitz.com%2Fedit%2Fangular-elements-tutorial-foxk3x%3Ffile%3Dsrc%2Fapp%2Fapp.routing.module.ts

### Please provide the exception or error you saw

_No response_

### Please provide the environment you discovered this bug in (run `ng version`)

_No response_

### Anything else?

_No response_
Repository: go
Issue: net/http: TestIssue3595 failures with `write: broken pipe`
Labels: NeedsInvestigation

```
#!watchflakes
post <- pkg == "net/http" && test == "TestIssue3595" && `write: broken pipe`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/67c85da09ea7809e03cbf1da9c6a3260d347824f)):

    --- FAIL: TestIssue3595 (2.57s)
        transport_test.go:2051: Post: Post "http://127.0.0.1:50430": write tcp 127.0.0.1:50431->127.0.0.1:50430: write: broken pipe


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: runtime: TestSegv failures with `did not see "SIGSEGV" in output`
Labels: NeedsInvestigation,compiler/runtime

```
#!watchflakes
post <- pkg == "runtime" && test == "TestSegv" && `did not see "SIGSEGV" in output`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/37657143b59bb3d2793bdf896055c7e6f3c879dd)):

    --- FAIL: TestSegv (0.00s)
        --- FAIL: TestSegv/SegvInCgo (0.01s)
            crash_test.go:58: /scratch/gobuilder/buildlet/tmp/go-build3109463291/testprogcgo.exe SegvInCgo (11.518812ms): ok
            crash_cgo_test.go:620: 
            crash_cgo_test.go:626: did not see "SIGSEGV" in output


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: x/build: add NetBSD 10_BETA builders
Labels: OS-NetBSD,Builders,NeedsDecision,new-builder

Context: NetBSD 10 is currently in beta state. There are no official releases yet, though there are daily builds from the branch.

https://go.dev/cl/463123 is the first change that has a different code path on NetBSD 10 than on earlier versions. Perhaps we should have some NetBSD 10 builders, at the very least for amd64.

Creating the image would be a simple change on top of the existing `x/build/env/netbsd_amd64` etc. Maybe we could have a parameter in there that specifies whether to build a -9 or -10 image.

/cc @bcmills @cagedmantis @golang/netbsd
Repository: go
Issue: x/build: move the tree re-opening documentation
Labels: Documentation,Builders,NeedsFix

We should collect all the steps required for the tree re-opening in a single document. The document should be comprehensive and easily followed since these steps only happen every 6 months.

@golang/release
Repository: go
Issue: all: test failures on `netbsd` blocked on waiting for subprocesses
Labels: OS-NetBSD,NeedsInvestigation

```
#!watchflakes
post <- builder ~ `netbsd-.*` && (log ~ `^\s*os\.wait6` || log ~ `^\s*syscall.wait4` || `DETECTED A HANGING GO COMMAND` || `test timed out while running command` || `script_test\.go:\d+: .*: signal: killed`)
```
Repository: TypeScript
Issue: Return types fail to emit for methods of anonymous plain objects
Labels: Suggestion,Needs Proposal

# Bug Report

### 🔎 Search Terms

declaration emit this any

### 🕗 Version & Regression Information

- This is the behavior in every version I tried

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.9.4#code/KYDwDg9gTgLgBAMwK4DsDGMCWEVxsAZxgAoBKOAbwCg44pgYkpdrbb6AbAT0xQHMA8igAqAC0wEylGm3YMmuGOIIBuGbQC+AGhka1GqlQD0RuAWDBcAQxQATOsDQQ+KTAC9g9jhDRWO3OF44YQBlREwOQip8IjIAOk4efiExCTI1IA)

### 💻 Code

```ts
export function test() {
  return {
    relyingOnThis() {
      return this;
    },
  };
}

// seen and recognized locally in TS files
test().relyingOnThis();
```

### 🙁 Actual behavior

```ts
// generated .d.ts
export declare function test(): {
    relyingOnThis(): any;
};
```

### 🙂 Expected behavior

Make `this` type to work in such contexts and emit that:
```ts
declare function test(): {
    relyingOnThis(): this; // currently reports `A 'this' type is available only in a non-static member of a class or interface.(2526)`
};
```

Or emit the content of the anonymous type there somehow (when possible, be cautious with circularities, generics etc):
```ts
declare const _type: {
    relyingOnThis(): typeof _type;
}

declare function test(): typeof _type
```

Or just emit a diagnostic that this isn't portable and that an explicit annotation is needed.
Repository: flutter
Issue: [in_app_purchase] Switch to standard federated plugin autoregistration
Labels: team,p: in_app_purchase,package,team-ecosystem,P2,triaged-ecosystem

Currently IAP is using the legacy model of the app-facing package doing platform switching and manually registering platform implementations. We should replace `registerPlatform()` with automatic Dart registration using `registerWith()`.

I haven't looked at it in depth, but I think we should be able to do it by making `registerPlatform()` a no-op while adding `registerWith()`, and then updating the app-facing package to require at least those versions and removing `registerPlatform()`. The one wrinkle is that there's non-registration-related initialization code in `registerPlatform()`; we may need to make a new platform interface method where we can trigger that, instead of running it in `registerWith()` which is almost certainly going to run earlier.
Repository: pytorch
Issue: Test Failure: TestUpgraders.test_aten_div_scalar_at_3 on a big-endian machine (issue in torch.jit.load())
Labels: oncall: jit

### 🐛 Describe the bug

When I execute the following test case on a big-endian machine, I got the test failure due to the runtime error. We expect that this test should also pass on a big-endian machine.

```python
$ python test/test_jit.py TestUpgraders.test_aten_div_scalar_at_3
CUDA not available, skipping tests
monkeytype is not installed. Skipping tests for Profile-Directed Typing
E
======================================================================
ERROR: test_aten_div_scalar_at_3 (jit.test_upgraders.TestUpgraders)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ishizaki/PyTorch/master/test/jit/test_upgraders.py", line 246, in test_aten_div_scalar_at_3
    loaded_model = torch.jit.load(model_path)
  File "/home/ishizaki/PyTorch/master/torch/jit/_serialization.py", line 162, in load
    cpp_module = torch._C.import_ir_module(cu, str(f), map_location, _extra_files)
RuntimeError: Unexpected end of pickler archive.
```

The minimum program to reproduce this issue is here. So, `torch.jit.load()` does not seem to work correctly on a big-endian platform.   

```python
import torch
loaded_model = torch.jit.load("test/jit/fixtures/test_versioned_div_scalar_float_v3.pt")
```

I believe that `torch.jit.load()` reads the multiple-byte data without swapping on a big-endian machine while pickle serialization store data as mostly little-endian (as shown in #92910).

### Versions

```
PyTorch version: 2.0.0a0+git215f4fc
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (s390x)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] (64-bit runtime)
Python platform: Linux-5.4.0-125-generic-s390x-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: False

Versions of relevant libraries:
[pip3] numpy==1.24.1
[pip3] torch==2.0.0a0+git17c570c
[conda] Could not collect
```

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Repository: pytorch
Issue: Feature request: access to variable
Labels: module: nn,triaged

### 🚀 The feature, motivation and pitch

In `torch.nn.functional.multi_head_attention_forward`, there is a variable, `use_separate_proj_weight` that can not be controled by the users of Transformers. I would have liked to use NON-shared weights.

In `torch.nn.modules.transformers.TransformerEncoderLayer.self_attn`, during the forward, use_separate_proj_weight is set to False only in the case where the dimensions for Q, K, V are not the same.  This is verified during initialisation of self_attn. But user can't control this if dimensions are the same.
(same with the decoder)

Could you add an option to control if weights are shared? Thank you very much!

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @bhosmer @cpuhrsch @erichan1 @drisspg
Repository: vscode
Issue: WordWrap quick toggle button
Labels: feature-request,editor-wrapping

<!-- ⚠️⚠️ 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. -->
Please feature a button which can toggle word wrap in just one click.
Doing it from the settings is tiresome and using other extensions is not a good work out.
Repository: Python
Issue: Concatenate/consolidate all algorithms with different implementations
Labels: enhancement,help wanted,good first issue

### Feature description

There are lots of algorithms with the same concept but different implementations/methods in different files. All these should be moved into one file