sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: puppeteer
Issue: [Bug]: Timezone override is already in effect
Labels: feature,confirmed

### Bug description

Steps to reproduce the problem:

1. Call `page.emulateTimezone(timeZone)` twice in a browser session.

See also: https://github.com/alixaxel/chrome-aws-lambda/issues/137

### Puppeteer version

14.4.1

### Node.js version

17.5.0

### npm version

8.4.1

### What operating system are you seeing the problem on?

Linux

### Relevant log output

```shell
/node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:268
                error: new Errors_js_1.ProtocolError(),
                       ^

ProtocolError: Protocol error (Emulation.setTimezoneOverride): Timezone override is already in effect
    at /node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:268:24
    at new Promise (<anonymous>)
    at CDPSession.send (/node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:264:16)
    at next (/node_modules/puppeteer-extra-plugin-stealth/evasions/sourceurl/index.js:34:41)
    at CDPSession.send (/node_modules/puppeteer-extra-plugin-stealth/evasions/sourceurl/index.js:67:18)
    at Page.emulateTimezone (/node_modules/puppeteer/lib/cjs/puppeteer/common/Page.js:1586:67)
    ...
}
```
Repository: terminal
Issue: Include Windows Terminal in Windows Sandbox
Labels: Issue-Feature,Product-Terminal,Tracking-External

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement

Currently, Windows Sandbox does not come with Windows Terminal, it would be nice to have it installed in there by default.

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
Repository: godot
Issue: Collisions between `ConcavePolygonShape3D` and `WorldBoundaryShape3D` are not implemented
Labels: documentation,topic:physics,topic:3d

### Godot version

4.0-alpha14

### System information

any

### Issue description


https://user-images.githubusercontent.com/229837/187175720-8555d2d8-7a7a-43ee-bae8-774f282859b8.mp4



### Steps to reproduce

1. Create a `StaticBody3D` node with a `WorldBoundaryShape3D` collision shape.
2. Create a `CharacterBody3D` node with the default script and a `ConcavePolygonShape3D` collision shape (e.g. generate it from a mesh).
3. Place the character on top of the world boundary.
4. Play the scene. Expect the character to stay on top of the world, watch it fall through.

### Minimal reproduction project

[WorldBoundaryCollisionTest.zip](https://github.com/godotengine/godot/files/9443662/WorldBoundaryCollisionTest.zip)
Repository: ant-design
Issue: <Dropdown arrow trigger={['contextMenu']}> can't show arrow
Labels: 🐛 Bug,help wanted,Inactive

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/you-jian-cai-dan-antd-4-22-8-forked-kntbec)

### Steps to reproduce

null

### What is expected?

show arrow

### What is actually happening?

not show arrow

| Environment | Info |
| --- | --- |
| antd | 4.22.8 |
| React | 16.14 |
| System | Mac |
| Browser | Chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: storybook
Issue: Telemetry environment variable not being used in Angular builder
Labels: bug,needs triage

**Describe the bug**
Building the storybook in an Angular application using the Storybook `@storybook/angular:build-storybook` builder ignores the `STORYBOOK_DISABLE_TELEMETRY` variable. Since the builder does not have an option to disable telemetry itself, the only way to disable telemetry is currently through the CoreConfig.

**To Reproduce**
Create a plain angular project and add storybook to it. Set the environment variable `STORYBOOK_DISABLE_TELEMETRY=1`. Run `yarn build-storybook`. Telemetry information are still being send.

**System**

Environment Info:
```
  System:
    OS: macOS 12.2.1
    CPU: (10) arm64 Apple M1 Pro
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 3.2.1 - ~/.nvm/versions/node/v16.14.0/bin/yarn
    npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 104.0.5112.101
    Safari: 15.3
  npmPackages:
    @storybook/addon-a11y: 6.5.10 => 6.5.10 
    @storybook/addon-docs: 6.5.10 => 6.5.10 
    @storybook/addon-essentials: 6.5.10 => 6.5.10 
    @storybook/addon-interactions: 6.5.10 => 6.5.10 
    @storybook/addon-viewport: 6.5.10 => 6.5.10 
    @storybook/addons: 6.5.10 => 6.5.10 
    @storybook/angular: 6.5.10 => 6.5.10 
    @storybook/api: 6.5.10 => 6.5.10 
    @storybook/builder-webpack5: 6.5.10 => 6.5.10 
    @storybook/components: 6.5.10 => 6.5.10 
    @storybook/manager-webpack5: 6.5.10 => 6.5.10 
    @storybook/source-loader: 6.5.10 => 6.5.10 
    @storybook/theming: 6.5.10 => 6.5.10 
```

**Additional context**
This problem is especially problematic in CI. Our proxy blocks the telemetry requests (this is also the reason I found this bug, took me quite a while) and the build waits 10 minutes to time out these requests. This effectively delays our pipeline by 10 minutes. 
Configuring the telemetry through CoreConfig is a workaround, but we want to let our developers decide themselves if they want to send telemetry data and only restrict it globally in CI. Using the CoreConfig disables telemetry everywhere.
Repository: go
Issue: fmt,sync/atomic: `fmt` functions should allow integer verbs for atomic integers
Labels: NeedsDecision,compiler/runtime

### What version of Go are you using (`go version`)?

`go 1.19`


### Does this issue reproduce with the latest release?

Yes.


### What operating system and processor architecture are you using (`go env`)?

https://go.dev/play/p/jHX7pcphAmV


### What did you do?

Format an `atomic.Int32` using the `%d` verb.


### What did you expect to see?

Since an `atomic.Int32` “[is an atomic `int32`](https://pkg.go.dev/sync/atomic@go1.19#Int32)”, I expected that the `fmt` verbs that apply for `int32` should generate the same representation when applied to an `atomic.Int32`.

Or, if the `%d` verb is not expected to work in the same way that it does for an `int32`, I expect the `atomic` package docs to note that detail.


### What did you see instead?

Applying the `%d` verb to an `atomic.Int32` prints it as a struct, not an integer:
```
{{} 42}
```

(CC @robpike @martisch)
Repository: storybook
Issue: In Angular component, "arrow methods" become strings
Labels: bug,needs triage

**Describe the bug**
In Angular component, "arrow methods" become strings.

**To Reproduce**
Any Component with an "arrow method":
`@Component({
  selector: 'bug',
  template: '<button click="click()"></button>',
})
export class BugComponent {
  logHello = () => { console.log('Hello') }
  click() { this.logHello() }
}`


**Additional context**
In runtime this.logHello will be a string "() => {...}"
happens here:
![image](https://user-images.githubusercontent.com/24486205/187229785-2a12de6e-9e55-4789-974f-3456afb59568.png)
Repository: pytorch
Issue: Attach execution time to each node in an fx trace
Labels: triaged,fx,hacktoberfest

## Proposal description

A proposal for HacktoberFest. 
The idea is to plot a graph of a model that shows the execution time of each node or op.

Most likely, this project should be implemented as a standalone repo rather than a feature in PyTorch.

## Background

TBD

## Details
You would need to go over:
- torch.fx Documentation: https://pytorch.org/docs/stable/fx.html
- torch.fx Profiler Tutorial: https://pytorch.org/tutorials/intermediate/fx_profiling_tutorial.html
- Printing torch.fx Graph: https://github.com/pytorch/pytorch/blob/aec0f98e7088b68ba119becffd4fdbd64b4d75a8/torch/fx/passes/graph_drawer.py#L98C1-L120C16

cc @ezyang @SherlockNoMad @soumith
Repository: go
Issue: proposal: go/build: export an API to identify which tags are implied by a given GOOS
Labels: Proposal

For #51572 we added a `unix` build constraint that implicitly applies to all Unix-like `GOOS` values.

That is in addition to some `GOOS` chains that already existed:
* `android` implies `linux`
* `ios` implies `darwin`
* `illumos` implies `solaris`

The number of such chains that already exist suggests that we may end up adding further chains in the future, and if we add new `GOOS` values in the future they may also imply `unix`, `linux`, or some other constraint.

Currently we have duplicated the logic for these implicit chains of constraints in at least three places: `go/build`, `cmd/go`, and `cmd/dist`. That suggests to me that authors of Go tools in general are likely to also need this information.

I propose that we add one or more functions to either the `go/build` package or the `go/build/constraints` package to resolve these chains. The simplest API I can think of for this would be something like:

```go
// OSImpliedTags reports additional build tags that are implicitly satisfied
// by the given GOOS value when evaluating build constraints.
//
// The returned slice may be nil, and does not include the GOOS value itself.
func ImpliedOSTags(goos string) []string {
	var tags []string
	switch goos {
	case "android":
		tags = append(tags, "linux")
	case "ios":
		tags = append(tags, "darwin")
	case "illumos":
		tags = append(tags, "solaris")
	}
	if unixOS[goos] {
		tags = append(tags, "unix")
	}
	return tags
}
```
Repository: pytorch
Issue: Pytorch gets small bias on the result of different types of divisors while doing floating point division.
Labels: module: numerical-stability,module: cuda,triaged

### 🐛 Describe the bug
results are different, which may arise from rounding.

```python
a1 = torch.tensor(858.8350830078125, dtype=torch.float32).cuda()/100.0

a2 = torch.tensor(858.8350830078125, dtype=torch.float32).cuda()/torch.tensor(100.0).cuda()

print(a1 - a2)
# out: tensor(-9.5367e-07, device='cuda:0')
```

### Versions

python: 3.8.10
pytorch: 1.8.1+cu111


While using tensorflow, the results are equal.

```python
with tf.device('/GPU:0'):
    a1 = tf.constant([858.8350830078125], dtype=tf.float32) /100.0
    a2 = tf.constant([858.8350830078125], dtype=tf.float32) / tf.constant(100.0, dtype=tf.float32)
    print(a1 - a2)

# out: tf.Tensor([0.], shape=(1,), dtype=float32)
```

cc @ngimel
Repository: flutter
Issue: Allow debugDefaultTargetPlatformOverride to be resetted with addTearDown
Labels: a: tests,framework,has reproducible steps,P3,found in release: 3.0,found in release: 3.1,team-framework,triaged-framework

```dart
void main() {
  testWidgets('reset debugDefaultTargetPlatformOverride with tearDown', (tester) async {
    debugDefaultTargetPlatformOverride = TargetPlatform.macOS;
    addTearDown(() {
      debugDefaultTargetPlatformOverride = null;
    });
  });
}
```

produces
```
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test:
The value of a foundation debug variable was changed by the test.

When the exception was thrown, this was the stack:
#0      debugAssertAllFoundationVarsUnset.<anonymous closure> (package:flutter/src/foundation/debug.dart:30:7)
#1      debugAssertAllFoundationVarsUnset (package:flutter/src/foundation/debug.dart:32:4)
#2      TestWidgetsFlutterBinding._verifyInvariants (package:flutter_test/src/binding.dart:861:12)
#3      AutomatedTestWidgetsFlutterBinding._verifyInvariants (package:flutter_test/src/binding.dart:1274:11)
#4      TestWidgetsFlutterBinding._runTestBody (package:flutter_test/src/binding.dart:848:7)
<asynchronous suspension>

The test description was:
  reset debugDefaultTargetPlatformOverride with tearDown
════════════════════════════════════════════════════════════════════════════════════════════════════
```

I was expecting `addTearDown` to be the correct solution because setting the override to `null` might not be executed at the end of the test when the test fails.

In fact - without `addTearDown` - all remaining tests will fail with the exception above when this test fails, because it never executes `debugDefaultTargetPlatformOverride = null;`.

```dart
void main() {
  testWidgets('reset debugDefaultTargetPlatformOverride with tearDown', (tester) async {
    debugDefaultTargetPlatformOverride = TargetPlatform.macOS;
    // ... test implementation
	expect(true, isFalse);
	
    // might not be called
    debugDefaultTargetPlatformOverride = null;
  });

  testWidgets('default target platform is android', (tester) async {
    // fails with exception although this test is 100% correct
    expect(true, isTrue);
  });
}
```

### How to fix

`_verifyInvariants` should be called after executing all `addTearDown`.

---

```
[✓] Flutter (Channel master, 3.1.0-0.0.pre.2434, on macOS 12.5.1 21G83
    darwin-arm, locale en-DE)
    • Flutter version 3.1.0-0.0.pre.2434 on channel master at
      /opt/homebrew/Caskroom/flutter/3.0.4/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c8569b6e98 (6 days ago), 2022-08-23 13:50:09 -0700
    • Engine revision c9d0a01281
    • Dart version 2.19.0 (build 2.19.0-127.0.dev)
    • DevTools version 2.16.0

```
Repository: go
Issue: x/crypto/ssh: support server-side Diffie-Hellman Group Exchange
Labels: Proposal,Proposal-Accepted,Proposal-Crypto

Support for Diffie-Hellman Group Exchange was proposed and added in the linked proposal: https://github.com/golang/go/issues/17230

This was marked as closed and completed.

However, the PR that actually closed and completed this only implemented client-side kex. It did not implement server-side; only a minimal implementation to allow tests for the client-side to pass. See PR https://go-review.googlesource.com/c/crypto/+/174257 and commit https://github.com/golang/crypto/commit/57b3e21c3d5606066a87e63cfe07ec6b9f0db000. 

I posit that the original issue should not have been marked as closed and completed because it was not truly completed as the Diffie-Hellman Group Exchange is still not fully supported.
Repository: go
Issue: cmd/go: go get <current package> gives arcane error
Labels: NeedsInvestigation,GoCommand,modules

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
go version
go version go1.18.5 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?



### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/$ME/Library/Caches/go-build"
GOENV="/Users/$ME/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/$ME/dev/pkg/mod"
GONOPROXY="github.com/$EMPLOYER*"
GONOSUMDB="github.com/$EMPLOYER*"
GOOS="darwin"
GOPATH="/Users/$ME/dev"
GOPRIVATE="github.com/$EMPLOYER*"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.18.5/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.18.5/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18.5"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/$ME/dev/src/github.com/$EMPLOYER/$REPO/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lx/c2s6byr55blfmt03c9zhhmv00000gn/T/go-build3003361518=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?
was trying a command in the wrong cwd and the error lead me to think my command was wrong, not the directory... An updated output could help. 

```bash
cd $GOPATH/src/github.com/$EMPLOYER/$REPO
go get github.com/$EMPLOYER/$REPO
```
--> 

```bash
go get github.com/$EMPLOYER/$REPO
go: github.com/$EMPLOYER/$REPO: invalid github.com import path "github.com/$EMPLOYER"

go get  github.com/$EMPLOYER/$REPOT@latest
go: can't request version "latest" of the main module (github.com/$EMPLOYER/$REPO)
```
### What did you expect to see?
I presume this is because you cannot import a module into itself? If so it might be helpful to emit a message that indicates a hint that you cannot do that 
eg:
```bash
go get github.com/$EMPLOYER/$REPO
go: github.com/$EMPLOYER/$REPO: cannot import module into itself

go get  github.com/$EMPLOYER/$REPO@latest
go: github.com/$EMPLOYER/$REPO: cannot import module into itself
```


### What did you see instead?
```
go: github.com/segmentio/personas-utils: invalid github.com import path "github.com/$EMPLOYER"

go: can't request version "latest" of the main module (github.com/$EMPLOYER/$REPO)
```

Happy to help with a PR if we agree this is would be a good change.
Repository: flutter
Issue: Add package CI checks for example contents
Labels: team,p: tooling,package,team-ecosystem,P3,triaged-ecosystem

Currently when we add a new package to flutter/plugins or flutter/packages, or when we add a platform to an existing plugin, we generally just run `flutter create` and check in the results. There are a number of things we could clean up or standardize in the examples, and if we're going to do that we should do it via tooling so people don't have to remember everything:
- [ ] Don't check in icons (or check in some tiny placeholder if the files are required)
- [ ] Don't check in all the pubspec comments (we often do clean this up, but nothing checks that).
- [ ] Don't check in files like `LaunchImage.imageset/README.md` or `Assets/.gitkeep`.
- [ ] Use a standard naming scheme for the example app package name. It's often `the_package_name_example`, but not always.
Repository: rust
Issue: asm_sub_register warnings should provide an example/quick-fix
Labels: A-diagnostics,T-compiler



Given the following code: [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021)

```rust
use std::arch::asm;
fn main() {
    unsafe {
        let val = 42i32;
        asm!(
            "movd xmm0, {0}",
            in(reg) val,
            out("xmm0") _,
        );
    }
}
```

The current output is:

```
 --> src/main.rs:6:25
  |
6 |             "movd xmm0, {0}",
  |                         ^^^
7 |             in(reg) val,
  |                     --- for this argument
  |
  = note: `#[warn(asm_sub_register)]` on by default
  = help: use the `e` modifier to have the register formatted as `eax`
  = help: or use the `r` modifier to keep the default formatting of `rax`
```


Ideally the output should look like:

```
 --> src/main.rs:6:25
  |
6 |             "movd xmm0, {0}",
  |                         ^^^
7 |             in(reg) val,
  |                     --- for this argument
  |
  = note: `#[warn(asm_sub_register)]` on by default
  = help: use `0:e` to have the register formatted as `eax`
  = help: or use  `0:r` to keep the default formatting of `rax`
```



<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: dead_code warning on an used module.
Labels: A-lints,A-diagnostics,T-compiler,L-dead_code

<!--
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.
-->
I've got recently a warning about unused_code when the code was in fact being used. This warning was reported both by my IDE and by the cargo run / build commands.

The warning was caused because I was using "mod some_module" in both main.rs and lib.rs, but I was importing it on my main.rs through lib.rs instead.

I think the compiler should throw the warning on the "mod some_module" statement in main.rs instead of reporting it at some_module.rs

This repo contains a minimal reproducible error: https://github.com/Aex12/rust_error_unused_code

```rust
// main.rs
mod some_module;

use my_crate::some_module::some_function;

fn main() {
    let input = "lorem ipsum";
    let output = some_function(input);
    println!("{}", output);
}

// lib.rs
pub mod some_module;

// some_module.rs
pub fn some_function (input: &str) -> &str {
    input
}
```

The current output is:

```
warning: function `some_function` is never used
 --> src/some_module.rs:2:8
  |
2 | pub fn some_function (input: &str) -> &str {
  |        ^^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: `error_unused_code` (bin "error_unused_code") generated 1 warning
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
warning: mod statement `mod some_module` is never used
 --> src/main.rs:1:1
  |
2 | mod some_module
  |     ^^^^^^^^^^^
```

Or maybe something like this:
```
warning: mod statement `mod some_module` is already declared on lib.rs:1:1
 --> src/main.rs:1:1
  |
2 | mod some_module
  |     ^^^^^^^^^^^
```

<!--
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: x/benchmarks/sweet: support for arm64
Labels: NeedsInvestigation

I am testing on a GCE T2A arm64 instance running Debian bullseye. So far I've encountered a few issues:

* [ ] `fogleman-fauxgl` is either extremely slow or completely stuck. Needs more investigation.
* [ ] `go-build` fails due to error creating systemd-run user scope: `test.scope: Failed to add PIDs to scope's control group: Permission denied`

cc @mknyszek
Repository: rust
Issue: unreachable_pub lint false positive
Labels: A-lints,C-bug,L-unreachable_pub

<!--
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
#![warn(unreachable_pub)]

mod foo {
    pub struct Foo;
}

use foo::Foo;
```
[Here's a link for the same code on playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9f3fee55f1c272893d91b9ab645d79ee)

I expected to see this happen: *No warning, as the item is actually accessible from the root crate*

Instead, this happened: *It says the item is unreachable, even though it isn't*