sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Intra-doc links do not work in markdown files
Labels: T-rustdoc,E-medium,C-feature-request,A-intra-doc-links,A-markdown-parsing

I tried this code:

```markdown
# Hello

Link to [std::process::Command]
```

I expected to see this happen: Rustdoc generates a link to https://doc.rust-lang.org/std/process/struct.Command.html

Instead, this happened: Rustdoc writes the literal text `[std::process::Command]`

This might be a little tricky because there is no scope to resolve in. I think ideally this would have the same scope as an empty crate with only the `std` injects (`extern crate std; use std::prelude::v1::*;`).

Noticed this in https://github.com/rust-lang/rust/pull/77971.

### 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.
-->

`rustdoc --version`:
```
rustdoc 1.49.0-nightly (91a79fb29 2020-10-07)
```
Repository: node
Issue: Headers with the same name are combined into one entry in `http2`
Labels: http2

Version: 14.13.1
Platform: macOS, Darwin Kernel Version 19.6.0 

### What steps will reproduce the bug?

```sh
$ node
Welcome to Node.js v14.13.1.
Type ".help" for more information.
> (() => {
...   const http2 = require("http2");
...   const client = http2.connect("https://www.httpbin.org");
...   const req = client.request({ ":path": "/response-headers?foo=42&foo=43&foo=44" });
...   req.on("response", (headers, flags) => console.log("Response:", headers, flags));
...   req.on("end", () => client.close());
...   req.end();
... })();
undefined
> Response: [Object: null prototype] {
  ':status': 200,
  date: 'Thu, 15 Oct 2020 14:15:24 GMT',
  'content-type': 'application/json',
  'content-length': '117',
  server: 'gunicorn/19.9.0',
  foo: '42, 43, 44',
  'access-control-allow-origin': '*',
  'access-control-allow-credentials': 'true'
} 4
```

Versus cURL on the same URL:

```sh
$ curl -i "https://httpbin.org/response-headers?Foo=42&Foo=43&Foo=44"
HTTP/2 200 
date: Thu, 15 Oct 2020 12:58:56 GMT
content-type: application/json
content-length: 117
server: gunicorn/19.9.0
foo: 42
foo: 43
foo: 44
access-control-allow-origin: *
access-control-allow-credentials: true

...body...
```

### How often does it reproduce? Is there a required condition?

Consistently reproducible

### What is the expected behavior?

```
foo: ['42', '43', '44'],
```

Quoting [the docs](https://nodejs.org/api/http2.html#http2_headers_object):

> Headers are represented as own-properties on JavaScript objects. The property keys will be serialized to lower-case. Property values should be strings (if they are not they will be coerced to strings) or **an Array of strings (in order to send more than one value per header field)**.

### What do you see instead?

```
foo: '42, 43, 44',
```
Repository: node
Issue: Some statements have already been executed when debugger stops at line breakpoint
Labels: inspector

<!--
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**: 14.13.1 
(also checked all major versions, 13, 12, 11, 10 – issue persists) 
* **Platform**: MacOS
* **Subsystem**: Debugger

### 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. Execute this script with any debugger (Chrome DevTools, VSCode, WebStorm).
2. Place line breakpoints on lines with comments. 
3. Debugger stopped at the first breakpoint. (`second(first());` line)  
Function `first()` have already been executed. – see console output
4. Resume execution
5. Debugger stopped at the second breakpoint (`second(first(1));` line)
The function `first()` has not yet been executed. 
6. Resume execution
7. Function `first()` executed -> see console. 

```
function first(x) {
    console.log("first() executed");
}

function second(x) {
    console.log("");
}

debugger;

second(first()); // place line breakpoint here

second(first(1)); // place line breakpoint here
```

![breakpoints-node](https://user-images.githubusercontent.com/7490808/96148681-2ab07480-0f11-11eb-97d9-848877a4885b.gif)



### How often does it reproduce? Is there a required condition?
Always
### What is the expected behavior?

It is expected that no statements have been executed before the debugger stopped at the line breakpoint. 
Also, the behavior must be consistent. As we see it differs for `second(first());` and `second(first(1));`

### What do you see instead?

Function `first` has been executed before the stop at the breakpoint. 


### Additional information

WebStorm debugger in both cases debugger sets breakpoint with `Debugger.setBreakpointByUrl` method with specified `lineNumber` and with not specified `columnNumber` (which by default must work for the whole line)

Both breakpoints later resolved to the `0` column. But the order of execution may be different. So it is not possible for a debugger to set a line breakpoint which stops before any statement being executed. 


The same script works perfectly in Chrome.
Repository: pytorch
Issue: Make Undefined reprensentable in DispatchKeySet. 
Labels: triaged,enhancement

followup for https://github.com/pytorch/pytorch/pull/46352
Currently Undefined is not representable in DispatchKeySet, but it has valid use cases as a runtime dispatch key. We should just make Undefined a normal key.
Repository: ant-design
Issue: Add callbacks to Upload itemRender function
Labels: Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
Our use case for this is to offer a file uploader with a "replace" button that does remove   add at once(we have restricted the file uploader to only a single file for this use case).

In addition we are looking to combine this and the download and remove buttons into a dropdown menu with the full names of each operation written out. This also has problems from the same source.

It is not currently possible to use the Upload `itemRender` prop for this if you need to be able to manipulate the fileList after adding files to it.

There are workarounds such as:
1. Extracting the handlers by inspecting the props of the returned `item`
2. Replicate the `fileList` manipulation logic.

Both of these are comparable work to just building a file list from scratch.

### What does the proposed API look like?
The solution is to expose the bound file actions to the renderer. The following is the proposed type changes:
```typescript
interface UploadFileActions {
  download(): void
  preview(): void
  remove(): void
}

interface UploadProps<T = any> {
  // ...
  itemRender?: (
    originNode: React.ReactElement,
    file: UploadFile,
    fileList?: Array<UploadFile<T>>,
    actions: UploadFileActions
  ) => React.ReactNode;
  // ...
}
```

Note: this API isn't the easiest to work with given the 4 arguments, however there aren't that many options that don't violate the contract of the existing API. Some alternatives that would also work:
* Put the methods on the `file` objects in the code that calls `itemRender` (this is pretty expensive and may cause issues for existing implementations that rely on the object identity being stable)
* Allow you to pass in a Component instead of a render function and use different logic in that case.


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: Cannot extend the base `Texture` class via script
Labels: bug,topic:core

**Godot version:**
3.2.2-stable


**OS/device including version:**
Windows 10


**Issue description:**
Impossible to create a new instance of a custom texture implemented via script which inherits `Texture`:

```gdscript
extends Texture
class_name CustomTexture
```

![godot_texture_base_extend](https://user-images.githubusercontent.com/17108460/96165222-05c5fc80-0f25-11eb-99b3-4ca9f2c1b95f.png)

Extending `ImageTexture` works in contrast:

```gdscript
extends ImageTexture
class_name CustomImageTexture
```

**Steps to reproduce:**
1. Create a global script to just extend `Texture`.
2. Create a `Sprite` and try to assign a new custom texture from the inspector.


**Workaround:**
Extend `ImageTexture` instead. The reason for extending from `Texture` directly is to achieve better efficiency and flexibility by using the `VisualServer` API directly. This is possible to do via C++ but seems like not possible in GDScript, so this caught be off guard.

Not every texture is based on an image, as it can be procedurally generated (like `NoiseTexture`), so using `ImageTexture` is not a perfect option for this.

If that's expected, than perhaps that's documentation issue. From the [`Texture`](https://docs.godotengine.org/en/3.2/classes/class_texture.html) description:

> Texture is a base for other resources. It cannot be used directly.

Perhaps this is what *directly* means here, so needs clarification.

That said, I'm not sure whether it's really possible to extend `Texture` via script in the first place, because I see no virtual methods.

**Minimal reproduction project:**
[texture_base_extend.zip](https://github.com/godotengine/godot/files/5386675/texture_base_extend.zip)
Repository: flutter
Issue: Write engine test for --disable-observatory-publication
Labels: a: tests,team,platform-ios,engine,P3,team-ios,triaged-ios

Follow up to PR https://github.com/flutter/engine/pull/21632#discussion_r501991784

Write unit test to confirm VM service port is not published when the flag is passed in.
Repository: rust
Issue: Uplift `declare_interior_mutable_const` and `borrow_interior_mutable_const` from clippy to rustc
Labels: A-lints,T-compiler,C-feature-request

In tokio 0.2, there was a footgun: if you created a `const Runtime`, then each time you called `runtime.block_on()` it would make a new runtime. This lead to confusing errors at runtime like 'reactor gone' which gave no hint of what actually went wrong: https://github.com/rust-lang/rust-clippy/issues/6088

Fortunately, this was fixed by `const_item_mutation` in https://github.com/rust-lang/rust/pull/75573. Unfortunately, `Runtime::block_on` will now take `&self` instead of `&mut self` starting in tokio 0.3: https://tokio.rs/blog/2020-10-tokio-0-3

`Runtime` can now only be constructed at runtime: as a local variable or in a `once_cell`, or `lazy_static`. The code for that looks like this:

```rust
use once_cell::sync::Lazy;
use tokio::runtime::Runtime;

const RUNTIME: Lazy<Runtime> = Lazy::new(|| {
    Runtime::new().unwrap()
});

fn main() {
    RUNTIME.block_on(async {});
}
```

rustc will compile this without a warning. Clippy, however, says that this is almost certainly not what you want:

```
error: a `const` item should never be interior mutable
 --> src/main.rs:4:1
  |
4 |   const RUNTIME: Lazy<Runtime> = Lazy::new(|| {
  |   ^----
  |   |
  |  _make this a static item (maybe with lazy_static)
  | |
5 | |     Runtime::new().unwrap()
6 | | });
  | |___^
  |
  = note: `#[deny(clippy::declare_interior_mutable_const)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#declare_interior_mutable_const

error: a `const` item with interior mutability should not be borrowed
 --> src/main.rs:9:5
  |
9 |     RUNTIME.block_on(async {});
  |     ^^^^^^^
  |
  = note: `#[deny(clippy::borrow_interior_mutable_const)]` on by default
  = help: assign this const to a local or static variable, and use the variable here
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#borrow_interior_mutable_const
```

To avoid having this footgun, the lint should be uplifted from clippy to rustc (possibly as warn-by-default), so that users will notice it even if they don't use clippy.

cc @Darksonn
Repository: go
Issue: x/tools/gopls: gopls is confused by //line directives
Labels: gopls,Tools

go1.15.1 darwin/amd64

Files with //line directives confuse gopls, for instance no hover returned, and no diagnostics generated.

In
```
//line a.y:1
package main

func main() {
	var err error
	err.Error()
}
```
hovering on `Error` returns nothing, but it hovers fine without the `//line` comment.

Likewise, in (the `-- <name> --` headers say what the contents of <name> are)
```
-- a.go --
package consts

const a = 1
-- b.go --
package consts
//line gen.go:5
const a = 2
```
no errors are generated for `b.go` as it stands (although the definition in `a.go` is described as the 'other' definition), while errors are generated correctly without the `//line` comment.
Repository: rust
Issue: Type inference results in accessing a private type, causing a compilation error
Labels: A-diagnostics,A-visibility,T-compiler,A-inference,C-bug

<!--
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.
-->

I tried this code ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6e39f95bda095067bac36b7020c1a7e2)):

```rust
mod foo {
    pub struct Public;

    impl AsRef<Private> for Public {
        fn as_ref(&self) -> &Private {
            &Private
        }
    }

    struct Private;

    pub fn bar() -> impl AsRef<Private> {
        Public
    }
}

pub fn baz() {
    fn blah<T>(_: T) {}

    blah(foo::bar);
}

```

I expected to see this happen: Code should compile successfully

Instead, this happened: 

```text
error: type `foo::Private` is private
  --> src/lib.rs:20:5
   |
20 |     blah(foo::bar);
   |     ^^^^ private type

error: type `foo::Private` is private
  --> src/lib.rs:20:10
   |
20 |     blah(foo::bar);
   |          ^^^^^^^^ private type
```

Note also that no error code is given.

### 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.
-->

Rust playground version 1.47.0

cc @jswrenn
Repository: godot
Issue: execute with debug -d,  get_stack() results in wrong stack trace from a another thread
Labels: bug,topic:gdscript,topic:editor

**Godot version:**
Godot Engine v3.2.3.stable.mono.official

**OS/device including version:**
Windows 10 x64

**Issue description:**
I want get debug informations from a running application.
The application is started from a editor plugin with the OS.execute command and debug option -d
To collect debug information i used get_stack() to collect.
In the main thread the stack trace is correct and holds the right stack with line numbers
But when using inside a extra thead the collected stack trace is wrong



**Steps to reproduce:**
Use the attached project and activate the plugin and run the command from the menu
![image](https://user-images.githubusercontent.com/347037/96174894-4f651600-0f2a-11eb-889d-7cacdc3c8d08.png)
Verify the console output 
```
main thread => [{function:_print_stack, line:30, source:res://addons/pluginDebug/TestCommand.gd}, {function:_initialize, line:6, source:res://addons/pluginDebug/TestCommand.gd}]
other thread => [{function:_initialize, line:8, source:res://addons/pluginDebug/TestCommand.gd}]
```
You can see the "other thread" stack trace is wrong

**Minimal reproduction project:**

[get_stack_issue.zip](https://github.com/godotengine/godot/files/5387239/get_stack_issue.zip)
Repository: TypeScript
Issue: Simpler Expression of Complex Type Conditions
Labels: Suggestion,Awaiting More Feedback

## Search Terms

Multiple, type, condition, expression, no, extra, case, and, or

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

I often find myself repeating sub-branches of conditional types, which makes reasoning about control flow more difficult. I'd recommend the same logical operators to those of JS land, at the type-level.

## Example

Let's say we have three boolean types––`ConditionA`, `ConditionB` and `ConditionC`––and we want to gather the number of true conditions in a new type `Result`, which will evaluate to `0 | 1 | 2 | 3` depending on the aforementioned conditions. The runtime equivalent can be expressed quite legibly:

```ts
const Result =
  (conditionA && conditionB && conditionC)
    ? 3
    : (
        (conditionA && conditionB) ||
        (conditionB && conditionC) ||
        (conditionA && conditionC)
      )
      ? 2
      : (conditionA || conditionB || conditionC)
        ? 1
        : 0;
```

The type-level equivalent is not as obvious in its meaning, and we end up repeating the potential results.

```ts
type Result =
  ConditionA extends true
    ? ConditionB extends true
      ? ConditionC extends true
        ? 3
        : 2
      : ConditionC extends true
        ? 2
        : 1
    : ConditionB extends true
      ? ConditionC extends true
        ? 2
        : 1
      : ConditionC extends true
        ? 1
        : 0;
```

While it nets more code, the following is––imo––easier to understand.

```ts
type Result =
  (ConditionA extends true && ConditionB extends true && ConditionC extends true)
    ? 3
    : (
        (ConditionA extends true && ConditionB extends true) ||
        (ConditionB extends true && ConditionC extends true) ||
        (ConditionA extends true && ConditionC extends true)
      )
      ? 2
      : (ConditionA extends true || ConditionB extends true || ConditionC extends true)
        ? 1
        : 0;
```

Ideally, the same rules from JS-land could apply to judging whether a type is a subtype of truthy, so we could do this:

```ts
type Result =
  (ConditionA && ConditionB && ConditionC)
    ? 3
    : (
        (ConditionA && ConditionB) ||
        (ConditionB && ConditionC) ||
        (ConditionA && ConditionC)
      )
      ? 2
      : (ConditionA || ConditionB || ConditionC)
        ? 1
        : 0;
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [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).
Repository: rust
Issue: Old vtable example fails with: "error: untyped pointers are not allowed in constant"
Labels: A-trait-system,T-compiler,C-bug,A-const-eval,requires-nightly,A-raw-pointers

While trying to play around with `raw::TraitObject` I found this thread [internals.rust-lang.org/...](https://internals.rust-lang.org/t/compile-time-access-to-vtable/9794) and in particular this code example [play.rust-lang.org/...](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=45ec73295c7b669841068802141fec38) which does not work anymore.

### Code

I tried this code:

```rust
#![feature(raw)]

use std::{mem, ptr, raw};

pub trait Trait {}

struct Struct;
impl Trait for Struct {}

#[allow(dead_code)]
const STRUCT_AS_DYN_TRAIT_VTABLE: *mut () =
    unsafe { mem::transmute::<*const dyn Trait, raw::TraitObject>(ptr::null::<Struct>()).vtable };
```

I expected to see this happen: 
I get the vtable as a const.

Instead, this happened: 
`error: untyped pointers are not allowed in constant`

### Version it worked on
Probably before c400f758e5cda9c2617f6d8dec87a6f24ddb291
Edit:  added PR number #71665

### Version with regression
rustc 1.49.0-nightly (e160e5cb8 2020-10-14)

Any chance we can get the example code to compile again?
Is there a different way to get the vtable?
Repository: vscode
Issue: Git - Removing a folder from multi-root workspace does not remove repo
Labels: bug,help wanted,git,good first issue

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
Version: 1.50.1 (user setup)
Commit: d2e414d9e4239a252d1ab117bd7067f125afd80a
Date: 2020-10-13T15:06:15.712Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.19041

Steps to Reproduce:

1. Create a multi-root workspace:

    * folder_A contains git-repo A
    * folder_B contains git-repo B

    SCM pane shows repo A and repo B

2.  Remove folder_B from workspace

    SCM pane still shows repo B (expected: repo B is automatically closed/removed)

3. Select "close repo" on repo B

    repo B vanishes from SCM pane

4. reopen workspace

    SCM pane again shows repo B (expected: repo B does no longer show up)

Workaround: Delete workspace settings under `C:\Users\<username>\AppData\Roaming\Code\User\workspaceStorage`.

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No
Repository: flutter
Issue: Add TimeOfDay parsing for Localizations
Labels: c: new feature,framework,f: material design,a: internationalization,c: proposal,team-design,triaged-design

`MaterialLocalizations` has methods to format and parse a date, but only format for time.

A localized parsing method for time should be added.
Repository: pytorch
Issue: send_object/recv_object APIs for c10d
Labels: oncall: distributed,triaged,module: c10d

## 🚀 Feature
We should expose 2 APIs, `send_object` and `recv_object` to send picklable, non-tensor objects with send/recv semantics, similar to what is done for RPC arguments (but without using RPC). We will allow these APIs to take in a `rank` argument to address the source/destination of the send/recv similar to the existing send/recv APIs for tensors. 

This is a natural extension of the work detailed in https://github.com/pytorch/pytorch/issues/23232, where we have made progress in adding collective-communication based APIs for general python objects. 

## Motivation

This was mentioned by @froody offline. The main motivation is that this API could be used in cases where the user does not necessarily want to set up RPC and use that for communication, they just want a quick way to transfer data across processes. 

## Alternatives

User can always simply use RPC, but for quick one-off send/recv calls, this might be too much of an overhead to set up and use. This would present a zero additional set-up approach (after initializing process group) to quickly send/recv general python objects. 

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar @jiayisuse @agolynski