sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: `fs` APIs don't understand AppExecLink reparse points on Windows
Labels: fs,windows,libuv

<!--
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 output of `"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"` in PowerShell console (Windows)
Subsystem: if known, please specify affected core module name
-->

* **Version**: v14.15.3
* **Platform**: Windows
* **Subsystem**: fs

### What steps will reproduce the bug?

<!--
Enter details about your bug, preferably a simple code snippet that can be
run using `node` directly without installing third-party dependencies.
-->

1. Install an app from the Microsoft Store like [PowerShell](https://www.microsoft.com/store/productId/9MZ1SNWT0N5D), [PowerShell Preview](https://www.microsoft.com/store/productId/9P95ZZKTNRN4), or [Python](https://www.microsoft.com/store/productId/9MSSZTT1N39L).
2. Run the following in Node.js:

```js
// 1
fs.statSync("C:\\Users\\tyleonha\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe")

// 2
fs.existsSync("C:\\Users\\tyleonha\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe")
```

### How often does it reproduce? Is there a required condition?

100% repro rate

### What is the expected behavior?

<!--
If possible please provide textual output instead of screenshots.
-->

```js
// 1
Stats {
  dev: 2191433689,
  mode: 33206,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: 4096,
  ino: 2251799813690117,
  size: 6,
  blocks: 0,
  atimeMs: 1609796639210.8977,
  mtimeMs: 1609794509320.4253,
  ctimeMs: 1609794563739.3364,
  birthtimeMs: 1609794509315.4263,
  atime: 2021-01-04T21:43:59.211Z,
  mtime: 2021-01-04T21:08:29.320Z,
  ctime: 2021-01-04T21:09:23.739Z,
  birthtime: 2021-01-04T21:08:29.315Z
}

// 2
true
```

### What do you see instead?

<!--
If possible please provide textual output instead of screenshots.
-->

```js
// 1
Uncaught:
Error: EACCES: permission denied, stat 'C:\Users\tyleonha\AppData\Local\Microsoft\WindowsApps\pwsh.exe'
    at Object.statSync (fs.js:1086:3) {
  errno: -4092,
  syscall: 'stat',
  code: 'EACCES',
  path: 'C:\\Users\\tyleonha\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe'
}

// 2
false
```

### Additional information

This only seems to happen with AppExecLink reparse points on Windows. Regular SymbolicLinks are fine on Windows and give the expected behavior.

Also, `fs.lstatSync` works with these AppExecLink's which I'm guessing is because lstat operates on the symlnk and not the file that the symlnk points to.

Related issues:
https://github.com/nodejs/node/issues/33024
https://github.com/microsoft/vscode/issues/95828
Repository: pytorch
Issue: resize_ documentation does not match implementation when memory_format is given
Labels: module: docs,triaged

## 📚 Documentation

Documentation says:
```
memory_format (torch.memory_format, optional) – the desired memory format of Tensor. Default: torch.contiguous_format. Note that memory format of self is going to be unaffected if self.size() matches sizes.
```

But this isn't what happens:
```
> >>> torch.randn((2,3,4,5)).to(memory_format=torch.channels_last).resize_((2,3,4,5), memory_format=torch.contiguous_format).stride()
(60, 20, 5, 1)
```

Note also that the default value appears to be incorrect as I provided the default value according to the docs (`resize_(*sizes, memory_format=torch.contiguous_format) → Tensor`), but the behavior is different:

```
>>> torch.randn((2,3,4,5)).to(memory_format=torch.channels_last).resize_((2,3,4,5)).stride()
(60, 1, 15, 3)
```

cc @jlin27 @mruberry
Repository: go
Issue: proposal: time: NewTickerStartingAt and RuntimeStarted
Labels: Proposal

Proposed new functions for NewTickerStartingAt and RuntimeStarted in time

NewTickerStartingAt - The function NewTicker has been limiting users as often I need a NewTicker that starts ticking at a specific time.  I find many times I was wrapping this timer call in an anonymous function with sleep then a NewTicker.  To avoid this redundancy for others and myself, I'd like to expose the interface to the underlying timer interface with both inputs: period duration and start time for the initial tick.  For example; an initial ticket the fires immediately use NewTickerStartingAt(duration, time.Now()).  If the proposed time is in the past it immediately fires and then syncs up on that interval. Another example: the duration is set to a minute, and then starting at a time is also on a minute mark, the result is ticked at the minute.  Times passing over a leap second is a known limitation, but this is also experienced by NewTicker

RuntimeStarted - is useful to have as a way of looking up the runtime.  I know something similar can be created by storing this value via an init() function, but having a static value in the time library can be useful in many places. Such as metrics.  Efficiency is achieved by storing the structure values in start_ local variables so subsequent calls will retrieve the exact same time.

Proposal:
https://go-review.googlesource.com/c/proposal/+/281453/2

View pull request: here:
https://github.com/golang/go/pull/43488

View pull request discussion here:
https://go-review.googlesource.com/c/go/+/281332

I need a function to start a timer at an arbitrary time.  This is related to and also resolves issues:
https://github.com/golang/go/issues/41885
https://github.com/golang/go/issues/17601
Repository: go
Issue: net: Resolver.LookupIP: document should clarify the return values
Labels: Documentation,help wanted,NeedsFix

The current document on `net.Resolver.LookupIP` was not clear on the return values (i.e. what to expect when `err` is `nil`). 

Looking into the source code, `LookupIP` uses `internetAddrList` [here][1], and the comment for `internetAddrList` [here][2] does state the slice would contain at least one IP when err is nil.

We should duplicate the comment of `internetAddrList` to `LookupIP`.


[1]: https://github.com/golang/go/blob/9eef49cfa6eb016e3b20df189e540c6c5a71f365/src/net/lookup.go#L221
[2]: https://github.com/golang/go/blob/9eef49cfa6eb016e3b20df189e540c6c5a71f365/src/net/ipsock.go#L236-L239
Repository: rust
Issue: Rustdoc shows impls out of source order
Labels: T-rustdoc,C-bug

I'm torn on this. On one hand, this is clearly distorting the SGX docs: https://edp.fortanix.com/docs/api/fortanix_sgx_abi/struct.Usercalls.html#asynchronous-usercalls

> Due to rustdoc, this section may appear at the top of the Usercalls documentation. You might want to read the other sections first and then come back to this one.

On the other, SGX is sort of abusing rustdoc here. Maybe we should suggest using modules to group the docs instead of impl blocks?

The other issue is that if rustdoc does this, it will look very strange for impls without a doc-comment.

cc @jethrogb, git says you wrote those docs.
Repository: PowerToys
Issue: [Color Picker Editor] Option for window startup location 
Labels: Idea-Enhancement,Help Wanted,Needs-Spec,Cost-Small,Product-Color Picker

I have two screens, I want the color picker to detect which screen to display, as PowerToy Run does
Repository: go
Issue: x/tools/gopls: can show full type info instead of the name of type alias
Labels: FeatureRequest,gopls,Tools

I write some code like: 

```go
type Param struct {
        Name string
}

type A = Param 

func XXX(a A) {

}
```

when I put the cursor to the func param `A`, gopls show me `type A = Param`，how about show the origin info of Param instead?

I think it's very helpfull.

Thanks.
Repository: pytorch
Issue: Torch native_layer_norm OP out-of-bounds access
Labels: triaged,module: norms and normalization

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

```python
import torch
from torch import tensor
torch.native_layer_norm(tensor([1.0,2,3,4,5]), tensor([1.0]), tensor([1.,2,3,4,5]), 213, 1, 5.280893892284248)
```
Crash [Details.](https://github.com/aivul/crashes/blob/main/native_layer_norm.txt)
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
`native_layer_norm(Tensor input, Tensor? weight, Tensor? bias, int M, int N, float eps) `
The param `M` and `N` are supposed to be limited in a certain range.

<!-- A clear and concise description of what you expected to happen. -->

## Environment

```
Collecting environment information...
PyTorch version: 1.7.0
Is debug build: True
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.2 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 9.0.0 (https://github.com/llvm-mirror/llvm c62b24f070c9a4bb1a76409e623042a740cac4cd)
CMake version: version 3.10.2

Python version: 3.6 (64-bit runtime)
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] numpy==1.19.4
[pip3] torch==1.7.0
[pip3] torchvision==0.8.1
[conda] Could not collect
```

## Additional context

<!-- Add any other context about the problem here. -->
Though some OPs are not user facing operators, they are exposed to every user. Normal user won't execute these OPs forever, but attackers may take advantage of these vulns to archieve their goals.


cc @ezyang
Repository: go
Issue: encoding/json: add line number to SyntaxError
Labels: NeedsDecision

<!--
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`)?

<pre>
$ go version
go version go1.15.6 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?
```go
package main

import (
	"encoding/json"
	"fmt"
	"io"
	"os"
)

func main() {
	dec := json.NewDecoder(os.Stdin)
	for {
		var m map[string]interface{}
		if err := dec.Decode(&m); err == io.EOF {
			break
		} else if err != nil {
			fmt.Printf("%#v\n", err)
			break
		}
	}
}
```
```
$ echo -e '{"x":\ny}' | go run jsonline.go 
&json.SyntaxError{msg:"invalid character 'y' looking for beginning of value", Offset:7}
```

At the moment `SyntaxError` provides an offset of the character that caused parsing error.
The proposal is add the line number as well.

I could not find such an issue therefore opened this one, please close if it was already resolved.
Repository: TypeScript
Issue: Missing error on class extending union of incompatible constructor types
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

**TypeScript Version:**  4.2.0-dev.20210105, worked in v3.6.3, regressed in v3.7

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** is not a constructor function type

**Expected behavior:**

Error: `Type 'typeof Base | typeof Base2' is not a constructor function type.`
Or `super` should not be inferred as `any`.

**Actual behavior:**

No error and `super: any` 

<!-- Did you find other bugs that looked similar? -->
**Related Issues:**

**Code**
```ts
class Base {
    prop = 1;
}

class Base2 {
    other = 1;
}

const base = Boolean() ? Base : Base2;

class Derived extends base { // ExpressionWithTypeArguments is inferred as 'any', expected error "Type 'typeof Base | typeof Base2' is not a constructor function type."
    static fn() {
        super.wargarbl.wat; // super is inferred as 'any'
    }
    fn() {
        super.wargarbl.wat; // super is inferred as 'any'
    }
}
```


<details><summary><b>Compiler Options</b></summary>

```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "moduleResolution": 2,
    "target": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play?ts=4.2.0-dev.20210105#code/MYGwhgzhAEBCkFNoG8CwAoaXoAcBOA9jtALzQCMA3BgL4YaiQzwQIBMKG20BALgBYI8pCtXR10DAgDsIvaACNEI2AQIgEYaQAoAlNAD8cZQC5jrNmIbgo0ACJCAlgDcEAE2gIAHrwTS3MEqsKNAA9KHQAKJe+AhQjjIA6o4CACoAnjgIAIJ4AOYArgC2frwwjuXSAGZCeO7QkNAA5FrpTQA0njEIwL4etQTCAEQZWc28mQgEVeZIAD7QE1nTs2xN0BXQ0nwN0MAycngFvYPQVQXSvQnSi5MAdENc2HJgvI7AZzr6aJjczwVZPB3ADuYHyYIUIBBr0oYQiEABQg2lRqeDqHkaLWkbSeWAk3CqX04vz+0ARgOh4LwkOhvFh4TJiOEm0c1Vq9UxrSauOgEhoQA)
Repository: You-Dont-Know-JS
Issue: Ukrainian translation of YDKJS Yet 2nd Edition
Labels: foreign language translations

Hello, Kyle.

We are a Ukrainian non-profit educational community Kottans. We have translated "Get Started" 2nd edition of YDKJSY into Ukrainian and are working on a translation of book 2. 

We kindly ask you to allow us to publish this translation in our organization's [repo](https://github.com/kottans/You-Dont-Know-JS-Yet-UK)) (with an appropriate link to your repo). Our work of 1st round review has been done and has received positive feedback from our community. 

In addition, it would be great if our work could be merged to your repo as the Ukrainian edition.

Also, we know that sadly further books of the series will not be updated, but we would like to translate 1st edition of those books as well.

Thanks in advance!
Repository: TypeScript
Issue: 'super.prop' should only be allowed for accessors
Labels: Bug,Help Wanted

# Bug Report

### 🔎 Search Terms

super property access

### 🕗 Version & Regression Information

- This changed in version v1.8.2

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?target=99&ts=4.2.0-dev.20210105#code/MYGwhgzhAEBCkFNoG8CwAoaXoFsEBcALAewBMAKAShQF8NtoAHAJ2MegF5oBGAbnuwBzAtDDBgCKMWZUU0ZgQCuzAHY9oddJoyhIMACIJmASwBuCUtAQAPfAhWkY8CEjSZsAMxWy3DBhEVGIwA6PCIyXmgAeijREBBiAHcLABorayDgO1IBP2gAoOZgsQkpZkiYuITk0jSbTOzcvwKQljYK2LBq1OgVYnx0hp7BM0loAHJFBwQPYxULcdEB5in8YzwmzRogA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
class Base {
    method() {}
    prop = 1;
    get accessor() { return 1 }
}

class Derived extends Base {
    fn() {
        super.method; // allowed, as expected
        super.accessor; // allowed for target >=ES2016, expected it to always be allowed
        super.prop; // allowed for target >=ES2016, expected it to always be disallowed, gives 'undefined' at runtime
    }
}
```

### 🙁 Actual behavior

For `target <= ES5` both `super.accessor` and `super.prop` are an error, for `target > ES5` both are allowed, although the runtime behavior is exactly the same. This change was introduced in #5860 because back then there was no (reliable) information whether a property was an accessor or a regular property. Now we have that information even in DTS files. The PR comments even mention that this change was not really correct.

Related: #24678 which was marked "Working as intended", although in the comments it was clearly stated that there should've been a compile error.

### 🙂 Expected behavior

Property access on `super` allows everything that resides on the prototype (methods and accessors) and disallows instance properties.
Same logic should apply to all target ES versions as the behavior is always the same.
Repository: TypeScript
Issue: 'super.prop' in static method should be allowed to access static properties of base class
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

super property access static

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about "super"

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?target=1&ts=4.2.0-dev.20210105#code/MYGwhgzhAEBCkFNoG8CwAoaXoQC5lwEthoBbBXACwHsATACgEoUBfDbHfIkgBwCdqPaAF5oARgDc7bHgLFoAcwrQwwYAijU+TFND4UArnwB246G3QWMoSDAAiCPoQBuCWtAQAPXAmO0Y8BBIaJgyXPIAZsY6IRwcEAY8jgB05FR0EtAA9FkqICDUAO5uADQqMF5JwD600nE4iSmq6pp8mTnQxtS4eQXFtGVdPZUI1W51cQlJfMn8gu25Q71FpZ3dHp5VNRMWLEA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
// @target: ES5
class Base {
    static method() {}
    static prop = 1;
    static get accessor() { return 1 }
}

class Derived extends Base {
    static fn() {
        super.method; // allowed, as expected
        super.accessor; // not allowed, not expected
        super.prop; // not allowed, not expected
    }
}
```

### 🙁 Actual behavior

`super.accessor` and `super.prop` are marked as error. That makes sense in instance methods, but not in static methods, because static properties are not on the prototype.

Related: #42214

### 🙂 Expected behavior

No error.
Repository: flutter
Issue: Streaming from assets
Labels: framework,a: assets,c: proposal,P3,team-framework,triaged-framework

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

I would like to efficiently stream large audio assets directly from an asset bundle. To do this, I need both a stream-based access API and the ability to seek to given byte offsets. The current AssetBundle API is limited to reading the entire asset into memory. The only workaround currently seems to be to dump that memory into a file and then use file-based APIs to read/seek, but it is still unfortunate to have to both read the entire asset into memory first, and then also to go through the additional step of writing a copy of it back to storage.

## Proposal

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->

It would be useful to have an API similar to Android's [AssetManager](https://developer.android.com/reference/android/content/res/AssetManager) which provides access to the asset via a stream with a method for seeking, subject to different access modes.
Repository: godot
Issue: JavaClass has no method 'notification'
Labels: bug,platform:macos,topic:core

**Godot version:**
Godot Engine v3.2.3.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: NVIDIA GeForce GT 750M OpenGL Engine



**OS/device including version:**
MacOS Sierra 10.12.6 fails
Windows 10 is working fine


**Issue description:**
During testing for orphan nodes on my project i had implement an *auto_free* on objects.
I need it for freeing mocked classes to release all dependencies.

Here the code to freeing objects and references
```
static func free_instance(instance :Object):
	if instance != null:
		if not instance is Reference:
			instance.free()
		else:
			instance.notification(Object.NOTIFICATION_PREDELETE)
```
I had an test where iterates over all engine classes and build a mock from it.
After the test is finished i release all mocked objects and only for class *JavaClass* the free fails by an error 
```
Bug, call error: #1431449824
```
This Bug only occurs on MacOS on Windows10 it works without any errors

**Steps to reproduce:**
```
var instance := JavaClass.new()
free_instance(instance)
```

**Minimal reproduction project:**
See steps to reproduce
Repository: pytorch
Issue: Broken LAPACK links in the documentation
Labels: module: docs,triaged,module: linear algebra

The links to LAPACK functions seem to be broken. See for example the links in:
https://pytorch.org/docs/stable/generated/torch.geqrf.html
In `torch.orgqr` and `torch.ormqr`, it directly points to the main Intel page, but I guess it would be better to point to the actual documentation of the methods:
https://pytorch.org/docs/stable/generated/torch.orgqr.html
https://pytorch.org/docs/stable/generated/torch.ormqr.html

cc @jlin27 @mruberry @jianyuh @nikitaved @pearu @heitorschueroff @walterddr @IvanYashchuk