sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [TextField] Placeholder doesn't differ from filled value on Safari when `type="date"`
Labels: bug 🐛,component: text field,ready to take

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

This bug is only happened in Safari.
If I set `type="date"` the text color remains black even though I am not typing.

```tsx
<InputBase id="greeting" type="date" />
```

<img width="200" alt="ss" src="https://user-images.githubusercontent.com/36793907/156764700-fe8a7185-b1f6-4b8b-8efc-fa802223f720.png">



### Expected behavior 🤔

When I am not typing, the text color should be grey like the below image.

<img width="200" alt="ss" src="https://user-images.githubusercontent.com/36793907/156765234-a4a92d04-1287-405c-8e5a-05a63a458c25.png">

I know this is because of styling problem. Adding below sx props works good for me.

```tsx
<InputBase id="greeting" type="date"
	sx={{
		"& .MuiInputBase-input": {
			backgroundColor: "white",
		},
	}}
/>
```

### Steps to reproduce 🕹

Steps:

1. add `type="date"`` to <InputBase />` 
2. run the application on Safari

### Context 🔦

This behavior causes confusion as to whether the user actually inputed the value or not.
It should be grey color if users don't input the values.

I know MUI DatePicker is great, but this time I have to use TextField for date. so I'm so happy to fix this problem.

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  System:
    OS: macOS 11.6
  Binaries:
    Node: 16.13.0 - ~/.volta/tools/image/node/16.13.0/bin/node
    Yarn: 1.22.17 - ~/.volta/tools/image/yarn/1.22.17/bin/yarn
    npm: 8.1.0 - ~/.volta/tools/image/node/16.13.0/bin/npm
  Browsers:
    Chrome: 98.0.4758.109
    Edge: Not Found
    Firefox: 97.0.1
    Safari: 15.0
  npmPackages:
    @emotion/react: 11.8.1 => 11.8.1 
    @emotion/styled: 11.8.1 => 11.8.1 
    @mui/base:  5.0.0-alpha.69 
    @mui/icons-material: 5.4.2 => 5.4.2 
    @mui/lab: 5.0.0-alpha.70 => 5.0.0-alpha.70 
    @mui/material: 5.4.3 => 5.4.3 
    @mui/private-theming:  5.4.2 
    @mui/styled-engine:  5.4.2 
    @mui/styles: 5.4.2 => 5.4.2 
    @mui/system:  5.4.3 
    @mui/types:  7.1.2 
    @mui/utils:  5.4.2 
    @types/react: 17.0.39 => 17.0.39 
    react: 17.0.2 => 17.0.2 
    react-dom: 17.0.2 => 17.0.2 
    typescript: 4.5.5 => 4.5.5 
```
</details>
Repository: godot
Issue: Physics_process timing creep (until crash) when multi-threading and updating label
Labels: bug,topic:core

### Godot version

3.4.3-stable

### System information

Ubuntu Linux, Intel NUCPJYH4, 8 gig mem

### Issue description

I have a multi-threaded app for terrain generation.
The thread emits a signal when it generates or removes a chunk.  This updates a label on screen.
When the line below is used, the physics_process time continues to climb until the app crashes.

`label.text += "\nChunk spawned: " +str(chunkIndex) # constant physics_process time creep until crash`

But if I remove the plus sign, and make it a straight assignment, the physics_process time stays generally constant, as expected.

`label.text = "\nChunk spawned: " +str(chunkIndex) # no physics_process time creep`

I have tried putting various things into call_deferred to no avail.
I have tried adding mutexes to no avail.
I have tried changing collision map so that the tiles only collide with the player, to no avail.

The only thing that stops the creep is either not emitting the signals that update the GUI, or the label.text workaround described above.

Some additional screenshots and conversation I had with the author of the terrain-gen code: https://github.com/alex-karev/godot-simple-procedural-terrain/issues/3

Repro attached.


### Steps to reproduce

Here is a video showing the issue in action.  https://www.youtube.com/watch?v=UTUhrfh6-NE

You might want to fast forward through much of it as I wait for the physics_process creep to crash the app.  Note how the total number of nodes becomes constant as tiles are removed and created on the fly to maintain a zone around the player.  The video shows three runs: first with the physics_process creep, second with the workaround showing the issue is gone, and third showing physics_process creep until crash.

### Minimal reproduction project

[repro.zip](https://github.com/godotengine/godot/files/8186395/repro.zip)
Repository: yt-dlp
Issue: arte.tv playlist does not collect videos
Labels: site-bug

### Checklist

- [X] I'm reporting a broken site
- [X] I've verified that I'm running yt-dlp version **2022.02.04**. ([update instructions](https://github.com/yt-dlp/yt-dlp#update))
- [X] I've checked that all provided URLs are alive and playable in a browser
- [X] I've checked that all URLs and arguments with special characters are [properly quoted or escaped](https://github.com/ytdl-org/youtube-dl#video-url-contains-an-ampersand-and-im-getting-some-strange-output-1-2839-or-v-is-not-recognized-as-an-internal-or-external-command)
- [X] I've searched the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues including closed ones. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)
- [ ] I've read about [sharing account credentials](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#are-you-willing-to-share-account-details-if-needed) and I'm willing to share it if required

### Region

Germany

### Description

The playlist parser for `arte.tv` does not find any videos. Single videos can be downloaded using the direct link

### Verbose log

```shell
yt-dlp -vU https://www.arte.tv/de/videos/RC-022077/victoria/
[debug] Command-line config: ['-vU', 'https://www.arte.tv/de/videos/RC-022077/victoria/']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, err utf-8, pref UTF-8
[debug] yt-dlp version 2022.02.04 [c1653e9ef]
[debug] Python version 3.10.2 (CPython 64bit) - Linux-5.15.12-1-MANJARO-x86_64-with-glibc2.35
[debug] exe versions: ffmpeg 5.0 (setts), ffprobe 5.0, rtmpdump 2.4
[debug] Optional libraries: Cryptodome, secretstorage, mutagen, sqlite, websockets
[debug] Proxy map: {}
Latest version: 2022.02.04, Current version: 2022.02.04
yt-dlp is up to date (2022.02.04)
[debug] [ArteTVPlaylist] Extracting URL: https://www.arte.tv/de/videos/RC-022077/victoria/
[ArteTVPlaylist] RC-022077: Downloading JSON metadata
[download] Downloading playlist: Victoria
[ArteTVPlaylist] playlist Victoria: Collected 0 videos; downloading 0 of them
[download] Finished downloading playlist: Victoria
```
Repository: yt-dlp
Issue: Different error levels for different errors
Labels: enhancement,triage

### Checklist

- [X] I'm reporting a feature request
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I'm running yt-dlp version **2022.02.04**. ([update instructions](https://github.com/yt-dlp/yt-dlp#update))
- [X] I've searched the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues including closed ones. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Description

is it possible to add an additional errorlevel %errorlevel%?
Both states give off the same one.
```
[youtube:tab] 'chanID': Downloading webpage
ERROR: [youtube:tab] 'chanID': The channel is not currently live
>echo 1
```
```
ERROR: [youtube] vidID: This live event will begin in 15 minutes.
>echo 1
```
Repository: neovim
Issue: -u flag init file not acknowledged in nvim
Labels: enhancement,needs:discussion,startup

### Feature already in Vim?

_No response_

### Feature description

not sure if it's a feature or a bug with the implementation but here goes:

# Problem: 
when using the -u flag to point to a different init.vim file, nvim loads the correct file, but this is not acknowledged in either `:checkhealth` nor does `:e $MYVIMRC` point to it. 

This makes it difficult to know if it's actually loading a different config, or if changes to the config are loaded. This is especially true if you are loading variations of the config file for testing (Is the init file loaded, is it a plugin problem, or a syntax error?).  

If you don't have a init.vim in the default folder, `:checkhealth` has a "Missing config" error, which makes it even more confusing. 

# Solution:
Have $MYVIMRC and `:checkhealth` register the new init file and have nvim treat it as the default for the session.
Repository: pytorch
Issue: [FSDP] Add Gradient Accumulation Outside `no_sync()` Compatibility with CPU Offloading
Labels: feature,triaged,module: fsdp

https://github.com/pytorch/pytorch/pull/73535 adds gradient accumulation outside the `no_sync()` context manager. However, it does not support the case when also using CPU offloading. With the PR, trying to do so yields the incorrect result since the newly-reduced gradient is used directly instead of accumulating with any existing gradient. This issue is meant to track this feature gap.

cc @zhaojuanmao @mrshenli @rohan-varma
Repository: vscode
Issue: File explorer mask won't disappear when creating file/folder in a nested folder
Labels: bug,file-explorer

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.65.0
- OS Version: Windows_NT x64 10.0.22000

Steps to Reproduce:

1. Create an empty nested folder, for example, `outer/inner`
2. Click on the `outer` folder
3. Click the "New File" button on the toolbar
4. Do not enter the file name, instead, click the "New Folder" button on the toolbar
5. The input box disappears but the mask remains on, neither clicking outside nor refreshing will work

![reproduce](https://user-images.githubusercontent.com/17172063/156784358-d5362c4f-beca-41c6-aa55-2cd4e792fb64.gif)
Repository: godot
Issue: Signal methods do not work with AutoLoad signals in a script with @tool annotaton
Labels: bug,topic:gdscript

### Godot version

4.0 alpha 3

### System information

Windows 10

### Issue description

Description:
An AutoLoad script has a signal. A script with the `@tool ` annotation attempts to connect to the script using Signal.connect(),

Expected Outcome:
The script can connect and emit the signal.

Outcome:
An error is thrown:   `res://editor_tool.gd:7 - Invalid get index 'signal_is_ready' (on base: 'Node ()').`

To note that this works with legacy `Object.connect()` (see example script / project)


### Steps to reproduce

Open the example project and open editor_tool.tscn. You will see the message 'I'm ready!' printed from the `Object.connect()` but an error for the `Signal.Connect()`

AutoLoad script:

```
extends Node

signal signal_is_ready()
signal object_is_ready()
```

Tool script:

```
@tool
extends Node

func _ready():
	Signals.connect("object_is_ready", on_is_ready)
	Signals.emit_signal("object_is_ready")
	Signals.signal_is_ready.connect(on_is_ready)
	Signals.signal_is_ready.emit()

func on_is_ready() -> void:
	print("I'm ready!")
```

### Minimal reproduction project

[godot-signal-method-tool-script-bug.zip](https://github.com/godotengine/godot/files/8187515/godot-signal-method-tool-script-bug.zip)
Repository: pytorch
Issue: Bug: torch.distributions.mixture_same_distribution._pad_mixture_dimension
Labels: high priority,module: distributions,triaged,module: correctness (silent)

### 🐛 Describe the bug

I already tracked down what's going on with this one; there is a bug in mixture_same_distribution._pad_mixture_dimension. It uses numel() on Size objects in order to get the number of dimensions in its tensors--however, Size.numel() multiplies all the elements of the size tensor together (it's telling you how many numel are in the tensor whose size it represents!), thus returning what is clearly the wrong value. 

This (which is in both 1.8, which I was on originally, and master):
```    
def _pad_mixture_dimensions(self, x):

        dist_batch_ndims = self.batch_shape.numel()
        cat_batch_ndims = self.mixture_distribution.batch_shape.numel()
        pad_ndims = 0 if cat_batch_ndims == 1 else \
            dist_batch_ndims - cat_batch_ndims
        xs = x.shape
        x = x.reshape(xs[:-1] + torch.Size(pad_ndims * [1]) +
                      xs[-1:] + torch.Size(self._event_ndims * [1]))
        return x
```

Should be this:
```
def _pad_mixture_dimensions(self, x):
        dist_batch_ndims = len(self.batch_shape)
        cat_batch_ndims = len(self.mixture_distribution.batch_shape)
        pad_ndims = 0 if cat_batch_ndims == 1 else \
            dist_batch_ndims - cat_batch_ndims
        xs = x.shape
        x = x.reshape(xs[:-1] + torch.Size(pad_ndims * [1]) +
                      xs[-1:] + torch.Size(self._event_ndims * [1]))
        return x
```

I didn't see this error anywhere else, but I haven't really done a thorough search.
I don't know what branch it's right to make a pull request on (master?) so I thought I'd report it here first.

### Versions

Versions of relevant libraries:
[pip3] numpy==1.20.3
[pip3] torch==1.8.0
[pip3] torchvision==0.9.0
[conda] blas                      2.109                       mkl    conda-forge
[conda] blas-devel                3.9.0                     9_mkl    conda-forge
[conda] cudatoolkit               10.2.89              h8f6ccaa_8    conda-forge
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] libblas                   3.9.0                     9_mkl    conda-forge
[conda] libcblas                  3.9.0                     9_mkl    conda-forge
[conda] liblapack                 3.9.0                     9_mkl    conda-forge
[conda] liblapacke                3.9.0                     9_mkl    conda-forge
[conda] mkl                       2021.2.0           h726a3e6_389    conda-forge
[conda] mkl-devel                 2021.2.0           ha770c72_390    conda-forge
[conda] mkl-include               2021.2.0           h726a3e6_389    conda-forge
[conda] numpy                     1.20.3           py38h9894fe3_1    conda-forge
[conda] pytorch                   1.8.0           py3.8_cuda10.2_cudnn7.6.5_0    pytorch
[conda] torchvision               0.9.0                py38_cu102    pytorch


cc @ezyang @gchanan @zou3519 @fritzo @neerajprad @alicanb @nikitaved
Repository: go
Issue: x/pkgsite: Accessibility Color Contrast Problems
Labels: pkgsite,UX

Would it be possible to change the color contrast on the pkg.go.dev website so people with color blindness or other eye deficiencies could enjoy and use the website better?
 
I made a test with the a11y.com tool to see the contrast between various colors on the website and the colors highlighted in the screenshot were problematic, these colors are mainly used in links, titles, and code backgrounds.

### Screenshot
 
<img width="1550" alt="image" src="https://user-images.githubusercontent.com/489775/156806762-b1cd0a04-7e45-4097-a286-e6e123d40cf6.png">
 
 
 
### What did you do?
 
1. Go to: https://color.a11y.com/Contrast/
2. Test a pkg.go.dev internal page, I tested: https://pkg.go.dev/encoding/json
Repository: TypeScript
Issue: NodeNext: Import mappings should support an override for the TypeScript file that the mapping points to
Labels: Suggestion,In Discussion

# Suggestion

## 🔍 Search Terms

nodenext, import mappings, package.json imports

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Right now, the detection for import mappings assume that the path passed in points both to the file to include in the compile and the built file. However, this cannot be used when you separate the dist from the src folder for example, as the file the import mapping would point to doesn't exist until after compiling. Ideally, just like how `exports` has a `types` property that can be specified so TS can tell where to find typings, so should `imports`. 

## 📃 Motivating Example

Consider this example:

```json
// package.json
{
	"type": "module",
	// ...
	"imports": {
		"#example": "./dist/example.mjs"
	}
}
```

```json
// tsconfig.json
{
	"compilerOptions": {
		"target": "ESNext",
		"module": "NodeNext",
		"moduleResolution": "NodeNext",
		// ... extra configs
		"rootDir": "./src",
		"outDir": "./dist",
		"tsBuildInfoFile": "./dist/.tsbuildinfo"
	},
	"include": ["src"]
}
```

```ts
// src/entrypoint.mts
import { add } from '#example';

console.log(add(9, 10));
```

```ts
// src/example.mts
export function add(num1: number, num2: number) {
	return num1 + num2;
}
```

Given that structure, you'll receive a `Cannot find module '#example'...` error *unless* you ignore errors and still emit the built code. Ideally, we should be able to replace the package.json's content with something like:

```json
// package.json
{
	"type": "module",
	// ...
	"imports": {
		"#example": {
			"node": "./dist/example.mjs",
			"types": "./src/example.mts"
		}
	}
}
```

which TS can then use to accurately point the files to their place.

## 💻 Use Cases

A workaround for now is to specify the import paths in your tsconfig/jsconfig (but that defeats the purpose of just reading them from package.json). While this works, a better solution would be ideal.
Repository: create-react-app
Issue: Dev servers keeps recompiling while no changes are made
Labels: needs triage,issue: bug report

Dunno does anyone of you had this, but after upgrade we are getting infinite rebuild on dev server. It happens after a while. When main index.tsx is touched it stops :P
Repository: vscode
Issue: suggest list hover view shouldn't appear border
Labels: bug,suggest

<img width="1440" alt="image" src="https://user-images.githubusercontent.com/41773861/156811836-b0c579e4-f3f0-4662-abe1-b2ba719afbf3.png">

I can't always reproduce this issue, but can often occured this issue when typing in recently months.


<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.66.0-insider
- OS Version: Monterey 12.2.1
Repository: go
Issue: runtime: "found pointer to free object" on aix-ppc64
Labels: NeedsInvestigation,OS-AIX,arch-ppc64x,compiler/runtime

```
aix-ppc64 at eeb9f095dc13a6beed41db0e734b6ae1e97f15d1
…
runtime: marked free object in span 0xa00000026d12a98, elemsize=48 freeindex=0 (bad use of unsafe.Pointer? try -d=checkptr)
…
fatal error: found pointer to free object
```

`greplogs --dashboard -md -l -e '(?ms)\Aaix-.*runtime: marked free object in span 0x[a-f0-9]'`

[2022-03-03T02:39:01-eeb9f09/aix-ppc64](https://build.golang.org/log/3b7376ee94f76d28721422ec9313eebd6921c679)

(CC @trex58)
Repository: rust
Issue: Profraw files are not produced when using instrument-coverage on freebsd
Labels: O-freebsd,C-bug,A-code-coverage

Running the following command on the [calloop](https://github.com/Smithay/calloop) repo on a FreeBSD environment:

```
env LLVM_PROFILE_FILE="calloop-%p-%m.profraw" RUSTFLAGS="-Cinstrument-coverage" cargo +nightly test --all-features
```

No `.profraw` file is produced with the latest nightly (which now causes our CI script to fail).

### Meta

The files were correctly produced with `rustc 1.60.0-nightly (88fb06a1f 2022-02-05)`, but are no longer produced on `rustc 1.60.0-nightly (30b3f35c4 2022-02-17)` nor `rustc 1.61.0-nightly (10913c000 2022-03-03)`. This fails on both FreeBSD 13.0 and FreeBSD 12.1 (according to our CI).

Running the command on Linux using `rustc 1.61.0-nightly (10913c000 2022-03-03)` works as expected, producing the `.profraw` files.