sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: C# abstract Godot types missing constructors
Labels: bug,confirmed,topic:dotnet

### Godot version

3.4.stable

### System information

macOS Big Sur, 2017 iMac, i7

### Issue description

When trying to extend a CanvasItem in C#, Godot throws an error saying that ```/Users/.../ShowInGame.cs(4,14): 'CanvasItem' does not contain a constructor that takes 0 arguments```. However, the C# metadata for CanvasItem does not contain a constructor and I can find no documentation for it on the internet. Is CanvasItem not intended to be extended? If so, why expose it as an extendable class?

Here is my code trying to extend CanvasItem:
```csharp
using Godot;
using System;

public class ShowInGame : CanvasItem
{
    public override void _Ready()
    {
        Visible = true;

        base._Ready();
    }
}
```

### Steps to reproduce

If you try to compile, run, or build the project, you can see the error described above.

### Minimal reproduction project

[MinCanvasItemError.zip](https://github.com/godotengine/godot/files/7643206/MinCanvasItemError.zip)
Repository: rust
Issue: Unhelpful error message for unsupported/tier-3 platforms when using no_std
Labels: C-enhancement,A-diagnostics,T-compiler,D-confusing,D-terse

<!--
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.
-->

Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=576f0120ca20fddb1eaed15e45b2dede

```rust
#![feature(lang_items)]
#![no_std]
#![no_main]
use core::panic::PanicInfo;

#[lang = "eh_personality"]
extern "C" fn eh_personality() {}

#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}
```

Compiled with: `cargo +nightly build --target armv6k-nintendo-3ds`

The current output is:

```
error[E0463]: can't find crate for `core`
  |
  = note: the `armv6k-nintendo-3ds` target may not be installed
  = help: consider downloading the target with `rustup target add armv6k-nintendo-3ds`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

For more information about this error, try `rustc --explain E0463`.
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0463]: can't find crate for `core`
  |
  = note: the `armv6k-nintendo-3ds` target may not be installed
  = help: consider downloading the target with `rustup target add armv6k-nintendo-3ds`
  = help: consider building libcore from source with `cargo build -Zbuild-std=core`

For more information about this error, try `rustc --explain E0463`.
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

The problem is that `-Zbuild-std` will try to build `std`. This is the default suggestion when building something that lacks `#![no_std]` when using nightly. However, when using a `no_std` build, the error does not match, and diagnosing the issue becomes a bit of a roadblock, and somewhat challenging at times. As a result, the final help hint should recommend building `libcore` with `-Zbuild-std=core` instead when this kind of build is expected.

Note, building this with the correct flag will still throw up an error about lacking a spec file in a clean environment (3dsx.specs) - this is fine, and not a bug of rustc/cargo, and is also not required to reproduce the issue. It is also not exclusive to the `armv6k-nintendo-3ds` target, but it was a useful one to use here - pick any tier 3 target that lacks `libstd` support.

<!--
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: cmd/doc: args are treated case-insensitive in some cases
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17 darwin/amd64

$ gotip version
go version devel go1.18-d34051b Thu Dec 2 07:04:05 2021 +0000 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.


### 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/kanataninaoki/Library/Caches/go-build"
GOENV="/Users/kanataninaoki/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/kanataninaoki/dev/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/kanataninaoki/dev"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.17/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.17/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/kanataninaoki/dev/src/github.com/kanata2/go-doc-case-insensitive-issue/go.mod"
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/02/8930c3s52tlfpw2_8ml_xm5w0000gn/T/go-build3338848241=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

The following is one of the examples to reproduce.

```
$ go doc Net/HttP/httpTEST.DefaultRemoteAddr
```

### What did you expect to see?

According to https://go.dev/blog/package-names, lowercase is recommended in Go,
so I think that the output should also follow it.
Thus I was expecting that the `go doc` will return an error(like not_found_error)
or the output which converted to lowercase.

### What did you see instead?

The following is the actual output.
The import path `import "Net/HttP/httpTEST"` is not a recommended style.

```
package httptest // import "Net/HttP/httpTEST"

const DefaultRemoteAddr = "1.2.3.4"
    DefaultRemoteAddr is the default remote address to return in RemoteAddr if
    an explicit DefaultRemoteAddr isn't set on ResponseRecorder.

```

### Investigation

This problem seems to occur in cases where the passed arguments are passed directly to `build.Import` function.
I don't know if this is the intended behavior, but it is because the `build.Import` function treats path as case-insensitive.

```go
package main

import (
	"go/build"
	"log"
	"os"
)

func main() {
	wd, _ := os.Getwd()
	pkg, err := build.Import("Net/HttP/httpTEST", wd, build.ImportComment)
	log.Printf("pkg: %v\nerr: %v", pkg, err) // err is nil
}
```

I'm thinking of submitting a CL based on the discussion here.
Repository: TypeScript
Issue: Suggest changing error message / adding more details for TS5055
Labels: Suggestion,Experience Enhancement

# Suggestion

There are a number of issues (#29549, #16749, #35082, #35541, probably many others) that all think this error:

```sh
error TS5055: Cannot write file '/path/to/file.d.ts' because it would overwrite input file.
```

is a bug.  I was about to open another one.

I believe the fundamental issue here is that most people, myself included, believe this is saying that `/path/to/file.d.ts` is explicitly being included in the `tsconfig`, e.g. through some weird combination of `includes`, `rootDir`, etc, and we all spend time banging our heads trying to figure out how the config is messed up.

What it's actually saying is that `/path/to/file.d.ts` is *somehow* being included *either* via `tsconfig.json` *or* an `import`/`require` statement in your project.  For several of these issues, the reason is because the import was referencing the root project folder, and consequently the `build` folder.  In my specific case, VSCode's auto-import referenced the project name I was currently in for some reason, instead of the relative path to a file.

I'm not quite sure how to re-phrase the error, but adding details such as the ones included in `--explainFiles` would be a huge help.

```sh
error TS5055: Cannot write file '/project/build/file.d.ts' because it would overwrite input file.
  Imported via '../../file' from file 'src/index.ts'
```

In my specific case, `--explainFiles` didn't even contain the offending file (no idea why), making the problem that much harder to figure out.

## 🔍 Search Terms

TS5055

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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

<!-- A summary of what you'd like to see added or changed -->

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

## 💻 Use Cases

I believe a clearer error message & details would be very helpful to a lot of people
Repository: go
Issue: testing: t.Failed() returns false during panic
Labels: NeedsFix

### Does this issue reproduce with the latest release?

Yes (1.17.3)

### What operating system and processor architecture are you using (`go env`)?

Any

### What did you do?

Called `t.Failed()` from a deferred cleanup function registered for a test that panicked (see https://go.dev/play/p/f0Xu8OyA--h).

### What did you expect to see?

`t.Failed()` return true.

### What did you see instead?

`t.Failed()` returned false.

---

The issue isn't verified if the test has parallel subtests (see https://go.dev/play/p/37YXOUyv5-z). I believe that's because in that case [this](https://github.com/golang/go/blob/36be0beb05043e8ef3b8d108e9f8977b5eac0c87/src/testing/testing.go#L1403) branch will be ignored, and [this](https://github.com/golang/go/blob/36be0beb05043e8ef3b8d108e9f8977b5eac0c87/src/testing/testing.go#L1343) closure will call `t.Fail()` before invoking the cleanup functions .
Repository: godot
Issue: OS.is_window_maximized() returns incorrect result in Ubuntu
Labels: bug,platform:linuxbsd,topic:porting,confirmed

### Godot version

3.4 stable

### System information

Ubuntu 20.04.3 LTS

### Issue description

After calling OS.set_window_maximized(true) in Ubuntu, OS.is_window_maximized() returns false.

### Steps to reproduce

Call OS.is_window_maximized() when the window is maximized.

### Minimal reproduction project

[Ubuntu_is_maximized_bug.zip](https://github.com/godotengine/godot/files/7644275/Ubuntu_is_maximized_bug.zip)

Run this project in Ubuntu - the label returns False; run on OSX or WIN it will return True.
Repository: godot
Issue: Document using CSG nodes as "clip brushes" (invisible colliders)
Labels: topic:core,documentation,topic:3d

### Godot version

v3.4.1.rc1.official [7b0801c7f]

### System information

Windows 10, GLES3, Nvidia RTX 2080 SUPER

### Issue description

I noticed that when you make any CSGCombiner Hidden or Non-Visible it causes the collision to stop calculating or working, resulting in Non-Collision. I was wondering if the collision was supposed to work regardless of whether any CSG object is non-visible?

Here is a link to a video demonstration to the bug I'm trying to explain:
https://youtu.be/GHgZliDruGk

I've also attached a sample project with everything shown in the video that showcases the bug.

### Steps to reproduce

In Godot's 3D viewport/space, place a Spatial node first, then a CSGCombiner Node as a child node to the Spatial, use either KinematicBody or RigidBody object/node to test the collision on the CSG to see if you can see the bug occurring.

### Minimal reproduction project

[3point4_Test.zip](https://github.com/godotengine/godot/files/7644626/3point4_Test.zip)
Repository: rust
Issue: Duplicate error messages in async code
Labels: A-async-await,AsyncAwait-Polish,AsyncAwait-Triaged

We often get multiple copies of the same error message in async code. For example, see [unresolved_type_param.stderr](https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/unresolved_type_param.stderr). It would be good to only get this error message once.
Repository: rust
Issue: [ER] Better wrong brackets recovery heuristics for error messages?
Labels: A-diagnostics,T-compiler

This is a diagnostic enhancement request, but it's rather vague, so if you think it isn't actionable, I'll close it down.

Generally I find the rustc compiler quite helpful at spotting problems in my code. One of the few (small) pain points it gives me is when a bracket is missing (or a stray one is added), this sometimes happens when I translate some Python code to Rust, or when I add some calls to macros that need brackets (like foo!{...}).

In the last of such cases I got an error message like:

```rust
error: unexpected closing delimiter: `}`
   --> ...\some_program.rs:636:1
    |
12  | fn main() {
    |           - this opening brace...
...
619 |     }
    |     - ...matches this closing brace
...
636 | }
    | ^ unexpected closing delimiter

error: aborting due to previous error
```

The problem was at line 361 and to find it I have had to comment-out chunks of code in some kind of binary search :-( Similar situations have happened to me several times in the last years of coding in Rust.

Assuming my Rust code is indented well enough, the question is: it's possible to improve the parser heuristics to give some hints were the brackets problem could be?
Repository: pytorch
Issue: Enable DDP checkpointing tests for Gloo backend
Labels: oncall: distributed,better-engineering,module: ddp,Stale

Currently checkpointing tests only exist for NCCL backend but it is backend independent, we should enable these tests for Gloo as well: https://github.com/pytorch/pytorch/blob/master/test/distributed/test_c10d_nccl.py. 

## Motivation

Parity to ensure that DDP features cover all backends.

## Pitch

Modularize the checkpoint tests, and then move them to `test_c10d_common` so that they are run for both gloo and nccl backends.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: pytorch
Issue: `torch.tensor` relies on implicit conversion being deprecated in Python 3.10
Labels: high priority,triaged,module: numpy,module: tensor creation

On Python 3.8.8:

```
>>> import torch as t
>>> t.tensor([1.23], dtype=t.int32)
<stdin>:1: DeprecationWarning: an integer is required (got type float).  Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
tensor([1], dtype=torch.int32)
```

This deprecation warning is being replaced with an error in Python 3.10.

NumPy and JAX currently perform this conversion silently and will not begin to error:

```
>>> import numpy as np
>>> np.array([1.23], dtype=np.int32)
array([1], dtype=int32)
```

```
>>> import jax.numpy as jnp
>>> jnp.array([1.23], dtype=jnp.int32)
DeviceArray([1], dtype=int32)
```

I'd propose modifying `torch.tensor` to avoid this implicit conversion so that it does not begin to error when running future Python versions. We can add a torch warning about the conversion (warn once) to replace the Python deprecation warning. 

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @mruberry @rgommers
Repository: next.js
Issue: Two locale path issue i18n
Labels: Internationalization (i18n)

### What example does this report relate to?

i18n

### What version of Next.js are you using?

v12.0.3

### What version of Node.js are you using?

16.13.0

### What browser are you using?

Brave

### What operating system are you using?

MacOS

### How are you deploying your application?

Other Platform

### Describe the Bug

I have an i18n configuration file as stated below. 

```javascript
  i18n: {
    locales: ['default', 'de-DE', 'en-US'],
    defaultLocale: 'default',
    localeDetection: true,
    domains: [],
  },
````

So, I want to have the locale path in the URL. I followed the conversation [here](https://github.com/vercel/next.js/discussions/18419#discussioncomment-1561577).  I configured my _middleware.js file accordingly to the discussion. However, when I write two locales to the browser, I get strange behavior. 

 * It seems like something funny happens when you write two locales such as `.com/en-us/de-de`. It uses the latest locale. In my case `de-de`. I expect to use `en-us` as locale and `de-de` as a path.

Further, when I give strange URLs such as `.com/en-us/de-de?foo=bar`, it still gives me the latest locale.

To fix this I followed the following workaround.

```javascript
// This statement blocks funny requests such as www.xxxxxx.com/de-de/us-en
  // Apparently, next.js confuses with that request.
  const hrefPathList = request.nextUrl.href
    .replace(request.nextUrl.origin, '')
    .split('?')[0]
    .split('/')
    .map((v) => v.toLowerCase())
    .filter(Boolean);

  const hasTwoLanguages = hrefPathList.filter((n) => wholeLanguageList.includes(n)).length >= 2;
  if (hasTwoLanguages) {
    request.nextUrl.locale = defaultLocale;
    // Redirect the request to the new URL with the new locale
    return NextResponse.redirect(`/`);
  }
```

### Expected Behavior

When we send a request to the `/en-us/de-de`, I expect to get `/en-us` as the locale and `/de-de` as the path(which will probably give 404)

### To Reproduce

Configure your next.js settings accordingly + follow the middleware configuration stated [here](https://github.com/vercel/next.js/discussions/18419#discussioncomment-1561577)
Repository: rust
Issue: Duplicate resolution error messages when using both extern crate and use
Labels: A-diagnostics,T-compiler

Due to recently merged PR #91045 duplicate error message can occur if a crate introduced via `extern crate` is not resolved successfully and subsequently symbol paths are derived via `use` from this missing crate. 

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
extern crate foo;

use foo::bar;

fn main() {
    bar::baz();
}
```

The current output is:

```
error[E0463]: can't find crate for `foo`
 --> src\main.rs:1:1
  |
1 | extern crate foo;
  | ^^^^^^^^^^^^^^^^^ can't find crate

error[E0433]: failed to resolve: use of undeclared crate or module `bar`
 --> src\main.rs:6:5
  |
6 |     bar::buzz();
  |     ^^^ use of undeclared crate or module `bar`
```

Ideally, a missing name should be issued for the missing crate and then silenced for names whose path is rooted in that crate:

```
error[E0463]: can't find crate for `foo`
 --> src\main.rs:1:1
  |
1 | extern crate foo;
  | ^^^^^^^^^^^^^^^^^ can't find crate
```

@rustbot claim


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: web tests always run in unsound mode unless explicitly opted in
Labels: a: tests,tool,platform-web,P2,team-web,triaged-web

## Steps to Reproduce

Open up the hello_world example app (or any flutter project), and add the following test:

```dart
import 'package:flutter_test/flutter_test.dart';

var unsoundNullSafety = <int?>[] is List<int>;

void main() {
  test('sound mode', () async {
    expect(unsoundNullSafety, isFalse);
  });
}
```

And then run `flutter test [--platform chrome]`.

On the chrome platform it will fail, while on the normal platform it will pass.

## Diagnosis

It looks like we are going through this code path https://github.com/flutter/flutter/blob/ff65ca56901809e44beb0964c4f885bd8a31d1ed/packages/flutter_tools/lib/src/test/web_test_compiler.dart#L57 with the mode set to `NullSafetyMode.autodetect`, which just defaults to disabling sound null safety.

The web platform requires the correct platform dill to be passed based on mode, so it isn't as simple as just removing ` || buildInfo.nullSafetyMode == NullSafetyMode.autodetect`. The tool will have to do its own detection of mode. It looks like there is already some code for this in [determineLanguageVersion](https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/dart/language_version.dart#L51).
Repository: material-ui
Issue: [Chip] Disabled a11y regression in MUIv5
Labels: support: question,component: chip

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

In updating to Material-UI v5.2.2 (from v5.0.6) I have noticed what appears to be a regression related to accessibility in the `<Chip>` component. It looks like the underlying `<div><span>` created by the component only designates the component as disabled via CSS class `.Mui-disabled`.
This does not pass an automated a11y test using Jest's `expect(chipComponent).toHaveAttribute("aria-disabled");`

### Expected behavior 🤔

Previously (last tested MUIv5.0.6 & v4.12.2), a disabled `<Chip>` component was marked disabled using the accessible `aria-disabled` attribute

### Steps to reproduce 🕹

Steps:
(Tested in Jest tests and in latest Chrome browser on MacOS)

1. Install MUI v5.2.2
2. Render a disabled chip, `<Chip disabled .../>`
3. Inspect DOM element created by Chip. There is no `aria-disabled="true"` attribute 
4. To compare, install MUI <= 5.0.6 or v4, perform steps 2-3 and there should be an `aria-disabled="true"` attribute


### Context 🔦

I am using Chip components to display some status information and need to differentiate some information as disabled. I need this to be accessible so it's clear to all users what is applicable or not.

Note: These are Basic informational/non-interactive Chips, I am not using actions, deletion, etc.

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
    @emotion/react: ^11.7.0 => 11.7.0
    @emotion/styled: ^11.6.0 => 11.6.0
    @mui/base:  5.0.0-alpha.58
    @mui/icons-material: ^5.2.0 => 5.2.0
    @mui/lab: ^5.0.0-alpha.58 => 5.0.0-alpha.58
    @mui/material: ^5.2.2 => 5.2.2
    @mui/private-theming:  5.2.2
    @mui/styled-engine:  5.2.0
    @mui/styles: ^5.2.2 => 5.2.2
    @mui/system:  5.2.2
    @mui/types:  7.1.0
    @mui/utils:  5.2.2
    @types/react: ^17.0.37 => 17.0.37
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    typescript: ~4.5.2 => 4.5.2
```
</details>