sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Missing "path statement drops value"
Labels: A-diagnostics,T-compiler

Given the following code: 

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ee9151221000d9d30a653aa00bd14d47

```rust
truct Test {
}

fn test(some_t: Test) {
    || {loop {
        some_t;
    }};
}

fn main() {
}
```

The current output is:

```
error[E0382]: use of moved value: `some_t`
 --> src/main.rs:6:9
  |
6 |         some_t;
  |         ^^^^^^ value moved here, in previous iteration of loop
  |
  = note: move occurs because `some_t` has type `Test`, which does not implement the `Copy` trait
```

The note does not explain well why the move occurs. It instead explains why in subsequent iterations of the loop the move cannot be performed: because the value is already moved in the first iteration. But there's no clue why the move wanted to occur (and occured) in the first iteration. The (unstated) reason is that `some_t;` is a _path statement_.

Reading `rustc --explain E0382` output does not provide any hints, either.

The problem is even more cryptic when using vscode (likely a pretty common case): the message is shortened to:

```
use of moved value: `some_t`
move occurs because `some_t` has type `Test`, which does not implement the `Copy` trait
```

Only when the closure is reduced to a `loop` without the closure, like this:
```rust
fn test(some_t: Test) {
    loop {
        some_t;
    };
}
```

is the message given by vscode the same as when issuing `cargo c` from command line (and mentions the move in the first iteration).

In any case (commandline or vscode) the messages given by the compiler (or RustAnalyzer) do not point to the root cause. But they could, as demonstrated by the code below:

```rust
use std::sync::mpsc;

struct Job;

fn test(job: Job) {
    job;
}

fn new(receiver: mpsc::Receiver<Job>) {
    receiver;
}

fn main() {
}
```

for which `cargo c` issues (among others) the following:

```
warning: path statement with no effect
 --> src/main.rs:6:5
  |
6 |     job;
  |     ^^^^
  |
  = note: `#[warn(path_statements)]` on by default

warning: path statement drops value
  --> src/main.rs:10:5
   |
10 |     receiver;
   |     ^^^^^^^^^ help: use `drop` to clarify the intent: `drop(receiver);`
```

In the `test` function the `job;` is a _path statement with no effect_. Interestingly enough, in the `new` function in the same situation we are told that _path statement drops value_. The side question is why in these two functions (`test` and `new`) the compiler messages are different. And the point is that this last message ("path statement drops value") likely indicates the real cause of the move occuring in the first loop iteration in the original problem - but it was not suggested by the compiler message there.

Ideally the "path statement drops value" should be produced by the compiler for the original problem.
Repository: youtube-dl
Issue: Site support request: https://rmc.bfmtv.com
Labels: site-support-request,patch-available

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2021.12.17**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [ ] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones

```shellsession
$ youtube-dl --version
2021.12.17
$ youtube-dl --verbose https://rmc.bfmtv.com/replay-emissions/estelle-midi/l-integrale-d-estelle-midi-du-lundi-4-juillet-2022_VN-202207040445.html
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', 'https://rmc.bfmtv.com/replay-emissions/estelle-midi/l-integrale-d-estelle-midi-du-lundi-4-juillet-2022_VN-202207040445.html']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2021.12.17
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.17763
[debug] exe versions: ffmpeg N-93151-gff03418348, ffprobe N-93151-gff03418348
[debug] Proxy map: {}
[generic] l-integrale-d-estelle-midi-du-lundi-4-juillet-2022_VN-202207040445: Requesting header
WARNING: Falling back on generic information extractor.
[generic] l-integrale-d-estelle-midi-du-lundi-4-juillet-2022_VN-202207040445: Downloading webpage
[generic] l-integrale-d-estelle-midi-du-lundi-4-juillet-2022_VN-202207040445: Extracting information
ERROR: Unsupported URL: https://rmc.bfmtv.com/replay-emissions/estelle-midi/l-integrale-d-estelle-midi-du-lundi-4-juillet-2022_VN-202207040445.html
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 815, in wrapper
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 836, in __extract_info
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\common.py", line 534, in extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\generic.py", line 3489, in _real_extract
youtube_dl.utils.UnsupportedError: Unsupported URL: https://rmc.bfmtv.com/replay-emissions/estelle-midi/l-integrale-d-estelle-midi-du-lundi-4-juillet-2022_VN-202207040445.html
```

Youtube-dl works perfectly with bfmtv.com but NOT with rmc.bfmtv.com
Repository: vscode
Issue: The pseudo terminal's name cannot be changed for custom task provider
Labels: bug,tasks,regression

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Version: 1.69.0-insider (user setup)
Commit: 2932e29645f12f08235b7560b3f7d763b8a1cf25
Date: 2022-07-04T10:51:04.591Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: 10.0.139.17-electron.0
OS: Windows_NT x64 10.0.22000

Steps to Reproduce:

1. Clone https://github.com/jdneo/vscode-extension-samples/tree/cs/rename-terminal/task-provider-sample
2. The [change](https://github.com/jdneo/vscode-extension-samples/commit/709c0373ba5da6a3214e043a4a054684ef235f37#diff-c1ef7214e83057c513732459e2b27adc41fc29380730c2db63d462ce5a94caab) will use change name emitter to rename the pseudo terminal
3. launch the extension and run the custom task
4. The rename does not take effect.
Repository: material-ui
Issue: `<Select />`'s `onChange` does not follow the type that I specify
Labels: bug 🐛,typescript,v5.x migration,regression

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

When supplying an `onChange` handler to the `<Select />` component, the resulting type for `event.target.value` is always `string`, even if I specify the type signature of the function to be `(event: SelectChangeEvent<number>) => void;`

### Expected behavior 🤔

`event.target.value` always seems to be `string` rather than the type that I specify.

### Steps to reproduce 🕹

Live example: https://codesandbox.io/s/affectionate-dust-bxrn7k?file=/src/App.tsx

### Context 🔦

I'd expect to be able to pull out a `number` in the example that I have given, and this used to work on V4 but we've uncovered this problem during our migration to V5.

### Your environment 🌎

_No response_
Repository: vscode
Issue: use "current working directory detection" in the implementation of "runInTerminal"
Labels: debug,debt

With integrated terminal's new feature "Current working directory detection", it should no longer be necessary to emit "cd <working_directory>" when launching the debuggee.
Repository: rust
Issue: Type and const parameters are not used as a fallback during type inference
Labels: E-hard,T-lang,T-compiler,A-inference,C-feature-request,T-types

Currently you're able to define default const parameters for a type.  This is explained [here](https://blog.rust-lang.org/inside-rust/2021/09/06/Splitting-const-generics.html#featureconst_generics_defaults). This allows one to write generic `impl` blocks but requires some explicit type coercion as shown in [this stack-overflow article on the `new` constructor](https://stackoverflow.com/questions/71233548/rust-cannot-infer-the-value-of-const-parameter-when-a-default-is-provided). 

It would be great if rust can infer that the type has to be the return type of the `new` constructor and, if the const parameter is not provided, infer that the type defaults to the default const value.

The stack-overflow article had me confused for a bit (see [this reddit post](https://www.reddit.com/r/rust/comments/vrvl6t/defaults_for_const_parameters_in_impl_blocks/)) so I'll provide a more explicit example:
```rust
#[derive(Debug)]
struct Foo<const N: usize = 1> {
    set_on_creation: bool,
    passed_in: bool,
    generic_field: [usize; N],
}

impl<const N: usize> Foo<N> {
    pub fn new(passed_in: bool) -> Self {
        Self {
            set_on_creation: true,
            passed_in,
            generic_field: [0; N],
        }
    }
}

fn main() {
    let a = Foo::new(true);
    dbg!(a);
    let b = Foo::new(false);
    dbg!(b);
    let c: Foo<2> = Foo::new(false);
    dbg!(c);
}
```

I expected to see this happen: 
Successfully infer that the type has to be the default const variant of the type.

Instead, this happened:
```
error[E0282]: type annotations needed for `Foo<N>`
  --> src/main.rs:19:13
   |
19 |     let a = Foo::new(true);
   |         -   ^^^^^^^^ cannot infer the value of const parameter `N`
   |         |
   |         consider giving `a` the explicit type `Foo<N>`, where the const parameter `N` is specified
```
### Clarity
To be clear, the following works:
```rust
    let a: Foo = Foo::new(true);
```
but this does not:
```rust
    let a = Foo::new(true);
```
On the face of it the above looks silly. 

### Meta
Bug is also present on `nightly`.

```
[walter@cuddles const-generic-default-playground]$ rustc --version --verbose
rustc 1.60.0 (7737e0b5c 2022-04-04)
binary: rustc
commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c
commit-date: 2022-04-04
host: x86_64-unknown-linux-gnu
release: 1.60.0
LLVM version: 14.0.0
```
Repository: node
Issue: http.IncomingMessage aborted Event isn't the same as http.IncomingMessage close Event
Labels: doc

### Affected URL(s)

https://nodejs.org/api/http.html#class-httpincomingmessage

### Description of the problem

The "`aborted`" event is deprecated and states "`Deprecated. Listen for 'close' event instead.`" which isn't related in any way.
The `close` event fires whenever the stream is `CLOSED` while the `aborted` event only fires if the request is `ABORTED`.

For exmaple a little HTTP-Server:
```js
// server.js
const http = require('http')

const server = http.createServer((request, response) => {
    request.on('error', (error) => {
        console.error('> THERE WAS AN ERROR', error)
    })

    request.on('aborted', () => {
        console.log('> REQUEST GOT ABORTED')
    })

    request.on('close', () => {
        console.log('> REQUEST GOT CLOSED')
        response.end('CLOSED');
    })

    request.resume(); // CONSUME ALL DATA
});
server.on('listening', () => console.log('HTTP-Server is running.'));
server.listen(3100, '127.0.0.1');
```

And some simple curl requests to this http server:
`curl -F file=somesmallfile.bin http://127.0.0.1:3100`
```console
REQUEST GOT CLOSED
```

`curl -F file=somebigfile.bin --limit-rate 1K http://127.0.0.1:3100` and cancel ``CTRL+C``
```console
REQUEST GOT ABORTED
THERE WAS AN ERROR Error: aborted
   at connResetException (node:internal/errors:704:14)
   at abortIncoming (node:_http_server:680:17)        
   at socketOnClose (node:_http_server:674:3)
   at Socket.emit (node:events:549:35)
   at TCP.<anonymous> (node:net:747:14) {
 code: 'ECONNRESET'
}
REQUEST GOT CLOSED
```

As we can see the close event gets triggered in both cases while the abort event only gets triggered in the event of a user interruption. Please clearify this as ``close`` isn't an alternative for ``aborted`` as stated above.
Repository: pytorch
Issue: C++ extensions inject a bunch of compilation flags
Labels: module: binaries,module: cpp-extensions,triaged,better-engineering

### 🐛 Describe the bug

Discovered by @vfdev-5 

This is possibly intentional, but I've noticed that C++ extensions, while building on linux, inject a bunch of compilation flags. For example, in functorch, we do not specify either of ['-g -NDEBUG'](https://github.com/pytorch/functorch/blob/b22d52bb15276cd919815cde01a16d4b3d8f798e/setup.py#L84-L88), but those appear in [our build logs](https://github.com/pytorch/functorch/runs/7140654131?check_suite_focus=true).

The end result of `-g` is that our linux binaries are a lot larger than they need to be (the debug symbols are 10s of mb) while our mac and windows binaries are very small < 1mb. I would expect the domain libraries to have the same issue.

## The diagnosis

In C++ extensions we adopt [certain flags from distutils](https://github.com/pytorch/pytorch/blob/f7678055033045688ae5916c8df72f5107d86a4a/torch/utils/cpp_extension.py#L558).

These flags come from Python's built-in sysconfig module (https://github.com/python/cpython/blob/ec5e253556875640b1ac514e85c545346ac3f1e0/setup.py#L476), which contains a list of flags used to compile Python. These include -g, among other things.

This is probably intentional (I wrote these lines by copy-pasting them from distutils) but I don't have a good understanding of why these flags are necessary or if only some of them are.

### Versions

main

cc @ezyang @seemethere @malfet @zou3519
Repository: TypeScript
Issue: Searching for references of a function, lists every reference to the interface which requested the implementation of that function, and also all other classes that implement that interface
Labels: Suggestion,Awaiting More Feedback

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.68.1
- OS Version: Windows 10

Steps to Reproduce:

Use the following code structure:

<!-- ⚠️⚠️ 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. -->

Is there a way to find only exact calls of a given function in my code?

Consider the following typescript code, and files:

```
/** Interface.ts */

export interface myInterface {
    myFunction();
}

/** UserA.ts **/
import {myInterface} from 'Interface';

class UserA implements myInterface {
    myFunction() {
        console.log('a');
    }
}

export default UserA;

/** UserB.ts **/
import {myInterface} from 'Interface';

class UserB implements myInterface {
     myFunction() {
        console.log('b');
     }
}

export default UserB;

/** fileA.ts **/
import UserA from 'UserA';

const aInstance = new UserA();
aInstance.myFunction();

/** fileB.ts **/
import UserB from 'UserB';

const bInstance = new UserB();
bInstance.myFunction();
```

If I try to get all references to `UserA` classes `myFunction`, all the above files are listed as a reference. My expected behaviour would be to get a list of references for files and locations, where `UserA.myFunction` is used, instead of a reference for `myInterface.myFunction`. In case I would want to see a reference for `myInterface.myFunction`, I could search for references for that exact function instead.

[img](https://gyazo.com/1830a24643cd813d273fa9b0d57d66ea)
Repository: rust
Issue: Linking to `str::replacen` from `alloc` crate docstring creates a broken link fragment
Labels: T-rustdoc,C-bug

Hi, in my PR #97977 I was unable to link to `str::replacen` from the `alloc` crate in a docstring:

https://github.com/rust-lang/rust/blob/eb1fa3cca138d57ca687cab9a55d2041bba5f8cd/library/alloc/src/string.rs#L1747

```
Rustbook (x86_64-unknown-linux-gnu) - embedded-book
Rustbook (x86_64-unknown-linux-gnu) - edition-guide
Building stage0 tool linkchecker (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.17s
alloc/string/struct.String.html:842: broken link fragment `#method.replacen` pointing to `core/primitive.str.html`
number of HTML files scanned: 32333
number of HTML redirects found: 10095
number of links checked: 2261468
number of links ignored due to external: 112628
```
Repository: rust
Issue: fs metadata : path "..." considered existing [Windows MSYS2]
Labels: O-windows,T-libs-api,C-bug,A-io

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

Path::exists return true for the path "...", which does not relate to any file.

I tried this code:

```rust
println!("{:?}", std::path::Path::new("...").exists());
```

I expected to see this happen: 
`false`
I checked with this:
```
$ cd ...
bash: cd: ...: No such file or directory
```

Instead, this happened: 
`true`

More detail using metadata function

```rust
println!("{:?}", std::path::Path::new("...").metadata());
```
```
Ok(Metadata { file_type: FileType(FileType { attributes: 16, reparse_tag: 0 }), is_dir: true, is_file: false, permissions: Permissions(FilePermissions { attrs: 16 }), modified: 
Ok(SystemTime { intervals: 133015096104411686 }), accessed: Ok(SystemTime { intervals: 133015098374221229 }), created: Ok(SystemTime { intervals: 133013522078653030 }), .. })   
```

### 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.
-->

I use rust via MSYS2.
`rustc --version --verbose`:
```
rustc 1.62.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-pc-windows-gnu
release: 1.62.0
LLVM version: 14.0.4
```
Repository: godot
Issue: GDScript 2.0: `@onready @export var n: Node = $Default` breaks.
Labels: bug,topic:gdscript

### Godot version

4.0.alpha11

### System information

Linux

### Issue description

Consider the following line:
```gdscript
@onready @export var n: Node = $Node2D:
```
This is an export for a `Node` with a default value. The default value forces me to use `onready`.
However due to initialisation order, if I set a custom export value in the inspector, the following happens:
 1. the exported value is set on init
 2. since the variable is `onready`, the *default* value is then set on ready, overriding the exported one, meaning you can't actually export.

Even worse, if a setter is defined the setter is called when setting the exported value before simply overriding this value with the default one and without calling the setter:
```gdscript
extends Node3D

@onready @export var n: Node = $Foo:
	set(value):
		print("setter n was ", n, " now ", value)
		n = value

func _init() -> void:
	print("init ", n)

func _ready() -> void:
	print("ready ", n)

```
![2022-07-05_18-13-26 export onready hell](https://user-images.githubusercontent.com/71937306/177371707-4fcca2a9-c3f7-496b-9754-c7043afe89af.png)


prints:
```
init null
setter n was null now Bar:[Node2D:24763171212]
ready Foo:[Node2D:24746393997]
```

### Steps to reproduce

```gdscript
extends Node

@onready @export var five := 5

func _ready() -> void:
	print(five)

```

### Minimal reproduction project

_No response_
Repository: rust
Issue: Non-descriptive error when building something which requires alloc on a platform which doesn't have it
Labels: A-diagnostics,T-compiler

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

When building a crate which requires alloc for a target which doesn't have alloc, the resulting error message just says that the build requires alloc and alloc isn't found/linked.

The current output is:

```
error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait

error: `#[alloc_error_handler]` function required, but not found
```

<!-- The following is not always necessary. -->
This is less than helpful in the case where the dependency on alloc is coming from a dependency, as it does not help pin down where it comes from. In this case, ideally the output should look something like this:

```
error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait

hint: use of the memory allocator is coming from the following dependencies:
...

error: `#[alloc_error_handler]` function required, but not found
```

This would help the user know which crate(s) are causing the problem, as opposed to having to search through the dependencies manually (which is made easier by using `cargo vendor` to download your dependencies in one place and then `ripgrep` to search for uses of alloc, but that requires knowing those tools and doing extra work).

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->