sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: dns.resolveSoa returns EBADRESP if hostname has a CNAME record
Labels: confirmed-bug,dns,cares

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name
-->

* **Version(s)**: v12.16.3 / v12.18.3 / v12.18.0
* **Platform**: Windows / Windows Subsystem for Linux (Debian) / Red Hat Enterprise Linux Server release 7.8
* **Subsystem**: DNS

### What steps will reproduce the bug?
```
const dns = require('dns');
const resolver = new dns.promises.Resolver();

// **************************************************************

async function test(hostname) {
  let data = '';

  console.log('hostname:', hostname);

  try {
    data = await resolver.resolveCname(hostname);
    console.log('CNAME result:', data);
  } catch (error) {
    console.log('CNAME result:', error.message);
  }

  try {
    data = await resolver.resolveSoa(hostname);
    console.log('SOA result:', JSON.stringify(data));
  } catch (error) {
    console.log('SOA result:', error.message);
  }

  console.log();
}

// **************************************************************

(async function main() {
  await test('support.microsoft.com');
})();
```

### Actual Results
hostname: support.microsoft.com
CNAME result: [ 'ev.support.microsoft.com.edgekey.net' ]
SOA result: querySoa EBADRESP support.microsoft.com

### Expected Results
hostname: support.microsoft.com
CNAME result: [ 'ev.support.microsoft.com.edgekey.net' ]
SOA result: querySoa ENODATA support.microsoft.com

### Additional information
This seems to happen for any hostname with a CNAME record.

Another example:

hostname: store.gocomics.com
CNAME result: [ 'gocomicsstore.wpengine.com' ]
SOA result: querySoa EBADRESP store.gocomics.com

I would expect to get an 'ENODATA' instead of 'EBADRESP', as with the other resolveXXX() calls.

For a hostname with an SOA record but no CNAME, you get:

hostname: microsoft.com
CNAME result: queryCname ENODATA microsoft.com
SOA result: {"nsname":"ns1-205.azure-dns.com","hostmaster":"azuredns- 
 hostmaster.microsoft.com","serial":1,"refresh":3600,"retry":300,"expire":2419200,"minttl":300}
Repository: TypeScript
Issue: Add typed overloads to `Object.create`
Labels: Suggestion,Awaiting More Feedback

## Search Terms

- object.create
- object create
- typed object.create
- typed object create

## Suggestion

Change the signatures of `Object.create` to:
```ts
interface ObjectConstructor {
	create<P extends object | null>(proto: P): null extends P ? {} : P;

	create<
		P extends object | null,
		M extends PropertyDescriptorMap = {}
	>(proto: P, properties?: M & ThisType<any>): {
		readonly [
			K in keyof M as M[K] extends { readonly writable: false }
				? K
				: never
		]: M[K] extends Readonly<TypedPropertyDescriptor<infer V>>
			? V
			: any;
	} & {
		-readonly [
			K in keyof M as M[K] extends { readonly writable: true }
				? K
				: never
		]: M[K] extends Readonly<TypedPropertyDescriptor<infer V>>
			? V
			: any;
	} & (null extends P ? {} : P);
}
```

## Use Cases

Getting correct types in code that does:
```js
// `foo` is `any`, because `T` of Object.assign<T, U> is `any`:
const foo = Object.assign(
	// `T` is currently typed as `any`:
	Object.create(null),

	// Only `U` is typed correctly as { bar: number; baz: string }:
	{
		bar: 123,
		baz: 'biz',
	},
);
```

## Examples

<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
	- This might need a flag similar to `strictBindCallApply`, or just done in a separate `lib` file.
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## Relevant issues

- <https://github.com/microsoft/TypeScript/issues/1108>
- <https://github.com/microsoft/TypeScript/issues/13206>
- <https://github.com/microsoft/TypeScript/issues/18609>
- <https://github.com/microsoft/TypeScript/issues/38385>
- <https://github.com/microsoft/TypeScript/issues/41424>
Repository: storybook
Issue: Props not showing in the DocsPage when they're imported from another file into the component (Vue)
Labels: question / support,vue,has workaround,block: props

**Describe the bug**
I have a component where the props are in a different JavaScript file because it's used for multiple button components but the props aren't rendered in the docs, am i doing something wrong?

**To Reproduce**
Steps to reproduce the behavior:
1. Run storybook with the 3 example files below

**Expected behavior**
Props being rendered in the DocsPage

**Screenshots**
![image](https://user-images.githubusercontent.com/3668615/89210417-5da8c480-d5c0-11ea-9743-2e3171ab1c9e.png)

![image](https://user-images.githubusercontent.com/3668615/89210590-abbdc800-d5c0-11ea-8e1b-c822c20d79db.png)


**Code snippets**
```javascript
// ButtonBrops.js
export default {
    label: {
        type: String,
        default: 'Button',
    },
};
```

```vue
// Button.vue
<template>
    <button @click="clickButton">{{ label }}</button>
</template>

<script>
    import ButtonProps from './ButtonProps';

    export default {
        name: 'button',
        props: ButtonProps,
        methods: {
            clickButton() {
                this.$emit('click-button');
            },
        },
    };
</script>
```

```mdx
// Button.stories.mdx
import { Meta, Props } from '@storybook/addon-docs/blocks';
import Button from './Button.vue';

<Meta title='Components/Button' component={Button} />

## Props, Events & Slots
<Props of={ Button } />
```

**System:**
```
Environment Info:

  System:
    OS: Linux 5.4 Ubuntu 19.10 (Eoan Ermine)
    CPU: (8) x64 Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
  Binaries:
    Node: 12.13.0 - ~/.nvm/versions/node/v12.13.0/bin/node
    npm: 6.12.0 - ~/.nvm/versions/node/v12.13.0/bin/npm
  Browsers:
    Chrome: 84.0.4147.125
    Firefox: 78.0.2
  npmPackages:
    @storybook/addon-actions: ^6.0.16 => 6.0.16
    @storybook/addon-docs:  ^6.0.16 => 6.0.16
    @storybook/addon-essentials:  ^6.0.16 => 6.0.16
    @storybook/addon-links:  ^6.0.16 => 6.0.16
    @storybook/vue:  ^6.0.16 => 6.0.16 

```
Repository: opencv
Issue: Python cv.cuda.multiply does not support scalars
Labels: bug,category: python bindings,category: gpu/cuda (contrib)

##### System information (version)

- OpenCV => 4.4.0
- Operating System / Platform => Linux
- Compiler => gcc

##### Detailed description

`cv::cuda::multiply` says that one of the arguments could be a scalar, but it does not work in Python.

##### Steps to reproduce

```
import cv2
a = cv2.cuda_GpuMat(100, 100, cv2.CV_8UC3)
b = cv2.cuda.multiply(a, 4)
```

```
TypeError: Expected Ptr<cv::UMat> for argument 'src1'
```


##### Issue submission checklist

 - [x] I report the issue, it's not a question
   <!--
   OpenCV team works with answers.opencv.org, Stack Overflow and other communities
   to discuss problems. Tickets with question without real issue statement will be
   closed.
   -->
 - [ ] I checked the problem with documentation, FAQ, open issues,
       answers.opencv.org, Stack Overflow, etc and have not found solution
   <!--
   Places to check:
   * OpenCV documentation: https://docs.opencv.org
   * FAQ page: https://github.com/opencv/opencv/wiki/FAQ
   * OpenCV forum: https://answers.opencv.org
   * OpenCV issue tracker: https://github.com/opencv/opencv/issues?q=is%3Aissue
   * Stack Overflow branch: https://stackoverflow.com/questions/tagged/opencv
   -->
 - [x] I updated to latest OpenCV version and the issue is still there
   <!--
   master branch for OpenCV 4.x and 3.4 branch for OpenCV 3.x releases.
   OpenCV team supports only latest release for each branch.
   The ticket is closed, if the problem is not reproduced with modern version.
   -->
 - [x] There is reproducer code and related data files: videos, images, onnx, etc
   <!--
   The best reproducer -- test case for OpenCV that we can add to the library.
   Recommendations for media files and binary files:
   * Try to reproduce the issue with images and videos in opencv_extra repository
     to reduce attachment size
   * Use PNG for images, if you report some CV related bug, but not image reader
     issue
   * Attach the image as archite to the ticket, if you report some reader issue.
     Image hosting services compress images and it breaks the repro code.
   * Provide ONNX file for some public model or ONNX file with with random weights,
     if you report ONNX parsing or handling issue. Architecture details diagram
     from netron tool can be very useful too. See https://lutzroeder.github.io/netron/
   -->
Repository: flutter
Issue: flutter build appbundle/apk --release should warn if x86 is supported
Labels: platform-android,tool,t: gradle,a: build,P3,team-android,triaged-android

Currently, if a plugin brings an x86 native library, AGP would produce an app bundle that supports this ABI. 
However, running Flutter in an x86 environment would produce a crash (`couldn't find "libflutter.so"`) as it's not supported. 

We could add a check that warns users if the app bundle can be expanded to an x86 APK. The brute force approach is to manually unzip and inspect the output `.aab` file.  However, this won't work in add-to-app.  Ideally, there's a way to enforce this policy within the Flutter Gradle plugin. 

I've started a thread with the AGP folks to see if there's a better approach that the brute force.

See https://github.com/flutter/flutter/issues/37566

cc @zanderso @xster @chinmaygarde
Repository: pytorch
Issue: Support recursive data type in TorchScript
Labels: high priority,oncall: jit,triaged,weeks

## 🚀 Feature

It would be really awesome to support recursive data type in TorchScript. For example:
```python
import torch
from typing import Dict

class TypedDataDict(object):
  def __init__(self):
    self.str_to_dict: Dict[str, 'TypedDataDict'] = {}

  def set_str_to_dict(self, value: Dict[str, 'TypedDataDict']):
    self.str_to_dict = value


class TestModule(torch.nn.Module):
  def __init__(self):
    super().__init__()

  def forward(self, input):
    return TypedDataDict().set_str_to_dict({"123": TypedDataDict()})


m = TestModule()
m_scripted = torch.jit.script(m)
m_scripted(torch.tensor(1.))

'''
Currently throws:

RuntimeError: 
Assignment to attribute 'str_to_dict' cannot be of a type that contains class '__torch__.TypedDataDict'.
Classes that recursively contain instances of themselves are not yet supported:
  File "test_yf225.py", line 6
  def __init__(self):
    self.str_to_dict: Dict[str, 'TypedDataDict'] = {}
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
'TypedDataDict.__init__' is being compiled since it was called from '__torch__.TypedDataDict'
  File "test_yf225.py", line 17
  def forward(self, input):
    return TypedDataDict().set_str_to_dict({"123": TypedDataDict()})
           ~~~~~~~~~~~~~ <--- HERE
'__torch__.TypedDataDict' is being compiled since it was called from 'TestModule.forward'
  File "test_yf225.py", line 17
  def forward(self, input):
    return TypedDataDict().set_str_to_dict({"123": TypedDataDict()})
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
'''
```

## Motivation

Many DPER3 modules take input of nested data types like `Dict[str, Dict[str, Dict[str, torch.Tensor]]]`, and it will be really hard to maintain if we had to add support to all variations of those nested data types to TypedDataDict (which is DPER3's typed dictionary object class). But if recursive data type is supported, then we only need `Dict[str, TypedDataDict]` and `Dict[str, torch.Tensor]` to cover all nesting possibilities. 

Having recursive data type support will **greatly speed up the work for moving all PyPer models to 100% TorchScript**, demonstrating TorchScript's production readiness for large-scale ranking models.

cc. @wanchaol @suo 


cc @ezyang @gchanan @zou3519 @suo @gmagogsfm
Repository: godot
Issue: Gridmap + BakedLightmap produces huge scene files
Labels: bug,topic:core

**Godot version:**
3.2.2


**OS/device including version:**
Windows 10 x64


**Issue description:**
When you use a BakedLightmap in conjunction with a Gridmap, a huge amount of data is added to the scene in the form of `baked_meshes`

Such as:
```
[node name="GroundGridmap" parent="." index="10"]
baked_meshes = [ SubResource( 536 ), SubResource( 537 ), SubResource( 538 ), SubResource( 539 ), SubResource( 540 ), SubResource( 541 ), SubResource( 542 ), SubResource( 543 ), SubResource( 544 ), SubResource( 545 ), SubResource( 546 ), SubResource( 547 ), SubResource( 548 ), SubResource( 549 ), SubResource( 550 ), SubResource( 551 ), SubResource( 552 ), SubResource( 553 ) ]
```
```
[sub_resource type="ArrayMesh" id=561]
lightmap_size_hint = Vector2( 328, 328 )
surfaces/0 = {
"aabb": AABB( 62.0751, -0.018673, -268.127, 1.99954, 2.09549, 1.7879 ),
"array_data": PoolByteArray( ... )
"blend_shape_data": [  ],
"format": 97591,
"index_count": 696,
"material": ExtResource( 17 ),
"primitive": 4,
"skeleton_aabb": [  ],
"vertex_count": 242
}

```
As TSCN this can add hundreds of MB to the file. Even when saved as a binary SCN these files are still dozens of MB for larger gridmaps.

Additionally, if the `BakedLightmap` node is removed from the scene, these `baked_mesh` resources don't get removed, so the scene file will never go back down in size.


**Steps to reproduce:**
Add a `Gridmap` node to a scene, place tons of tiles down. Note that the scene is still quite small. Add a BakedLightmap node to the scene that covers the whole gridmap, and bake the light map. Now note that the scene file size has ballooned to many MB.

Finally delete the `BakedLightmap` and note that the size does not go back down again.


**Minimal reproduction project:**
Having trouble setting this up as the assets I have to work with keep crashing the 3.2.2 light mapper.
Repository: go
Issue: x/build/maintner/maintnerd/maintapi/version: support parsing all Go version tags, remove allocations
Labels: Builders,NeedsFix

The current Go tag parser supports only final releases, not betas and not RCs. It would become more useful if it supported all release types. There are some places in x/build where we've wanted to use it, but couldn't do so because of this limitation.

Historically, we've worked around not having a parser by using string manipulation to analyze and modify Go versions, but that can be error prone and won't detect all problems a complete parser would. It's hard to compare or manipulate versions (e.g., get a previous minor release).

<details><summary>Examples</summary><br>

```Go
if strings.HasPrefix(goVer, "go1.13") || strings.HasPrefix(goVer, "go1.14") {
	// ...
}
```

```Go
func nextVersion(version string) (string, error) {
	parts := strings.Split(version, ".")
	n, err := strconv.Atoi(parts[len(parts)-1])
	if err != nil {
		return "", err
	}
	parts[len(parts)-1] = strconv.Itoa(n + 1)
	return strings.Join(parts, "."), nil
}
```

```Go
if strings.Contains(release, "beta") {
	// ...
} else if strings.Contains(release, "rc") {
	// ...
} else if strings.Count(w.Version, ".") == 1 {
	// ...
} else if strings.Count(w.Version, ".") == 2 {
	// ...
}
```

</details>

Additionally, the [`ParseTag`](https://pkg.go.dev/golang.org/x/build/maintner/maintnerd/maintapi/version?#ParseTag) function currently makes allocations, which can be avoided. That would be nice to make it less expensive to use in various loops in the build infrastructure.

[CL 245277](https://golang.org/cl/245277) implements this.

In the future, if more places in x/build start using this, we may consider moving it to a shorter import path. It doesn't have to happen right away.
Repository: godot
Issue: Mysterious FileDialog failure - Open Button doesn't work after Build
Labels: bug,topic:core,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.2

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 10

**Issue description:**
<!-- What happened, and what was expected. -->
I'm trying to use FileDialog to open up resource files from a sub-directory of res:// (ie:  res://dialogues).
When running the project in-editor, the FileDialog works perfectly fine.  The list populates and the resources load.
When running the project after Building, the FileDialog connect signal effectively disables, yet is still 'connected'.  The list populates so it does know the folder is there, but the Open button is interact-able but unresponsive, as if it is no longer sending the signal.  Double clicking or pressing Enter also fail to fire the signal, it simply ignores any attempt to fire the file_selected signal.

**Steps to reproduce:**
Make a new project.
Make a new folder.
Place a file in the new folder to populate the list.
Make a Control node.
Make a FileDialog inside the Control node.
Make a Script for the Control node to popup() the child FileDialog.
Test the project to make sure you can navigate to the sub folder.
Build the project.
Run the project.exe.
Navigate to the sub folder and attempt to fire the file_selected signal by any means (press open, double click, hit enter on the keyboard).


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[FileFail.zip](https://github.com/godotengine/godot/files/5019139/FileFail.zip)
(Godot Project)
[FileFailExe.zip](https://github.com/godotengine/godot/files/5019154/FileFailExe.zip)
(Executable in case it's simply my computer reacting weird)
Repository: PowerToys
Issue: Power profile selection based in active hours
Labels: Idea-New PowerToy

Power users are some of most likely to be running a high performance power profile to get the most out of their machine, because even on the latest processors, the ramp up time for clock speed makes an impact. However, that increased responsiveness is really only needed while they're _at the computer_ for most people.

What if we allowed selection of power profiles based on Windows 10's already-known "active hours" used for updates & patching? For example, I'd love to pick high performance for active hours, and balanced for inactive hours - costing me nothing in experience and increasing power savings.

Anyway, just an idea for functionality connecting these two things!
Repository: pytorch
Issue: [proposal] batch mode for randperm
Labels: triaged,enhancement,module: random

## 🚀 Feature
I'd like to implement some features for torch.random.randperm. What I've thought of so far:
-batch parameter, allowing multiple permutations to be sampled at the same time.
-partial or k-permutations

These would be accessible using optional arguments whose default behavior match current behavior (i.e. batch=1, k=None).

I'm uncertain about what options would be given for controlling the shape of the output (i.e. column or row permutations, automatic squeezing). One possibility is an optional size parameter for the output, and a dim parameter that specifies which axis the permutation lies on. If size is none then it defaults to current behavior.

 I'm also open to additional features. 

## Motivation

Whenever I've used randperm I've used it in a batched context, so it seems like a natural feature. 

## Pitch

I will code cpu and gpu replacements for the current randperm implementations to allow the new features.


## Alternatives
Currently batching can be done using a for loop, which is tedious and unperformant
Partial permutations can easily be obtained by taking a subtensor of the return value but can be unperformant if n is large and k is small.

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->


cc @pbelevich
Repository: node
Issue: Pausing readline pauses SIGINTs
Labels: readline

So lets say you are making a cute little CLI app, and you write this code:

```js
const rl = readline.createInterface(...);
rl.on('SIGINT', () => {
  console.log('bye!');
  process.exit();
});
rl.on('line', (line) => {
  rl.pause();
  compute(line).then(() => {
    rl.resume();
  });
});
```

You will discover that, while the interface is paused, the SIGINT event stops working. This is because pausing readline just pauses the underlying input stream. To fix this I think we would need to decouple that and have readline have an internal buffer of events. Alternatively we could say that people just shouldn't use readline pausing in this case, and do the line buffering themselves (that being said, I don't know how you would do this yourself or if it is even possible).

cc @nodejs/readline
Repository: go
Issue: x/build/internal/releasetargets: evaluate for each upcoming major Go release
Labels: Builders,NeedsInvestigation,release-blocker,recurring

At the start of each code freeze, we should evaluate the choice of releaselets (builders that are used for constructing a release artifact) used to make the upcoming major Go release, and confirm they are the most appropriate choice out of what is available.

The start of a code freeze is a safe time to introduce a builder change, as it will be tested during pre-release versions, starting with beta 1 and onwards.

Making this a release blocker for Go 1.16 (and not okay after beta 1—it needs to be done before). Once completed, this issue should be moved to the next major release milestone.

**Edit:** Starting with Go 1.21, releaselets are only used for running tests. Release artifact construction happens by reproducibly cross-compiling a distpack distribution on a fixed builder.

CC @golang/release, @ianlancetaylor.
Repository: rust
Issue: `--message-format json` doesn't apply to rustdoc coverage output
Labels: T-rustdoc,C-bug,A-doc-coverage,A-CLI

I tried this:

```sh
RUSTDOCFLAGS='--show-coverage -Z unstable-options' cargo doc --message-format json --no-deps --all-features
```

I expected to get a json message containing the coverage information, but instead I still got a table.

Then I tried this:

```sh
RUSTDOCFLAGS='--show-coverage -Z unstable-options --output-format json' cargo doc --no-deps --all-features
```

and it _did_ output a json message, but that message is missing a `reason` key to identify it within the greater message stream when combined with `--message-format json`.

```
rustdoc 1.47.0-nightly (d8cbd9cac 2020-08-03)
```