sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Late property initialization in a child node is not reflected in parent's `_integrate_forces()` tick
Labels: bug,topic:physics,needs testing

### Tested versions

- Reproducible: v4.3.stable.official [77dcf97d8], v4.4.dev6.official [1f47e4c4e]

### System information

Godot v4.3.stable - macOS 11.7.10 - Vulkan (Forward+) - integrated Intel HD Graphics 5000 - Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz (4 Threads)

### Issue description

A `RigidBody2D` (probably applies also to 3D) has a child `Node` (or any derivative).
If during its `_integrate_forces()` invocation the parent calls a method of the child node, the latter doesn't see any updates to its own properties, if those were changed _after_ the child was added to the scene and the `_integrate_forces()` was called at least once.

If the properties were somehow modified in the parent's `_ready()` before the first invocation of `_integrate_forces()`, everything works as expected.

### Steps to reproduce
In the MRP there's a `body.gd` script, attached to `RigidBody2D`, and `some_component.gd` script, attached to `Node`, child of the body. 

The `_integrate_forces()` passes its direct `state` to the node's `update_parent_state()`, which sets the `linear_velocity` of the parent's state based on two own properties, `move_direction` and `speed`. 

The `move_direction` property is set in parent's `_ready()`, _after_ a one second delay, and thus, after `_integrate_forces()` is called the first time. This triggers the bug - the `move_direction` as seen by the child node during the `update_parent_state()` call is still the default `Vector2(0,0)`.

1) Open the attached MRP
2) Launch `main.tscn` scene
3) Notice that the labels are not in sync: the label updated in child's `update_parent_state()` method during `_integrate_forces()` call shows the default value.
![Image](https://github.com/user-attachments/assets/db3cb214-ab8f-4a98-a4bd-224f19e9d638)

"work-around":
1) Comment the `await ...` line in `body.gd`, which modifies the child's property before `_integrate_forces()` is called for the first time.
2) Launch the `main.tscn` scene
3) Notice that the labels are in sync and the Godot logo is moved by the direct state update in child's `update_parent_state()` method:
![Image](https://github.com/user-attachments/assets/db52f47f-62d8-47ec-8c04-d0f9ceef3e3a)


### Minimal reproduction project (MRP)

[physics-props-out-of-date.zip](https://github.com/user-attachments/files/18043497/physics-props-out-of-date.zip)
Repository: flutter
Issue: Eliminate use of `integration_test_driver_extended.dart`
Labels: a: tests,f: integration_test,P2,team-framework,triaged-framework

`integration_test_driver_extended.dart` was added in order to support a host-side component to `integration_test` tests, specifically screenshot testing for the web. Unlike mobile/desktop apps, the web does not have target-side mechanisms for capturing screenshots of the browser window, and thus a host side mechanism was added.

A goal of `integration_test` is to move all screenshot testing to use underlying target-side APIs to capture screenshots, not just of Flutter content but of any platform content including system chrome, dialogs, etc. and thus screenshotting should happen target side for mobile/desktop apps. We'll want an eventual host-side mechanism for exporting those screenshots, but that should be added to the standard `integration_test_driver.dart` when it's implemented.

`integration_test_driver_extended.dart` is currently used in a [few places](https://github.com/search?q=org%3Aflutter%20%22integration_test_driver_extended.dart%22&type=code):
* [devtools_extentions](https://github.com/flutter/devtools/blob/7488fd09e333e3c523b57d5e8ce5d045f6ebb7f5/packages/devtools_extensions/test_driver/integration_test.dart#L6)
* [devtools_app](https://github.com/flutter/devtools/blob/7488fd09e333e3c523b57d5e8ce5d045f6ebb7f5/packages/devtools_app/test_driver/integration_test.dart#L13), which is using the `onScreenshot` handler.
Repository: PowerToys
Issue: Force Focus on Program/App/Window
Labels: Idea-New PowerToy,Product-Always On Top,Needs-Triage

### FORCED FOCUS

Similar to enabling Always On Top, there could be an option to force Windows to 'focus' on a window of an app or a browser. 

This might be part of the options in Always On Top or its own separate feature.



### Scenario when this would be used?

Specifically, the scenario is caused by a program I am using called Protopie (PP, for short) and its extension Protopie Connect.

PP is a digital prototyping tool for HMI. PP Connect allows you to connect to Arduino or even XBOX hardware. 

Trouble is, in Windows-based machines, universal input monitoring doesn't exist apparently. So, if the PP Connect app window becomes un-focused for some reason, the connection to external hardware is effectively lost, and in-browser prototypes stop responding.

In however it might manifest, this request is a workaround to allow for what the Input Monitoring similar to Macs readily provides.


### Supporting information

https://www.protopie.io/learn/docs/connect/getting-started

https://support.apple.com/guide/mac-help/control-access-to-input-monitoring-on-mac-mchl4cedafb6/mac
Repository: vscode
Issue: Missing or invalid credentials. Error: connect ENOENT /run/user/1000/vscode-git-76f8f1b8ce.sock
Labels: info-needed,git

<!-- ⚠️⚠️ 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. -->
- VS Code Version: 1.95.3
- OS Version: NixOS (`nixos-unstable`)

Steps to Reproduce:

N/A, intermmittent issue

Sometimes happens during git operations that require auth, such as push/pull

Restarting or reloading the window fixes the issue

```
> git push origin master:master
Missing or invalid credentials.
Error: connect ENOENT /run/user/1000/vscode-git-76f8f1b8ce.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1607:16) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'connect',
  address: '/run/user/1000/vscode-git-76f8f1b8ce.sock'
}
Missing or invalid credentials.
Error: connect ENOENT /run/user/1000/vscode-git-76f8f1b8ce.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1607:16) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'connect',
  address: '/run/user/1000/vscode-git-76f8f1b8ce.sock'
}
remote: No anonymous write access.
fatal: Authentication failed for '<redacted>'
```
Repository: godot
Issue: Export Error with .NET 9 on iOS
Labels: bug,platform:ios,topic:dotnet,topic:export

### Tested versions

Reproducible in 4.3.stable.mono

### System information

macOS Sequoia (15.1.1) - Mac Mini (2018)

### Issue description

With `.NET 9` out of RC I tested for any errors and there is an error that prevents exporting specifically for iOS.

```
MSB3030: Could not copy the file "/Users/[username]/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.ios-arm64/9.0.0/runtimes/ios-arm64/native/icudt.dat" because it was not found. /Users/[username]/.nuget/packages/godot.net.sdk/4.3.0/Sdk/iOSNativeAOT.targets(18,5)

```

Checking this directory shows that indeed this file no longer exists and that the entire structure is different now. A quick search shows that `icudt.dat` is not longer bundled in `.NET 9` as outlined [here](https://github.com/xamarin/xamarin-macios/issues/17877#issuecomment-2243000189).



### Steps to reproduce

* Create C# enabled Godot project
* Use `.NET 9`
* Export for iOS

### Minimal reproduction project (MRP)

N/A
Repository: vscode
Issue: Block Extension Access to Sensitive Files in the Project
Labels: feature-request,extensions,file-io

<!-- ⚠️⚠️ 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. -->

related to #52116

Currently, VSCode extensions have access to all files within a project by default. This poses a potential security risk, as projects may include files containing sensitive information, such as .env files.

To enhance security, it would be valuable to allow developers to explicitly mark certain files or patterns as **sensitive** in .vscode/settings.json. Files marked as sensitive would remain invisible to all third-party code, including extensions.

Proposed Feature:
Introduce a files.sensitive setting in the workspace configuration to define sensitive files. Example:

```json
{
  "files.sensitive": {
    "**/.env": true
  }
}
```
This feature would:

- Ensure extensions cannot access or read marked files.
- Improve trust and security when using third-party extensions.
Repository: godot
Issue: Remote debug fails in chrome browser Godot 4.3
Labels: bug,platform:web,needs testing

### Tested versions

Reproducible in 4.3

### System information

Godot v4.3.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 4070 Ti (NVIDIA; 32.0.15.6614) - AMD Ryzen 9 7950X 16-Core Processor (32 Threads)

### Issue description

Remote debug works for Firefox and Edge browsers, but fails for Chrome browser.

The following error is logged in the web debugger:

Uncaught (in promise) TypeError: WebAssembly.instantiate(): Import #0 "a": module is not an object or function
    at tmp_js_export.js:153:17


This has happened for any project I have exported in Godot 4.3.
Couldn't find an issue for it, so wasn't sure if this was known or if others don't have this issue.
Projects work fine in chrome once they are hosted on an external site such as itch.io. It just fails to load in the debugger.

Thanks!


### Steps to reproduce

- Open any Godot project.
- Export to Web.
- Run remote debugger

### Minimal reproduction project (MRP)

[new-game-project.zip](https://github.com/user-attachments/files/18044245/new-game-project.zip)
Repository: next.js
Issue: Subpath imports broken since 15.0.3-canary.7
Labels: bug

### Link to the code that reproduces this issue

https://github.com/fluidsonic/next-import-subpaths-bug

### To Reproduce

1. `cd` into the cloned repo
2. `pnpm i` to install dependencies (it's a pnpm workspace)
3. `cd project-a`
4. `pnpm build`

### Current vs. Expected behavior

Build fails because it can't resolve `import "#internal/internal"` in `Test.tsx`.

```text
% pnpm build

> project-a@0.0.0 build /Users/marc/Documents/next-test/next-import-subpaths-bug/project-a
> next build

   ▲ Next.js 15.0.3-canary.7

   Creating an optimized production build ...
Failed to compile.

../common/src/Test.tsx
Module not found: Can't resolve '#internal/internal'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./src/app/page.tsx


> Build failed because of webpack errors
```

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 22.12.0
  npm: 10.9.0
  Yarn: 1.22.19
  pnpm: 9.15.0
Relevant Packages:
  next: 15.0.3-canary.7 // There is a newer canary version (15.0.4-canary.45) available, please upgrade! 
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.2
Next.js Config:
  output: N/A
 ⚠ There is a newer canary version (15.0.4-canary.45) available, please upgrade! 
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue
```
```


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

Not sure

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

next dev (local), next build (local)

### Additional context

It works in `15.0.3-canary.6` but fails in `15.0.3-canary.7` and later.
Repository: rust
Issue: better explanation when evaluation of constant value failed with overflowing literal
Labels: A-diagnostics,T-compiler

### Code

```Rust
fn main() {
    const _:() = assert!(0 <= 2_147_483_648);
}
```

### Current output

```Shell
error[E0080]: evaluation of constant value failed
 --> src/main.rs:4:18
  |
4 |     const _:() = assert!(0 <= 2_147_483_648);
  |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: 0 <= 2_147_483_648', src/main.rs:4:18
  |
  = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0080`.
```

### Desired output

```Shell
error[E0080]: evaluation of constant value failed
 --> src/main.rs:4:18
  |
4 |     const _:() = assert!(0 <= 2_147_483_648);
  |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: 0 <= 2_147_483_648', src/main.rs:4:18
  |
  = note: the literal `2_147_483_648` does not fit into the type `i32` whose range is `-2147483648..=2147483647`
  = help: consider using the type `u32` instead

For more information about this error, try `rustc --explain E0080`.
```

### Rationale and extra context

See: https://users.rust-lang.org/t/const-assertion-fails-to-infer-correct-type/122166/3

Desired output based on the [message returned in normal (not const) context](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7136d82a7b4a351769c38695ab75a871).

### Other cases

```Rust

```

### Rust Version

```Shell
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1
```

### Anything else?

_No response_
Repository: TypeScript
Issue: Rethink AutoImportProvider automatic limits
Labels: Needs Investigation

There have been a few issues with `"includePackageJsonAutoImports": "auto"` recently.

Today, we scan your project's package.json for dependencies not yet included in your TS program, scanning those dependencies' package.jsons for entrypoints to include as root files for the auxiliary program that collects additional auto-importable files. By default, we limit this to **10 entrypoints** before giving up and not making an auto import provider at all. I think this was intended to be **10 packages**, not 10 entrypoints. At the time the feature was added, most packages only had one detectable entrypoint (`"main"`/`"types"`). Now, it's quite common to see packages with more than 10 `"exports"` subpaths, which effectively guarantees that the feature will be disabled. https://github.com/microsoft/TypeScript/issues/53116#issuecomment-2466507060 shows an example of this.

On the flip side, once we've added our (10 or fewer) root files, there's no limit to how many files they might transitively pull in via imports. AutoImportProvider size was an editor startup time issue for the Teams codebase, not because of package.json inclusion, but because of referenced project inclusion (which has no limiter in place). At any rate, a limiter on root files is not a great solution for preventing costly project load, since a single file could pull in an unbounded number of others.

I'm interested in experimenting to see what would happen if we limit the auto import provider program's module resolution in certain ways, and then relax the limits on adding entrypoints. We could try limiting the depth of module resolution (e.g. root files can pull in other files, but then those files cannot pull in any more). At least, we could prevent explosions of dependencies by not allowing a node_modules package to transitively include any files outside of itself. Experimentation is needed, but off the top of my head, I think this wouldn't remove any available auto-imports except ones generated by `export * from "other-package"`, since we don't (shouldn't) need to know the contents of `other-package` to generate an auto-import for `foo` after seeing `export { foo } from "other-package"`.

I'm less sure what to do about referenced project inclusion, since projects often have `include` globs instead of distinct entrypoints, so it's very possible to add a huge number of root files even without performing any module resolution.
Repository: deno
Issue: Do not require cached packuments to construct npm resolution from the lockfile
Labels: perf

If we store more information in the lockfile it should be possible to not need to reach into the global cache to get information for running a Deno program that already has the tarballs cached.

Right now we load:

- cpu, os
- dependencies
- dist
- optional dependencies
- bin
- scripts
- deprecated

But probably in the case that the tarballs are cached we can avoid reading the packuments entirely and only require reading them for npm resolution or for fetching the tarballs (Ideally we don't store tarball urls in the lockfile because it can lead to someone changing urls in the lockfile to cause security issues).

This would require a new lockfile version.

Also, we should investigate how we optimize for these three scenarios:

1. information required when everything is cached (this issue)
1. information required when doing npm resolution
1. information required when the package itself is not cached (info to download tarballs)

It might mean doing something like downloading the packument and then creating a subset from it (ex. a shortened version of the packument that only has the information we need).

Related:

* https://github.com/denoland/deno/issues/24322
* https://github.com/denoland/deno/pull/27261
Repository: TypeScript
Issue: Design Meeting Notes, 11/19/2024
Labels: Design Notes

*Notes from @RyanCavanaugh*

# Node unflagging `--experimental-strip-types`

https://github.com/nodejs/typescript/issues/17

* Removes types
* Doesn't do downleveling or e.g. `enum` syntax
  * Covered by `--experimental-transform-types`
* Requires no commandline flag
* Node.js docs cover recommended tsconfig settings
* We don't have any flag to cover the "no enum" restriction though
  * We should have this flag 
  * See #59601
  * We should name it
  * Is this just a temporary flag if nodejs et al will support these features anyway?
 * Many people want this for purity reasons (complimentary)
  * Should *imply* verbatimModuleSyntax and isolatedModules but does not *enforce* that
  * TODO: Name this (extremely difficult), implement it (easy, probably)
* Should we support `const x = require('foo')` in TS?
  * Probably (eventually)
* Excited!
Repository: TypeScript
Issue: Design Meeting Notes, 12/3/2024
Labels: Design Notes


## New `--module` Targets for Node.js

https://github.com/Microsoft/TypeScript/issues/60589
https://github.com/Microsoft/TypeScript/issues/60534

* Previously, we were pretty loose about JSON `import`s in `nodenext`.
    * We need to stop allowing named imports from these JSON files.
    * Also, Node.js *requires* you to use import attributes for JSON files.
* In 5.7 we added fixes for cases when we resolve to JSON files.
* We enabled this for `node16` as well, but we error saying that you can only use import attributes in `nodenext`.
* In Node.js 16, you can only use import *assertions* (the old deprecated thing), not import attributes.
    * We will probably make things loose again in `node16` as well - no checks for JSON modules.
* Node.js 16 is already EOL.
* So where does this leave us?
    * Node.js 18 is still in maintenance, but does support import attributes.
    * Node 23 will have `require(ESM)` support.
* Proposal:
    * `--module nodenext` allows `require(ESM)` (for Node.js 23/24, possibly 22)
        * Eventually settle on a specific line.
    * `--module node20` depending on if the above features get back-ported.
    * `--module node18` for import assertions and JSON import checks (what `nodenext` should be in TypeScript 5.7)
    * `--module node16` to be deprecated farther down.
        * It is not the most ideal state (it is EOL, doesn't support JSON imports correctly), but TBD.
* We like this plan, we feel okay to move forward with this for TypeScript 5.8.
Repository: TypeScript
Issue: Design Meeting Notes, 12/6/2024
Labels: Design Notes

# Disallow `override` on non-literal computed names in classes 

https://github.com/microsoft/TypeScript/pull/60691

* For the longest time, computed names in classes with non-literal names were ignored.
* But we let you write `override` on there. But we never enforced it.
* So this change makes it an error to write `overrride`.
* Not controversial.