sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: `const { ... }` blocks cannot be written outside of function
Labels: A-diagnostics,C-bug,D-papercut,D-terse

I tried this code:

```rust
// error
const { assert!(size_of::<u32>() <= size_of::<usize>()) };

fn main() {
    //ok
    const { assert!(size_of::<u32>() <= size_of::<usize>()) };
}
```

I expected to see this happen: *it compiles*

Instead, this happened: *it doesn't compile*

```
error: expected item, found keyword `const`
 --> src/main.rs:2:1
  |
2 | const { assert!(size_of::<u32>() <= size_of::<usize>()) };
  | ^^^^^ expected item
  |
  = note: for a full list of items that can appear in modules, see <https://doc.rust-lang.org/reference/items.html>

error: could not compile `app` (bin "app") due to 1 previous error
```

### 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.82.0-nightly (2cbbe8b8b 2024-07-28)
binary: rustc
commit-hash: 2cbbe8b8bb2be672b14cf741a2f0ec24a49f3f0b
commit-date: 2024-07-28
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 18.1.7
```
Repository: pytorch
Issue: Implementation of a Q-RNN layer nn.QRNN(filters,kernel,stride,n_cnn,)
Labels: module: nn,module: rnn,triaged

### 🚀 The feature, motivation and pitch

Addition of Q-RNN layer might bring more exposure and experiment around the field to innovate parallel and efficient architectures

Q-RNN has a lot of potential in NLP and some Image and Video restoration process 
this will encourage a lot of people (especially non-researchers) to try out new things for their education and projects


cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: deno
Issue: package.json cannot resolve jsr dependencies from npm:vite inside workspace
Labels: needs investigation

Version: Deno 1.45.3

I am working on building a sveltekit project that can be developed in deno and ran in deno production. So far I have been able to get vite dev & vite build to work with a custom adapter. The code is here in a [barebones example repo](https://github.com/andykais/sveltekit-deno). The issue is that deno dependencies seem to behave differently inside a workspace. 


If I take the linked repo above and drop it inside a workspace in another repo I get errors like this 
```
failed to load config from /home/andrew/Code/development/forager/packages/web/vite.config.ts
error when starting dev server:
TypeError: npm package '@jsr/andykais__ts-rpc' does not exist.
    at file:///home/andrew/Code/development/forager/packages/web/vite.config.ts.timestamp-1722216203693-cbe5226eadf6e.mjs:2:27
    at async loadConfigFromBundledFile (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:66365:15)
    at async loadConfigFromFile (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:66206:24)
    at async resolveConfig (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:65816:24)
    at async _createServer (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:62432:18)
    at async CAC.<anonymous> (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/cli.js:735:20)
```

Where the simple top level deno.json might look like so:

```json
{
  "workspace": [
    "./packages/web"
  ]
}
```

I suspect this is because deno is not treating the current directory like a "node project", since I can achieve a similar error by adding a deno.json file to the current directory
Repository: kubernetes
Issue: Create New Test Cases for Pod Lifecycle Events
Labels: sig/node,kind/feature,triage/accepted

**What should be added?**
This issue focuses on writing new test cases that cover Pod lifecycle events in Kubernetes. The aim is to create a suite of tests that thoroughly document and validate the behaviours throughout the Pod lifecycle. These tests will ensure that Pods function correctly during various phases, including creation, deletion, probe handling, restart policies, and termination scenarios.

Tasks:
- [ ] Create a new directory structure to organise tests by area and behaviour: test/e2e_node/AREA/BEHAVIOUR-SHORTNAME_test.go
 
**Write test cases for the following Pod lifecycle behaviours:**

Pod Phases:

- [ ]  Pending 
- [ ]  Running
- [ ]  Succeeded
- [ ]  Failed
- [ ]  Unknown

Container States:

- [ ]  Waiting
- [ ]  Running
- [ ] Terminated

Lifecycle Hooks:

- [ ] postStart Hook
- [ ] preStop Hook

Probes:

 - [ ] Liveness Probe
 - [ ] Readiness Probe 
 - [ ] Startup Probe

Restart Policies:

 - [ ] Always
 - [ ] OnFailure
 - [ ] Never

Pod Termination

 - [ ] Graceful Termination
 - [ ] Forced Termination

CrashLoopBackOff

- [ ] Test how Kubernetes handles retries when containers fail repeatedly and enter backoff.

Pod Conditions:

- [ ] PodScheduled: 
- [ ] Initialised
- [ ] ContainersReady:
- [ ] Ready

Fault Recovery:

- [ ] Initial Container Failure
- [ ] Repeated Failures

Node Failure and Pod Eviction:

- [ ] Test what happens when Pods are evicted due to node failure or resource shortages.
Pod Garbage Collection:
- [ ] Test the behaviour of the Kubernetes garbage collector when removing terminated Pods.

Sidecar Containers and Pod Shutdown:

 - [ ] Test how Kubernetes handles the termination order of sidecar containers during Pod shutdown.

**Expected Outcome:**
A set of well-organised and documented test files that demonstrate key Pod lifecycle behaviours, ensuring Pods function as expected throughout their lifecycle.
Repository: godot
Issue: Unset properties of an "instantiated" scene (in-editor) override adjustments made in the inherited scene
Labels: bug,topic:core,confirmed

### Tested versions

v4.3.rc1.official [e343dbbcc]

### System information

Ubuntu

### Issue description

When using the ![image](https://github.com/user-attachments/assets/e23928e9-7e8f-40ac-8a73-2d8a95efea24) button to instantiate a child scene into an existing scene, then we expect this scene to inherit all of its property values from its ancestor scene unless and only unless we explicitly change them in the inspector of that instance.

Praying that it is not an intended change, this expectation is broken in 4.3 RC1. Now, when adjusting a property in the ancestor scene, Godot implicitly adds an override to the child scene for that property, causing the previous value to persist, meaning that the user has to now go through all instances of that scene to reset the property in question.

### Steps to reproduce

1. Create a clean project
2. Click the new scene button, select Control as root node, save the scene as `base.tscn`
3. Click the new scene button, click the ![image](https://github.com/user-attachments/assets/e23928e9-7e8f-40ac-8a73-2d8a95efea24) `Instantiate Child Scene` button and have it be based on the `base.tscn`, then save that scene as `inhertiting.tscn`
4. Click the new scene button, select Control as root node, then click the ![image](https://github.com/user-attachments/assets/e23928e9-7e8f-40ac-8a73-2d8a95efea24) `Instantiate Child Scene` button and add an instance of `inheriting.tscn` before saving this third scene as `level.tscn`
5. Go back to your `base.tscn` and for example, in the inspector change Mouse > Filter from Stop to Pass, then save the scene.
6. Switch to `level.tscn` and notice that despite never having set an explicit property override for Mouse > Filter, it is now overridden with Stop.

### Minimal reproduction project (MRP)

[godot_4_inherited_property_bug.zip](https://github.com/user-attachments/files/16413485/godot_4_inherited_property_bug.zip)

In this MRP, first verifiy that the child control node in `level.tscn` does not have an override for `mouse_filter` set (you can also check the tscn file in a text editor to confirm that it is void of any `mouse_filter` line). Then continue with reproduction step 5.
Repository: kubernetes
Issue: Update Documentation for Pod Lifecycle Tests
Labels: priority/awaiting-more-evidence,sig/node,kind/feature,sig/docs,lifecycle/rotten,needs-triage

**What would you like to be added?**
This issue involves updating the Kubernetes documentation to include details about the new Pod lifecycle tests. Each test should be documented with clear explanations and cross-referenced with its corresponding test file in the Kubernetes repository.

**Tasks:**
- [ ] Create a new markdown file to document Pod lifecycle tests.

Document Pod Phases:
- [ ] Document the Pending phase test 
- [ ] Document the Running phase test 
- [ ] Document the Succeeded phase test 
- [ ] Document the Failed phase test 
 - [ ] Document the Unknown phase test 
 
 Document Container States:
 - [ ] Document the Waiting state test 
 - [ ] Document the Running state test 
 - [ ] Document the Terminated state test 
 
 Document Container Lifecycle Hooks:
 - [ ] Document the postStart hook test 
 - [ ] Document the preStop hook test 
 
Document Probes (Health Checks):
 - [ ] Document the Liveness Probe test
 - [ ] Document the Readiness Probe test 
 - [ ] Document the Startup Probe test 
 
Document Restart Policies:
 - [ ] Document the Always restart policy test
 - [ ] Document the OnFailure restart policy test 
 - [ ] Document the Never restart policy test 
 
Document Pod Termination:
 - [ ] Document the Graceful Termination test 
- [ ]  Document the Forced Termination test 
 
Document CrashLoopBackOff:
 - [ ] Document the CrashLoopBackOff test 
 
 Document Pod Conditions:
 - [ ] Document the PodScheduled test 
 - [ ] Document the Initialised test.
 - [ ] Document the ContainersReady test 
 - [ ] Document the Ready test 
 
 Document Fault Recovery:
- [ ] Document the initial container failure test 
 - [ ] Document the repeated failures test 
 
Document Node Failure and Pod Eviction:
 - [ ] Document the node failure test 
 
Document Pod Garbage Collection:
 - [ ] Document the PodGC test 
 
Document Sidecar Containers and Pod Shutdown:
- [ ]  Document the sidecar termination order test

**Why is this needed?**

This documentation is essential for enhancing the understanding and testing of Pod lifecycle transitions, as described in issue #126369.
Repository: kubernetes
Issue: Implement Auto-Generation of Documentation from Test Cases
Labels: sig/node,kind/feature,lifecycle/rotten,needs-triage

### What would you like to be added?

Description:
The goal of this issue is to create a script that can auto-generate documentation from the comments in the test cases. This will ensure that the documentation is always up-to-date with the latest tests and reduce the manual effort required to maintain it.

Tasks:

- [ ] Create a script and place it in the hack directory.
- [ ] Ensure the script extracts comments from test files and generates an indexed set of test cases. 
- [ ] Hand document the detailed behavior for Pod lifecycle events, including pod specs and evaluation conditions.
- [ ] Integrate the script to append or link the extracted information to the relevant sections of the documentation
- [ ] Test the script to ensure it correctly extracts comments and updates the documentation.
- [ ] Review and refine the generated documentation for clarity and completeness.
- [ ] Gather feedback from the Kubernetes community and refine the approach based on the feedback.
- [ ] Consider integrating the script into the CI pipeline if necessary, ensuring it runs on new commits.


Expected Outcome:
A script that automatically generates an indexed set of test cases from comments in test files, with the ability to append or link this information to relevant sections of the documentation. The documentation is kept up-to-date with continuous updates, either through manual processes or CI pipeline integration based on feedback.

### Why is this needed?

This issue is a key part of issue to improve pod lifecycle transitions testing and documentation, as detailed in [issue #126369](https://github.com/kubernetes/kubernetes/issues/126369).
Repository: godot
Issue: GPUParticle2D Visibility and Crash Issues with gl_compatibility Rendering Method
Labels: bug,platform:ios,platform:android,needs testing,crash,topic:particles

### Tested versions

Godot 4.2.2 stable

### System information

 Samsung Galaxy M20 SM-M205N (Android 10), iPhone 15

### Issue description

* Android: GPUParticle2D is invisible when using the gl_compatibility Rendering Method.
* iPhone 15: Application crashes when using gl_compatibility with GPUParticle2D.
* GPUParticle2D works correctly with the mobile Rendering Method on both platforms.
* Previously, gl_compatibility was recommended to fix FPS drops on Android (ref: https://github.com/godotengine/godot/issues/94261).
* A similar issue was resolved by disabling shader cache (Project Settings -> General -> Rendering -> Shader Compiler -> Shader Cache -> Enabled), but this solution didn't work here. (ref: https://github.com/godotengine/godot/issues/82419)
* If this is related to "Shadow", "glow", and "DOF BLUR" not being available for OpenGL (mentioned in the same issue), are there any workarounds? For instance, avoiding certain process material settings?


### Steps to reproduce

1. Create a new Godot project.
2. Add particle_torch.tscn to the project.
3. Export the project for Android and iOS.

### Minimal reproduction project (MRP)

[ParticleBug.zip](https://github.com/user-attachments/files/16413780/ParticleBug.zip)
Repository: next.js
Issue: Docs: Doc is lying about query params for canonical segments
Labels: linear: docs

### What is the update you wish to see?

https://nextjs.org/docs/app/api-reference/functions/generate-metadata#url-composition

It is written here that 
> Trailing slashes between metadataBase and metadata fields are normalized.

This works well in most case as defined in example, but with query params not.

```ts
{
  "alternate": {
    "canonical": "./?someparams=true"
  }
}
``` 

end up with `https://someURL.fr/mypage/?someparams=true` when I want `https://someURL.fr/mypage?someparams=true` I guess it consider the next string to be a path segment where it's just query params.

Current workaround (using in my case next-intl)

```ts
import { getPathname } from "@modules/navigation";

// ...
 alternates: {
      canonical: `/${locale}/${getPathname({ locale, href: "/search" })}${searchParamsSerializer(params)}`, // Keep params
    },
```


### Is there any context that might help us understand?

When playing with canonical URL, sometimes you might want to exclude some query parameters (in search for example) and only generate a canonical URL with allowed parameters.

If URL contains query params A,B,C

And only A and B have effects on the search, I want to strip C from canonical URL.

### Does the docs page already exist? Please link to it.

https://nextjs.org/docs/app/api-reference/functions/generate-metadata#url-composition
Repository: deno
Issue: Deno panic while calling `fetch` `Result::unwrap()` after `Object.defineProperty`
Labels: bug

Hi, 
I want to report a Deno panic caused by `fetch` after changing `Array`'s property. It can reproduced by running the following code snippet: 

```javascript
 Object.defineProperty(Array.prototype, '1', {
  set: function () {
  }
});

const response = await fetch('https://example.com');
```

Deno output: 

```shell
Platform: macos x86_64
Version: 1.45.4
Args: ["deno", "run", "12.js"]

thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde_v8-0.208.0/de.rs:268:61:
called `Result::unwrap()` on an `Err` value: BadType { actual: "v8::data::Value", expected: "v8::data::Object" }
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: serde::de::impls::<impl serde::de::Deserialize for alloc::vec::Vec<T>>::deserialize
   4: deno_fetch::op_fetch::op_fetch<FP>::v8_fn_ptr
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```


Thanks,
Repository: godot
Issue: Local to Scene resources implicitly create overrides in inheriting scenes within the editor
Labels: bug,topic:core,topic:editor

### Tested versions

v4.2.2.stable.official [15073afe3]
v4.3.rc1.official [e343dbbcc]

### System information

Ubuntu

### Issue description

When a resource is flagged as Local to Scene and then its scene is used as a basis for a new scene using the ![image](https://github.com/user-attachments/assets/e23928e9-7e8f-40ac-8a73-2d8a95efea24) `Instantiate Child Scene` button, then for the child scene the resource is overriden in the editor. 

The point of the Local to Scene feature is that it creates an unique instance of the resource at the time of instantiation at runtime - it's not supposed to have any effect in the editor. If we would want this behavior, then we would use the "Make Unique" option on that resource instead.

Perhaps related to https://github.com/godotengine/godot/issues/94912

### Steps to reproduce

1. Create a clean project
2. Create a new scene with a `Panel` root node, in its `theme_override_styles/panel` property plug in a `StyleBoxFlat` (arbitrary example). Then save the scene as `base.tscn`.
3. Create a new scene and use the ![image](https://github.com/user-attachments/assets/e23928e9-7e8f-40ac-8a73-2d8a95efea24) `Instantiate Child Scene` to have it based on the `base.tscn`. Save it as `inheriting.tscn` and notice that `theme_override_styles/panel` property is derived from `base.tscn` as expected.
4. Back in the `base.tscn`, enable Local to Scene on the `StyleBoxFlat` resource.
5. Then in the `inheriting.tscn`, notice that the editor has now created an override for that resource.
6. When hitting the reset button on that stylebox panel override, saving, and re-opening `inheriting.tscn`, notice that the override is imposed once again.

### Minimal reproduction project (MRP)

[godot_4_local_to_scene_bug.zip](https://github.com/user-attachments/files/16414939/godot_4_local_to_scene_bug.zip)

In this MRP you can jump to reproduction step 6.
Repository: ant-design
Issue: Calendar cellRender  自定义单元格的延迟闪烁问题
Labels: Inactive,improvement

### Reproduction link

[![Edit on StackBlitz](https://developer.stackblitz.com/img/open_in_stackblitz.svg)](https://stackblitz.com/edit/react-sr8xe1?file=demo.tsx)

### Steps to reproduce

july and aug 月份切换的时候 cell 的闪烁比较明显

### What is expected?

没有闪烁

### What is actually happening?

单元格闪烁

| Environment | Info |
| --- | --- |
| antd | 5.18.0 |
| React | 18.2.0 |
| System | Windows |
| Browser | chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->


![无标题视频——使用Clipchamp制作](https://github.com/user-attachments/assets/307f2a4f-7eec-4705-a32b-4feb97646921)
Repository: tauri
Issue: [bug] unable to use 2024 edition because tauri-build reads Cargo.toml with old cargo_toml crate
Labels: type: bug,priority: 1 high,status: needs triage

### Describe the bug

unable to use 2024 edition

```
error: failed to run custom build command for `app v0.1.0 (/Users/anatawa12/tauri-2024/src-tauri)`

Caused by:
  process didn't exit successfully: `/Users/anatawa12/tauri-2024/src-tauri/target/release/build/app-2cd9b7cd989b4b2b/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=TAURI_CONFIG
  cargo:rerun-if-changed=tauri.conf.json
  cargo:rustc-cfg=desktop
  TOML parse error at line 11, column 11
     |
  11 | edition = "2024"
     |           ^^^^^^
  data did not match any variant of untagged enum Inheritable
  : TOML parse error at line 11, column 11
     |
  11 | edition = "2024"
     |           ^^^^^^
  data did not match any variant of untagged enum Inheritable

warning: build failed, waiting for other jobs to finish...
       Error failed to build app: failed to build app
```

### Reproduction

Create project with tauri cli and bump to 2024 edition

### Expected behavior

it should work

### Full `tauri info` output

```text
[✔] Environment
    - OS: Mac OS 14.4.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0-beta.2 (08328a323 2024-07-25)
    ✔ cargo: 1.81.0-beta.2 (a2b58c3da 2024-07-16)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: beta-aarch64-apple-darwin (default)
    - node: 20.12.2
    - pnpm: 8.15.4
    - yarn: 1.22.19
    - npm: 10.8.1

[-] Packages
    - tauri [RUST]: 1.7.1 (no lockfile)
    - tauri-build [RUST]: no manifest (no lockfile)
    - wry [RUST]: no manifest (no lockfile)
    - tao [RUST]: no manifest (no lockfile)
    - tauri-cli [RUST]: 1.5.14
    - @tauri-apps/api [NPM]: 1.6.0
    - @tauri-apps/cli [NPM]: 1.6.0

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: out
    - devPath: http://localhost:3030/
    - framework: React (Next.js)
    - bundler: Webpack
```


### Stack trace

_No response_

### Additional context

It looks parsing `Cargo.toml` is only for several checks so option to skip such a checks is one possible solution I think.

Rust 2024 is planned to be stabilized in rust 1.82.0 which will be released on October 17th so I tried them with nightly toolchain.
Repository: angular
Issue: API docs are missing info on generic type parameters
Labels: P3,area: docs

### Describe the problem that you experienced

I want to quickly look up whether a given class has any generic type parameters and if so, what the defaults of those are.

For example, I should be able to quickly see that the class `FormGroup` is actually defined as `FormGroup<TControl = any>`.

However, generics are not currently part of the displayed API docs.  This can be confusing because the documented class members may reference the generic type name (e.g., in this case `TControl`) with no clear indication of where that type name originates.

### Enter the URL of the topic with the problem

https://angular.dev/api/forms/FormGroup
Repository: rust
Issue: rustdoc converts byte literal discriminants into decimal numbers
Labels: T-rustdoc,C-bug,A-rustdoc-ui,T-rustdoc-frontend

<!--
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.
-->

For some code that generates my command prompt, I use a single ASCII character for the discriminant of an enum:

```rust
pub enum Permissions {
    Guest = b'%',
    User = b'$',
    System = b'@',
    Absolute = b'#',
}
```

However, rustdoc displays this as:

```rust
pub enum Permissions {
    Guest = 37,
    User = 36,
    System = 64,
    Absolute = 35,
}
```

Personally, I think that rustdoc should try to display the literal as it was originally written, rather than converting it to a plain integer.

### 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.
-->

`rustdoc --version --verbose`:
```
rustdoc 1.81.0-nightly (9057c3ffe 2024-07-19)
binary: rustdoc
commit-hash: 9057c3ffec44926d5e149dc13ff3ce1613b69cce
commit-date: 2024-07-19
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7
```
Repository: pytorch
Issue: Make C++ torch::autograd::Function support functorch
Labels: triaged,enhancement,module: functorch

In order to use a Python torch.autograd.Function with functorch, one must write an autograd.Function with separate forward and setup_context staticmethods. There is no way to do this for C++ torch.autograd.Function; we should add a similar mechanism. (https://pytorch.org/tutorials/advanced/cpp_autograd.html)

See following testcases: https://github.com/pytorch/pytorch/blob/main/torch/testing/_internal/autograd_function_db.py

cc @Chillee @samdow @kshitij12345 @janeyx99