sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: errors silenced by presence of async function with errors
Labels: A-diagnostics,C-bug

I tried this code:

```rust
pub fn bar() {
    match true {};
}

pub async fn foo() {
    match false {};
}
```

I expected to see this happen: Two `error[E0004]: non-exhaustive patterns: type bool is non-empty`

Instead, this happened: Only one is reported, in the async function. The error in the async function is still reported if the order is flipped. Making both functions sync or async correctly reports both errors. If there is any code following the faulty match, it is always reported as unreachable, despite no error being emitted for the preceding line in the sync function.

Found in #111533 test

### Meta
`rustc --version --verbose`:
```
rustc 1.71.0-nightly (4a59ba4d5 2023-05-12)
binary: rustc
commit-hash: 4a59ba4d54a3ec0d8ea1e82b7eeb5c8b0162de04
commit-date: 2023-05-12
host: x86_64-unknown-linux-gnu
release: 1.71.0-nightly
LLVM version: 16.0.2
```
Repository: TypeScript
Issue: Type guard/Equality narrowing doesn't work on "any"
Labels: Possible Improvement

# Bug Report

### 🔎 Search Terms

type guard equality narrowing strict equal equality

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I found earlier issues (https://github.com/microsoft/TypeScript/pull/9407 and the PR that added this feature https://github.com/microsoft/TypeScript/pull/9407)

### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/FAMwrgdgxgLglgewgAgEYEMBOAKZWDmAXHhAJ7ICUyA3sMvcnCMrgcgLyfIRgA2vlGnQYjMAUxhhMKAgG5h9AL7AFjZq0z4OXEOl4BnMYNojREqTM3yRy5SqA

### 💻 Code

```ts
function bar( arg: any ) {
    if ( arg === null ) {
        return arg;
    }

    if ( arg === false ) {
        return arg;
    }
}
```

### 🙁 Actual behavior

arg should be `null`/`false` inside the if conditions

### 🙂 Expected behavior

arg is `any`

The docs say this should work https://www.typescriptlang.org/docs/handbook/2/narrowing.html
When using `unknown` instead of `any` it works perfectly fine. I think adjusting this, so it works for `any` too, isn't too far fetched.
Repository: stable-diffusion-webui
Issue: [Feature Request]: auto categorization of LoRA file
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Files in "models" directory is moved to each type directory (e.g. Stable-diffusion , LDSR).
this is where the feature was written
it looks LoRA file is not supported.

It is unable to categorize by file name but categorization by file size is able.
https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/b08500cec8a791ef20082628b49b17df833f5dda/modules/modelloader.py#L71-L94

### Proposed workflow

1. Put LoRA file to under models directory
2. start program
3. LoRA file is automatically located in "models/Lora/" directory

### Additional information

To do this , filter of file size must be added in `move_files` function.
I don't think it is good idea to add it just for this feature.
What can I do ?
Repository: rust
Issue: Type inference doesn't properly handle closures that don't return
Labels: A-diagnostics,A-closures,T-lang,T-compiler,A-inference,C-bug,D-confusing

In the code below, both of the `demo_*` functions provoke type inference errors that I believe should not happen.

```rust
use std::error::Error;
use std::process::exit;

fn demo_one<F>(f: F) -> ()
where
    F: FnOnce() -> Result<(), Box<dyn Error>>,
{
    f().or_else(|e| {
        eprintln!("{:?}", e);
        exit(1)
    });
}

fn demo_two<F>(f: F) -> ()
where
    F: FnOnce() -> Result<(), Box<dyn Error>>,
{
    f().or_else(|e| -> ! {
        eprintln!("{:?}", e);
        exit(1)
    });
}
```

The errors I observe are (suggestions omitted for space):

```
error[E0282]: type annotations needed for `Result<(), F>`
 --> src/lib.rs:8:17
8 |     f().or_else(|e| {
error[E0271]]: expected `[closure@lib.rs:18:17]` to be a closure that returns `Result<(), _>`, but it returns `!`
  --> src/lib.rs:18:17
18 |       f().or_else(|e| -> ! {
```

I believe these errors to be incorrect, because:

1. Both closures end with a call to `std::process::exit`, which does not return.  The return type of the closure in `demo_one` should therefore have been inferred to be `!`, matching the closure in `demo_two`.  (Note: whether that call has a `;` afterward does not make any difference.)
1. As documented in <https://doc.rust-lang.org/std/primitive.never.html>, `!` coerces to any type, therefore a callable which never returns ought to be compatible with a caller expecting any return type.

### Meta

`rustc --version --verbose`:
```
rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: aarch64-unknown-linux-gnu
release: 1.69.0
LLVM version: 15.0.7
```

Identical behavior observed from nightly ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=864975f5caf0f7d9aef63b8520876db4)).
Repository: rust
Issue: Tracking Issue for trim-paths RFC 3127
Labels: A-debuginfo,B-RFC-approved,T-compiler,T-cargo,C-tracking-issue,A-reproducibility,F-trim-paths,A-backtrace

This is a tracking issue for the RFC 3127 (rust-lang/rfcs#3127).

This enhancement adds the `--remap-path-scope` command-line flag to control the scoping of how paths get remapped in the resulting binary.

Issues: https://github.com/rust-lang/rust/labels/F-trim-paths
Documentation (rustc): https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/remap-path-scope.html
Documentation (cargo): https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-trim-paths-option
Cargo tracking issue: https://github.com/rust-lang/cargo/issues/12137

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Implement the RFC (https://github.com/rust-lang/rust/pull/115214)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions

- [ ] Should we use a slightly more complex remapping rule, like distinguishing packages from registry, git and path, as proposed in https://github.com/rust-lang/rust/issues/40552?
- [ ] What concerns are there regarding the use of relative paths causing issues with backtraces and debuggers?
- [ ] Should we treat the current package the same as other packages?
- [ ] Will these cover all potentially embedded paths? Have we missed anything?
- [ ] What exactly is the intended use case for the "diagnostics" scope, and when would someone want to turn it on? Is that something someone would really want to enable in cargo? See https://github.com/rust-lang/rust/issues/87745.
- [ ] Should rustdoc support remapping (like for diagnostics)? Does remapping matter for doctests?
  - doctest has supported remapping: https://github.com/rust-lang/rust/pull/122450
  - rustdoc diagnostics as well: <https://github.com/rust-lang/rust/issues/69264#issuecomment-2261945619>
- [ ] On Windows PDB hasn't yet got sanitized. See <https://github.com/rust-lang/cargo/pull/14908>.
- [ ] Consider the impact of back versus forward slashes, and whether or not that will work with either. See <https://github.com/rust-lang/cargo/pull/14908#pullrequestreview-2489623807>


### Implementation history

* https://github.com/rust-lang/rust/pull/115214
* https://github.com/rust-lang/rust/pull/122450
* https://github.com/rust-lang/cargo/pull/12625
Repository: TypeScript
Issue: Accessors should be allowed to be optional
Labels: Suggestion,In Discussion

# Suggestion

Right now accessors are barred from being declared optional. This is a DX regression for decorator users.

## 🔍 Search Terms

accessor optional

## ✅ Viability 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, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

Allow accessors to be declared options;

## 📃 Motivating Example

Decorating a class field should require as few changes over a non-decorated field as necessary. Disallowing accessors from being optional adds an additional change.

Take a plain class:
```ts
class A {
  foo?: number;
}
```
Where you then want to make `foo` reactive with some library that vends decorators. This would be the change I would expect to make:

```ts
import {reactive, Base} from 'some-reactivity-lib';

class A extends Base {
  @reactive
  accessor foo?: number;
}
```

But 5.0 requires:
```ts
import {reactive, Base} from 'some-reactivity-lib';

class A extends Base {
  @reactive
  accessor foo: number | undefined;
}
```

I don't see a semantic problem with optional accessors. They behave very similar to optional fields (with standard field semantics). With `useDefineForClassFields` and this example:

```ts
class C {
  accessor foo?: number;
  
  bar?: number;
}
```

both `foo` and `bar` would exist on the runtime object even though they're optional, ie `'foo' in c === 'bar' in c`.

## 💻 Use Cases

More ergonomic decorator usage.
Repository: next.js
Issue: Unexpected behavior in `router.query` when using `Link` with `as` prop
Labels: bug,Navigation

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 21.6.0: Thu Mar  9 20:08:59 PST 2023; root:xnu-8020.240.18.700.8~1/RELEASE_X86_64
Binaries:
  Node: 16.13.2
  npm: 8.1.2
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 13.4.3-canary.0
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 4.9.5
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Routing (next/router, next/navigation, next/link)

### Link to the code that reproduces this issue

https://github.com/dzucconi/nextjs-example-as-prop

### To Reproduce

1. Set up the following routes in the `pages` directory: [profileId]/[channelId].tsx and post/[postId].tsx.
2. Link to the channel page using the `as` prop to mask the route as the post route:

```tsx
<Link
  href={{
    pathname: "/[profileId]/[channelId]",
    query: { profileId: "author-slug", channelId: "example", postId: 1 },
  }}
  as="/post/1"
>
  View post
</Link>
```

3. On the `[profileId]/[channelId].tsx` page, try to access the `router.query` object and check its content.
4. Observe that the received `router.query` object has incorrect values, as shown below:

```tsx
{
  "profileId": "post",
  "channelId": "1",
  "postId": "1"
}
```


### Describe the Bug

I'm encountering an issue with the `Link` component when using the `as` prop to display a modal preview of a post while updating the URL to the post route. Here's the scenario:

I have two routes: `[profileId]/[channelId].tsx` and `post/[postId].tsx`. I want to display a post modal preview in the Channel page and simultaneously update the URL to the post route. The `router.query` does not contained the expected parameters.

### Expected Behavior

Compare the received object with the expected/desired `router.query` object:

```tsx
{
  "profileId": "author-slug",
  "channelId": "example",
  "postId": "1"
}
```

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_
Repository: bitcoin
Issue: Allow getblockfrompeer to use any peer
Labels: Feature

### Please describe the feature you'd like to see added.

When you use `getblockfrompeer` you have to specify an index of a specific peer. But it would be much easier if it allowed you to use ANY peer.

For example, if you run a pruned node, and your first peer happens to be also pruned, the call will fail. If the call tried all nodes, until it finds a peer that has the block, it wouldn't require you that implement any logic for that.

### Is your feature related to a problem, if so please describe it.

_No response_

### Describe the solution you'd like

The solution would be simple: if you don't specify any index, then try all peers untill you find one that does have block, otherwise fail.

### Describe any alternatives you've considered

_No response_

### Please leave any additional context

_No response_
Repository: godot
Issue: The anchor to the grid does not work well.
Labels: bug,topic:editor,needs testing,topic:2d

### Godot version

v3.6.beta1.official [632a544c6]
v3.6.stable.official [de2f0f147]

### System information

w10 64

### Issue description

What can I say, the anchor seems out of place and the grid is not well positioned.

I don't know what information I can provide. The grid and the anchors are simply not coherent.

Watch the video.
The anchor changes when I change the grid dimensions.
At 16x16 the anchor is in one place.
After I change the grid to 8x8, now the anchor has been moved slightly, this should not be the case, the anchor should be the same as 16x16, the difference is now one more step (8x8) has been added.

https://github.com/godotengine/godot/assets/19652075/7178814b-c9a0-4d4e-8fb5-e8ce6dad6f4e

Problem, the anchor to the grid is positioned in a different place depending on whether the grid is 8x8 or 16x16 in size.

Solution, place the node just at the 0,0 coordinates of the editor, the error does not occur there.
The error is a small offset that is added to the grid when it moves away from the 0,0 coordinate, that's what it seems to me at first.
But it's not a solution because I need the grid to be correct at any point to position and resize my nodes.

### Steps to reproduce

Watch the video

### Minimal reproduction project

[project.zip](https://github.com/godotengine/godot/files/11472074/project.zip)
Repository: create-react-app
Issue: Broken Link
Labels: needs triage,issue: bug report

The "More Information here" link, under the Building for Relative Paths heading, on this page: https://create-react-app.dev/docs/deployment  is broke.  Not sure where that is supposed to go.
Repository: rust
Issue: `.await` does not perform autoref or autoderef
Labels: A-diagnostics,T-lang,C-bug,A-async-await,A-suggestion-diagnostics,AsyncAwait-Triaged,WG-async,T-types

<!--
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:

```rust
use core::future::IntoFuture;
use futures::future::{ready, Ready};
struct Foo;

impl IntoFuture for &Foo {
    type Output = u32;
    type IntoFuture = Ready<u32>;

    fn into_future(self) -> Self::IntoFuture {
        ready(2)
    }
}

#[tokio::main]
async fn main() {
    assert_eq!(Foo.await, 2);
}
```

I expected to see this happen: Compiles and runs successfully. The `.await` performs auto-ref, and `<&Foo as IntoFuture>::into_future()` is called.

Instead, this happened: 

```
error[E0277]: `Foo` is not a future
  --> src/main.rs:16:19
   |
16 |     assert_eq!(Foo.await, 2);
   |                   ^^^^^^
   |                   |
   |                   `Foo` is not a future
   |                   help: remove the `.await`
   |
   = help: the trait `futures::Future` is not implemented for `Foo`
   = note: Foo must be a future or must implement `IntoFuture` to be awaited
   = help: the trait `std::future::IntoFuture` is implemented for `&Foo`
   = note: required for `Foo` to implement `std::future::IntoFuture`
```

### 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.
-->

`rustc --version --verbose`:
```
1.71.0-nightly (2023-05-12 4a59ba4d54a3ec0d8ea1)
```

@rustbot label A-async-await
Repository: stable-diffusion-webui
Issue: [Bug]: Vae not loaded at startup if selected, it is loaded after first generation.
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

When you start the application the VAE selected is not loaded. it says: Couldn't find VAE named vae-ft-mse-840000-ema-pruned.safetensors; using None instead
It is loaded after the first image generation. 

### Steps to reproduce the problem

1. Open Webui
2. Select a VAE
3. Restart Webui
4. Observe that the VAE is not loaded
5. Try generating an image
6. The VAE is now loaded


### What should have happened?

VAE should load at startup

### Commit where the problem happens

b08500c

### What platforms do you use to access the UI ?

Windows

### What browsers do you use to access the UI ?

Mozilla Firefox

### Command Line Arguments

```Shell
--no-half-vae
```


### List of extensions

No

### Console logs

```Shell
Creating model from config: D:\Programmi\stable-diffusion-webui\configs\v1-inference.yaml
LatentDiffusion: Running in eps-prediction mode
DiffusionWrapper has 859.52 M params.
Couldn't find VAE named vae-ft-mse-840000-ema-pruned.safetensors; using None instead
Applying scaled dot product cross attention optimization.
```


### Additional information

_No response_
Repository: godot
Issue: PackedDataContainer ignores Resource values
Labels: topic:core

### Godot version

4.1.dev2

### System information

Windows 11, i7, gpu:Intel Iris Plus Graphics (integrated)

### Issue description

I came across PackedDataContainer thanks to PR #76561, and wanted to serialize a dictionary containing an Image using it but the image does not appear to be included in the resulting file (I tried serializing in both, tres and res file), and upon deserialization, a null value is returned without any error being thrown.

Since the documentation doesn't explicitly mention whether Resources (I only tested Images and ImageTextures though) are handled or not, it's possible that this behavior is not a bug. However, as I don't have a deep understanding of the low level things in godot, I'm assuming it to be one by default.

### Steps to reproduce

Running
```
var img := Image.create(100, 100, false, Image.FORMAT_RGB8)
img.fill(Color.RED)
var data = { "img": img }
var packed = PackedDataContainer.new()
packed.pack(data)
ResourceSaver.save(packed, "res://packed_data.res", ResourceSaver.FLAG_BUNDLE_RESOURCES)

var container = load("res://packed_data.res")
for key in container:
	res = container[key]
	prints(key, container[key]) # prints "img <null>"
```

### Minimal reproduction project

N/A
Repository: neovim
Issue: <cmd> mappings don't result in statusline update
Labels: needs:discussion,has:workaround,statusline

### Problem

Using `<cmd>` in the right hand side of a mapping used to result in the status line being subsequently updated when changing e.g., `formatoptions`. This is no longer the case. I am not sure if this is intended behavior, so I thought I'd report it here in case it's not intended. A workaround is to use `:` in a mapping instead of `<cmd>`.

This started in fe11079. Cc: @luukvbaal 

### Steps to reproduce

```
nvim /tmp/tmpfile --clean
```

Add the following content:

```vim
function! StatusLine() abort
  return &formatoptions
endfunction

noremap <space>t <cmd>set formatoptions+=t<cr>
noremap <space>T <cmd>set formatoptions-=t<cr>

set statusline=%{StatusLine()}
```

Source the script.

```
:source %
```

Type `<space>t` to add `t` to `formatoptions`.

### Expected behavior

I expected the status line would be updated to reflect the new value for `formatoptions`, which now includes `t`.

However, it's not updated until I e.g., move the cursor or press `<ctrl-l>`.

### Neovim version (nvim -v)

v0.9.0

### Vim (not Nvim) behaves the same?

No, 9.0.1189

### Operating system/version

Kubuntu 23.04

### Terminal name/version

Konsole 22.12.3

### $TERM environment variable

xterm-256color

### Installation

appimage
Repository: godot
Issue: Blender version check fails if Blender outputs extra text early
Labels: bug,topic:editor,needs testing,topic:import

### Godot version

v4.0.2.stable.official [7a0977ce2]

### System information

Linux Mint 21

### Issue description

If Blender outputs additional information before the "Blender <version>" line when Godot attempts to get the version, Godot will fail with "unexpected --version output from Blender"
In my case, Blender outputs the following with "--version":
`Color management: using fallback mode for management`
`Color management: Error could not find role data role.`
`Blender 3.0.1`
This is with the version of Blender supplied with Ubuntu/Mint. Some reading online suggests it's a graphics driver related issue, but I couldn't find any specific methods of fixing it aside from recompiling Blender (which seems extreme when Blender works fine).

I created a simple shell script that simply echoed the Blender 3.0.1 line before running Blender, and it successfully verified the version and moved on (though now I'm stuck with RPC errors which I believe are an unrelated issue).

I'm guessing a suitable fix for this would be to process ALL the text returned with "blender --version" and look for the correct line instead of assuming it will be the first line.

### Steps to reproduce

Have a version of Blender that gives additional text prior to the Blender line when run with --version.


### Minimal reproduction project

N/A