sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: stable-diffusion-webui
Issue: [Feature Request]: 2 lock icons in IMG2IMG tab next to width and height
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 ?

a lock icon for width and heigth in the img2img tab, either for both together or each seperate.

So that when you send image to img2img from txt2img, the width and heigth won't adjust to the one used in txt2img if you don't want it to.

I would find this useful for the workflow.
Generate a bunch of txt2img at 512x512 , pick 20% of those, one by one to send to img2img to automatically create 4 variations.

Almost every parameter is kept when using send to img2img, aside from Width and heigth, which I then have to change each time back to a higher value for my final results, because they always reset back to 512x512 after a send, if txt2img had those values.

### Proposed workflow

1. Go to img2img, enable the lock icon so width and heigth cannot be set to something else automatically (for example 704x704)
2. Press send2img while in the txt2img tab after generating 512x512 images
3. Have your image appear in img2img with width and heigth still set to 704x704


### Additional information

_No response_
Repository: rust
Issue: Incorrectly reported borrow error instead of bad signature when using tuples
Labels: A-diagnostics,T-compiler,C-bug

The following code
```rust
fn a(_: &State) {}
fn b(_: &State) {}

struct State {}

fn expected_bad_signature_error() {
    let fns: Vec<fn(_)> = vec![a, b];
    
    for test in fns {
        let state = State {};
        
        test(&state);
    }
}
```
 reports a bad signature error as expected:
```
error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
 --> src/lib.rs:7:35
  |
7 |     let fns: Vec<fn(_)> = vec![a, b];
  |                                   ^ expected fn pointer, found fn item
  |
  = note: expected fn pointer `fn(&State)`
                found fn item `for<'a> fn(&'a State) {b}`
```

but changing from a single value to tuples
```rust
fn unexpected_borrow_error() {
    let fns: Vec<(fn(_),)> = vec![
        (a,),
        (b,),
    ];
    
    for (test,) in fns {
        let state = State {};
        
        test(&state);
    }
}
```
 causes the compiler to report a borrow error:
```
error[[E0597]](https://doc.rust-lang.org/stable/error-index.html#E0597): `state` does not live long enough
  --> src/lib.rs:25:14
   |
22 |     for (test,) in fns {
   |                    --- borrow later used here
...
25 |         test(&state);
   |              ^^^^^^ borrowed value does not live long enough
26 |     }
   |     - `state` dropped here while still borrowed
```

[Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dd05e32eae9023542dba4e84a97e4384) 

To clarify, my issue is not the error itself (the correct type is `fn(&_)`), but the incorrect error being reported for the `unexpected_borrow_error` case.

@vincenzopalazzo helped me double-check this issue
Repository: rust
Issue: [ICE]: compiler segfault with GAT
Labels: I-crash,A-trait-system,P-high,I-compilemem,C-bug,T-types,A-GATs

### Code

```Rust
pub trait Functor
{
    type With<T>: Functor;
}

pub struct IdFunctor<T>(T);
impl<T> Functor for IdFunctor<T> {
    type With<T2> = IdFunctor<T2>;
}

impl<T> Functor for Vec<T> {
    type With<T2> = Vec<T2>;
}

impl<T> Functor for Box<T> {
    type With<T2> = Box<T2>;
}

pub struct Compose<F1, F2, T>(F1::With<F2::With<T>>)
where
    F1: Functor,
    F2: Functor;

impl<F1, F2, T> Functor for Compose<F1, F2, T>
where
    F1: Functor,
    F2: Functor
{
    type With<T2> = F1::With<F2::With<T2>>;
}

pub enum Value<F, FVEC>
where
    F: Functor,
    FVEC: Functor,
{
    UnsignedInt(F::With<u64>),
    Array(Box<Value<FVEC, Compose<F, FVEC, ()>>>),
}


fn main() {
    let x: Value<IdFunctor<()>, Compose<IdFunctor<()>, Vec<()>, ()>> = Value::UnsignedInt(IdFunctor(1));
}
```


### Affected release channels

- [ ] Previous Stable
- [X] Current Stable
- [X] Current Beta
- [X] Current Nightly

### Rust Version

```Shell
rustc 1.66.1 (90743e729 2023-01-10)
binary: rustc
commit-hash: 90743e7298aca107ddaa0c202a4d3604e29bfeb6
commit-date: 2023-01-10
host: x86_64-unknown-linux-gnu
release: 1.66.1
LLVM version: 15.0.2
```


### Current error output

```Shell
>>> RUSTFLAGS="-A unused" cargo test --color=always -- --nocapture --test-threads=1
   Compiling traceevent v0.1.0 (lisa/tools/analysis/traceevent)
error: could not compile `traceevent`

Caused by:
  process didn't exit successfully: `rustc --crate-name traceevent --edition=2021 traceevent/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test -C metadata=a2a838ea58b05a7f -C extra-filename=-a2a838ea58b05a7f --out-dir lisa/tools/analysis/target/debug/deps -C incremental=lisa/tools/analysis/target/debug/incremental -L dependency=lisa/tools/analysis/target/debug/deps --extern memmap2=lisa/tools/analysis/target/debug/deps/libmemmap2-39be61c96f5d1d0c.rlib --extern nom=lisa/tools/analysis/target/debug/deps/libnom-ff2be7353b7bf974.rlib --extern nom_locate=lisa/tools/analysis/target/debug/deps/libnom_locate-4ec40cb54fefc4c1.rlib --extern smartstring=lisa/tools/analysis/target/debug/deps/libsmartstring-b065da3210ea89f5.rlib --extern thiserror=lisa/tools/analysis/target/debug/deps/libthiserror-5bdf89cac3d44f1d.rlib -A unused` (signal: 11, SIGSEGV: invalid memory reference)
```


### Backtrace

```Shell
No backtrace:
(signal: 11, SIGSEGV: invalid memory reference)
```


### Anything else?

This happened while tinkering with a code similar to this issue:
https://github.com/rust-lang/rust/issues/107362

The difference is that I "manually unrolled" one level of `Compose<F, Vec>` into FVEC, so the type of `Value<FVEC, Compose<F, FVEC, ()>>` is now (possibly) an infinite chain of mutually recursive F and FVEC instead of a directly recursive chain of F
Repository: go
Issue: openbsd/mips64: x/sys incompatible with main repo
Labels: OS-OpenBSD,NeedsFix,arch-mips

[CL 459497](https://go.dev/cl/459497) was submitted to x/sys with the result that x/sys cannot be imported into the main repo without breaking `GOOS=openbsd GOARCH=mips64 ./make.bash`. This blocks all non-openbsd development from importing a new x/sys, which in turns blocks importing a new x/tools and x/net. This is of course not a viable development state.

Deferring to the openbsd-mips64 maintainers' decision on that CL that this breakage is the best possible state of affairs, the response for the main repo should be to remove openbsd-mips64 from the misc-compile-openbsd builder, which I will do.
Repository: tensorflow
Issue: How to make the program end without moving tf_func() out of the loop?
Labels: stat:awaiting tensorflower,type:support,comp:core,TF 2.11

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Support

### Have you reproduced the bug with TF nightly?

No

### Source

source

### Tensorflow Version

tf 2.11.0

### Custom Code

Yes

### OS Platform and Distribution

Windows 11

### Mobile device

_No response_

### Python version

3.7.16

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

```shell
Code doesn't work correctly.
```


### Standalone code to reproduce the issue

```shell
import tensorflow as tf
import numpy as np


class test:
    def __init__(self):
        self.counter=None
    
    
    def sum_func(self):
        if np.sum(self.counter)==1875:
            return True
    
    
    @tf.function
    def tf_func(self):
        flag=self.sum_func()
        return flag
    
    
    def counter_func(self):
        while True:
            for i in range(1875):
                if i==0:
                    self.counter=np.array(1)
                else:
                    self.counter=np.append(self.counter,np.array(1))
                flag=self.tf_func()
                if flag==True:
                    return

t=test()
t.counter_func()
```


### Relevant log output

_No response_</details>
Repository: next.js
Issue: router.query is empty in catch all routes when middleware, basePath and trailingSlashes are used.
Labels: bug

### Verify canary release

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

### Provide environment information

    Operating System:
      Platform: linux
      Arch: x64
      Version: #22 SMP Tue Jan 10 18:39:00 UTC 2023
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: 1.22.19
      pnpm: 7.1.0
    Relevant packages:
      next: 13.1.5
      eslint-config-next: 13.1.5
      react: 18.2.0
      react-dom: 18.2.0


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

Middleware / Edge (API routes, runtime), Routing (next/router, next/navigation, next/link)

### Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/adoring-diffie-lllgcy?selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A20%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A20%7D%5D&file=%2Fnext.config.js

### To Reproduce

1) Open Codesandbox
2) In the preview URL bar change the URL from 
`https://lllgcy-3000.preview.csb.app/` to `https://lllgcy-3000.preview.csb.app/de-de/some/`.
3) Watch the console output, or the render output - a double render occurs, first with `route.query === {slug: "some"}` and on the second render with `route.query === {}`.

### Describe the Bug

When using the new middleware with dynamic routes and a config with a `basePath` other than `"/"` and `trailingSlash` option set to `true` all dynamic pages render twice, with some delay between the renders, but on the second render the `router.query` object is empty. 
This is true regardless of whether a `useRouter` hook or the `withRouter` HOC is used. Interestingly enough the rest of the `router` object looks very similar on the second render so `asPath`, `basePath`, `pathname` and `route` are preserved but `query` is not.

- The bug goes away when removing/renaming the middleware.
- The bug goes away when setting `trailingSlash` to `false`.
- The bug goes away when setting the `basePath:"/"` or removing the option entirely
- The bug does not happen on non-dynamic routes.

There is a [closed issue](https://github.com/vercel/next.js/issues/38267) that might be related to this, but the linked PR does not fix this issue.

### Expected Behavior

I would not expect a double render to occur. 
And in case there is a technical reason to re-render I would expect the second render to preserve the `router.query` object.

In our project we use the basePath for i18n naming conventions, we can't disable the `trailingSlash` option,  we need dynamic routes for our product catalogue and we need middleware for multiple things so we can not work around this problem easily and so we can't migrate to Next 13.

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

_No response_

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

_No response_
Repository: rust
Issue: Always show crate name with -Z print-type-sizes
Labels: C-enhancement

Currently it is only shown for foreign crates. Also showing it for local crates will make the output of `RUSTFLAGS="-Z print-type-sizes"` easier to interpret.
Repository: stable-diffusion-webui
Issue: [Feature Request]: Option to offset prompt editing steps
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 ?

I would like to have an option in the ui that offsets the prompt editing steps by one. At the moment, prompt editing steps are off by one (they start at -1 instead of 0). For example, `[a:b:5]` starts including `b` only at the 7th step (so at step 6 if counting from 0) instead of the 6th (so at step 5 if counting from 0).

This makes it hard to understand what my prompts do often, because the indices are off. I'm proposing to create an option for this because the syntax has to be backwards compatible with existing prompts for past generations reproduction. If you have a better idea on how to implement this I'm all ears.

### Proposed workflow

1. Go to settings tab
2. Go to "Prompt Syntax" subtab, or somewhere appropriate
3. check the "0 based prompt editing step indices", or some other appropriate label


### Additional information

_No response_
Repository: pytorch
Issue: Support for VeLO optimizer.
Labels: module: optimizer,triaged,needs research

### 🚀 The feature, motivation and pitch

VeLO: Training Versatile Learned Optimizers by Scaling Up  
https://arxiv.org/abs/2211.09760  
the velo optimizer sames very good, is there any plan to support it?

### Alternatives

_No response_

### Additional context

_No response_

cc @vincentqb @jbschlosser @albanD @janeyx99
Repository: go
Issue: time: update zoneinfo_abbrs on Windows 
Labels: OS-Windows,NeedsFix

[time/zoneinfo_abbrs_windows.go](https://github.com/golang/go/blob/a106defddac515db4d70e1cad162b88dd026deee/src/time/zoneinfo_abbrs_windows.go) has not been updated since go1.14 (in [CL 201378](https://go-review.googlesource.com/c/go/+/201378)).

A few things changed since then, we should generate it again before releasing go 1.21.
We could also do it for go 1.20, but I suppose it is too late.

@alexbrainman @golang/windows
Repository: godot
Issue: Slow debug stepping when there are script properties referencing tilemap nodes
Labels: bug,topic:rendering,topic:editor,performance

### Godot version

4.0.beta15

### System information

windows 10, nvidia graphics

### Issue description

When stepping through lines in the debugger, if the current script has properties referencing tilemap nodes and those tilemaps have a tileset with a big texture (I'm using 1024x1024 but I haven't tested a minimum size), the stepping becomes increasingly slower the more member properties there are that reference that tile map and the more there are TileSetAtlasSources in those tilesets using big textures.

### Steps to reproduce

see attached video:

https://user-images.githubusercontent.com/5783414/215133530-bf3d7e6f-6d1a-469d-baec-f318d8d0a027.mp4


### Minimal reproduction project

[SlowDebugStepWithTileMapNodeMemberProperties.zip](https://github.com/godotengine/godot/files/10520757/SlowDebugStepWithTileMapNodeMemberProperties.zip)

### WorkAround
This bug can be worked around by not having any reference to tilemap nodes. That is, replacing this:
```gdscript
@onready var map:TileMap = $Map
```
with this
```gdscript
@onready var map:int = $Map.get_instance_id()
func get_map()->TileMap: return instance_from_id(map)
```
Unlike the other slow debug step bugs, this bug cannot be worked around by turning on "update continuously" in the editor settings.

### Notes
Just for reference, here are other bug reports about slow debug stepping

https://github.com/godotengine/godot/issues/67696
https://github.com/godotengine/godot/issues/68232
https://github.com/godotengine/godot/issues/72118
Repository: rust
Issue: Tracking Issue for `-Znext-solver`
Labels: A-trait-system,C-tracking-issue,T-types,WG-trait-system-refactor

This is a tracking issue for the next-generation trait solver in rustc. It can be enabled on nightly by using the `-Znext-solver` flag. This work is lead by the @rust-lang/initiative-trait-system-refactor.

### 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.

### Links

Original Types Team MCP: https://github.com/rust-lang/types-team/issues/58
Types Team Tracking Issue: https://github.com/rust-lang/types-team/issues/76
Types Team announcement and Roadmap: https://blog.rust-lang.org/2023/01/20/types-announcement.html
EOY 2023 Update Blog Post: https://blog.rust-lang.org/inside-rust/2023/12/22/trait-system-refactor-initiative.html
2024 Types Team Update Blog Post: https://blog.rust-lang.org/2024/06/26/types-team-update.html
EOY 2024 Update Blog Post: https://blog.rust-lang.org/inside-rust/2024/12/04/trait-system-refactor-initiative.html
Tracking issue for `-Znext-solver=coherence`: #114862

### Milestones and future work

For a complete list of changes, see [the list of merged PRs](https://github.com/rust-lang/rust/pulls?page=19&q=is%3Apr+is%3Amerged+label%3AWG-trait-system-refactor+-label%3Arollup). We also track the decisions we've made - and decisions we still have to make - in https://github.com/rust-lang/trait-system-refactor-initiative/issues. We mostly discuss these issues [on zulip](https://rust-lang.zulipchat.com/#channels/364551/t-types.2Ftrait-system-refactor/general) and in Types Team meetings.

#### Major milestones

- [x] #105661 initial skeleton of the trait solver
- [x] #113317 full independence of the old trait solver implementation
- [x] #113991 initial crater run with `-Znext-solver=coherence`
- [x] #112875 always use next-gen trait solver for `feature(with_negative_coherence)`, which is used while compiling the standard library
- [x] #122747 always use next-gen trait solver in the `non_local_definitions` lint
- [x] #126614 uplift the next-generation trait solver into a separate library
- [x] #121848 (reverted) https://github.com/rust-lang/rust/pull/130654 stabilize `-Znext-solver=coherence` 
- [x] #133502 bootstrap with `-Znext-solver=globally`
- [x] https://github.com/rust-lang/rust/pull/133502#issuecomment-2516183651 initial perf run with `-Znext-solver=globally`
  - [ ] get remaining benchmarks to compile
  - [ ] fix exponential slowdowns
  - [ ] get perf of nearly all benchmarks to be neutral or positive
- [ ] initial crater run with `-Znext-solver=globally`
- [ ] stabilize `-Znext-solver=globally`
Repository: terminal
Issue: White borders are back in 1.17
Labels: Help Wanted,Issue-Bug,Product-Terminal,Priority-3,Area-Theming

> This problem is back in v1.17, I guess due to the recent changes around theming. The grey border is there to start with until you switch to another window and back (presumably it's part of the dark theme and doesn't get repainted until switching). Once you switch back it is white and will stay so even after closing/re-opening.
> 
> Steps to reproduce:
> * Delete settings.json and state.json
> * Open Terminal and switch to light theme
> * Border is grey
> * Alt tab to another window then back again
> * Border is now forever white

_Originally posted by @harristom in https://github.com/microsoft/terminal/issues/6620#issuecomment-1406570765_
Repository: TypeScript
Issue: Internal compiler error: "DataCloneError: Function object could not be cloned."
Labels: Bug,Website

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
DataCloneError: Function object could not be cloned.

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This crashes all versions of TypeScript on the playground

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.9.4#code/C4TwDgpgBAglC8UBCUIA9gQHYBMDOUAwlAPxQAMUAXFAIxA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type A = B extends C ? 0 : 1
```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->

Firefox:

```
DataCloneError: Function object could not be cloned.
```

Chrome:

```
Uncaught (in promise) DOMException: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': function(Kr){return void(Kr.externalModuleIndicator=dn(Kr))} could not be cloned.
    at https://typescript.azureedge.net/cdn/4.9.4/monaco/min/vs/base/worker/workerMain.js:11:383
    at Object.sendMessage (https://typescript.azureedge.net/cdn/4.9.4/monaco/min/vs/base/worker/workerMain.js:22:17680)
    at L._send (https://typescript.azureedge.net/cdn/4.9.4/monaco/min/vs/base/worker/workerMain.js:22:15521)
    at https://typescript.azureedge.net/cdn/4.9.4/monaco/min/vs/base/worker/workerMain.js:22:14591
```

Safari:

```
Unhandled Promise Rejection: DataCloneError: The object can not be cloned.
```

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->

I expected the TypeScript compiler to not crash.
Repository: vscode
Issue: Editor mouse selection scrolling isn't smooth
Labels: bug,editor-core

![Recording 2023-01-27 at 09 05 27](https://user-images.githubusercontent.com/2644648/215149405-7d4b9f6b-94ce-4177-88d9-594f6a512742.gif)

Steps:

* have an editor with content that goes off the screen
* select some text and move your mouse in the direction of off screen

I expect a smooth scrolling experience where the editor smoothly scrolls to the right so I can select the text I want.

What actually happens is that it just jumps all the way to the end.