sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Custom Shader: Lighting artifacts are produced just outside of the area of effect of Spotlights and Omnilights
Labels: enhancement,documentation,topic:shaders

### Godot version

Godot 4 rc1

### System information

Windows 10, Vulkan, NVIDIA GTX 1660

### Issue description

It's likely that I configured something incorrectly, but I'm using a custom lighting shader and objects that are outside of the area of effect of spotlights and omnilights get lighting artifacts:
![image](https://user-images.githubusercontent.com/6559151/218334888-02222313-9fb6-4079-b803-8489e0790a6e.png)

This is the shader code:
```
shader_type spatial;
render_mode diffuse_toon, specular_toon;

group_uniforms Textures;

	uniform vec4 base_color : source_color = vec4(1.0, 1.0, 1.0, 1.0);

group_uniforms;


group_uniforms LightingAndShadows;

	uniform float attenuation_strength : hint_range(0.0, 1.0, 0.01) = 0.8;
	uniform float shadow_edge : hint_range(0, 2.0, 0.01) = 0;
	uniform float light_edge : hint_range(0.01, 2.0, 0.01) = 0.3;
	
group_uniforms;


void fragment() {
	ALBEDO = base_color.rgb;
}

void light() {
	// Attenuation
	float attenuation = mix(clamp(ATTENUATION, 0.0, 1.0), 1.0, 1.0 - attenuation_strength);
	
	// Diffuse
	float NdotL = dot(NORMAL, LIGHT);
	float diffuse = clamp(NdotL, 0.0, 1.0);
	diffuse = smoothstep(shadow_edge, light_edge, diffuse);
	
	// Light color
	vec3 light_color = normalize(LIGHT_COLOR);
	
	DIFFUSE_LIGHT += diffuse * attenuation * ALBEDO * light_color;
}
```

### Steps to reproduce

1. Create an object that uses a material with the toon.gdshader
2. Add either a spot light or an omni light, place the object just outside of the area of effect of the light; where it shouldn't be light, but is close to the border.
3. This produces lighting artifacts

### Minimal reproduction project

[CustomShaderLightingBug.zip](https://github.com/godotengine/godot/files/10717219/CustomShaderLightingBug.zip)
Repository: godot
Issue: ExitTree no longer called with NotificationWMCloseRequest
Labels: bug,discussion,topic:core,topic:porting

### Godot version

4.0.rc1.mono

### System information

Windows 11 Vulkan

### Issue description

Back in Godot 3, ExitTree would be called on OS application close requests, not just when queue_free()'ing the node.

However, this is no longer the case. I don't know if this was intended for newer versions of Godot.

Instead of using ExitTree it's possible to listen for the NotificationWMCloseRequest notification, so it's not that big of an issue.

### Steps to reproduce

Override _ExitTree(). Start the game and close it, _ExitTree() will not be called.

### Minimal reproduction project

[Test.zip](https://github.com/godotengine/godot/files/10717204/Test.zip)
Repository: TypeScript
Issue: Show jsdoc for `keyof` when used as a parameter.
Labels: Suggestion,Help Wanted,Domain: Completion Lists,Experience Enhancement

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

* keyof jsdoc
* "keyof jsdoc"

## ✅ 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 -->

When using `keyof` as a parameter for a function and the key has `jsdoc`, it would be nice if the `jsdoc` would show with the completion item in the editor. Currently it only shows the the item and no description of the item.

## 📃 Motivating Example

```typescript
export interface ExampleInterface {
  /** Description of example 1. */
  example_one: string;
  /** Description of example 2. */
  example_two: string;
}

function example(usage: keyof ExampleInterface) {
  // Do something
}

// Show description of item in editor (`|` represents the cursor).
example('example_t|')
```

## 💻 Use Cases

With a library, the user may not know what the values mean without doing research. It would help if they could see the jsdoc for the item.

As seen here where something such as `_ansestor` has a meaning that someone may not know what it means without doing a web search.

![image](https://user-images.githubusercontent.com/1571806/218340045-f0dcfa1c-bff2-4691-8e55-3bf863978150.png)
Repository: excalidraw
Issue: Feature: add "replace color" option
Labels: enhancement,discussion

Hi there.

I'm loving the website. It's been already extremely useful for me. So thank you very much for your work!

I wanted to suggest that you add an option to replace colors. Sometimes I prepare a diagram and end up with a not so nice looking color palette. So I have to go element by element and change them to see the result. And if I messed up choosing the colors, I have to do it all over again until I get the right combination or I run out of time or energy. So this would save me a good amount of both.

Probably not a first priority feature, but hoping to see it live some day.

Thanks again!
Repository: godot
Issue: resizing a shared RectangleShape2D using the editor gizmos doesn't propagate the position offset this change often introduce
Labels: discussion,topic:editor,usability

### Godot version

4.0.rc1

### System information

linux

### Issue description


[simplescreenrecorder-2023-02-13_00.08.43.webm](https://user-images.githubusercontent.com/71937306/218342865-64e3e7cf-f847-48eb-8042-5e61d2d1ebbb.webm)


- since 4.0 (I think?), the gizmo allows one to set the edge position rather than the rect size.
- As you can see, resizing the shape resource actually moves the CollisionShape2D node to compensate for this.
- this position offset isn't propagated to the other users of the resource, making them extend or shrink in both directions.
- imo, this is unwanted behavior. If the positions were corrected automatically, the worst that could happen is the CollisionShape not being rotated in the direction the user expects. The current behavior just feels wrong to me, and tedious to work around.

### Steps to reproduce

(see mrp)
1. add 2 CollisionShapes2D that share the same RectangleShape2D resource
2. resize one of them
3. notice that on the other node, the shape's edges grow in both direction

### Minimal reproduction project

[mrp_resize_rect.zip](https://github.com/godotengine/godot/files/10717561/mrp_resize_rect.zip)
Repository: godot
Issue: 4.rc1, Inc-decrement buttons remain hidden on property group fold/unfold
Labels: bug,topic:editor,topic:gui

### Godot version

v4.0.rc1.official [8843d9ad3]

### System information

Windows 10 22H2, Compatibility, Geforce GTX 550 Ti

### Issue description

In the `Inspector` panel, the increment and decrement buttons,
on the right side of some property input boxes.

Remain hidden if the property group is folded and unfolded,
when the input box is focused.

Issue observed in: v4.0.rc1.official [8843d9ad3]

Expected behavior observed in:
- v3.5.2.rc2.official [1a2bf3eb4]
- v3.5.1.stable.official [6fed1ffa3]

### Steps to reproduce

- open the attached project: [issue, inc-, decrement buttons remain hidden.zip](https://github.com/godotengine/godot/files/10717653/issue.inc-.decrement.buttons.remain.hidden.zip)
- in the `Inspector` panel, left-click on the property group: `Ordering` to unfold its properties.
Notice the increment and decrement buttons on the right side of the `Z Index` input box.
- left click to focus the `Z Index` input box
notice that the increment and decrement buttons became hidden,
and the input box's background color became highlighted (slightly brighter).
- left click twice on the property group: `Ordering` to fold and unfold its properties


### Expected
The `Z Index` input box should show the increment and decrement buttons on the right side.
And the input box's background color should return to the normal (slightly darker) unfocused color.


### Observed
The increment and decrement buttons remain hidden,
and the input box's background color remains highlighted (slightly brighter).


https://user-images.githubusercontent.com/13420573/218345129-12861d05-7669-4ca0-8ab0-1dcf25b21fbf.mp4

### The expected behavior is observed in 3.5.2.rc2 and 3.5.1.stable

https://user-images.githubusercontent.com/13420573/218345171-6a0a25c1-f2c7-467b-bfce-8d8974b995fd.mp4


### Minimal reproduction project

### v4.0.rc1.official [8843d9ad3]
[issue, inc-, decrement buttons remain hidden.zip](https://github.com/godotengine/godot/files/10717653/issue.inc-.decrement.buttons.remain.hidden.zip)

### v3.5.2.rc2.official [1a2bf3eb4]
[inc-decrement buttons visible after property group fold-unfold.zip](https://github.com/godotengine/godot/files/10717654/inc-decrement.buttons.visible.after.property.group.fold-unfold.zip)
Repository: rust
Issue: Run Miri on tests (ui? stdlib? vote now on your phones)
Labels: A-testsuite,T-compiler,T-bootstrap,A-miri

Thanks to the work of @matthiaskrgr we recently found UB in a handful of ui tests. That's... pretty bad. This was found by running Miri on the tests, so we should probably do that in CI.

Some of the tests are supposed to contain UB, such as tests which are checking that our ASan support works or tests that verify that our MIR opts do not exploit things that Miri says are UB. These tests should have an annotation that verifies that Miri emits `error: Undefined Behavior` when run on them.

And some of our tests do not run under Miri, for various reasons. Some of them ICE due to features which are not completely supported yet in Miri, and if we don't already, we should expect that we have tests which use things that Miri does not support at all like FFI. So we should have another annotation that checks that Miri produces a non-UB kind of error.

I suspect the vast majority of tests will be good as-is, and defaulting to running Miri will reduce the amount of manual work required to start doing this.
Repository: rust
Issue: Miscompilation: Equal pointers comparing as unequal
Labels: A-LLVM,P-high,T-compiler,I-unsound,WG-llvm,I-miscompile,C-external-bug

I [tried this code](https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=9078cfb7b98e213bb02373f54e8b19b2):

```rust
pub fn foo() -> (usize, usize, bool) {
    let a: *const u8;
    let b: *const u8;
    {
        let v: [u8; 16] = [std::hint::black_box(4); 16];
        a = &(v[0]);
    }
    {
        let v: [u8; 16] = [std::hint::black_box(4); 16];
        b = &(v[0]);
    }
    (a as usize, b as usize, a == b)
}

fn main() {
    println!("{:?}", foo());
}
```

I expected to see this happen: Either the pointers (when cast to integers) are the same and the comparison is `true`, or they are not the same and the comparison is `false`.

Instead, this happened: It printed: `(140728325198984, 140728325198984, false)`

[Upstream LLVM issue](https://github.com/llvm/llvm-project/issues/45725)

### 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.
-->

Reproduced via `rustc +nightly -Copt-level=3 test.rs && ./test`.

`rustc --version --verbose`:
```
rustc 1.69.0-nightly (5b8f28453 2023-02-12)
binary: rustc
commit-hash: 5b8f284536d00ba649ca968584bedab4820d8527
commit-date: 2023-02-12
host: x86_64-unknown-linux-gnu
release: 1.69.0-nightly
LLVM version: 15.0.7
```

Also reproduces on master.

@rustbot label +I-unsound +T-compiler +A-llvm
Repository: transformers
Issue: Project_Test01
Labels: New model

### Model description

This model takes parameters - training data(optional) and rubrics(list of strings) to train. It gives us zero shot results for scoring logical reasoning answers provided by the students.

### Open source status

- [X] The model implementation is available
- [X] The model weights are available

### Provide useful links for the implementation

chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://arxiv.org/pdf/2301.08771.pdf
Repository: rust
Issue: E0507 suggestion for borrowing mistake inside of a macro suggests a syntax error
Labels: A-diagnostics,T-compiler

### Code

here's a minimal case -- a bit nonsensical but pulled out of a larger example


#### Cargo.toml

```toml
[package]
name = "wat"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
wat-derive = { path = "wat-derive" }
```


#### src/main.rs

```rust
use wat_derive::Example;

trait Example {
    fn f(&self);
}

#[derive(Example)]
struct S {
    x: Option<String>
}

fn main() {
    let s = S { x: None };
    s.f();
}
```

#### wat-derive/Cargo.toml

```toml
[package]
name = "wat-derive"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
quote = "1.0.23"
syn = "1.0.107"

[lib]
proc-macro = true
```


#### wat-derive/src/lib.rs

```rust
#[proc_macro_derive(Example)]
pub fn m(_input: proc_macro::TokenStream) -> proc_macro::TokenStream {
    quote::quote! {
        impl Example for S {
            fn f(&self) {
                // borrowing mistake here
                if let Some(v) = self.x {
                    dbg!(v);
                }
            }
        }
    }.into()
}
```


### Current output

```Shell
$ cargo build
   Compiling wat v0.1.0 (/home/asottile/workspace/pre-commit-rs/y/wat)
error[E0507]: cannot move out of `self.x` as enum variant `Some` which is behind a shared reference
 --> src/main.rs:7:10
  |
7 | #[derive(Example)]
  |          ^^^^^^^
  |          |
  |          data moved here
  |          move occurs because `v` has type `String`, which does not implement the `Copy` trait
  |
  = note: this error originates in the derive macro `Example` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider borrowing here
  |
7 | #[derive(&Example)]
  |          +

For more information about this error, try `rustc --explain E0507`.
error: could not compile `wat` due to previous error
```


### Desired output

anything else tbh -- I don't really know the correct thing to do here -- it would be nice if it pointed at the borrow error inside the macro-generated code, but I don't think `rustc` currently displays the generated code anywhere


### Rationale and extra context

_No response_

### Other cases

_No response_

### Anything else?

_No response_
Repository: rust
Issue: Confusing diagnostic message for a derive-macro implementation bug
Labels: A-diagnostics,T-compiler

### Code

```Rust
// the code is from THE BOOK
// https://doc.rust-lang.org/book/ch19-06-macros.html#how-to-write-a-custom-derive-macro
// but I forgot to append `!` to `stringify`, in the `hello_macro_derive/src/lib.rs/impl_hello_macro`.
// However, the `hello_macro_derive` crate was built successfully, but the `pancake` crate,
// which uses the derive-macro, was built failed with a confusing diagnostic message.

//
// pancake/src/main.rs
//
use hello_macro::HelloMacro;
use hello_macro_derive::HelloMacro;

#[derive(HelloMacro)]
struct Pancake;

fn main() {
    Pancake::hello_macro();
}

//
// hello_macro/hello_macro_derive/src/lib.rs
//
use proc_macro::TokenStream;
use quote::quote;
use syn;

#[proc_macro_derive(HelloMacro)]
pub fn hello_macro_derive(input: TokenStream) -> TokenStream {
    let ast = syn::parse(input).unwrap();
    impl_hello_macro(&ast)
}

fn impl_hello_macro(ast: &syn::DeriveInput) -> TokenStream {
    let name = &ast.ident;
    let gen = quote! {
        impl HelloMacro for #name {
            fn hello_macro() {
                println!("Hello Macro! This is {}", stringify(#name))
            }
        }
    };
    gen.into()
}
```


### Current output

```Shell
error[E0423]: expected function, found macro `stringify`
 --> src/main.rs:4:10
  |
4 | #[derive(HelloMacro)]
  |          ^^^^^^^^^^ not a function
  |
  = note: this error originates in the derive macro `HelloMacro` (in Nightly builds, run with -Z macro-backtrace for more info)
help: use `!` to invoke the macro
  |
4 | #[derive(HelloMacro!)]
  |                    +

For more information about this error, try `rustc --explain E0423`.
error: could not compile `pancakes` due to previous error
```


### Desired output

```Shell
`hello_macro_derive` crate should be failed to build due to `stringify`, since this does not pass the compilation in the normal crate.
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Anything else?

_No response_
Repository: pytorch
Issue: Option to bypass NOLA check in torch.istft
Labels: triaged,module: fft

### 🚀 The feature, motivation and pitch

The proposal is to add an option to skip the NOLA check during `istft` computation as the NOLA check causes host-device synchronization. 

This has been discussed in other issues regarding reconstruction with certain windows when `center=False` ( #62323, #91309), but my proposal is from a performance standpoint (https://discuss.pytorch.org/t/torch-istft-nola-check-causes-synchronization-and-massive-slow-down/172430).

 I understand that NOLA check is necessary for invertibility, but if we are certain about the NOLA condition then we should ideally have the option to bypass the check (and subsequent synchronization) in the `istft` function.

### Alternatives

_No response_

### Additional context

Below is the profiler trace for `istft`. As you can see, it spends almost the entire time in synchronization. While for standalone usage it might not be much of a problem, in the case when `istft` is part of a neural network, the synchronization really slows down the computations during training. 

![image](https://user-images.githubusercontent.com/12119806/218385260-06bc264d-c78d-45ed-8e5b-774c748aea48.png)

The above trace was obtained with the following code:

```
import torch
from torch.profiler import profile, ProfilerActivity

device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")

dummy_x = torch.randn(256, 7*44100, device=device)
dummy_spec = torch.randn(256, 2049, 302, device=device, dtype=torch.cfloat)

with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
             on_trace_ready=torch.profiler.tensorboard_trace_handler('./log'),
             schedule=torch.profiler.schedule(
                 wait=5,
                 warmup=1,
                 active=1),
             profile_memory=True,
             with_stack=True,
             record_shapes=True
             ) as prof:
    for _ in range(8):
        ispec = torch.istft(dummy_spec, n_fft=4096, hop_length=1024, length=dummy_x.shape[-1])
        prof.step()

```


cc @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano @peterbell10
Repository: deno
Issue: 'connection closed before message completed' with fetch
Labels: bug,needs info

deno 1.30.3 (release, aarch64-apple-darwin) (Apple M1)
v8 10.9.194.5
typescript 4.9.4

'connection closed before message completed' when using fetch, occurring sometimes locally (seemingly random), but always occurring on the 4th outbound fetch request in a Google Cloud Run First Generation service (reoccurs on 4th request when calling the endpoint again). Interestingly, in Cloud Run Second Generation the issue does not occur.
* Locally was not using Docker - running Deno directly on host

[GCP article about First Generation vs Second Generation](https://cloud.google.com/run/docs/about-execution-environments). Maybe most interestingly, 'The second generation execution environment provides full Linux compatibility rather than system call emulation.'

Will try create a reproduction sometime this week.
Repository: kubernetes
Issue: [Proposal] Run once daemonSet (daemonJob) support in Kubernetes
Labels: sig/node,kind/feature,sig/apps,lifecycle/stale,needs-triage,wg/batch

### What would you like to be added?

I: Motivation:

We have some per-node setup works in our platform when provisioning new nodes, but they should operate as an one-shoot manner, so we tried:
- `daemonSet`, but pods will not run-to-complete, this is not fully what we want. But yes, it can work like idling in a sleep-loop when initialization works finished
- `batchv1.Job`, we achieved this goal by setting job's `parallelism`(equal to the nodes total number) and injecting `podAntiAffinity` to avoid replicas being allocated in the same node. But when scaling up, we have to re-apply the job and also exclude the former nodes.

We seek the solutions from the community, and found this is widely required, see, maybe more:
- https://github.com/kubernetes/kubernetes/issues/64623 
- https://github.com/kubernetes/kubernetes/issues/50689
- https://github.com/kubernetes/kubernetes/issues/69001

II: Alternatives:

We also find other ways the community is struggling with:
- daemonSet with initContainer, normal container will run with a pause pod to keep alive.
- automation suite like Ansible.
- Weird ways like making pods unschedulable after running once, see https://www.sl.id.au/posts/kubernetes-run-pod-once-per-node/
- Implement the controller self, like https://openkruise.io/docs/user-manuals/broadcastjob/, but this will absolutely lead to the wheel of reimplements in the community.
- leverage static pods

III: Proposal

OPT-1. Add a new Job API named like daemonJob(mostly like the daemonSet, but will maintain some features as batchv1.Job), just like deployment vs daemonSet. It behaves as:

- ensures that all or a sub-set of Nodes run a copy of a run-to-complete Pod
- as nodes are added to the cluster, Pods are added to them
- as nodes are removed from the cluster, those Pods are garbage collected
- deleting a DaemonJob will clean up the Pods it created.


OPT-2. Add a `runOnce` policy to daemonSet, when pod completes, it will not restart anyway. But I think daemonSet is designed for long-running workloads, so prefer not.

IV: Other requirements related:
- https://github.com/kubernetes/kubernetes/issues/36601

### Why is this needed?

- Met the setup/cleanup demands of run-once pod in all nodes
- prevent reimplementing the wheel

🌟 Google doc: https://docs.google.com/document/d/1QnAre0Eh8yaDxAnm_3ZrOhbE3d0J-BuieLa25_jzMOE/edit#heading=h.xgjl2srtytjt