sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Impossible intersection is supposedly never but any can still be assigned to it
Labels: Suggestion,Needs Proposal

# Bug Report

### 🔎 Search Terms

intersection assign never

### 🕗 Version & Regression Information

This is the behavior in every version I tried (including nightly), and I reviewed the FAQ for relevant entries. But really this is a loose end left by #36696; prior to that the impossible intersection (`AB` below) was not `never` at all.

### ⏯ Playground Link

[link](https://www.typescriptlang.org/play?ts=4.9.5#code/C4TwDgpgBAglC8UDeUDWBLAdgEwFxQHIBDAgGigDMB7K-AZ2ACcsBzKAXwG4AoUSKAEIJkaLHkIAjMpRr5MAVwC2EiIw49e4aDCGI4AMkGcoUAPSmomCADdV5OvLBgqdCNgA2Ibt3NQAAsB0ALQQAB6QAMbAIYyMVIz4ACpahESYIARQ6HSWVMBQRHR06CyYRBLu0MBUUHzQBFa2jAQAdNwRVJgMlgCMcjaqwkjsBTlpXr4S8vnAABbZWTlUqO2d3ZgATPg6QyOFBelAA)

### 💻 Code

(modified from the example in #36696)

```ts
type A = { kind: 'a', foo: string };
type B = { kind: 'b', foo: number };

type AB = A & B;  // never, supposedly

// @ts-expect-error: Type 'any' is not assignable to type 'never'.
const n1: never = {} as any
// but this is ok
const n2: AB = {} as any
```

### 🙁 Actual behavior

`any` is assignable to `AB`, despite the fact that `any` is not assignable to `never` and `AB` is supposedly `never` (per both #36696 and hovering it)

### 🙂 Expected behavior

`any` should not be assignable to `AB`
Repository: go
Issue: crypto/x509: Certificate.Verify rejects self-signed leaf
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
1.19.6 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

</pre></details>

### What did you do?

https://go.dev/play/p/tE0FcCY4HfS

In short, the leaf certificate is self-signed. There is an intermediate certificate that has the same subject/key as the leaf that was signed by the root.

We encountered this issue while attempting to upgrade from 1.18 to 1.19. The linked code works correctly in 1.18, but gets rejected with "x509: certificate signed by unknown authority" in 1.19+.



### What did you expect to see?

`Certificate.Verify` should succeed with a chain from leaf to intermediate to root.

### What did you see instead?

It rejects the self-signed leaf.
Repository: vscode
Issue: status bar in debugging session with light+ v2 theme hints an error happened
Labels: bug,themes

<!-- ⚠️⚠️ 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. -->

<!-- 🪓 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. -->

The status bar's color during a debugging session is close to red and hints as if some error happened (eg compilation error) 

<img width="2560" alt="image" src="https://user-images.githubusercontent.com/16353531/221967652-eb69cb87-47c5-4d1d-9452-32ad4a5a12f8.png">


Version: 1.76.0-insider (Universal)
Commit: 92da9481c0904c6adfe372c12da3b7748d74bdcb
Date: 2023-02-28T11:54:11.765Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Darwin arm64 22.3.0
Sandboxed: Yes
Repository: godot
Issue: Exported vars  without a default set, of enum types with no entry with a value of 0, show misleading info in inspector
Labels: bug,topic:gdscript,topic:editor,confirmed,topic:dotnet

### Godot version

v4.0.rc6.official [0cd148313]

### System information

Arch Linux

### Issue description

In GDScript, when exporting a variable of an enum type that does NOT have an entry with value `0` (zero), and you don't  a default value, the inspector looks as if you have selected the first element, but in truth, the value of the variable is `0`.

Given the following snippet:

```
enum Foo{
	bar = 1,
	foobar = 2,
}
@export var foo : Foo
```

The inspector looks like this:

![image](https://user-images.githubusercontent.com/7486114/221964166-7493668b-bf60-4f7a-b95f-787081599882.png)

This suggests `bar` is selected, and thus `foo` should be `1`.

However,
```
func _ready():
	print(str(foo))
```
prints `0` (zero).

If you _do_ give a default:

```
@export var foo : Foo = Foo.bar
```

the inspector looks exactly the same as it did without the default specified, but the output _is_ the (expected) `1`. As a user, I thus can't tell the difference without inspecting the code. 

As a user, I expect that whatever is shown in the inspector is a representation of what I'll get when I run the code. So when no default is specified, I expect that either (the inspector shows `0` or `null`) _or_ (the value of `foo` ends up being `bar` instead of `0`). Ideally, I would like it to do the latter, but I think that the former is technically more correct

### Steps to reproduce

1. Make a new scene 
2. Attach the following script:
```
extends Node

enum Foo{
	bar = 1,
	foobar = 2,
}

@export var foo : Foo

func _ready():
	print(str(foo))
```
3. Observe that the inspector for this node suggest that `foo`  is set to `bar`.
4. Run the code, and observe the ouput prints `0` instead.
5. Change the export line to `@export var foo : Foo = Foo.bar`
6. Observe that the outliner looks exactly the same as before
7. Run the code, and observe that the output now reads `1`.

### Minimal reproduction project

n/a, but can be supplied if helpful.
Repository: next.js
Issue: [NEXT-734] Revalidated page with notFound true does not return 404 Page
Labels: linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```
npx --no-install next info

    Operating System:
      Platform: linux
      Arch: x64
      Version: #32-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 20 15:20:08 UTC 2023
    Binaries:
      Node: 16.19.0
      npm: 8.19.3
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.2.2-canary.3
      eslint-config-next: 13.2.1
      react: 18.2.0
      react-dom: 18.2.0
```

### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue

https://github.com/floreq/200-to-404

### To Reproduce

1. Install project:
```
npm install
```
2. Build and run production application:
```
npm run build && npm run start
```
3. Go to `http://localhost:3000/blog/1` page.
4. Make some page refreshes.
5. Spot that the page never become `404 Page` when minutes are even.
    - In this example, when **minutes are even** is set `notFound: true` for Post Page.

### Describe the Bug

When a page was correctly generated. Than when `getStaticProps` returns `notFound: true` for that page. The page is not removed from `.next/server/pages`. The page is still visible.

In the code to reproduce issue, when the page is revalidated with `notFound: true` on even minutes. `x-nextjs-cache` is set to `STALE` and stays that way. Even if refreshing the page. 
- `x-nextjs-cache` changes only to `HIT` when the page is revalidated without ``notFound: true``.

----

In `next.config.js` is set `isrMemoryCacheSize: 0` to highlight this problem.
```js
//next.config.js
module.exports = {
  [...]
  experimental: {
    isrMemoryCacheSize: 0,
  },
};
```

----

Image 1
- correctly loaded page, `x-nextjs-cache: HIT`, odd minutes

![image](https://user-images.githubusercontent.com/25390589/221961854-fa62f8d5-11b5-4d0f-8bb5-926f0da79288.png)

Image 2
- incorrectly loaded page, `notFound: true`,  `x-nextjs-cache: STALE`, even minutes
![image](https://user-images.githubusercontent.com/25390589/221961984-12913eb7-6c14-465b-952e-1b942acde9c7.png)


### Expected Behavior

When a page is successfully revalidated with `notFound: true` returned from `getStaticProps`:

1. the page should display 404 Page, not itself,
2. and the page should not be in `.next/server/pages`.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

next start

<sub>[NEXT-734](https://linear.app/vercel/issue/NEXT-734/revalidated-page-with-notfound-true-does-not-return-404-page)</sub>
Repository: flutter
Issue: Web engine leaks SemanticsHandle when running integration test
Labels: engine,a: accessibility,platform-web,P2,team-web,triaged-web

The Web Engine is causing a `SemanticsHandle` leak when an integration test generates semantics information. This leak went previously undetected because our leak detection logic contained a bug that's getting fixed in https://github.com/flutter/flutter/pull/121571.

Here's what's causing the leak:

An integration test calls `SemanticsBinding.ensureSemantics` and holds on to the returned semantics handle (it is properly disposed at the end of the test). This will cause the framework to generate a semantics tree, which at the end of the frame gets send to the engine via `FlutterView.updateSemantics` and ends up here in the web engine:

https://github.com/flutter/engine/blob/0f4acf3be29203de0f71f65574e400b5e9f77858/lib/web_ui/lib/src/engine/semantics/semantics.dart#L1787

The web engine now thinks that because it received a semantics tree it should turn around and tell the framework to turn on semantics. This happens indirectly by setting this `semanticsEnabled` setter to true:

https://github.com/flutter/engine/blob/0f4acf3be29203de0f71f65574e400b5e9f77858/lib/web_ui/lib/src/engine/semantics/semantics.dart#LL1799C9-L1799C25

At the end of that setter, the framework is informed that the engine is interested in semantics updates:

https://github.com/flutter/engine/blob/0f4acf3be29203de0f71f65574e400b5e9f77858/lib/web_ui/lib/src/engine/semantics/semantics.dart#L1608

This causes a SemanticsHandle to be created, which represents the engine's interest in semantics updates. This SemanticsHandle is never disposed, causing the SemanticsHandler leak detection to fail. Also, the fact that one test turned on semantics now leaks into the next test. The only proper way of disposing this SemanticsHandle is for the engine to give up its interest in receiving semantics update. In an integration test there isn't really a way to do this, though.

Overall, the engine should only tell the framework to turn on semantics when it itself has an interest in it. Not because somebody else (e.g. a test) expressed their interest and caused semantics updates to be generated. AFAIK, all other embedders behave this way.

The web engine already contains special logic for regular unit tests to avoid this problem. Maybe this needs to be extended to cover integration tests as well?

https://github.com/flutter/engine/blob/0f4acf3be29203de0f71f65574e400b5e9f77858/lib/web_ui/lib/src/engine/semantics/semantics.dart#L1789
Repository: PowerToys
Issue: Zone resizing by keyboard input
Labels: Needs-Triage

### Description of the new feature / enhancement

Double click / F2 gives the option to change the size in pixels, using the keyboard.

### Scenario when this would be used?

This would be used when resizing windows. It would:

1. allow keyboard operation
2. allow more precise input

### Supporting information

_No response_
Repository: go
Issue: runtime: TestCgoTracebackSigpanic fails on android/arm64 and android/arm
Labels: OS-Android,NeedsInvestigation,mobile,arch-arm64,arch-arm,compiler/runtime

In [CL 472096](https://go.dev/cl/472096), I am experimenting with enabling tests that use `go build` on `android`, because I don't see a good reason not to.

However, `runtime.TestCgoTracebackSigpanic` seems to fail when run on that platform (https://storage.googleapis.com/go-build-log/8970bcfa/android-arm64-corellium_f7cf8915.log):
```
--- FAIL: TestCgoTracebackSigpanic (2.10s)
    crash_cgo_test.go:519: /data/data/com.termux/files/home/tmpdir/workdir-host-android-arm64-corellium-android/tmp/go-build2337918989/testprogcgo.exe TracebackSigpanic: signal: segmentation fault
    crash_cgo_test.go:520: 
    crash_cgo_test.go:523: did not see "runtime.sigpanic" in output
FAIL
FAIL	runtime	58.095s
```

I don't think this is particularly important to fix and don't plan to investigate it myself, but I'm filing this issue to have something to refer to in a test skip.

(CC @golang/android)
Repository: kubernetes
Issue: Conditionally `Apply`ing with SSA
Labels: sig/api-machinery,triage/accepted

This issue copies a slack thread to preserve it and continue discussion: https://kubernetes.slack.com/archives/C0EG7JC6T/p1677203415388589. Note that our own use case is (mostly) handled, so I don't mind if this is a "won't fix"; I just wanted to at least make sure the discussion was preserved.

---

We want to essentially _conditionally_ SSA.

Use case: SimpleService resource "foo" as input, controller generates a Service "foo". But if the Service already existed and isn't owned by us, we don't want to mutate it (could cause outage on their end).
We want to "Apply only if we own it". The user could later modify it if they want, just not have existed before. We define ownership by a special label but could change (managedField, etc).

---

The best current way to do this is:
1. If object doesn't exist, just Apply as normal
2. If it does exist, set ResourceVersion to the existing object; if it has changed we will get a conflict (like Update).

Note for our use case this is actually largely fine, we just want to avoid taking over an existing thing since it may cause an outage; (1) only allows a tiny window where this could happen so its highly unlikely to cause an outage _practically_. But there may be cases where this is unacceptable as well

What doesn't work:
* tricks like setting UID=0, UID="", ResourceVersion=0, etc to ensure an object is "new".
* Owning metadata.name (can't)
* Force=false and always conflicting on some field (could work, but not a generalization for all use cases)

/sig api-machinery
Repository: vscode
Issue: Extensions not installing on vscode insiders when running inside a dev container
Labels: info-needed,extensions,extension-signature

<!-- ⚠️⚠️ 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?: n/a

n/a I think. The code editor cannot install extensions when booting up a development container. I've ran the 'Help: Start Extension Bisect' command to reload the container without any extensions installed.... unfortunately, when I attempt to install the `ms-python.python` extension, the extension is stuck on 'Installing'.

<!-- 🪓 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: 

Version: 1.76.0-insider
Commit: 92da9481c0904c6adfe372c12da3b7748d74bdcb
Date: 2023-02-28T11:50:50.947Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Darwin arm64 22.3.0
Sandboxed: Yes

- OS Version: macOS Ventura 13.2.1

Notes:

I'm on an macos and am using rosetta to emulate `x86_64` architecture.
Repository: PowerToys
Issue: File previews don't work when PowerToys is installed on a drive other than C:(?)
Labels: Issue-Bug,Area-Setup/Install,Product-File Explorer,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.67.1

### Installation method

WinGet

### Running as admin

Yes

### Area(s) with issue?

File Explorer: Preview Pane

### Steps to reproduce

Not sure if what I wrote in the title is actually the case, but it has something to do with the installation's path.

With PowerToys installed on my second (E) drive – file previews in Preview Pane don't work. [file-explorer-log_2023-02-28.txt](https://github.com/microsoft/PowerToys/files/10855593/file-explorer-log_2023-02-28.txt)
After seeing the log I tried reinstalling it onto my main (C) drive – file previews worked correctly.
I have since installed it back on my E drive – file previews are broken as before.



### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

Preview Pane is blank, no loading bar or any text whatsoever.

![image](https://user-images.githubusercontent.com/69874143/222000858-7116feac-0a3b-48c5-9d4c-93baf6ddb213.png)


### Other Software

_No response_
Repository: godot
Issue: Tile Map Bug
Labels: bug,topic:editor,crash,topic:2d

### Godot version

RC6

### System information

Windows 11

### Issue description

when i delete 1000+ tiles at once in the tile map it exits without saving and same thing when i place 1000+ tiles at once and does not save it so if you open godot and your project and you saved it 1 hr ago you just lost 1 hour of progress

### Steps to reproduce

when i delete 1000+ tiles at once in the tile map it exits without saving and same thing when i place 1000+ tiles at once and does not save it so if you open godot and your project and you saved it 1 hr ago you just lost 1 hour of progress

### Minimal reproduction project

i am using the forward+ version
Repository: next.js
Issue: [NEXT-736] Metadata API does not work with routes in named slots
Labels: bug,linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

Operating System:
    Platform: darwin
    Arch: arm64
    Version: Darwin Kernel Version 22.3.0: Thu Jan  5 20:48:54 PST 2023; root:xnu-8792.81.2~2/RELEASE_ARM64_T6000
Binaries:
    Node: 19.6.0
    npm: 9.5.1
    Yarn: N/A
    pnpm: N/A
Relevant packages:
    next: 13.2.1
    eslint-config-next: N/A
    react: 18.2.0
    react-dom: 18.2.0

### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Metadata (metadata, generateMetadata, next/head, head.js)

### Link to the code that reproduces this issue

https://github.com/mritzerfeld/next-slots-metadata

### To Reproduce

1. Create new installation via create-next-app
2. Change layout.js in app directory to accept named slot `slot` instead of children property
3. Create folder `@slot` in app directory
4. Create folder `demo` in `@slot` and move example page.js to this location (change css import herein)
5. Move the metadata export from layout.js to page.js

### Describe the Bug

When creating (nested) routes within a slot directory, Metadata api does not produce any output in `<head>`. It does however work properly with a page.js on the root level of a named slot. The error only occurs on deeper levels.

### Expected Behavior

Configured meta data properties title and description should be includes in <head> output.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

<sub>[NEXT-736](https://linear.app/vercel/issue/NEXT-736/metadata-api-does-not-work-with-routes-in-named-slots)</sub>
Repository: godot
Issue: Overriding scenes remove its scripts and resets its transforms
Labels: bug,topic:editor

### Godot version

4.0 rc6

### System information

windows 10, ryzen 5 5600x rx 590, m2 ssd

### Issue description

Overriding scenes cause them to remove its nodes' scripts and reset their transforms. This happens only when you try to override it, when you slightly change the name of the scene while saving it, this issue does not occur, FYI.

### Steps to reproduce

create a scene with a node that has a script attached to it, let's say it's a gun scene
save the gun scene
add the saved gun scene on your main scene
change the script's variable values, change its tranform values
make it local
drag & drop it to the file system
make sure it has the same exact name to be asked to override it by godot
override it and then you'll see its script's variable values and tranform values have been reset.

### Minimal reproduction project

There's no need for this.
Repository: godot
Issue: LightmapGI doesn't take CameraAttributes into account when baking indirect light in lightmaps (and only partially for direct light)
Labels: bug,topic:rendering,topic:3d

- *Related to https://github.com/godotengine/godot/issues/74134.*

### Godot version

4.0.rc6

### System information

Fedora 37, GeForce RTX 4090 (NVIDIA 525.85.05)

### Issue description

LightmapGI doesn't take CameraAttributes into account when baking indirect light in lightmaps (and only partially for direct light, i.e. when using Static bake mode).

### DirectionalLight3D bake mode set to Dynamic

*Regardless of the presence of a CameraAttributes resource in the LightmapGI's properties, this is the result after baking.*

![Screenshot_20230301_015822](https://user-images.githubusercontent.com/180032/222018406-756d2b53-84dd-4926-a8de-33fb7efa5bbf.png)

### DirectionalLight3D bake mode set to Static, LightmapGI with CameraAttributesPhysical

*This works as expected, but changing exposure parameters then baking again doesn't affect light brightness at all even after rebaking lightmaps (be it aperture, shutter speed, ISO or multiplier).*

*Also note that using a CameraAttributes**Practical** results in the same lighting, which is unexpected.*

![Screenshot_20230301_020238](https://user-images.githubusercontent.com/180032/222018409-83f43d15-b3b1-4804-9c92-5e70001ebbe0.png)

### DirectionalLight3D bake mode set to Static, LightmapGI *without* CameraAttributesPhysical

*This is overly bright as expected (which shows that the presence of the CameraAttributes **is** taken into account by LightmapGI somehow).*

![Screenshot_20230301_020248](https://user-images.githubusercontent.com/180032/222018411-14848998-804e-4193-99d6-27d6236854bc.png)

### Steps to reproduce

- Follow [Physical light and camera units](https://docs.godotengine.org/en/latest/tutorials/3d/physical_light_and_camera_units.html) documentation to enable physical light and camera units in a project.
- Set up LightmapGI then bake it.

### Minimal reproduction project

[physical_light_camera_units_lightmap.zip](https://github.com/godotengine/godot/files/10856015/physical_light_camera_units_lightmap.zip)