sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Some valid IPv4 addresses are not parsed by Ipv4Addr::from_str()
Labels: T-libs-api,C-bug,A-io

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

An IPv4 address is usually represented by four decimal numbers separated by a dot, but this isn’t the only allowed representation. Most programs support alternative representations with fewer dots where the last number is either 16-bit, 24-bit, or 32-bit, see [the manpage of `inet_aton()`](https://linux.die.net/man/3/inet_aton). In order to be compatible with these programs and users’ assumptions, `std::net::Ipv4Addr` should add support for these formats.

I tried this code:

```rust
use std::net::Ipv4Addr;
fn main() {
    let localhost: Ipv4Addr = "127.1".parse().unwrap();
    assert_eq!(format!("{}", localhost), "127.0.0.1");
}
```

I expected to see this happen: nothing, as the parsing would succeed and then the assert would pass.

Instead, this happened: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: AddrParseError(())', src/main.rs:3:47

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.58.0-nightly (547a6ffee 2021-10-21)
binary: rustc
commit-hash: 547a6ffee0cf4da9929a9e3d49546dc87d607735
commit-date: 2021-10-21
host: x86_64-unknown-linux-gnu
release: 1.58.0-nightly
LLVM version: 13.0.0
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: AddrParseError(())', src/main.rs:4:45
stack backtrace:
   0: rust_begin_unwind
             at /rustc/514b3877956dc594823106b66c164f8cdbc8b3da/library/std/src/panicking.rs:495:5
   1: core::panicking::panic_fmt
             at /rustc/514b3877956dc594823106b66c164f8cdbc8b3da/library/core/src/panicking.rs:107:14
   2: core::result::unwrap_failed
             at /rustc/514b3877956dc594823106b66c164f8cdbc8b3da/library/core/src/result.rs:1617:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/514b3877956dc594823106b66c164f8cdbc8b3da/library/core/src/result.rs:1299:23
   4: playground::main
             at ./src/main.rs:4:29
   5: core::ops::function::FnOnce::call_once
             at /rustc/514b3877956dc594823106b66c164f8cdbc8b3da/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```

</p>
</details>
Repository: pytorch
Issue: `torch.jit.is_scripting()` not set when scripting a Module
Labels: oncall: jit

## 🐛 Bug

The function `torch.jit.is_scripting()` returns constant False when accessed in a property implemented in a Module.

## To Reproduce

```py
class Model(torch.nn.Module):
    @property
    def hello(self):
        if not torch.jit.is_scripting():  # does not work
            warnings.warn("this property is deprecated")
            
        # prints False
        print(torch.jit.is_scripting())
        return "hello"

    def forward(self, x):
        if torch.jit.is_scripting():  # works
            return x + 1
        return x

jitted_model = torch.jit.script(Model())
print(jitted_model(torch.tensor(2)))  # output: 3

def function(x):
    if torch.jit.is_scripting(): # works
        return x + 1
    return x

jitted_function = torch.jit.script(function)
print(jitted_function(torch.tensor(2)))  # output: 3

```
This shows a warning despite 
1. the property hello is never used in the code
2. the guarding with `if not torch.jit.is_scripting()` is not working

## Expected behavior

The code above should not produce any warning from the hello property, because it is never used.

There should be a way to detect if scripting is turned on. The function `torch.jit.is_scripting()` should return True even outside the forward() function when scripting a Module.


## Environment

```
PyTorch version: 1.10.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 10.15.7 (x86_64)
GCC version: Could not collect
Clang version: 12.0.0 (clang-1200.0.32.29)
CMake version: version 3.20.1
Libc version: N/A

Python version: 3.8.11 (default, Aug  6 2021, 08:56:27)  [Clang 10.0.0 ] (64-bit runtime)
Python platform: macOS-10.15.7-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
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

Versions of relevant libraries:

[pip3] torch==1.10.0
[pip3] torchaudio==0.10.0
[pip3] torchmetrics==0.5.0
[pip3] torchvision==0.11.1
```

## Additional context

<!-- Add any other context about the problem here. -->
Repository: rust
Issue: Tracking Issue for `{array, slice}::{from_ref, from_mut}` as const fn
Labels: T-libs-api,C-tracking-issue,disposition-merge,finished-final-comment-period,A-array

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gates: `#![feature(const_array_from_ref)]` and `#![feature(const_slice_from_ref)]`

This is a tracking issue for `{array, slice}::{from_ref, from_mut}` functions marked as const fn

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

This feature makes the following APIs `const`:

```rust
// core::array
pub const fn from_mut<T>(s: &mut T) -> &mut [T; 1];

// core::slice
pub const fn from_mut<T>(s: &mut T) -> &mut [T];
```

These functions as `const` were previously tracked here, but are now stabilized:
```rust
// core::array
pub const fn from_ref<T>(s: &T) -> &[T; 1];

// core::slice
pub const fn from_ref<T>(s: &T) -> &[T];
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #90162
- [x] Stabilization of `_ref` functions: #97366
- [x] Final comment period (FCP)
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.
Repository: node
Issue: Strange CPU architecture handling/checking at build time
Labels: build

While attempting to track down the possible values for `target_arch`/`process.arch` I noticed that there is some strange stuff going on with regard to node's CPU architecture references at build time. Specifically:

* tools/v8_gypfiles/v8.gyp references `"mips64"` for `(v8_)target_arch`, which is not a value permitted/used by configure.py anywhere.

* tools/v8_gypfiles/v8.gyp appears to be missing support for `"x32"` (although tools/v8_gypfiles/toolchain.gypi seems to check for it), which is allowed by configure.py. At the very least the sources for the relevant builtins-*.cc file are missing for this platform.

* [tools/v8_gypfiles/v8.gyp does the same check twice in the same conditional](https://github.com/nodejs/node/blob/1fd984581ce469d64f514ee66519d1cb77e4212e/tools/v8_gypfiles/v8.gyp#L310). Not sure if the second check should be removed or if one of the values was supposed to be something like `"riscv32"`.
  * If it's supposed to be `"riscv32"`, then we should probably add this to configure.py and elsewhere.

* configure.py can return `"riscv32"` from `host_arch_cc()` (whose return value gets set to `target_arch` when not cross compiling). This arch is not listed as a valid arch in configure.py (and further leads me to believe that one of the checks in the previous point should've been `"riscv32"`).

* `host_arch_cc()` in configure.py also seems to return `'ppc64'` when checking for the `__PPC__` define, which AFAICT is 32-bit and thus should be `'ppc'` instead.

* `host_arch_cc()` is missing support for checking for x32 ABI, which AFAICT should be doable by checking both `__ILP32__` and `__x86_64__`.

* [process.arch](https://nodejs.org/docs/v17.0.1/api/process.html#processarch) docs seem to be outdated. Depending on if/how any of the above issues get resolved, at least the following values appear to be **missing**:

  * `'mips64'`
  * `'mips64el'`
  * `'riscv64'`

  Also the following `process.arch` values should be **removed** from the documented list because they don't show up anywhere in the build system(?):

  * `'s390'`
Repository: PowerToys
Issue: ColorPickerUI appears to reference CoreSDK 3.1.20 instead of Shared Framework (runtime)
Labels: Issue-Bug,Area-Setup/Install

### Microsoft PowerToys version

0.47.1

### Running as admin

- [X] Yes

### Area(s) with issue?

ColorPicker

### Steps to reproduce

I uninstalled the CoreSDK 3.1.20 and was warned that ColorPickerUI referenced it. I also have the shared framework installed.

### ✔️ Expected Behavior

References to SharedFramework

### ❌ Actual Behavior

SDK uninstall required closing colorpickerui to continue

### Other Software

CoreSDK 3.1.20
Repository: vscode
Issue: Incorrect color codes / rendering from the color picker
Labels: under-discussion,editor-color-picker

Issue Type: <b>Bug</b>

Enter a color or pick a color. Use the system color picker or any other color picker to sample the color and the codes and colors are different.

<img width="644" alt="Screen Shot 2021-10-23 at 11 18 12 AM" src="https://user-images.githubusercontent.com/82769344/138567645-ddf8fead-8254-45ed-a06d-60689fb35514.png">


VS Code version: Code 1.61.2
OS version: Darwin x64 20.6.0
Restricted Mode: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>metal: disabled_off<br>multiple_raster_threads: enabled_on<br>oop_rasterization: enabled<br>opengl: enabled_on<br>rasterization: enabled<br>skia_renderer: disabled_off_ok<br>video_decode: enabled<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|2, 2, 2|
|Screen Reader|no|
|VM|0%|
</details>
<!-- generated by issue reporter -->
Repository: PowerToys
Issue: Pristine installation (or equivalent) that  does not preserve current settings.
Labels: Idea-Enhancement,Area-Setup/Install,Needs-Triage

### Description of the new feature / enhancement

Some mechanism that would allow a pristine installation.  Any of a number of approaches could work as long as there was a clear distinction between preserving prior settings versus resetting to install defaults.  For example, it could be an option on install, or a special option in Settings, or a simple, clearly documented, extra manual step.  Whatever the approach, it should be easy to find in the documentation.  This should not prevent the preservation of current settings during an update or reinstall.

An ideal approach might also include listing the settings that are different (showing current v. default) -- or even an optional advanced step of accepting or removing each one from a list.  The actual comparison might be better done as a report in Settings, so it could be referred to at any time, not just install.  That report could also be repurposed and produced during the installation, if requested.  (If there is already a simple way to do a pristine install, this paragraph would be a seperate enhancement.)

### Scenario when this would be used?

In this particular case, I wanted a pristine installation of the current version to use to reproduce and document a bug/feature request (e.g., see Repair bug(?) in supporting info; or try setting the same shortcut for multiple PowerToys utilities).  I also wanted to check the current shortcut defaults.

### Supporting information

I tried to uninstall and install, but that preserved the settings (generally a good thing).  I could not find anything in the documentation wiki nor by searching Issues (although I suspect I overlooked an issue as I also did not find anything on preserving settings during install).  

I also tried the Repair option, but that failed to find the bootstrap msi (an issue to be researched and documented another day).
Repository: node
Issue: `imports` allows and ignores `#name/` in package map
Labels: esm

### Version

v17.0.1

### Platform

Darwin Evans-MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

### Subsystem

_No response_

### What steps will reproduce the bug?

Here's a simple example:

```
$ cat test.mjs
import * as x from '#x'
console.log(x)

$ cat package.json
{
  "imports": {
    "#x": "#what/foo/y.mjs"
  }
}

$ cat node_modules/foo/y.mjs
export let y = true

$ node test.mjs
[Module: null prototype] { y: true }
```

Notice the bogus `#what/` prefix that is being discarded by node.


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

Always

### What is the expected behavior?

I expected path resolution to fail, at least according to the documented algorithm here: https://nodejs.org/api/esm.html#resolution-algorithm. From what I understand, it's supposed to go something like this:

1. `ESM_RESOLVE("#x", "file://.")`
2. `PACKAGE_IMPORTS_RESOLVE("#x", "file://.", ["default"])`
3. `PACKAGE_IMPORTS_EXPORTS_RESOLVE("#x", { "#x": "#what/foo/y.mjs" }, "file://.", true, ["default"])`
4. `PACKAGE_TARGET_RESOLVE("file://.", "#what/foo/y.mjs", "", false, true, ["default"])`
5. `PACKAGE_RESOLVE("#what/foo/y.mjs", "file://./")`

At this point `packageName` should be `"#what"` and `packageSubpath` should be `./foo/y.mjs`. That should then fail because there is no file called `node_modules/#what/foo/y.mjs` on the file system.


### What do you see instead?

Somehow the `#what/` prefix seems to be getting lost in the process which lets the remapping to `#what/foo/y.mjs` succeed. Specifically `#what/foo/y.mjs` behaves just like `foo/y.mjs`. If I'm reading the algorithm correctly, then I think node's implementation is diverging from the specification somewhere and is incorrect.


### Additional information

This looks like a bug in node to me. But if it's not, it would be great to update the documentation so that other implementations of node's algorithm can be implemented correctly. I'm trying to get the module resolution algorithm in [esbuild](https://esbuild.github.io/) to match node and I'm not sure what to do here.
Repository: godot
Issue: After enabling BVH in 2d physics, set monitorable to true for more than 4000 area through the Physic2DServer will cause an instantaneous permanent huge drop in performance
Labels: bug,confirmed,topic:physics,performance

### Godot version

3.4.rc(62f56af694)

### System information

Windows 11, RTX 2060, GLES2/GLES3

### Issue description

After enabling BVH in 2d physics, set monitorable to true for more than 4000 area through the Physic2DServer will cause an instantaneous and permanent huge drop in performance.

### Steps to reproduce

Enable Bvh in 2D physics settings, and then use Physic2DServer to create some areas (more than 4000). Then gradually set monitorable to true for these areas. When the number of active areas reaches 4000 or more, the original 144fps will instantly drop below 15fps, and will drop below 5fps within 3 seconds.

After disabling BVH, the FPS does not start to decrease from 144 until there are 7000 active areas, and until 12000 active areas the FPS are still able to remain above 60.

### Minimal reproduction project

I am using a C++ custom module to control the behavior of the area through Physics2DServer, so it may not be possible to provide a minimal project.

But I can guarantee that there is nothing in my module that will affect the physical behavior of Godot, because it simply calls Physic2DServer-related functions. And after many comparative tests, it is confirmed that this problem is caused by BVH

https://user-images.githubusercontent.com/44023235/138574787-dc642e09-616f-4dcc-b443-e22e227bc840.mp4

(In the video, due to screen recording, the base fps dropped to 90-100, but this problem is still very obvious)
Repository: vscode
Issue: Combine workspace trust with enablePromptUseWorkspaceTsdk
Labels: feature-request,typescript

<!-- ⚠️⚠️ 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: 
https://github.com/microsoft/vscode/issues/65546#issuecomment-617937038
https://github.com/microsoft/vscode/issues/65546
https://github.com/microsoft/vscode/issues/30069#issuecomment-312732928

Now that we have workspace trust feature in VSCode. The separate prompt of `enablePromptUseWorkspaceTsdk` felt somewhat redundant. Can we automatically honor `typescript.tsdk` in workspace setting when user already trust the workspace?

This doesn't regress on security and makes distributing `typescript.tsdk` among our large developer user base much easier.

Actually I would prefer if it can be enforced because we have 500 developers and "my enlistment doesn't work" - "oh wrong TS was selected" came up several times every month. And people usually tolerance the issue for quite some time before they reach out for help, slowing down their daily development work in the meantime.

@mjbvz
Repository: create-react-app
Issue: [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tokenize'  error
Labels: needs triage

after yarn create-react-app and yarn start, the below error message was displayed. how solve it?
my node version is v17.0.1

```
> docker_react_app@0.1.0 start
> react-scripts start

node:internal/modules/cjs/loader:488
      throw e;
      ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tokenize' is not defined by "exports" in /Users/satoutaishin/Desktop/practice/docker_react_app/node_modules/postcss-safe-parser/node_modules/postcss/package.json
    at new NodeError (node:internal/errors:371:5)
    at throwExportsNotFound (node:internal/modules/esm/resolve:416:9)
    at packageExportsResolve (node:internal/modules/esm/resolve:669:3)
    at resolveExports (node:internal/modules/cjs/loader:482:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/satoutaishin/Desktop/practice/docker_react_app/node_modules/postcss-safe-parser/lib/safe-parser.js:1:17) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Node.js v17.0.1
Repository: pytorch
Issue: Build not working with cuda 11.5
Labels: module: cuda,triaged

## 🐛 Bug

Build fail with cuda 11.5

## To Reproduce

Steps to reproduce the behavior:

1. Install cuda 11.5
2. Build will crash due to changes in cub.
3. I spent few hours trying to figure out if it was a config issue or a problem with cub itself. In the end, I uninstalled cuda 11.5 and reverted to cuda 11.4.2 and master builds fine.

## Expected behavior

Master and release 1.10.0 build complete without error.

## Environment



 - PyTorch Version (e.g., 1.0): master branch or tag/v1.10.0
 - OS (e.g., Linux): Ubuntu 20.04
 - How you installed PyTorch (`conda`, `pip`, source): Conda as described in documentation + cudatoolkit 11.5, magma-cuda113
 - Build command you used (if compiling from source): python setup.py develop
 - Python version: 3.9.7
 - CUDA/cuDNN version: cuda toolkit 11.5, Vienna 8.2
 - GPU models and configuration: rtx 2080 ti, rtx 3090
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->


cc @ngimel
Repository: godot
Issue: Multithreading in ImportPlugins basically impossible
Labels: bug,topic:editor,documentation,topic:import,topic:3d

### Godot version

3.3.3, 3.3.4

### System information

Windows 10, Ubuntu 20.4 LTS

### Issue description

I have written am Import plugin that I am using to import larger scenes into Godot. However I am facing some issues trying to optimize the plugin. Especially trying to use multiple threads during the import.

Since there are 4 independent steps during the import process, creating different parts of the scene, the logical Idea to speed up the import process was to use multiple threads to parallelize the workload. The problem is that at least
`SurfaceTool::commit`, `ArrayMesh::_new` and `ResourceLoader::load` all deadlock when the editor thread is blocked by the import plugin. Note that when launching the whole import process in a separate thread and directly returning from the `import` method in the Plugin the deadlock does not occur however the import itself also does not work correctly in that case.

### Steps to reproduce

1. Write an import plugin.
2. Create a separate thread.
3. Call `SurfaceTool::commit`, `ArrayMesh::_new` or `ResourceLoader::load` in the new thread while the import thread is still locked in your import method.
4. Deadlock

### Minimal reproduction project

_No response_
Repository: rust
Issue: Non-deterministic overflow in rustc-rayon-core causing CI failures
Labels: T-compiler,A-parallel-queries,WG-compiler-parallel

It seems that enabling overflow checks (#89776) uncovered non-deterministic overflows in rustc-rayon-core causing the build failures of #90042 and #90222:
* https://github.com/rust-lang-ci/rust/runs/3987259810?check_suite_focus=true#step:25:26550
* https://github.com/rust-lang-ci/rust/runs/3987471878?check_suite_focus=true#step:25:21315

Overflow location:
https://github.com/rust-lang/rustc-rayon/blob/c8ec88d8a2236d1fe19d65a4ab38834f76d256b7/rayon-core/src/sleep/mod.rs#L330

This code is not in upstream rayon but just in our fork, introduced here:
https://github.com/rust-lang/rustc-rayon/commit/27911f7176419b0fa8ca8cc666d44b212077302e#diff-cde9d726ca2f32c319420be6c61d2e57ad9daff7f85a5f8f7be25474a15f9c4dR328
Repository: create-react-app
Issue: I am getting this error when I run create react app on the terminal 
Labels: stale

![npm](https://user-images.githubusercontent.com/76728318/138586402-b6668e69-81f8-4811-8f44-09d58e1c2c9b.png)