sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Ensure package repo is not broken after a new package is published. 
Labels: team,package,team-ecosystem,P2,triaged-ecosystem

This is inspired by https://github.com/flutter/flutter/issues/105182

I will use the exact plugins in this incident to describe the issue, but the issue can happen on any plugin in the repo. 

This is the sequence of the events that caused a breakage. 
1. A commit landed and updated video_player version. The commit passed post commit CI. 
2. The new version of video_player is released.
3. A new commit is landed on master/main, it is not related to video_player or image_picker. (So presubmit didn't run any image_picker tests)
4. Image_picker's example app depends on video_player, and the example app contains some tests. Because video_player's new version is released, image_picker runs the tests with the new video_player version the first time on CI, and the new version of video_player broke the image_picker test, which caused the ci to fail. 

The breakage was around dependencies in androidx test libraries. I have very limited knowledge on this topic so I'm not sure how severe the damage could be. My guess is that any flutter app that has the same set up as image_picker_example would break if they depend on video_player. 

The bigger issue is that we don't know if the video_player breaks other flutter apps out there, it was nice that we had image_picker_example depends on video_player, which caught the issue. It would be even better to have this failure show up before we publish the video_player, so that we can catch that and fixing the issue before landing/releasing video_player.
Repository: react
Issue: Bug: React 18 Strict mode does not simulate unsetting and re-setting DOM refs
Labels: Type: Needs Investigation,React 18

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 18.1.0

## Steps To Reproduce

1. Use `<React.StrictMode>`
2. Set a ref to a JSX element in a component
3. Create a `useLayoutEffect`/`useEffect `in the component where the returned cleanup function console logs the ref
4. Save and refresh the app
5. You should have access to the ref element in the the `useLayoutEffect`/`useEffect `cleanup function during the _simulated_ unmount.

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example: https://codesandbox.io/s/proud-snow-ox4ngx?file=/src/App.js

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior
Does not unset/re-set refs in simulated unmount. This could lead to unexpected bugs in development like having double-set event listeners, i.e.` if( ref.current ){ //add eventlistener to it } `and might not match the behavior of _actually_ unmounting the DOM node as described in the docs: https://reactjs.org/docs/strict-mode.html

> On the second mount, React will restore the state from the first mount. This feature simulates user behavior such as a user tabbing away from a screen and back, ensuring that code will properly handle state restoration.

## The expected behavior
In normal unmounts and mounts refs are unset(before layout effects are cleaned up) and set(before layout effects).
Repository: storybook
Issue: Cannot find module 'react-dom/client' in render.jss under React 18
Labels: question / support,has workaround

**Describe the bug**
render.jss is erroring after upgrading to React 18 when attempting to access `react-dom/client`

**To Reproduce**
Run storybook with React 18.1.0

**System**
```
System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-8569U CPU @ 2.80GHz
  Binaries:
    Node: 16.14.2 - ~/.nvm/versions/node/v16.14.2/bin/node
    Yarn: 1.22.10 - ~/frame.io/web-app/node_modules/.bin/yarn
    npm: 8.5.0 - ~/.nvm/versions/node/v16.14.2/bin/npm
  Browsers:
    Chrome: 102.0.5005.61
    Firefox: 100.0.2
    Safari: 15.1
  npmPackages:
    @storybook/addon-actions: 6.3.7 => 6.3.7 
    @storybook/addon-knobs: 6.3.0 => 6.3.0 

```
Repository: vscode
Issue: SCM view doesn't maintain highlight after reload
Labels: bug,scm

Follow up from https://github.com/microsoft/vscode/issues/137330

I noticed that the SCM view doesn't highlight the active editor on restoring:

* Have an empty git repo
* create a file `test_a.md`
* open the SCM view and see that that file is highlighted
![image](https://user-images.githubusercontent.com/2644648/171941589-e0f2f465-d1cb-4d45-a418-f4b1df62aa92.png)

* reload the window
* that item is no longer highlighted in the SCM view
![image](https://user-images.githubusercontent.com/2644648/171941616-ffb196d3-ea4e-4d46-b6df-13a361beb6a0.png)


However, the explorer, by contrast, _does_ maintain the highlighting after reloading
![image](https://user-images.githubusercontent.com/2644648/171941646-13ee3912-a95a-4cad-9249-600b776c1360.png)

*might be hard to see but test_a.md has a different background color*

Once you `ctrl`+`tab` to a different file, that file is highlighted:
![image](https://user-images.githubusercontent.com/2644648/171941937-301fddc3-b9e6-4a0b-b1ab-4bb4460038c2.png)
Repository: pytorch
Issue: Add TORCH_SHOW_CPP_STACKTRACES when TORCH_DISTRIBUTED_DEBUG = detail
Labels: oncall: distributed,module: bootcamp,pt_distributed_rampup,module: c10d

### 🚀 The feature, motivation and pitch

when TORCH_DISTRIBUTED_DEBUG = detail, we should also enable cpp stacktraces so that if a collective is inconsistent, user can get the entire C++ stack to help debug. 

Arguably, we could also just do this for tdd = info. We could also discuss whether if TDD = detail, we also want to enable NCCL_DEBUG=warn or info, although one reason for not doing this is nccl is a separate library who's env vars should be explicitly set by the user.

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Repository: pytorch
Issue: [Modes] no_dispatch is not the same as DisableTorchFunction, causing differences in modes
Labels: triaged,module: __torch_function__,module: __torch_dispatch__

### 🐛 Describe the bug

## Repro
The following passes
```
      def test_disable_subclass_not_mode(self):
          called = False
            
          class A(TorchFunctionMode):
              def __torch_function__(self, func, types, args=(), kwargs=None):
                  nonlocal called
                  if kwargs is None:
                      kwargs = {}
                  called = True
                  return func(*args, **kwargs)
                  
          class B(torch.Tensor):
              pass
              
          x = B(torch.randn(5))
          with torch.overrides.push_torch_function_mode(A):
              with torch._C.DisableTorchFunction():
                  self.assertNotIsInstance(torch.sum(x), B)
  
          self.assertTrue(called)
```

while the following fails because `torch.sum(x)` is of type B (also adjusting the test, called is not True)

```
      def test_disable_subclass_not_mode(self):
          called = False

          class A(TorchDispatchMode):
              def __torch_dispatch__(self, func, types, args=(), kwargs=None):
                  nonlocal called
                  if kwargs is None:
                      kwargs = {}
                  called = True
                  return func(*args, **kwargs)

          class B(torch.Tensor):
              pass

          x = B(torch.randn(5))
          with push_torch_dispatch_mode(A):
              with no_dispatch():
                  self.assertNotIsInstance(torch.sum(x), B)

          self.assertTrue(called)
```

## Problem
This suggests that the behavior of `no_dispatch` and `DisableTorchFunction` don't match

We should either make the behavior of these functions match or make a version of `DisableTorchDispatch` which matches `DisableTorchFunction`

cc @hameerabbasi @rgommers @peterbell10 @Chillee @ezyang @zou3519 @albanD @samdow @eellison 

### Versions

master
Repository: electron
Issue: [Bug]: `<webview>`.setVisualZoomLevelLimits(1, 5) doesn't work
Labels: component/webview,bug :beetle:,platform/all,status/confirmed,has-repro-gist,19-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

17.4.6

### What operating system are you using?

Other Linux

### Operating System Version

Linux archlinux 5.18.1-arch1-1

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

By default, pages loaded in electron do not support pinch-to-zoom, unless enabled using `setVisualZoomLevelLimits()`. Documentation states that on `<webview>` tags, this method can be called to configure pinch-to-zoom.

### Actual Behavior

However, calling `<webview>`.setVisualZoomLevelLimits(1, 5) does not enable pinch-to-zoom for the OOPIF loaded within the page.

### Testcase Gist URL

https://gist.github.com/ppotvin/fa87558cf3bbf3bd76ace2b93d0de43e

### Additional Information

_No response_
Repository: flutter
Issue: salt state dependency requirement for bot_code.py
Labels: team-infra,P3,triaged-infra

/opt/s/bot_code.py will fail on a fresh host install, because it depends on machine_tokend json file to exist. We need to add the correct require clause to this state.

Note: a rerun will pass, assuming the machine_tokend stuff installed successfully the first time states were applied.
Repository: godot
Issue: Console is not available when debugging 3.5 builds w/ MSVC
Labels: discussion,topic:editor

### Godot version

3.x

### System information

Windows 10

### Issue description

Since https://github.com/godotengine/godot/pull/55987 the console no longer appears when debugging in MSVC and there's no means to enable it (`--console` command line argument?).

Using a `.cmd` file is not an acceptable solution because MSVC wont attach to a `cmd.exe` and allow debugging the `Godot.exe` through it. It does not seem to support this kind of deferred attaching through a separate process.

### Steps to reproduce

Debug with MSVC and note there is no means to see any `printf()`'s or console logging.

### Minimal reproduction project

_No response_
Repository: godot
Issue: Internal script error! Opcode: 38, const outside of class causes crash under specific circumstances
Labels: bug,topic:gdscript,crash

### Godot version

v3.4.4.stable.official.419e713a2

### System information

ArcoLinux, Kernel 5.17.9-arch1-1, x86

### Issue description

The code below crashes Godot, this is easily solvable by moving CONSTANTS into the class, this workaround however, isn't very straight forward and I would've expected the first option, that currently crashes Godot to be the correct one.

There is also a second workaround to this issue, where we can change the way the class is being imported, please note that really using either first or second fix, fixes the issue, you do not have to make both changes to the project.

Class file
```
const CONSTANTS = preload("res://constants.gd")

class Class:
	# Fix number one
	# Moving the CONSTANTS here instead of above the class fixes the issue
	# const CONSTANTS = preload("res://constants.gd")

	func _init():
		print(CONSTANTS.VARIABLE)
```

Node file
```
const Class = preload("res://class.gd").Class
# Fix number two
# const Class = preload("res://class.gd")

func _ready() -> void:
	Class.new()
	# Fix number two
	# Class.Class.new()
```

This is obviously just a bug, because using any other combination of instantiating, calling etc. solves the issue.

### Steps to reproduce

You can skip all these steps by downloading the sample project.

1. GDScript file with a constant
2. GDScript file with class, where the class uses constant from previous file, and the 1st file is imported outside of the class
3. GDScript file that is actually attached to any node and creates a new instance of the class from 2nd file, the class has to be imported exactly like so: const Class = preload("res://class.gd").Class

### Minimal reproduction project

[crash.zip](https://github.com/godotengine/godot/files/8835867/crash.zip)
Repository: vscode
Issue: Replace hardcoded progress badge icon
Labels: debt,polish,icons-product

Looks like the image is hardcoded instead of coming from codicons:

<img width="200" alt="CleanShot 2022-06-03 at 15 54 09@2x" src="https://user-images.githubusercontent.com/25163139/171964384-abe75b68-5c7a-4881-ba61-53f0461b7430.png">

https://github.com/microsoft/vscode/blob/d9de4afd7a5bdeae266b06a5c98b227c1e9e88c7/src/vs/workbench/services/progress/browser/media/progressService.css#L6-L8

cc @misolori
Repository: TypeScript
Issue: TS should provide a way to patch buggy package.json files of dependents (ESM use of `"moduleResolution": "nodenext"` is not plausible during transition from CJS to ESM)
Labels: Suggestion,Needs Proposal

# Bug Report

### 🔎 Search Terms

ESM
project.json main
exports

### 🕗 Version & Regression Information

4.7.2 this is new and experimental according to the [handbook](https://www.typescriptlang.org/docs/handbook/esm-node.html)


### ⏯ Playground Link

https://github.com/rosskevin/ts-esm-workspaces/tree/apollo-exports

### 💻 Code

`"moduleResolution": "nodenext"` vs `"moduleResolution": "node"` for modules targeting pure ESM output is not possible because _ANY_ dependency that does not meet the standard e.g. properly defined `exports` will fail to build.

### 🙁 Actual behavior

We can use `"moduleResolution": "node"` to build a project with non-ESM dependencies, but we cannot use `"moduleResolution": "nodenext"` to build a project with _any_ non-ESM dependency.  IF you use `"moduleResolution": "node"`, [you MUST FAKE `main` behavior for typescript project references to build](https://github.com/microsoft/TypeScript/issues/49266#issuecomment-1146391005). This causes a multiplier effect of bad signals that a CJS `main` is present when that is clearly not the case.

If _you have one single dependency that does not meet the spec_, your build will fail and you cannot use `"moduleResolution": "nodenext"`.

If a project has hundreds of dependencies,  the likelihood _it has A SINGLE DEPENDENCY_  that does not meet the ESM `exports` standard _IS INCREDIBLY HIGH_!

### 🙂 Expected behavior

In order to facilitate a transition to pure ESM modules, typescript should hybridize `moduleResolution` to allow a distinct transition period wherein faulty ESM targeted modules are allowed to be recognized, similar to `node` resolution.

@reference https://github.com/microsoft/TypeScript/issues/49266#issuecomment-1146391005
@cc @milesj @weswigham

Ultimately, it seems like typescript MUST DECIDE TO BECOME an interop to allow for this transition period from CJS to ESM, otherwise it is bound to cause immense pain, 100x, to the community.  Typescript is the vessel to mediate this issue, and I request they seek this as a primary goal.  I agree that this is not to spec, but what about a flag?  HOW did `esModuleInterop` come to pass?  I request the same consideration.  `esmInterop: true` should be a thing, shouldn't it?
Repository: material-ui
Issue: Style override for <DialogTitle> 's height does not move the Typography text inside.
Labels: component: dialog,v4.x,customization: css

Running Material-UI/core version 4.12.3 (may be a bit old, as I've not updated during development of the current project)

I'm trying to tweak a Dialog 's title via a style override so that ` <DialogTitle>` is a thinner version. However, the text inside DialogTitle is not adhering to the new height, despite other elements repositioning.

![image](https://user-images.githubusercontent.com/63443061/171971636-e709a51a-befc-4d88-804f-f9ac06a7fa33.png)

Dialog is generated via:
 `          <div>
                <Dialog open={this.props.open}>
                    <DialogTitle>
                        {this.props.title}
                    </DialogTitle>
                    <DialogContent>
                        ...
                    </DialogContent>
                    <DialogActions>
                        ...
                    </DialogActions>
                </Dialog>
            </div>`

and the override for DialogTitle is:
`overrides: {
        ...
        MuiDialogTitle: {
            root: {
                backgroundColor: "#2c9cf2",
                height: "20px",
                fontSizeAdjust: 0.4,
                "& .MuiTypography-h6": {
                    textAlign: "center",
                },
            },
        },
    },`
Repository: rust
Issue: dtrace's ustack() function cannot unwind stack frames on FreeBSD since 1.56.0
Labels: A-LLVM,O-x86_64,P-medium,T-compiler,regression-from-stable-to-stable,O-freebsd,C-bug

One of the best ways to profile Rust code is with dtrace, as described at https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html#DTrace .  As recently as Rust 1.55.0 that worked fine.  But with Rust 1.56.0 the stack just isn't there.  Dtrace can only see a single Rust-level stack frame.  For example:

### Code
With Rust 1.55.0
```
$ sudo dtrace -x ustackframes=100 -n 'profile-199 /pid == $target && arg1/ {@[ustack()] = count();}' -c "target/debug/deps/test-bc98e078c2bbb61b"
    ....
              libc.so.7`__je_malloc_mutex_prefork+0x124
              libc.so.7`__je_arena_prefork7+0x73
              libc.so.7`_malloc_prefork+0x15b
              libthr.so.3`0x392e4a8c4686
              libthr.so.3`_fork+0x18
              test-dad15ed382b075cf`nix::unistd::fork::h358225d652a86eab+0xe
              test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::hb93c7cdf2b79d680+0x36
              test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::_$u7b$$u7b$closure$u7d$$u7d$::h329a121974ff9291+0x11
              test-dad15ed382b075cf`core::ops::function::FnOnce::call_once::h2261827bcba63036+0x11
              test-dad15ed382b075cf`test::__rust_begin_short_backtrace::hefb7644d11da2ff9+0xa
              test-dad15ed382b075cf`test::run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::hdaa0fb71aac8d97e+0x2f3
              test-dad15ed382b075cf`std::sys_common::backtrace::__rust_begin_short_backtrace::h8bcc057a546c1087+0xce
              test-dad15ed382b075cf`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hf7d978d08be459d0+0x6a
              test-dad15ed382b075cf`std::sys::unix::thread::Thread::new::thread_start::h6b52ca0eca213387+0x2b
              libthr.so.3`0x392e4a8c3a7a
    ...
```

With Rust 1.56.0
```
$ sudo dtrace -x ustackframes=100 -n 'profile-199 /pid == $target && arg1/ {@[ustack()] = count();}' -c "target/debug/deps/test-bc98e078c2bbb61b"
    ...
              libc.so.7`__je_malloc_mutex_prefork+0x124
              libc.so.7`__je_arena_prefork7+0x73
              libc.so.7`_malloc_prefork+0x15b
              libthr.so.3`0x1106cebc6686
              libthr.so.3`_fork+0x18
              test-b377ad62cc9e0624`nix::unistd::fork::hbf1ed55b658aa870+0xa
              0x8
              0xcccccccccccccccc
    ...
```

### Version it worked on

It most recently worked on: Rust 1.55.0

### Version with regression

```
rustc 1.56.0 (09c42c458 2021-10-18)
```

### Workaround
The old behavior can be restored by compiling with `RUSTFLAGS="-C force-frame-pointers"`.  This flag was added by https://github.com/rust-lang/rust/issues/48785 , but that was a long time ago.  There is nothing in the 1.56.0 release notes, nor any recent commit messages, that mention anything about frame pointers.  Was this change therefore accidental?  Or could it have been a by product of switching to LLVM 13?
Repository: rust
Issue: Rustc does not recognize ttbr0_el2 as a valid armv8 system register
Labels: A-LLVM,E-needs-test,A-inline-assembly,T-compiler,O-AArch64

Rustc does not recognize ttbr0_el2 as a valid armv8 system register.
[ttbr0_el2](https://developer.arm.com/documentation/100403/0200/register-descriptions/aarch64-system-registers/ttbr0-el2--translation-table-base-register-0--el2) is used by hypervisors to configure page tables for the lower half of memory, typically used for userspace.

```rust
#![no_std]
use core::arch::asm;

static PT: [u64; 512] = [0; 512];
pub fn main() {
    unsafe {
        asm!("msr {pt}, ttbr0_el2", pt = in(reg) &PT as *const _ );
    }
}
```

This fails to compile with the error:
```
error: expected writable system register or pstate
 --> <source>:8:15
  |
8 |         asm!("msr {pt}, ttbr0_el2", pt = in(reg) &PT as *const _ );
  |               ^
  |
note: instantiated into assembly here
 --> <inline asm>:1:6
  |
1 |     msr x8, ttbr0_el2
  |         ^

error: aborting due to previous error

Compiler returned: 1
```
Here is a live example on godbolt:
https://godbolt.org/z/3jsGEd59a

My rustc version is:
```
$ rustc --version
rustc 1.63.0-nightly (e71440575 2022-06-02)
```
Repository: flutter
Issue: Cleanup TODOs from engine artifact names.
Labels: P2,c: tech-debt,team-engine,triaged-engine

The engine artifacts are not following a naming convention forcing logic to generate the names differently according to the platforms. Changing the names require a complicated testing process and coordinating with changes to the flutter tool.

This change will happen in multiple steps:

* Generate artifacts with gn and ninja using the same artifact names.
* Validate the artifacts generated with gn and ninja with the framework tests and the flutter tool.
* Make the gn generated artifacts the default ones
* Standardize names.
Repository: pytorch
Issue: [RecordFunction] Hold a durable schema reference
Labels: triaged,oncall: profiler

### 🚀 The feature, motivation and pitch

When an op is called through the dispatcher we hold a reference to the schema in the RecordFunction object for the duration of the call: https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/record_function.h#L372 We would like to keep the schema until post processing and expose it to users as that would enable certain analyses like FLOP counting. However it is prohibitively expensive to copy the schema while profiling. We should be able to guarantee the lifetime of the FunctionSchema in the Dispatcher and then just store a pointer in RecordFunction, however work needs to be done to ensure that all the machinery is safe.

### Alternatives

_No response_

### Additional context

_No response_

cc @ilia-cher @robieta @chaekit @gdankel @bitfort @ngimel @nbcsm @guotuofeng @guyang3532 @gaoteng-git