sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: not-found.tsx shows a blank page when calling notFound() from a dynamic route with JavaScript disabled
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/ericnishio/not-found-js-disabled-dynamic-route

### To Reproduce

1. Run the application in dev with `npm run dev` or run a production build with `npm run build && npm start`.
2. Disable JavaScript in your browser.
3. Navigate to http://localhost:3000/blog/foo

### Current vs. Expected behavior

Current behavior: Displays a blank page.

Expected behavior: Renders the text "Not Found".

When `notFound()` is called from a **dynamic route** with JavaScript disabled, the `not-found.tsx` page turns out blank. If you have JavaScript enabled, it works correctly.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
Binaries:
  Node: 18.17.0
  npm: 9.6.7
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.0.1-canary.0
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router, Routing (next/router, next/navigation, next/link)

### Additional context

_No response_
Repository: TypeScript
Issue: Misleading error message
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

Misleading error message

### 🕗 Version & Regression Information

I think in all version but I just tries 5.2.2 and 5.3.0-beta


### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgPIAczAPYgDwAqAfMgN4CwAUMjcsJALYD8AXMgQNxW3IzAQAbACYBnVsgAUAawgBPbDHYBKDgHpVyAK4jQAc2QADEWCh6A2gF0DyOCORhZ6FAAtoKAO7ZNw5AzgzkdGwRHQAjARQwV3swMBsQ4F0QBghwKgBfKgQBWzsCCGMAIVsIQmQIAA9IEFFkbFCAKwgEOIBeOsbmsBIKalpIYwkwNgwsXEIiJTJMyhnQSFhEFAARODA4Mm5aITW4NmNTEF0uWayckPYCsABhZ2AfSura-KKSvFX1nq2aAbAhkcwOHwHzgk2mGSoVAicViw0urxEKHaIAg7nhNzuwgkKiAA

### 💻 Code

```ts
interface Option<T> {
    item?: T;
    fields?: (keyof T);// using `string[]` as type here would make possible the ttt assignment
}
class TestBase<T extends object = object> {
    test(t: Option<T>) {}
}
interface Data {
    data: string;
}
class TestChild extends TestBase<Data> {
    test(t: Option<Data>) {}
}

let ttt: TestBase = new TestChild();
```


### 🙁 Actual behavior

In the error message if I hover over `ttt` it states that the `item` member is incompatible, but I think it is not the problem but the `fields` member. If I change its type from `(keyof T)[]` to type `string[]` the error is solved but as I see this means the error message was misleading.

### 🙂 Expected behavior

The error message should state that the `fields` member is the problematic

### Additional information about the issue

I think the problem is that `fields` member has  type `keyof object` in base class (`TestBase`) which maybe results in type `never` and in derivative class (`TestChild`) the `fields` results in `"data"` which is defineatly not assignable to `never` type.
Although I have years of experience in ts it can surprise me sometimes. :)

ps: Sorry if it is a known issue or expected behavior. Then please point me out to the corresponding documentation
Repository: go
Issue: cmd/dist: SIGSEGV during `Building packages and commands` on freebsd-arm-paulzhol
Labels: OS-FreeBSD,NeedsInvestigation,arch-arm,compiler/runtime

```
#!watchflakes
post <- builder == "freebsd-arm-paulzhol" && log ~ `make\.bash: .*Segmentation fault.*dist bootstrap`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/646c6277e9066da497ba53f805dc2c31ba77a63f)):

    /tmp/workdir-host-freebsd-arm-paulzhol/go/src/make.bash: line 226:  1157 Segmentation fault      ./cmd/dist/dist bootstrap -a $vflag $GO_DISTFLAGS "$@"


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: rust
Issue: Tracking Issue for restructuring `std::sys`
Labels: E-help-wanted,C-tracking-issue,T-libs

On Wednesday, the libs-team [discussed](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202023-10-25/near/398512745) reorganizing the platform-specific modules inside `std`, namely `sys` and `sys_common` into [a new structure](https://github.com/rust-lang/rust/issues/84187#issuecomment-1774066353). These modules will be merged into one `sys` module with a feature-first organization:

* the submodules of `sys`, named after the feature they implement, contain all the implementations of the different platforms and provide a uniform interface that the rest of `std` may depend on. E.g. `sys::thread_local`, `sys::fs` or `sys::thread_parking`.
* `sys::pal` contains platform-specific generic API wrappers like ~~`FileDesc`~~ `cvt` (UNIX) used to implement these features. E.g. `sys::pal::unix`, `sys::pal::windows` or ([perhaps](https://github.com/rust-lang/rust/issues/84187#issuecomment-1779980934)) `sys::pal::apple`.

The rest of `std`, modulo `std::os`, should now only depend on `sys::feature_name` and not `sys::pal`. The implementations themselves may however depend on other parts of `std` as necessary.

```[tasklist]
### Tasks
- [ ] #117285
- [ ] https://github.com/rust-lang/rust/pull/119935
- [ ] https://github.com/rust-lang/rust/pull/119996
- [ ] https://github.com/rust-lang/rust/pull/120109
- [ ] https://github.com/rust-lang/rust/pull/120776
- [ ] https://github.com/rust-lang/rust/pull/121177
- [ ] https://github.com/rust-lang/rust/pull/121758
- [ ] https://github.com/rust-lang/rust/pull/122386
- [ ] https://github.com/rust-lang/rust/pull/123807
- [ ] https://github.com/rust-lang/rust/pull/124159
- [ ] https://github.com/rust-lang/rust/pull/126523
- [ ] https://github.com/rust-lang/rust/pull/126546
- [ ] https://github.com/rust-lang/rust/pull/128134
- [ ] https://github.com/rust-lang/rust/pull/135696
- [ ] Move remaining features from `sys_common` and `sys::pal` into `sys`
```

@rustbot label +T-libs +E-help-wanted
@rustbot claim

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: go
Issue: crypto/tls: Large session tickets in Go 1.21 can cause Windows Schannel clients to be unable to connect
Labels: Security,OS-Windows,NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.21.3 linux/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='/home/user/.cache/go-build'
GOENV='/home/user/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/user/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/user/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.3'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/user/golang-tls-session-ticket-bug/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2373417620=/tmp/go-build -gno-record-gcc-switches'
</pre></details>

### What did you do?

See https://github.com/printfn/golang-tls-session-ticket-bug for a minimal example and reproduction steps.

In Go 1.21, client TLS certificates are included in session tickets by default. When the client cert chain is very long (or the certificate is otherwise very large), the session ticket grows as well, eventually preventing Windows Schannel clients from being able to connect. 

Changing the `WrapTicket` implementation to return a shorter session ticket (e.g. `return []byte{0}, nil`) works around the issue.

This bug happens on the current latest version of Windows 11 (22H2, build 22621.2428). It worked fine on Go 1.20 and earlier, but is broken as of Go 1.21.0. It's worth noting that the Golang TLS client is still able to connect.
Repository: vscode
Issue: Incorrect exit lifecycle for utility process
Labels: bug,upstream,electron

https://github.com/microsoft/vscode/issues/194477 revealed that utility process will send faulty exit events while the process is still active, this is because the [exit handler based on message channel](https://github.com/electron/electron/blob/652f995128de858c7a68fad853f56e80e0c2c222/shell/services/node/node_service.h#L52) will get fired first and if the process were to crash during destruction of `node::Environment` which happens later then it will not be propagated.

Secondly, due to lack to isolate termination we allow entering JS when cleaning up pending tasks during `node::Environment` cleanup which can lead to crashes or deadlocks.
Repository: ant-design
Issue: Select - not scroll to selected item
Labels: 💡 Feature Request,Inactive

### What problem does this feature solve?

When opening select, I have cases where I don't want it to scroll to the selected item because I have options at the beginning of the list that I want users to select most often.

example: https://codesandbox.io/s/big-data-antd-5-10-2-forked-dwcryy - here i dont want scroll to selected option because I would like to show the user the beginning of the list

### What does the proposed API look like?

scrollToSelectedItemOnOpen?: boolean = true

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: puppeteer
Issue: "Target should not report uninitialized pages" does not make sense for BiDi
Labels: bug,confirmed,P3

In CDP we checked that target cannot be changed during initialization. In bidi, there is no initialization step that is needed so the target is changed whenever the context is changed. We need to either make this test compatible with BiDi and CDP or disable it for BiDi.

cc @whimboo @Lightning00Blade
Repository: pytorch
Issue: Optest is unable to xfail on parametrized tests
Labels: triaged,module: opcheck

It is currently not possible to `xfail` on a parametrized test that is marked e.g. as

```
      "TestPSRoIAlign.test_faketensor__test_forward[x_dtype0-True-mps]": {
        "comment": "AssertionError: Dtypes torch.int64 and torch.int32 are not equal!",
        "status": "xfail"
      },
```

in the `failures_dict`. (I thought https://github.com/pytorch/pytorch/pull/111797 was a fix, but it's not enough)

From what I can tell, the problem is that here

https://github.com/pytorch/pytorch/blob/cf5479b57e607f4bbdee06c6eb6e890d42d3aa05/torch/testing/_internal/optests/generate_tests.py#L748-L753

`test_name` isn't found in `dct` (i.e. in the failures_dict) because test_name looks like `TestPSRoIAlign.test_faketensor__test_forward`, i.e. it's missing the `[x_dtype0-True-mps]` part. That's because this name  is generated all the way up in

https://github.com/pytorch/pytorch/blob/cf5479b57e607f4bbdee06c6eb6e890d42d3aa05/torch/testing/_internal/optests/generate_tests.py#L252-L254


where `attr` is `test_forward`, but of course it's missing any parametrization info because this is only looking at the "static" test class object.

I'm not sure how to fix this without a significant rework of the whole opcheck logic, but perhaps @zou3519 has an idea?

Unfortunately, for now we cannot really use optests on the torchvision test suite. Note that we can't just put `TestPSRoIAlign.test_faketensor__test_forward` without the `[...]` part in the `failure_dict`, because that test actually passes on cpu and cuda, which would lead to an "unexpected success".

cc @zou3519
Repository: ant-design
Issue: Dropdown autoAdjustOverflow 逻辑
Labels: 🐛 Bug,Inactive,unconfirmed

### Reproduction link

[https://stackblitz.com/edit/react-t8fkvg?file=demo.tsx](https://stackblitz.com/edit/react-t8fkvg?file=demo.tsx)

### Steps to reproduce

对于第二个"bottom"按钮，把预览窗口拖的比较窄，小于dropdown 内容， mouseover "bottom"按钮，dropdown出现遮挡

### What is expected?

虽然设置了 topRight, autoAdjustOverflow 应该把这种left还是 right 都会遮挡的情况变成 center之类的

### What is actually happening?

dropdown出现遮挡

| Environment | Info |
| --- | --- |
| antd | 5.10.2 |
| React | 18.2.0 |
| System | Macos 14.1 |
| Browser | Chrome 118 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: material-ui
Issue: [material-ui][Select] Adding `<fieldset disabled>` doesn't disable it
Labels: component: select,package: material-ui,enhancement

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/friendly-dijkstra-g62dv9?file=/src/Demo.js

Steps:
1. add "disabled" to a <fieldset> surrounding a select component

### Current behavior 😯

The form element is active

### Expected behavior 🤔

Form element should be disabled like the rest of the elements when the fieldset is marked disabled

### Context 🔦

I need to disable all form elements on page with a huge form.

I think I'm also supposed to mention we have a license: Order #72705

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 14.0
  Binaries:
    Node: 20.3.0 - ~/.nvm/versions/node/v20.3.0/bin/node
    Yarn: 3.2.2 - /opt/homebrew/bin/yarn
    npm: 9.6.7 - ~/.nvm/versions/node/v20.3.0/bin/npm
  Browsers:
    Chrome: 118.0.5993.70
    Edge: Not Found
    Safari: 17.0
```
</details>
Repository: go
Issue: x/tools/gopls: fails to find new std library APIs dynamically
Labels: gopls,Tools,gopls/imports

Reminder issue, following up on #63641: it appears that gopls was not finding the new slices package in `GOROOT` until the `ztdlib.go` index was updated. But according to @heschi this index is meant to just be a cache. We should debug why dynamic scanning of GOROOT was not working.
Repository: godot
Issue: Correctly type hinted methods do not show up in the method picker when connecting signals with type hints for custom classes.
Labels: bug,topic:gdscript,topic:editor

### Godot version

4.2.beta3

### System information

Windows 11

### Issue description

The method picker for connecting signals in the editor will filter out correctly type hinted methods if the signal's arguments have a custom class type hint. It only shows up if you disable "Compatible Methods Only".

### Steps to reproduce

Write a custom class, like "CustomData".
If you write this signal on a node:
  signal custom_data_updated (custom_data: CustomData)

And then write this method on another node:
  on_data_updated(custom_data: CustomData) -> void:

That method will not show up when picking a method from that node to connect to the signal. It only shows up if you turn off "Compatible Methods Only".

### Minimal reproduction project

[CustomClassSignal.zip](https://github.com/godotengine/godot/files/13190214/CustomClassSignal.zip)
Repository: godot
Issue: Visual Shader Albedo appears desaturated/lightened from Color variables, except when using ColorParameter with Qualifier set to Instance (Vulkan Forward+)
Labels: bug,topic:shaders

### Godot version

v4.1.2.stable.official [399c9dc39]

### System information

Godot v4.1.2.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Laptop GPU (NVIDIA; 31.0.15.3699) - AMD Ryzen 9 5900HX with Radeon Graphics (16 Threads)

### Issue description

VisualShader ColorConstant appears washed out compared to ColorParameter Instance

### Steps to reproduce

- Add a mesh to 3d scene
- Add a new visual shader to the mesh
- edit the visual shader: create a colorConstant node and map to albedo output
- compare using the same color (same raw vec4 values) default value on a colorParameter node mapped to albedo output
   - compare setting Qualifier: None and Qualifier: Instance 

### Minimal reproduction project

[ColourTest.zip](https://github.com/godotengine/godot/files/13190309/ColourTest.zip)
Repository: rust
Issue: Library documentation being created despite `lib.doc = false` setting
Labels: T-rustdoc,C-bug

<!--
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.
-->

The `tetromino` crate has the following settings:
https://github.com/d-e-s-o/tetromino/blob/fb5b5e05d7cfe08d71a8490f50d40d3be5e8078c/Cargo.toml#L29-L31

The `lib.doc` field, specifically, is [documented](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-doc-field) as:
> The doc field indicates whether or not the target is included in the documentation generated by [cargo doc](https://doc.rust-lang.org/cargo/commands/cargo-doc.html) by default.

When I build the documentation locally it seems to work reasonably fine: I don't see anything from `lib.rs` in said documentation:
![screenshot-2023-10-27_08-09-09](https://github.com/rust-lang/rust/assets/6610056/b6aa95f6-02cc-4e7a-96ec-6aa2d54bde20)

However, after publishing this crate, [documentation](https://docs.rs/tetromino/0.1.2/tetromino_impl/) looks different:
![screenshot-2023-10-27_08-10-44](https://github.com/rust-lang/rust/assets/6610056/9185c846-c24a-4233-9412-109509ff2e41)

Namely, I see *only* stuff from there. I am confused by this behavior. Is that because it's a crate with both a main and a lib? But why the divergence between local and remote? What is docs.rs doing differently?

Does it have to do with this clause? (which really should *not* apply here because both are named differently, actually)
> Note: The binary will be skipped if its name is the same as the lib target.

If so, then, again, why the divergence? I'd really wish for things to be testable locally and then have the same effect everywhere.

Can somebody comment on the expected behavior, please?

### Meta
<!--
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.
-->

`rustc --version --verbose`:
```
rustc 1.73.0-nightly (cc66ad468 2023-10-03) (gentoo)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: x86_64-unknown-linux-gnu
release: 1.73.0-nightly
LLVM version: 17.0.2
```
Repository: node
Issue: Synchronous exceptions in ES modules are always 'caught'
Labels: inspector,esm

### Version

20.3.1

### Platform

Darwin mbp.peet.io 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:39:52 PDT 2023; root:xnu-8796.141.3.700.8~1/RELEASE_X86_64 x86_64

### Subsystem

inspector

### What steps will reproduce the bug?

1. Start a program containing `throw new Error('foo');` in an ES module
2. Attach a debugger, like devtools or VS Code's debugger, and enable "pause on uncaught exceptions"
3. Run the program

### How often does it reproduce? Is there a required condition?

100%

### What is the expected behavior? Why is that the expected behavior?

The runtime should pause on the `throw` line

### What do you see instead?

The runtime does not pause and the program exits

### Additional information

First reported in https://github.com/microsoft/vscode-js-debug/issues/1861

Guessing this is because module evaluation is in a try/catch. Wonder if there's any machinery that can be used to mark containing exceptions as uncaught

https://github.com/nodejs/node/blob/0a0b8dfd0d3684d6602599e1f0d9d935b3758700/lib/internal/modules/esm/module_job.js#L217-L219
Repository: go
Issue: x/crypto/ssh: support service names in Client.Dial with net.LookupPort 
Labels: Proposal,NeedsInvestigation,FeatureRequest

Add support for service names additional to port numbers to `ssh.Client.Dial`.

PR: https://go.dev/cl/443775 (https://github.com/golang/crypto/pull/235)

`net.Dial` already supports this same, this proposal adds that same feature to `ssh.Client.Dial`.

Currently `ssh.Client.Dial` uses `strconv.ParseUint` to convert a port number as string into the int type it needs.
The proposal is to use `net.LookupPort` instead.

`net.LookupPort` is purpose build for interpreting strings as ports and has the additional feature that it also supports service names.
Repository: angular
Issue: HttpClient: Allow HttpInterceptors to modify the original HttpParams before converting them to strings
Labels: area: common/http

### Which @angular/* package(s) are relevant/related to the feature request?

common

### Description

In `HttpParams`, defer conversion of `options.fromObject` to strings to allow interceptors to modifiy those while they have the original type/value.

### Proposed solution

Move conversion from `constructor` to `toString`.

### Alternatives considered

Instead of moving conversion to `toString`, another method may be defined to contain this conversion and invoked only once. Not sure, as `toString` may access them before this conversion.