sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: bitcoin
Issue: Continuous benchmark tracking
Labels: Brainstorming,Tests,Resource usage

It would be beneficial to have continuous tracking of our benchmark tests, because regressions (or unexpected improvements) otherwise go undetected (at least for a while). Afaict currently, the only benefit of our benchmarking tests is to evaluate changes as they are being proposed but imo that only gives us ~50% of the benefit that benchmarks can provide.

I am imagining this to be a separate service (maybe integrated with @DrahtBot) that regularly runs the benchmarks in an environment configured for benchmarking. Regressions could be reported by the service through opening issues or sending emails. Additionally, a website that presents the benchmark data with some pretty graphs would be nice ([example from firefox's infra](https://treeherder.mozilla.org/perfherder/graphs?highlightAlerts=1&highlightChangelogData=1&highlightCommonAlerts=0&series=mozilla-central,3405208,1,13&timerange=31536000)).

Setting this up in a way that it is easy to replicate would be very beneficial.
Repository: vscode
Issue: Git - Prompt to stash or rebase uncommitted changes on checkout
Labels: feature-request,git

<!-- ⚠️⚠️ 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. -->

A feature to prompt to stash or rebase uncommitted changes on checkout

_Enhancement of #86668_

## Exemple

- **[GitHub Desktop](https://docs.github.com/en/desktop/making-changes-in-a-branch/managing-branches-in-github-desktop#switching-between-branches:~:text=If%20you%20have%20saved%2C%20uncommitted%20changes%2C%20in%20the%20%22Switch%20Branch%22%20window%2C%20select%20Leave%20my%20changes%20on%20CURRENT%2DBRANCH%20or%20Bring%20my%20changes%20to%20NEW%2DBRANCH%2C%20then%20click%20Switch%20Branch.)**
[![enter image description here](https://i.stack.imgur.com/ufhD3.png)](https://docs.github.com/en/desktop/making-changes-in-a-branch/managing-branches-in-github-desktop#switching-between-branches:~:text=If%20you%20have%20saved%2C%20uncommitted%20changes%2C%20in%20the%20%22Switch%20Branch%22%20window%2C%20select%20Leave%20my%20changes%20on%20CURRENT%2DBRANCH%20or%20Bring%20my%20changes%20to%20NEW%2DBRANCH%2C%20then%20click%20Switch%20Branch.)
[UI Source Code](https://github.com/desktop/desktop/blob/555274f8818eb26886575fbcfe2878422879d226/app/src/ui/stash-changes/stash-and-switch-branch-dialog.tsx#L97)
Repository: tauri
Issue: [bug] Popup Window not open issue in macos
Labels: type: bug,platform: macOS,status: needs triage

### Describe the bug

I load the web URL into the Tauri app with the below code:

```` 
fn main() {
    use tauri::Manager;
  tauri::Builder::default()
    .setup(|app| {
        app.get_window("main").unwrap().eval(&format!("window.location.replace('{}')", "https://mail.google.com/mail/u/0/")).unwrap();
      Ok(())
    }).run(tauri::generate_context!())
    .expect("error running tauri app");
}

````

--> In the window system it's showing the popup window on click but the same code not working in the macOS system.
--> It's not showing any error in the console and terminal.
--> I need to open a popup like the below-attached screenshot.
--> I load the web URL so nothing to change in the open popup code.

![image](https://user-images.githubusercontent.com/118716238/226365868-095a6d68-0804-471d-819c-c530173a0dd8.png)


### Reproduction

1. Run the app.
2. click on the open popup button.


### Expected behavior

![image](https://user-images.githubusercontent.com/118716238/226365258-77c5927c-38a4-45f9-b1a8-55ef78dd60b8.png)


### Platform and versions

```text
Environment
  › OS: Mac OS 13.2.0 X64
  › Node.js: 16.17.0
  › npm: 8.15.0
  › pnpm: Not installed!
  › yarn: 1.22.19
  › rustup: 1.25.2
  › rustc: 1.68.0
  › cargo: 1.68.0
  › Rust toolchain: stable-aarch64-apple-darwin 

Packages
  › @tauri-apps/cli [NPM]: 1.2.3
  › @tauri-apps/api [NPM]: Not installed!
  › tauri [RUST]: 1.2.4,
  › tauri-build [RUST]: 1.2.1,
  › tao [RUST]: 0.15.8,
  › wry [RUST]: 0.23.4,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../src
  › devPath: ../src

App directory structure
  ├─ node_modules
  ├─ src-tauri
  ├─ .vscode
  └─ src
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: storybook
Issue: [Bug]: Neither '@/mixins/window.vue' nor '@/mixins/window.js(x)' or '@/mixins/window/index.js(x)' or '@/mixins/window/index.ts(x)' could be found in '/Users/something/Desktop/something/repos/vue3-playground/packages/storybook/src/components/Modules/MainNav'
Labels: bug,help wanted,vue3,builder-vite,sev:S3

### Describe the bug

When I try to import a js file that exists inside the src/ folder it seems to not be bundled or available to storybook in the client.



### To Reproduce

![image](https://user-images.githubusercontent.com/47485736/226376868-f12790f1-b754-45e5-adbc-a12c5d8f6e15.png)
Create a file structure like this in storybook 7 and put js files inside it. 

Type to import them in a vue component with the following alias: "@/mixins/file.js".

You get the following error: 
![image](https://user-images.githubusercontent.com/47485736/226377334-0af05269-65d2-44d2-b3d0-8f0b7376ef33.png)
![image](https://user-images.githubusercontent.com/47485736/226377368-bdcdfce5-1a85-4012-abd8-dd6dd48f91e2.png)


### System

```shell
Environment Info:

  System:
    OS: macOS 13.2.1
    CPU: (12) x64 Apple M2 Pro
  Binaries:
    Node: 18.14.0 - ~/.nvm/versions/node/v18.14.0/bin/node
    npm: 9.3.1 - ~/.nvm/versions/node/v18.14.0/bin/npm
  Browsers:
    Chrome: 111.0.5563.64
    Safari: 16.3
  npmPackages:
    @storybook/addon-actions: ^7.0.0-beta.47 => 7.0.0-rc.5
    @storybook/addon-essentials: ^7.0.0-beta.47 => 7.0.0-rc.5
    @storybook/addon-interactions: ^7.0.0-beta.47 => 7.0.0-rc.5
    @storybook/addon-links: ^7.0.0-beta.47 => 7.0.0-rc.5
    @storybook/testing-library: ^0.0.14-next.1 => 0.0.14-next.1
    @storybook/vue3: ^7.0.0-beta.47 => 7.0.0-rc.5
    @storybook/vue3-vite: ^7.0.0-beta.47 => 7.0.0-rc.5
```


### Additional context

_No response_
Repository: flutter
Issue: Re enable java integration tests on Espresso plugin
Labels: a: tests,team,package,team-ecosystem,P2,triaged-ecosystem

Discovered as part of https://github.com/flutter/packages/pull/3367/
The test file 
https://github.com/flutter/packages/blob/74fd094884fe97bd04eb461e6b96ea6eda11a3b2/packages/espresso/example/android/app/src/androidTest/java/com/example/MainActivityTest.java was found to be broken on main. This happened because the tooling was excluding integration tests from running. 

This ticket tracks enabling java integration tests and adding back the functionality covered by the deleted tests.
Repository: rust
Issue: bootstrap: Ensure that all Steps are exercised in `--dry-run`
Labels: A-testsuite,E-help-wanted,T-bootstrap,E-medium

Right now, we have several steps that just return immediately when dry_run is enabled:
https://github.com/rust-lang/rust/blob/c90eb4825a9faca0d6317292a452859f00d5b786/src/bootstrap/setup.rs#L117-L118
https://github.com/rust-lang/rust/blob/c90eb4825a9faca0d6317292a452859f00d5b786/src/bootstrap/compile.rs#L473-L474
https://github.com/rust-lang/rust/blob/c90eb4825a9faca0d6317292a452859f00d5b786/src/bootstrap/compile.rs#L1059-L1060

That decreases how useful the --dry-run flag is, and also means if we moved the `sanity.rs` checks to individual steps, as suggested in https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/--all-platforms.20flag.20for.20.2E.2Fx.20check/near/343061406, that not all checks will be run. We should add back the assertion that no new steps are registered after the dry_run is performed. That assertion was removed in https://github.com/rust-lang/rust/pull/48913/commits/184d3bca6cc1ac2023bbd723223d1a9bd4d4380b, although I'm not sure why it was flaky - the first thing to do here would be to investigate that bug.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"KittyBorgX"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: pytorch
Issue: Implement `torch.distributions.Poisson.cdf()`
Labels: module: distributions,feature,triaged

### 🚀 The feature, motivation and pitch

I'm currently working with Tobit Poisson loss functions, and I'm lacking the ability to calculate the Poisson CDF as part of a loss function. Currently the `cdf` function for the Poisson distribution isn't implemented.

### Alternatives

I've tried using scipy to do this, but this doesn't go well when calculating grads. I'm currently using a very hacky workaround, which seems unnecessary. 

### Additional context

If any efficient workarounds are known, feel free to share them here :)
I'm currently using `torch.special.gammaincc(torch.floor(k+1),  lambda)`

cc @fritzo @neerajprad @alicanb @nikitaved
Repository: material-ui
Issue: [LoadingButton] Should be able to show loading indicator if onClick returns a promise
Labels: new feature,waiting for 👍,package: lab,component: LoadingButton

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

If the onClick handler returns a promise the LoadingButton could set its own internal state to show a loading indicator despite the loading prop value. Also, this behavior could be enabled/disabled by default and overwritten with a prop like enableOnClickPromiseCheck or something like that

### Examples 🌈

I don't expect this work as it is, just drafted something quickly based on the component source code, this example does not consider the ability to enable/disable this behavior since it may break existing users' implementations. 

```jsx
const LoadingButton = props => {
  const [_loading, setLoading] = useState(false);
  const { onClick, loading = false, disabled = false, ...other } = props;

  const ownerState = {
    ...props,
    loadingIndicator,
    loadingPosition,
    variant,
    loading: _loading || loading,
    disabled: disabled || _loading || loading,
  };

  const loadingButtonLoadingIndicator = ownerState.loading ? (
    <LoadingButtonLoadingIndicator className={classes.loadingIndicator} ownerState={ownerState}>
      {loadingIndicator}
    </LoadingButtonLoadingIndicator>
  ) : null;

  const handleClick = async (...args)=> {
    setLoading(true);
    await onClick?.(...args);
    setLoading(false);
  };

  return <LoadingButtonRoot onClick={handleClick} disabled={ownerState.disabled} {...other} />;
};
```

### Motivation 🔦

In my projects, I used to create my own AsyncButton every time, with my own progress indicator and all that stuff. When LoadingButton was added to the lab package I thought I could get rid of that but it only made it simple, I don't need to maintain the loading indicator styling and all that stuff but I still need to wrap my handler to achieve the promise like behavior

### CodeSandbox 🧊
https://codesandbox.io/s/mui-async-loading-button-demo-g1fm6e
Repository: neovim
Issue: Better default text object motions
Labels: enhancement,syntax,treesitter,mappings

### Problem

Currently we have these:

```
==============================================================================
5. Text object motions					*object-motions*

							*(*
(			[count] |sentence|s backward.  |exclusive| motion.

							*)*
)			[count] |sentence|s forward.  |exclusive| motion.

							*{*
{			[count] |paragraph|s backward.  |exclusive| motion.

							*}*
}			[count] |paragraph|s forward.  |exclusive| motion.

							*]]*
]]			[count] |section|s forward or to the next "{" in the
			first column.  When used after an operator, then also
			stops below a "}" in the first column.  |exclusive|
			Note that |exclusive-linewise| often applies.

							*][*
][			[count] |section|s forward or to the next '}' in the
			first column.  |exclusive|
			Note that |exclusive-linewise| often applies.

							*[[*
[[			[count] |section|s backward or to the previous "{" in
			the first column.  |exclusive|
			Note that |exclusive-linewise| often applies.

							*[]*
[]			[count] |section|s backward or to the previous "}" in
			the first column.  |exclusive|
			Note that |exclusive-linewise| often applies.

```

Having a bunch of motions centred around the sentences, paragraphs and `{}` (aka "section") characters obviously isn't great.

### Proposal

Use Treesitter to define `@block` (instead of paragraph) and `@section` (instead of section) which these mappings can be used to navigate.

Other suggestions welcome.

Related: #8544
Repository: rust
Issue: Debuginfo does not describe enums with uninhabited variants correctly
Labels: A-debuginfo,T-compiler,C-bug

I tried this code:

```rust
enum Uninhabited { }

fn main() {
    let x = Option::<Uninhabited>::None;

    foo(x);
}

#[inline(never)]
fn foo<T>(_: T) { }
```

I expected to see this happen: gdb reports that `x` is `None`.

Instead, this happened: gdb reports that `x` is `Some`:

```
$ gdb ./uninhabited_enum_test
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
...
(gdb) break uninhabited_enum_test.rs:4
Breakpoint 1 at 0x8491: file uninhabited_enum_test.rs, line 6.
(gdb) r
Starting program: /tmp/uninhabited_enum_test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, uninhabited_enum_test::main () at uninhabited_enum_test.rs:6
6           foo(x);
(gdb) info locals
x = core::option::Option<uninhabited_enum_test::Uninhabited>::Some(uninhabited_enum_test::Uninhabited)
```

### Meta
`rustc --version --verbose`:
```
rustc 1.68.0 (2c8cc3432 2023-03-06)
binary: rustc
commit-hash: 2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74
commit-date: 2023-03-06
host: x86_64-unknown-linux-gnu
release: 1.68.0
LLVM version: 15.0.6
```

Also affects beta and nightly.
Repository: pytorch
Issue: [FSDP][optim_state_dict] Need more comprehensive tests for optim_state_dict interface
Labels: oncall: distributed,triaged,module: fsdp

### 🚀 The feature, motivation and pitch

FSDP optim_state_dict has many different APIs that confuse users a lot. In a recent PR, the two new APIs have been proposed to consolidate all the use cases -- `optim_state_dict` and `optim_state_dict_to_load`. However, current unittests do not have enough coverage of the new interfaces. More test coverage is required for `state_dict_type` and `optim_state_dict` and `optim_state_dict_to_load`.

https://github.com/pytorch/pytorch/pull/97110 fixes a breakage.
https://github.com/pytorch/pytorch/pull/96534 introduce some tests but need more.

cc., @wz3

### Alternatives

_No response_

### Additional context

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: rust
Issue: Natvis not embedded in staticlib
Labels: A-debuginfo,T-compiler,O-windows-msvc,WG-debugging

Rust embeds natvis information in PDBs by default. However, due to https://github.com/rust-lang/rust/issues/89986, this doesn't happen with staticlibs. This makes debugging code linked statically into a C++ project harder.

I created a mostly-minimal reproduction of the issue here: https://github.com/obsgolem/rust-staticlib-issue-repro

To reproduce, make sure you are on a Windows machine with VS installed. Then do roughly the following:
```
cd cmake_test
mkdir build
cd build
cmake ..
```
Once this is done, open the Visual Studio solution and build all in Debug. Set the startup project to test, then set a breakpoint in `lib.rs:5`. When you hit the breakpoint, note that the debugger doesn't recognize the layout of the `Vec`.

To demonstrate the expected behavior, remove the `staticlib` entry from `CMakeLists.txt:14` and change the `crate-type` in `Cargo.toml` to `cdylib`. Then, following a clean build, you will find the debugger will correctly pick up the natvis for `Vec`.
Repository: flutter
Issue: Remove fuchsia support from tools.
Labels: engine,platform-fuchsia,P2,team-engine,triaged-engine

Just a stub for issue discussed in triage. Importantly, the device discovery tools.
Repository: flutter
Issue: Drawing text with a non-opaque color can sometimes reveal internal glyph overlaps
Labels: engine,a: typography,P3,team-engine,triaged-engine

Recently we fixed some bugs in the engine where applying an opacity widget to text might cause internal glyph overlaps to reveal themselves (see https://github.com/flutter/flutter/issues/122266 for example). Rather than applying such opacity as a saveLayer, the engine had been applying it by changing the color used to render the text to a less-opaque version.

While it reduced the number of developer surprises to not equate "alpha saveLayer" with "translucent coloring" in that case, a developer might choose to use a translucent color themselves and they'd see the same overlaps. Such behavior might surprise them as the same result does not occur when they apply a translucent color to a path rendering that has overlaps in it.

We should probably treat any given text operation as an atomic rendering and protect it from overlap similar to how paths are protected from overlap effects during rendering (not similar by way of implementation, but similar by way of expected output).
Repository: flutter
Issue: InkResponse.onSecondary* docs are not clear
Labels: framework,f: material design,d: api docs,team-design,triaged-design

Added in #119058, the onSecondary* properties all mention being activated by the secondary button. What is the secondary button? This should explain more, or link to associated documentation on the mysterious secondary button. 

Noticed in #123036.

Note: I know I reviewed and approved this PR. Outside of the context of that PR, I realized looking at another PR that it may be kind of confusing for folks who don't know what the secondary button is. 🙃
Repository: vscode
Issue: Ability to ignore `star-activation` warning
Labels: feature-request,extensions-development

I would like to have a setting in the workspace `.vscode/settings.json` for a project that disables the `star-activation` warning.  We are developing an accessibility tool, so our extension needs to be available as soon as possible, otherwise VSCode is not usable to our users who have accessibility needs.

The `star-activation` warning leads to unnecessary noise in our problem panel, and makes it more difficult to ensure that we keep a clean slate of warnings

I know there is the `--allow-star-activation` flag to `vsce`, but that does not disable the lint warning appearing in the VSCode problems panel
Repository: tauri
Issue: [feat] Semver Syncing
Labels: type: feature request

### Describe the problem

Dramatic reenactment of a potential future Discord thread: 

> Woot plugins! Woot packages! Oh wait, more packages. Errrrmmm what version goes with what? Do I have the right Tauri CLI? Wait, why is the CLI and the API version different? Oh, that's how it's supposed to be. But I'm getting an error from the `camera` plugin I just added. Ahhh I need to update the Tauri rust dependency to be compatible!

The plugin system is exciting but it does bring more configuration options and more complexity with that.

There are 2 main issues that I see happening:
1. Support is tough because we have to keep in mind what versions are released and what work with each other
2. Automated checks (maybe via a future CLI addition) are tough because we'd have to create and maintain a mapping of versions

### Describe the solution you'd like

Begin versioning all packages to the same major and minor versions. Patches are fine to bump independently and still fairly easy to explain and test (if major and minor match you're fine). 

- This would include user-facing Crates and NPM packages (such as `tauri`, `tauri-cli`, tauri-api` etc.)
- Plugins (in the workspace such as the upcoming camera plugin: https://github.com/tauri-apps/plugins-workspace/pull/260)
  - Not sure about additional plugins such as `log` `localhost`, etc.
- I'm not sure if more "internal" tools would need to be included in this (such as `tauri-build`, `tauri-codegen`, `tauri-macros`, etc.)

### Alternatives considered

- Keep the versioning as-is: Difficult to support and DX issues as outlined above
- Match major.minor.patch: A bit too rigid. I can't think of a reason to bump all packages just for a patch update. 

### Additional context

_No response_
Repository: vscode
Issue: How to know which extension is asking for interaction
Labels: feature-request,quick-pick

<!-- ⚠️⚠️ 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. -->
When I opened my vscode, there's a dialog opened on the top center of the VSCode window that asking for something, in this case asking for providing a new PAT, but I would like to know who (which extension) is asking for this.
Is it possible to automatically add the extension name in the dialog windows ? Maybe in the form of a prefix like `[extension name] message`
It would be nice to add this feature at vscode core level, instead of asking the extension authors to add it in their extensions.

![image](https://user-images.githubusercontent.com/13083856/226460970-2118aac6-1074-4109-9007-c8fb5c492099.png)

If we have someting like the notification center at the lower right corner, it would be great enough:
![image](https://user-images.githubusercontent.com/13083856/226848624-2d31d366-3efe-4953-a5c4-f291b34078bc.png)
Repository: TypeScript
Issue: ...args should not be readonly within function body
Labels: Suggestion,Experience Enhancement

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

readonly parameter inferred tuple array args variadic

### 🕗 Version & Regression Information

- This is the behavior in every version I tried
### ⏯ Playground Link

[Playground Link](https://www.staging-typescript.org/play?ts=5.0.2#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXzCgggDFUAeAFXhAA8MRVgBneOKYPCAT3ilW4BtALoA+ABSwA5swBc8SgBokqeeIB0m6XIUBKeAF5R8AG44swXfLMWA3AFgAUE9CRYCMHmYZ4WVAAdkDHl2TlQeeG8YPykRB2dHQmIycT9AjGUNLRgZfSN4AG8neBK+HOZ40vgAemr4AD0AficAX10nDsdXaDgkNExcfCTSVAA5PABxRhBosElykJAOLl4omJFlRFV4LPVtReXw1Yxo1FjhPOMbS2tzYHinYbJx1CnUGaw5tKDMzT3yy6FYqlbSVUq1BrNRxtJxAA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
declare function callFn<T extends readonly any[]>(args: T, fn: (...args: T) => void): void;

declare const input: readonly string[];

callFn(input, (...args) => {
    args; // readonly string[] ?
})

declare function callFnNonGeneric(args: readonly string[], fn: (...args: readonly string[]) => void): void;

callFnNonGeneric(input, (...args) => {
    args; // readonly string[] ?
})
```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->

`...args` is readonly.

### 🙂 Expected behavior

`...args` is not readonly.

When this function is called, the input will be a brand new array which can be modified without affecting the caller:

```
> const fn = (...args) => { args[0] = "oops" }
undefined
> const arr = ["some", "values"]
undefined
> fn(...arr)
undefined
> arr
[ 'some', 'values' ]
```

Split out of https://github.com/microsoft/TypeScript/pull/53258#issuecomment-1470970487

The "fix" here is to strip readonly from variadic args (at the top level). This also means the fix in #53258 can be reverted (as the real fix can be more general).