sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Unclear diagnostic with closures pass by reference
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.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
#![feature(fmt_internals)]

use std::sync::Arc;
use std::marker::PhantomData;

struct ThreadPool<'env> {
    task_queue: Arc<PhantomData<Box<dyn FnOnce() + 'env>>>,
}

impl<'env> ThreadPool<'env> {
    fn new() -> Self {
        Self {
            task_queue: Arc::new(PhantomData),
        }
    }

    fn send<F: FnOnce() + 'env>(&mut self, _f: F) {}
}

pub fn test_func<'a>(mut iter: impl Iterator<Item = &'a ()>) {
    let mut pool: ThreadPool = ThreadPool::new();
    let v = iter.next().unwrap();
    pool.send(|| {
        let _ = ::core::fmt::ArgumentV1::new_debug(&v);
    });
}
```

The current output is:

```
error[[E0597]](https://doc.rust-lang.org/nightly/error-index.html#E0597): `v` does not live long enough
  [--> src/lib.rs:24:53
](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8e43f71b340a7059ee643fdd6acb861f#)   |
23 |     pool.send(|| {
   |               -- value captured here
24 |         let _ = ::core::fmt::ArgumentV1::new_debug(&v);
   |                                                     ^ borrowed value does not live long enough
25 |     });
26 | }
   | -
   | |
   | `v` dropped here while still borrowed
   | borrow might be used here, when `pool` is dropped and runs the destructor for type `ThreadPool<'_>`
   |
   = note: values in a scope are dropped in the opposite order they are defined

For more information about this error, try `rustc --explain E0597`.
error: could not compile `playground` due to previous error
```

<!-- The following is not always necessary. -->
Ideally the output should mention that `&&Path` (which is what causes the source error) is passed or that the use of `move` keyword in the closure declaration may be needed.

This is a problem because I people on the IRC lost near 20 minutes at debugging that issue.

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
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.
-->
Repository: go
Issue: cmd/go: add a `go mod edit -f` flag akin to `go list -f`
Labels: NeedsDecision,GoCommand,Tools

`go list -json` is very useful, because it makes its output very easy to consume by other programs. Its companion, `go list -f`, is almost equally as useful for similar cases, such as when one needs just one field, or when one is calling the Go tool from a shell script, where JSON decoding isn't as straightforward.

So, for instance, I can obtain the current package's import path via just `go list -f {{.ImportPath}}` rather than reaching for an external tool like `go list -json | jq -r .ImportPath`.

I argue that a similar situation applies to `go mod edit -json`; it's a great way to obtain the data contained by `go.mod` files without needing to use a parser that understands its syntax. However, we lack a `go mod edit -f`, so if I want to obtain just one field like `{{.Go}}`, I have to reach for a JSON parser.

I think it would be relatively straightforward to add `go mod edit -f`, and it would make the command more consistent with `go list -f`.

One potential argument against this proposed flag addition is that we already have other cmd/go commands that have a `-json` flag, but no `-f` flag. One by one, and excluding `go mod edit`, these are:

* `go work edit`: arguably the same case as `go mod edit`, and should be changed as well
* `go test -json`: it prints a newline-separated stream of JSON objects, and it tends to print a lot more output, so a proper program with a JSON parser is a reasonable requirement
* `go env -json`: it's already easy to get a single value without JSON encoding via `go env NAME`, so `go env -f {{.NAME}}` feels redundant
Repository: go
Issue: cmd/go: detect corrupt (overwritten) installation
Labels: NeedsDecision,GoCommand

Every major release, a few users seem to trip over accidentally creating a corrupt installation by extracting the new Go release over an old Go release, without deleting the old release. This leaves around files from the old release that no longer exist in the new release, often leading to build failures.

Some examples of this:

1.18: https://www.reddit.com/r/golang/comments/tfvb6i/go_118_redeclared_in_this_block_error/ `StackGuardMultiplier redeclared in this block`
1.17: #47773 #48714 `PtrSize redeclared in this block`
1.16: #43320 #46936 `memstats.gc_sys undefined (type mstats has no field or method gc_sys)` (plus 4 linked issues in other repos with folks hitting the same problem).

I'm sure there are more, this is just from 5 minutes of searching.

I think we should make the Go command attempt to detect such corrupt installations and point users in the right direction towards fixing it.

One way to achieve this would be to autogenerate a unique file per release (e.g., `cmd/go/internal/version/go1.19.1.txt` or `cmd/go/internal/version/c379c3d58d5.txt` (tip build) [1]). The Go command would then check this directory in GOROOT (if it exists, I think source-less installations are technically possible?), and if it finds multiple files [2] then it exits with an error, informing the user that the installation is corrupt and to delete and reinstall.

[1] I propose a different file even for minor and tip releases because, though less common, even 1.19 -> 1.19.1 may remove files and could result in a corrupt installation if overwritten.

[2] Initially I was thinking the Go command should be a bit more strict and look for a file matching the version of the Go command, but I suspect this could trip up folks working on Go itself. If you modify code in GOROOT and rebuild the Go command, but don't regenerate the version file then we don't want that to report an error.

cc @bcmills @matloob
Repository: angular
Issue: Animation not working correctly with Angular routing and component reusing (caching)
Labels: area: animations,area: router,P3

### Which @angular/* package(s) are the source of the bug?

animations, router

### Is this a regression?

No

### Description

If you use routing and a reuse strategy that caches the components and switches between two pages that contain an animation, then the animation will not work correctly the first time you switch to an already cached page. The state of the animation does not match the value of the animation trigger expression.

Test scenario:
reuse strategy: caching
- choose page 1. Three rows with one line are displayed and the button label is "Expand rows".
- chosse page 2.
- go back to page 1. Three rows with two lines are displayed although the button label is still "Expand rows".
- press "Expand rows". The second line is expanded a little more.
- from now on the state of the animation and the button is in sync agagin and the animation is working correctly until you switch to another cached component.

### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-ivy-w1pir8

### Please provide the exception or error you saw

```true
No exception
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 13.2.6
Node: 16.14.0
Package Manager: npm 8.5.3
OS: win32 x64

Angular: 13.2.6
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1302.6
@angular-devkit/build-angular   13.2.6
@angular-devkit/core            13.2.6
@angular-devkit/schematics      13.2.6
@schematics/angular             13.2.6
rxjs                            7.5.5
typescript                      4.5.5
```


### Anything else?

_No response_
Repository: PowerToys
Issue: PowerToys Run should fully support using forward slashes in paths
Labels: Issue-Bug,Product-PowerToys Run,Priority-3

### Description of the new feature / enhancement

I can enter `c:/tmp` instead of `c:\tmp` in the PowerToys Run box to open that folder in File Explorer.

But if I enter `c:/tm` and hit `Tab` autocomplete doesn't work.

That's one of possibly many scenarios where PowerToys Run _demands_ backslashes. 

It would be a good improvement to support forward slashes in all contexts where (partial) pathspecs are input.

### Scenario when this would be used?

In my default (almost only) shell, i.e. PowerShell, I can use forward slashes instead of backslashes in about any common context for pathspecs:

````text
PS❯  gi c:/tmp

        Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----        2022-03-15     16:43                  tmp

PS❯  gi c:/tm<TAB>
# TAB performs completion, result is c:\tmp\
````

This is especially convenient because, even though I'm using Windows with the _display language_ set to English, I'm French, using French computers with the French AZERTY keyboard layout, where entering a forward slash (`Shift+:`) is _way more convenient_ than entering a backslash (`AltGr+8`). So this has become muscle memory...





### Supporting information

_No response_
Repository: tauri
Issue: [bug] Loading a video/audio as an assets does not work.
Labels: type: bug,priority: 1 high,status: upstream,platform: Linux

### Describe the bug

Loading a video as an asset does not work.

I followed the guide here: https://tauri.studio/docs/api/js/modules/tauri

It works fine with image files (png/jpg etc.) but not with videos. 
I tried loading the video https://www.w3schools.com/html/mov_bbb.mp4 directly from the URL, and this worked without problems.
But using the `asset:///home/paul/Downloads/mov_bbb.mp4` URL this does not work
Loading images from the same folder does work.

In the network panel you can see that the request failed but no further reason is specified
![image](https://user-images.githubusercontent.com/10563452/158854074-2a3b165e-8490-4ae2-b418-2ff682bac0a1.png)

![image](https://user-images.githubusercontent.com/10563452/158854189-c1b2de0a-6fd5-4b1d-9bb3-a0a8bc8ccf0b.png)


The loading of assets this way is IMO not very good explained and when it fails, for some reason, it is very difficult to find out why.

Thank you for creating Tauri, it is awesome!

### Reproduction

_No response_

### Expected behavior

_No response_

### Platform and versions

```shell
Operating System - Arch Linux, version Rolling Release X64

Node.js environment
  Node.js - 17.7.1
  @tauri-apps/cli - 1.0.0-rc.6
  @tauri-apps/api - 1.0.0-rc.2

Global packages
  npm - 8.5.4
  pnpm - Not installed
  yarn - 1.22.17

Rust environment
  rustup - 1.24.3
  rustc - 1.59.0
  cargo - 1.59.0
  toolchain - stable-x86_64-unknown-linux-gnu 

App directory structure
/dist
/node_modules
/src-tauri
/src
/.git
/public

App
  tauri - 1.0.0-rc.4
  tauri-build - 1.0.0-rc.4
  tao - 0.6.4
  wry - 0.13.3
  build-type - build
  CSP - default-src tauri: asset: https://asset.localhost
  distDir - ../dist
  devPath - http://localhost:3000/
  framework - React
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: go
Issue: cmd/internal/obj/x86: Ym is used as the prefix of AMULPS
Labels: NeedsInvestigation

The prefix of `MULPS` in `optab` is `Ym` not `Pm`. Is it a typo here?

https://github.com/golang/go/blob/0fca8a8f25cf4636fd980e72ba0bded4230922de/src/cmd/internal/obj/x86/asm6.go#L1245

The original C code is the same.

https://bitbucket.org/inferno-os/inferno-os/src/75323f4992b2b4e593bd2f548db9ac6897e894d3/utils/6l/optab.c#lines-792
Repository: storybook
Issue: [Angular - Storybook] Error: No configuration files have been found in your configDir
Labels: bug,angular

**Describe the bug**
I'm trying to create a new angular workspace without root application (Component Library) and storybook. 
I've created the workspace and add storybook into it. Configuration files exist inside the project but Storybook can not find configuration file.

**To Reproduce**
1. ng new test --createApplication=false
2. cd test
3. ng g library foo
4. ng generate application demo --routing=true
5. npx sb init
6. npm run storybook

**System**
ERR! Error: No configuration files have been found in your configDir ([PATH]/.storybook).
ERR! Storybook needs either a "main" or "config" file.
ERR!     at validateConfigurationFiles ([PATH]/node_modules/@storybook/core-common/dist/cjs/utils/validate-configuration-files.js:50:11)
ERR!     at loadCustomPresets ([PATH]/node_modules/@storybook/core-common/dist/cjs/utils/load-custom-presets.js:19:62)
ERR!     at loadAllPresets ([PATH]/node_modules/@storybook/core-common/dist/cjs/presets.js:342:131)
ERR!     at buildDevStandalone ([PATH]/node_modules/@storybook/core-server/dist/cjs/build-dev.js:104:48)
ERR!     at processTicksAndRejections (node:internal/process/task_queues:96:5)
ERR!     at async Object.buildDev ([PATH]/node_modules/@storybook/core-server/dist/cjs/build-dev.js:161:5)
ERR!  Error: No configuration files have been found in your configDir ([PATH]/.storybook).
ERR! Storybook needs either a "main" or "config" file.
ERR!     at validateConfigurationFiles ([PATH]/node_modules/@storybook/core-common/dist/cjs/utils/validate-configuration-files.js:50:11)
ERR!     at loadCustomPresets ([PATH]/node_modules/@storybook/core-common/dist/cjs/utils/load-custom-presets.js:19:62)
ERR!     at loadAllPresets ([PATH]/node_modules/@storybook/core-common/dist/cjs/presets.js:342:131)
ERR!     at buildDevStandalone ([PATH]/node_modules/@storybook/core-server/dist/cjs/build-dev.js:104:48)
ERR!     at processTicksAndRejections (node:internal/process/task_queues:96:5)
ERR!     at async Object.buildDev ([PATH]/node_modules/@storybook/core-server/dist/cjs/build-dev.js:161:5)

WARN Broken build, fix the error above.
WARN You may need to refresh the browser.

**Additional context**
Project's file structure:
_As you can see the configuration file does exist_
![Screen Shot 2022-03-17 at 10 33 08 PM](https://user-images.githubusercontent.com/21294962/158876895-79892072-044f-44ca-8cad-4f3c732783c2.png)
Repository: pytorch
Issue: Package and Deploy: Generate External Python Registration files at runtime [WIP]
Labels: triaged,module: deploy

Torch::deploy is a runtime for python which embedded multiple python interpreters into a single process such that we can execute them in parallel. This allows us to get around the GIL problem and run python on multiple threads 🥳 

Currently we have to manually register external python modules and stick them in the source directory in order for them to be exposed to the interpreter. Examples of this can be found with [pyyaml](https://github.com/pytorch/pytorch/blob/master/torch/csrc/deploy/interpreter/register_pyyaml.cpp) and [numpy](https://github.com/pytorch/pytorch/blob/master/torch/csrc/deploy/interpreter/register_numpy.cpp). However, in practice this can be automated.

In order to do this with the current implementation of deploy we'd likely see the following steps

1. Create a seperate folder for these registration modules, and get the linking to work with CMakeLists.txt and TARGETS to work such that our unit tests pass for pyyaml and numpy
2. Create a script (let's call it `generate_registration_module.sh`) which takes in the path to a python module and spits out the CMakeLists.txt file into our the folder created in step1
    1. Run `objdump`
    2.
Repository: flutter
Issue: Some of our environments prefer sized deletes, others don't support it
Labels: engine,c: proposal,P3,team-engine,triaged-engine

In (permalink once https://github.com/flutter/engine/pull/32088 lands needed) we need to supply a Deleter for our shared_ptr because it was allocated with an unexpected size. If we do not, then we get build failures downstream in environments that check for consistency between the new and delete operators.

We can supply a Deleter that calls the specific sized delete with the right size, which would be faster on those platforms, but unfortunately at least one environment (iOS) uses an allocator that does not provide the sized delete.

When all of our environments support sized deletes then we can provide the proper size.
Repository: TypeScript
Issue: Tsbuild watching packagejson is dependent on whether program was built in the invocation
Labels: Needs Investigation,Fix Available

With `tsc --build` we watch input files, config files and output file timestamps to determine if we need to rebuild or not. In past we never checked for module resolution and related files and their timestamps and requiring users to either force build if all inputs and outputs are UpToDate with only change to module resolution related changed. Eg `node_modules/@types/someType/packge.json` say exports or imports map or types entry changes. 

Recently in anticipation to nodenext resolution changes we added package.json also as part of list of files to check timestamps on. But since it cannot be derived without having program constructed, it meant that we only watch/check their timestamps when we construct program. This means we benefit from this only in watch scenario and that too if program was constructed.

So here are two questions:
1. Do we really need to watch/timestamp check `package.json` as now it could change fields that affect the module resolution
2. If we need to treat `package.json` can we use heuristics or do we need fields. Note that we could store this list in buildinfo but then non incremental programs will have the same issue as there wont be buildinfo to read from?
    Options for package.json detection:
    a. package.json next to your own tsconfig, and next to any config referenced in references section?
    b. @RyanCavanaugh suggested packagejson entry in the tsconfig 
    c. references section allows `packge.json` but are we allowing tsconfig options in package.json then?



_Originally posted by @sheetalkamat in https://github.com/microsoft/TypeScript/pull/44935#r829461596_
Repository: go
Issue: cmd/compile: global vars initialized with func calls like net.IPv4 allocate at init time
Labels: Performance,NeedsInvestigation,compiler/runtime

See https://go-review.googlesource.com/c/go/+/391114, which replaces lines like:

```
var IPv4bcast = IPv4(255, 255, 255, 255) // limited broadcast
```

with:

```
var IPv4bcast = IP{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0xff, 255, 255, 255, 255} // limited broadcast
```

The latter is certainly more verbose, which is the reason why the CL isn't submitted, but the former does allocate at init time as reported by `GODEBUG=inittrace=1`. Below are three samples before and after the 7 var changes:

```
init net @0.98 ms, 0.016 ms clock, 2840 bytes, 74 allocs
init net @1.0 ms, 0.017 ms clock, 3048 bytes, 75 allocs
init net @0.96 ms, 0.018 ms clock, 3048 bytes, 75 allocs

init net @1.1 ms, 0.020 ms clock, 2760 bytes, 67 allocs
init net @1.6 ms, 0.017 ms clock, 2760 bytes, 67 allocs
init net @0.98 ms, 0.018 ms clock, 2760 bytes, 67 allocs
```

The funcs in question are tiny, and they allocate fixed-size slices. As far as I can tell, they are getting inlined. I imagine it should be possible for the compiler to avoid the allocations even with the function calls.

cc @randall77 @josharian
Repository: rust
Issue: Confusing error from an incorrect `return;` in `async` block
Labels: A-diagnostics,T-compiler,D-confusing

<!--
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.
-->

This code compiles without errors:
```rust
async fn foo() -> Result<(), Box<dyn std::error::Error>> {
    async {
        Err(anyhow!("oh no"))?;
        Ok(())
    }.await
}
```
Adding a `return;` in the middle of the `async` block makes this code wrong
```rust
async fn foo() -> Result<(), Box<dyn std::error::Error>> {
    async {
        Err(anyhow!("oh no"))?;
        return;
        Ok(())
    }.await
}
```
and `rustc` correctly produces an error. [Playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8efbb96b159cc8c48359d0457d9ffcce)
However, the error is very confusing:

```
error[E0277]: the `?` operator can only be used in an async block that returns `Result` or `Option` (or another type that implements `FromResidual`)
  --> src/lib.rs:27:30
   |
26 |       async {
   |  ___________-
27 | |         Err(anyhow!("oh no"))?;
   | |                              ^ cannot use the `?` operator in an async block that returns `()`
28 | |         return;
29 | |         Ok(())
30 | |     }.await
   | |_____- this function should return `Result` or `Option` to accept `?`
   |
   = help: the trait `FromResidual<Result<Infallible, anyhow::Error>>` is not implemented for `()`

error[E0308]: mismatched types
  --> src/lib.rs:29:9
   |
29 |         Ok(())
   |         ^^^^^^ expected `()`, found enum `Result`
   |
   = note: expected type `()`
              found enum `Result<(), _>`
note: return type inferred to be `()` here
  --> src/lib.rs:27:9
   |
27 |         Err(anyhow!("oh no"))?;
   |         ^^^^^^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> src/lib.rs:26:5
   |
26 | /     async {
27 | |         Err(anyhow!("oh no"))?;
28 | |         return;
29 | |         Ok(())
30 | |     }.await
   | |___________^ expected enum `Result`, found `()`
   |
   = note:   expected enum `Result<(), Box<(dyn std::error::Error + 'static)>>`
           found unit type `()`
help: try adding an expression at the end of the block
   |
30 ~     }.await;
31 +     Ok(())
   |
```
It simultaneously complains in the first error that the `?` is invalid because the async block returns `()` and then in the next error it says that it inferred the return type to *be* `()` because of that `?`.

Ideally the compiler could figure out based on the return type of the function that the `return;` is the problem here, but at the very least it would be good to not point at the `Err(...)?` line as the reason for the return type being inferred as `()`.

Tested on stable 1.59 and nightly 1.61 (2022-03-16).