sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: database/sql: the Null* types naively/prematurely set .Valid=true before converting and scanning data
Labels: NeedsFix

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?
Go tip f53c2fac46e2e193493045eef08591ded1496b74


### Does this issue reproduce with the latest release?
Yes!


### What operating system and processor architecture are you using (`go env`)?
N/A

### What did you do?
https://play.golang.org/p/WPwq58LV2ym or inlined below:

```go
package main

import (
	"database/sql"
)

func main() {
	f32 := &sql.NullInt32{}
	err := f32.Scan([]byte("p10004"))
	if f32.Valid && err != nil {
		panic("inconsistency, .Valid yet err != nil")
	}
}
```

### What did you expect to see?
No panic


### What did you see instead?
```shell
panic: inconsistency, .Valid yet err != nil

goroutine 1 [running]:
main.main()
	/tmp/sandbox708621220/prog.go:11 +0xd6
```

I noticed these just now while reviewing @a8m's [CL for NullByte and NullInt64](https://go-review.googlesource.com/c/go/+/311572) with the pattern that the already existing code naively/prematurely sets .Valid=true before converting and assigning values per
* NullString https://github.com/golang/go/blob/f53c2fac46e2e193493045eef08591ded1496b74/src/database/sql/sql.go#L199-L200
* NullInt64 https://github.com/golang/go/blob/f53c2fac46e2e193493045eef08591ded1496b74/src/database/sql/sql.go#L225-L226
* NullInt32 https://github.com/golang/go/blob/f53c2fac46e2e193493045eef08591ded1496b74/src/database/sql/sql.go#L251-L252
* NullFloat64 https://github.com/golang/go/blob/f53c2fac46e2e193493045eef08591ded1496b74/src/database/sql/sql.go#L277-L278
* NullBool https://github.com/golang/go/blob/f53c2fac46e2e193493045eef08591ded1496b74/src/database/sql/sql.go#L303-L304
* NullTime https://github.com/golang/go/blob/f53c2fac46e2e193493045eef08591ded1496b74/src/database/sql/sql.go#L329-L330

The argument that folks should be checking the error always doesn't correctly stand because `Null*.Scan(value) error` is a method on an already created Null* type's instance, and that Null could be reused and accidentally cause inconsistencies.

That code can all be fixed to the following pattern
```go
        err := convertAssign(&n.Time, value)
        n.Valid = err == nil
        return err
```
Repository: rust
Issue: Document environment variables used by programs rustc invokes underneath (linkers, etc)
Labels: C-enhancement

This is related to issue #16330: `rustc` invokes other programs underneath (most notably, a linker) which recognize environment variables of their own. A prominent example would be the `LIB` variable that is recognized by Microsoft `link.exe` (and `lld-link`) which is what, as I understand, is used by `rustc` on Windows.

Having an accurate list of environment variables that can affect the result of compilation is important to build systems that track changes to the environment.
Repository: pytorch
Issue: Python static variable access for TorchScript's custom C++ classes
Labels: oncall: jit

## 🚀 Feature

My configuration system relies on static class variables in Python and C++ (e.g. for a threshold for non-max suppression or a boolean feature guard for an ablation study). I'd like to configure my custom C++ classes from Python. Ideally, we would have the function that is called `def_readwrite_static` in pybind (see the "See also" box [in the pybind docs](https://pybind11.readthedocs.io/en/stable/classes.html#instance-and-static-fields)).

I assume it is a small extra function that would be added here:
https://github.com/pytorch/pytorch/blob/ff537b77ff2a8c05cf56da33d2f36c41f5ac8df8/torch/custom_class.h#L274

For completeness, it would be nice to have the full set of functions `class_::def_readwrite_static()`, `class_::def_readonly_static()`, `class_::def_property_static()` and `class_::def_property_readonly_static()`.

## Alternatives

Explicit getters and setters that are exposed with `def_static`.

## Additional context

I came across this issue while working on the TorchScript extension of [OpenPifPaf](https://github.com/openpifpaf/openpifpaf).


cc @gmagogsfm
Repository: vscode
Issue: [remote][connection] Allow offline editing in Remote-WSL
Labels: bug,WSL,remote

<!-- ⚠️⚠️ 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. -->
After successfully opening a VSCode editor in Remote-WSL mode and then some time after, I lose network connectivity, I want the editor to remain usable.  The current behavior brings up the `Disconnected. Attempting to reconnect`  modal. After dismissing the modal, the modal returns almost immediately, making it impossible to continue editing. I want to be able to continue editing the file until network connectivity is restored. Only VSCode features [dependent on the network](https://code.visualstudio.com/docs/setup/network#_common-hostnames)  should be disabled
Repository: opencv
Issue: MAX_ARRS=20 in ocl modules is not enough
Labels: category: core,category: ocl

I'm trying to add more than 16 UMat through method cv::ocl::Kernel::set(). However, I found that a constant variable MAR_ARRS(in opencv-4.1.2/modules/core/src/ocl.cpp:2862) was set to 16.
The code is:
```
enum { MAX_ARRS = 16 };
UMatData* u[MAX_ARRS];
```
I checked the source code and I didn't find any methods that could modify this variable. To be honest, 16 is too small.
Repository: flutter
Issue: Support mouse interaction in tests utils
Labels: a: tests,c: new feature,framework,c: proposal,a: desktop,a: mouse,P3,team-framework,triaged-framework

## Use case
As flutter's desktop app developer
I want to be able to mimic mouse interactions
So that I'm able to confidently test my application

## Proposal

Support mouse interaction in tests utils.

Some public test utils do not expose the possibility of defining the PointerDeviceKind, eg.

- [drag](https://github.com/flutter/flutter/blob/12a2e682b47e16818cc7cd9ca5fe8ea09fd38992/packages/flutter_test/lib/src/controller.dart#L525) / [dragFrom](https://github.com/flutter/flutter/blob/12a2e682b47e16818cc7cd9ca5fe8ea09fd38992/packages/flutter_test/lib/src/controller.dart#L555)
- [timedDrag](https://github.com/flutter/flutter/blob/12a2e682b47e16818cc7cd9ca5fe8ea09fd38992/packages/flutter_test/lib/src/controller.dart#L654) / [timedDragFrom](https://github.com/flutter/flutter/blob/12a2e682b47e16818cc7cd9ca5fe8ea09fd38992/packages/flutter_test/lib/src/controller.dart#L681)
- [fling](https://github.com/flutter/flutter/blob/12a2e682b47e16818cc7cd9ca5fe8ea09fd38992/packages/flutter_test/lib/src/controller.dart#L365) / [flingFrom](https://github.com/flutter/flutter/blob/12a2e682b47e16818cc7cd9ca5fe8ea09fd38992/packages/flutter_test/lib/src/controller.dart#L395)

We're missing a way to use mimic mouse wheel scroll, and the only scroll related method assumes that the device uses drag to scroll (see [scrollUntilVisible](https://github.com/flutter/flutter/blob/12a2e682b47e16818cc7cd9ca5fe8ea09fd38992/packages/flutter_test/lib/src/controller.dart#L1129)).
Repository: vscode
Issue: "Reopen folder using..." should use a more dedicated ux solution, not notifications
Labels: ux,under-discussion,remote

Refs: https://github.com/microsoft/vscode/issues/119463

Currently we have mulitple experience to reopen the folder because there is a `Dev Container` file or a `.code-workspace` file. Both of them use notifications in order to make the user aware of this.

Instead of this I propose the following:
* Do not use notificaitons for this (especially painful since they appear on startup)
* We should consider showing this in the empty editor area instead of action hints. Button "Reopen in Container" 
* Consider having this in the welcome view
* We should have something in the explorer. Either a Ttitle area button, or a blue button in the empty area

fyi @misolori @bpasero for ideas

![Screenshot 2021-04-21 at 12 21 42](https://user-images.githubusercontent.com/1926584/115538538-46b81880-a29c-11eb-9868-793a4c8c63c6.png)
Repository: TypeScript
Issue: Support automatically updating URL import references when using `new URL(<file>, import.meta.url)`
Labels: Suggestion,Help Wanted,Experience Enhancement

# Bug Report

### 🔎 Search Terms

`import.meta.url`

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about 4.3.0

### ⏯ Playground Link

[Workbench repo](https://www.typescriptlang.org/dev/bug-workbench/?#code/PTAEAEBMFMGMBsCGAnRAXAlgewHYCgQIAzDeaHRAW2gC5Qit4ZlgSyBGAOjQGc9ZcPRtE7wsAcwAUAcjbR20gJQBuPHmgAPAA5ZkaUAJw99DLKAC8oACwAmVQTBQ4SVJlwPipclVqhIGIiJoZHI0AFoGJmDWLxtuPhxoAHdQAFUAJQAZGU5OVkZmGI5OACseaQAaUAxKHT1OajRETgBXZHgVPBq6tBy8yMK5LjKle00eg0F9ACMUC1AAVlUgA)

### 💻 Code

Given the following files:

`folder/file1.ts`
```ts
console.log('file1');

export const foo = 42;
```

`different-folder/file2.ts`
```ts
new URL('../folder/file1.js', import.meta.url);
import('../folder/file1.js');

export const bar = 5;
```

1. Create a new directory `sub-folder/` in root
2. Move `different-folder/` into `sub-folder/` so that the layout becomes `sub-folder/different-folder/file2.ts`
3. When prompted for "Update imports for 'different-folder'?" click "Yes"

### 🙁 Actual behavior

`sub-folder/different-folder/file2.ts`
```ts
new URL('../folder/file1.js', import.meta.url);
import('../../folder/file1.js');

export const bar = 5;
```

The same is true if `folder/file1.js` is moved to a different location.

### 🙂 Expected behavior

Similar to the dynamic import, a file reference based on `import.meta.url` that points to a different TypeScript file should correctly be renamed accordingly.

`sub-folder/different-folder/file2.ts`
```ts
new URL('../../folder/file1.js', import.meta.url);
import('../../folder/file1.js');

export const bar = 5;
```

VS Code supports the standard dynamic import to handle file renaming. Since `import.meta.url` and `URL` are a standard way of resolving files, I would expect VS Code to natively support it as well. For example, Parcel compatibility is implemented in https://github.com/parcel-bundler/parcel/issues/5473, is implemented in Webpack 5 https://github.com/webpack/webpack/pull/11075 and is scheduled for implementation in ESBuild https://github.com/evanw/esbuild/issues/312#issuecomment-800730525

This issue was originally filed at https://github.com/microsoft/vscode/issues/121391
Repository: storybook
Issue: Expose `extractArgTypes` helpers 
Labels: feature request,args

**Is your feature request related to a problem? Please describe**

It is not possible to change arg types for a specific story easily. The arg types are generated based on the default exported story file configuration (the `component` entry). In some cases, it is needed to actually display `argTypes` for a different component in the controls. Because `extractArgTypes` is not exposed officially, it has to be done manually and any manual work is quickly desynchronizing with the source code. The example use case:

```tsx
import React from 'react';
import { Story } from '@storybook/react';
import { MetadataForm } from ;

// @ts-expect-error
import { extractArgTypes } from '@storybook/addon-docs/dist/esm/frameworks/react/extractArgTypes';

type MetadataParams = {
  config: any
};

type MetadataFormProps = React.ComponentProps<typeof MetadataForm>;

export function applyMetadataFormStoryConfig<T>(
    story: Story<T>,
    metadata?: MetadataParams
): Story<T> {
    const metadataFormArgTypes = extractArgTypes(MetadataForm);

    // eslint-disable-next-line no-param-reassign
    story.parameters = {
        ...story.parameters,
        controls: {
            // Disable all current story controls
            // And show MetadataForm controls only
            include: Object.keys(metadataFormArgTypes),
        },
        metadata,
    };

    // Inject MetadataForm args to enable controls for MetadataForm
    // eslint-disable-next-line no-param-reassign
    story.argTypes = {
        ...story.argTypes,
        ...metadataFormArgTypes,
    };

    return story;
}
```

**Describe the solution you'd like**

Make the `extractArgTypes` function public so that users can use it in their storybook.

**Describe alternatives you've considered**
Import from ESM sources but it is unstable

**Are you able to assist to bring the feature to reality?**
Maybe

**Additional context**
-
Repository: godot
Issue: Script editor - inline syntax highlighting for dictionaries is off
Labels: bug,topic:gdscript,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3, 3.3rc9

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Not relevant, happens on all platforms.


**Issue description:**
<!-- What happened, and what was expected. -->
When declaring a dictionary "inline" (i.e. in a function call) and using a variable as dictionary value, it will be highlighted like a class name (light green in the default theme).
This does not happen when a dictionary is declared normally or when anything but a variable is used as dictionary value.
Variables in an "inline" dictionary declaration should be highlighted like normal variables.
![image](https://user-images.githubusercontent.com/36260114/115550071-b7196680-a2a9-11eb-876c-1261535899c8.png)

**Steps to reproduce:**
Paste this into the script editor:
```gdscript
func a():
	var value = "2"
	b({1: value})           # Wrong highlighting.
	var dict = {1: value}   # Correct highlighting.

func b(var d: Dictionary):
	pass
```


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Not needed.
Repository: rust
Issue: `StructuralEq` and `derive(PartialEq,Eq)` in the stdlib
Labels: T-lang,A-const-generics,A-patterns

I've been meaning to open this for a few weeks now, but haven't had the time.

Currently, in the implementation of the rust standard library, many types use `derive(PartialEq,Eq)`. While, for other derive macros, this isn't an issue, `derive(PartialEq)` and `derive(Eq)` are special, and interacts with various language features. In particular, types like `String` (suprisingly) have the `StructuralEq` impl that `derive(Eq)` presents. Another example is `TypeId`, which is currently both `StructuralEq` and `StructuralPartialEq`, so it could be used in structural matching of `const`s and (eventually) in const generics. 
This particularily affects an implementation I am working on [here](https://github.com/LightningCreations/lccc/blob/ff39e55ff4c5e26f8005f2ed002bd0eaacdc2caf/rust/libcore/src/any.rs#L9..L35), which is intended to solve a longstanding [soundness issue](https://github.com/rust-lang/rust/issues/10389) involving TypeId collisions, at the cost of a non-structural PartialEq implementation. While this is not currently an issue, the stablization of const generics, or making the `TypeId::of` function `const`, would bind `TypeId` to an implementation similar to what already exists, on all implementations (and, in any case, will run into #10389 at some level). For example, with the `#[feature(const_generics)]`, it is [currently possible](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=649202904e42fb8aa12efcc7b1d8adbb) to declare a type with `TypeId` as a generic parameter (though it's not possible to instantiate that parameter).

I have previously described the TypeId issue [on IRLO](https://internals.rust-lang.org/t/typeid-structuraleq-is-this-necessary-or-planned-to-be-useful-in-the-future/14167), and the more general issue [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/derive.28PartialEq.2CEq.29.20in.20the.20stdlib). 
I maintain my recommendation from the zulip thread, that currently, if a type cannot be used in structural matching of constants, the derive be removed and replaced with something effectively similar (possibly an equivalent, unstable, derive macro that excludes the impls of Structural{Partial,}Eq).
Repository: create-react-app
Issue: Primary / Accent color is not accessible
Labels: tag: documentation

<!--
    Please note that your issue will be fixed much faster if you spend about
    half an hour preparing it, including the exact reproduction steps and a demo.

    If you're in a hurry or don't feel confident, it's fine to report bugs with
    less details, but this makes it less likely they'll get fixed soon.

    In either case, please use this template and fill in as many fields below as you can.

    Note that we don't provide help for webpack questions after ejecting.
    You can find webpack docs at https://webpack.js.org/.
-->

### Describe the bug
Same issue as #7946
https://github.com/facebook/create-react-app/issues/7946

The primary / accent color is not accessible, and is very difficult to read in light mode.

Can raise a PR if someone can help me decide which colors we can use and how do we decide that ?
Repository: TypeScript
Issue: Type error not indicated when spreading into a JSX component whose props type is defined as interface
Labels: Bug

# Bug Report

### 🔎 Search Terms

react, component props, interface type, spread

### 🕗 Version & Regression Information

Bug present in 3.3.3 (oldest version available on Playground), as well as Nightly.

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.2.3&ssl=1&ssc=1&pln=18&pc=1#code/JYWwDg9gTgLgBAKjgQwM5wEoFNkGN4BmUEIcA5FDvmQFA0D09cAwgBbIB2A5lnMBzCxQCeXjAgo4MAJ5heAEyy4ANsijIYwCBxQd5U1rwBGAVy5x5wVMjBy1qAHQ1+g4aLgAFYmHQBvAL4MTDJynt7oALxwAXSMLOzcvGReED5kcBEAfOQB6QAUwFgOfBzK-GKGUrJYAJS6+jCVpuaW1rY4UI40BCYc+Fo6zCSQHFgCeQD6AFxhqah1vnA0cCtwlDAmUDoAPJYAbpnMAEzb9PuZNIE0WAAekLBwPX2a2nAAQmZ5C8uruNqo8DA4Qy0TgqRgMwARABGSFwfwodB-DgAuirOBxADKrAgJmU+iMvGQVVCQmIUAANHBUPxcLwhuBtGN4PIIFhUBwyPA8HSwPAyOD0kDUj8VutNjsGSNmdEHHLhT4EfQLoEgA)

### 💻 Code

```ts
import * as React from 'react'

// Change interface to a type declaration and the bug disappears.
interface Props {}
// type Props = {}

// Change 'Props' => '{}' (ie. inline the type) and the bug disappears.
function Component(_: Props) { 
    return <div>C2</div>
}

export function Bug() {
    const props = { opt: "1" } as const

    // Should be a type error, since Component doesn't accept 'opt' prop
    return <Component {...props} />
}
```

### 🙁 Actual behavior

No error is indicated.

Error is indicated correctly when interface is changed to a type declaration, or the type is inlined.

### 🙂 Expected behavior

TypeScript should indicate a type error since Component doesn't accept the 'opt' prop.
Repository: kubernetes
Issue: Pod readiness probe cannot be directed at specific IP family
Labels: kind/bug,sig/network,sig/node,lifecycle/frozen,triage/accepted

#### What happened:
When trying to deploy an **IPv6-only** application in a IPv4-first dual-stack cluster, I noticed that the following readiness probe will fail because it is trying to probe the first pod IP, which is IPv4.

```
    readinessProbe:
      failureThreshold: 30
      httpGet:
        path: /healthz/ready
        port: 15021
        scheme: HTTP
```

#### What you expected to happen:
It should be configurable which of the pod IPs should be probed

#### How to reproduce it (as minimally and precisely as possible):
Deploy application that does not listen for or accept IPv4 requests for readiness probe (==only IPv6) in IPv4-first DS cluster

#### Anything else we need to know?:
I guess I can work around it by adding the `host: ::1` option to `httpGet`, though I ran into another problem with my application and could not verify this.

#### Environment:
- Kubernetes version (use `kubectl version`): v1.20.4
Repository: pytorch
Issue: Support multi-dim reductions for torch.prod, torch.all, torch.any
Labels: triaged,enhancement,module: reductions

## 🚀 Feature

Currently, only `torch.sum` and `torch.mean` have multi-dimension reductions. It would be nice to extend this property to reduction operations such as `torch.prod`, `torch.all` and `torch.any`. This will also ensure that the interface is similar to NumPy, which supports this.

The current alternative to doing multi-dim reductions is to chain the operations like so:
```python
import torch

x = torch.randn(2, 3, 5)
x.prod(-1).prod(-1)  # can be replaced by x.prod(dim=(-1, -2))

y = torch.randint(2, (2, 3, 5), dtype=bool)
y.all(-1).all(-1)  # can be replaced by y.all(dim=(-1, -2))
# analogously for torch.any
```
Repository: rust
Issue: Confusing diagnostic - error[E0308]: mismatched types
Labels: A-diagnostics,A-lifetimes,T-compiler,D-confusing

https://play.rust-lang.org/?gist=d912ef0e107be493dd10b72f973897ba
```rust
use serde::*;

#[derive(Serialize)]
struct Test;

fn main() {
    serialize_wrap(serialize, &Test);
}

fn serialize_wrap<F: FnOnce(&Test)>(f: F, ser: &Test) {
    f(ser)
}
fn serialize<T: Serialize>(x: T) {
    todo!()
}
```

The current output is:

```rust
error[E0308]: mismatched types
  --> src/main.rs:7:5
   |
7  |     serialize_wrap(serialize, &Test);
   |     ^^^^^^^^^^^^^^ lifetime mismatch
   |
   = note: expected type `FnOnce<(&Test,)>`
              found type `FnOnce<(&Test,)>`
note: the lifetime requirement is introduced here
  --> src/main.rs:10:22
   |
10 | fn serialize_wrap<F: FnOnce(&Test)>(f: F, ser: &Test) {
   |                      ^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground`

To learn more, run the command again with --verbose.
```

I'm not quite sure what's the right diagnostic here, maybe that it should be by value?
Repository: flutter
Issue: artifacts class refactoring in the flutter_tool
Labels: tool,P3,c: tech-debt,team-tool,triaged-tool

When trying to migrate artifacts.dart to null safety (context https://github.com/flutter/flutter/pull/79866) I discovered that the API is currently in a pretty bad state. Based on the type of Artifact, the caller is required to provide zero or more of the build mode, target platform, and environment enums. This has made the null safety migration awkward, since all arguments must be nullable and its up to the callsite to unit test to ensure correctness.

I think we should fix this, though not to the point of completely rewriting the library.

Given that each value of the Artifacts enum has different requirements, we should split the single enum into various different enums based on what they require to be looked up, and then create specialized lookup methods.

For example, the dartSdkPath does not require a build mode or target platform, this could be part of a "HostPlatform" artifacts:


```dart
enum HostPlatformArtifact {
  dartSdkPath,
  flutterWebSdkPath,
  iproxy,
  ...
}

String getHostPlatformArtifact(HostPlatformArtifact artifact) { ... }

```

Similarly, the gen_snapshot binaries always require a target platform and build mode:

```dart
enum TargetPlatformArtifact {
  genSnapshot,
  ...
}

String getTargetPlatformArtifact(HostPlatformArtifact artifact, BuildMode mode, TargetPlatform platform) { ... }
```

Finally there are some artifacts that require a build mode but not a host platform, since that platform is somewhat implied:

```dart
enum DontKnowWhatToCalllYouArtifacts {
  linuxDesktopWrapper,
  windowsDesktopWrapper,
}

```

This would us to make all of the required arguments appropriately non-nullable.