sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Confusing error when metavariable expressions are used outside of reptitions
Labels: A-diagnostics,T-compiler,requires-nightly,F-macro_metavar_expr

Currently when a metavariable expression is used outside of any repetitions, it produces a somewhat cryptic error message instead of saying its not within a repetitions, example:

```rust
#![feature(macro_metavar_expr)]

macro_rules! f {
    ($n:ident) => {
        ${length()};
    }
}

fn main() {
    f!(a);
}
```
```
error: length depth must be less than 0
 --> src/main.rs:5:10
  |
5 |         ${length()};
  |          ^^^^^^^^^^
```
Repository: godot
Issue: dFdx and dFdy behave in reverse
Labels: discussion,topic:rendering,topic:shaders

### Godot version

Godot 4.0 3d8c971ff8936a7c57bdae536d050207077a9427

### System information

Windows 10 64 bits GLES3 GeForce GTX 1060 6GB/PCIe/SSE2

### Issue description

I've been using the following piece of shader code to make smooth meshes non-smooth:
```glsl
NORMAL = normalize(cross(dFdx(VERTEX), dFdy(VERTEX)));
```
However it appears Godot 4 behaves in reverse:
![image](https://user-images.githubusercontent.com/1311555/165870580-75572b81-d51f-4fa6-b87d-cd16f99fa721.png)


### Steps to reproduce

Create a `MeshInstance` with a `SphereMesh`, add a `DirectionalLight3D`, then add a shader to the mesh with the following code:
```glsl
shader_type spatial;

void fragment() {
	NORMAL = normalize(cross(dFdx(VERTEX), dFdy(VERTEX)));
}
```
Observe the shading of the sphere gets inverted.

Workaround: swap the code to `cross(dFdy(VERTEX), dFdx(VERTEX))`.

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: [JIT][Autocast] Batchnorm folding pass during freezing doesn't preserve types
Labels: oncall: jit

### 🐛 Describe the bug

The optimize_numerics pass in the freezing pass interferes with the types used by the autocasting freezing pass.

Autocast() during freezing will cast weights to half precision; but then FoldFrozenConvBatchnorm turns them into full precision, causing errors when the model is run. 

```python
import torch
from typing import Final
net = torch.nn.Sequential(torch.nn.Conv2d(3, 64, (3, 3), 1, 1, bias=False),
                                      torch.nn.BatchNorm2d(64),
                                      torch.nn.PReLU(64)).cuda().eval()
img = torch.randn(3, 3, 112,112).cuda()
with torch.cuda.amp.autocast(True):
    net = torch.jit.trace(net, img, check_trace=False)
    net = torch.jit.freeze(net)
print(net.graph)
feature = net(img)  # forward pass
```

Workaround for now - you can disable optimize_numerics during freezing with `torch.jit.freeze(model, optimize_numerics=False)`

thanks to @xsacha who found the issue & provided the repro

### Versions

master
Repository: pytorch
Issue: Random Generator for Dropout
Labels: feature,triaged,module: random

### 🚀 The feature, motivation and pitch

I am doing some study on dropout, and want to keep the same randomness for dropout, but may change randomness in other parts of the code.
Can we add rng as an extra argument for random generator of Dropout (like JAX did) so that we can have better control of randomness under specific study?

### Alternatives

_No response_

### Additional context

_No response_

cc @pbelevich
Repository: node
Issue: Document why `node:test` exists
Labels: doc

### Affected URL(s)

https://nodejs.org/api/test.html

### Description of the problem

# Background

The core module `node:test` was proposed in https://github.com/nodejs/node/issues/40954 and shipped at `Experimental` stability in 18.0.0 via https://github.com/nodejs/node/pull/42325. Dozens of people expressed support for the idea via 👍 reactions and written comments. The sentiment of commenters toward the feature is overwhelmingly supportive.

# Problem

TL;DR the questions asked in https://github.com/nodejs/node/issues/40954#issuecomment-1037512376 seem unanswered, reducing the likelihood that `node:test` becomes adopted.

It's unclear what problems the project aims to solve by including a test runner in core.

...or should I say—given the broad support shown by participants in https://github.com/nodejs/node/issues/40954 —that they're unclear to _me_. 😕

- If it's relevant, my background: I'm primarily a maintainer of Node.js applications, ~5 years of experience doing so, and am not a maintainer of any OSS.
- I'm unsure how "should X go in core?" questions are usually settled, or if there are heuristics that exist in docs somewhere or in the heads of regular contributors. I went looking and found https://github.com/nodejs/node/blob/68fb0bf553e2af3e0b61733d29e1e9ba7f73d9b2/doc/contributing/pull-requests.md#accept-that-there-are-different-opinions-about-what-belongs-in-nodejs, which doesn't address the question so much as COC concerns at the periphery of the question. The couple “sufficient to put a thing in core” criteria it does identify aren’t met by a testing framework.

@bcomnes had a comment here - https://github.com/nodejs/node/issues/40954#issuecomment-1037512376 - that resonated very much with me: It distilled and synthesized a lot of rough ideas that commenters had submitted up to that point. IMO his comment effectively highlights the _variety_ of goals that people might have for the module. It seems to me that the questions he raised remain unanswered.

cc @nodejs/test_runner (which I saw referenced in https://github.com/nodejs/TSC/issues/1194#issuecomment-1088280424 as a recently formed team)

meta note: My framing of this as a docs request might not be the best. If this is more suited as a Discussion or other type of issue, please let me know. Thanks.
Repository: godot
Issue: `clamp*` inconsistency when min > max
Labels: bug,topic:core

### Godot version

v4.0.alpha7.official [3e9ead05f]

### System information

Kubuntu 21.10

### Issue description

I noticed that `clamp` and `clampi`/`clampf` give different results if max > min:

```gdscript
print(clamp(-5, 10, 0)) # 0
print(clampi(-5, 10, 0)) # 10
```

The difference is because `clamp` doesn't use the `CLAMP` template:

https://github.com/godotengine/godot/blob/cbdc33bcf73090962e60c1cf5ee50a21b29e4bad/core/typedefs.h#L125-L128

https://github.com/godotengine/godot/blob/cbdc33bcf73090962e60c1cf5ee50a21b29e4bad/core/variant/variant_utility.cpp#L348-L386

I believe the inconsistency should be fixed and the behavior of the functions when min > map should be documented. Also the docs should mention the alternatives:

```gdscript
min(max(min_value, value), max_value) # max_value is more important
max(min_value, min(value, max_value)) # min_value is more important
```

What values should be returned here is a matter for discussion.

```gdscript
print(clamp(-5, 10, 0))
print(clamp( 5, 10, 0))
print(clamp(15, 10, 0))
```

Possible options:

1. Minimum value priority.
2. Maximum value priority.
3. Swap min and max if min > max.
4. Display warning/error.

### Steps to reproduce

```gdscript
@tool
extends EditorScript

func test(v: int, a: int, b: int) -> void:
    printt(
        clamp(v, a, b),
        clampi(v, a, b),
        clampf(v, a, b),
        a if v < a else (b if v > b else v),
        mini(maxi(a, v), b),
        maxi(a, mini(v, b)),
    )

func _run() -> void:
    test(-5, 0, 10) # 0   0   0   0   0   0
    test( 5, 0, 10) # 5   5   5   5   5   5
    test(15, 0, 10) # 10  10  10  10  10  10

    print()

    test(-5, 10, 0) # 0   10  10  10  0   10
    test( 5, 10, 0) # 0   10  10  10  0   10
    test(15, 10, 0) # 0   0   0   0   0   10
```

### Minimal reproduction project

_No response_
Repository: storybook
Issue: How to make the built output target be es5?
Labels: feature request,needs triage

How to make the built output target be es5?
It seems that the default output target is es6, and I can't change it. I have tried many times and I can't find the way to make the ouput target be es5.
Please give me some help. Thanks.

Storybook version: 6.4.22
React version: 17.0.2
Repository: kubernetes
Issue: tracker: improve the kubelet test coverage
Labels: sig/node,help wanted,good first issue,needs-triage

There is a strong and growing consensus in sig-node about the need of increasing the test coverage in the kubelet, improving the current testsuite about coverage and reliability. See for example the [April 26 sig-node meeting notes](https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.d9zp2j5jvkke) and the [April 27 sig-node CI subgroup meeting notes](https://docs.google.com/document/d/1fb-ugvgdSVIkkuJ388_nhp2pBTy_4HEVg5848Xy7n5U/edit#heading=h.2v8vzknys4nk).

This work has already begun and there are already some PR posted (see: https://github.com/kubernetes/kubernetes/pull/108024#pullrequestreview-954083698). This is a great start. There are more areas in the kubelet, especially in the container manager and resource manager area, that can use better unit test coverage.

Besides the obvious benefits of documenting and preserving the current behaviour, adding tests is meant to lower the barrier for future work and contributions.

Examples of some areas which can benefit of more tests:

- k/k/pkg/kubelet/cm/internal_container_lifecycle.go
- k/k/pkg/kubelet/cm/internal_container_lifecycle_linux.go
- k/k/pkg/kubelet/cm/pod_container_manager_linux.go
- k/k/pkg/kubelet/cm/qos_container_manager_linux.go
- everything coverage-driven (check [test code coverage](https://go.dev/blog/cover) and build from there)
- error paths in general
-  e2e tests in general
Repository: storybook
Issue: LinkTo component does not apply storybook MDX styles
Labels: feature request,needs triage

Currently @storybook/addon-links@6.4.22 does not apply any styling to anchor in a documentation using mdx for example.

Ideally, the anchor should inherit the same styling/css class as anchor created from mdx via `[name](URL)` synthax.

**Are you able to assist to bring the feature to reality?**
yes, I can...
Repository: angular
Issue: FormControl of html date-picker does not report errors for non-existent dates
Labels: area: forms,P3,bug

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

When a form-control is attached to an `input[type="date"]`, then invalid dates such as the non-existent 30.02.2022 can be manually entered without bringing it into an error-state.
It is not possible to recognize that an invalid date was entered using the form-control since it reports neither a value nor an error, even though the native input-element is in an invalid state!

The control is considered `valid` and has a value of `null` as if it would not have been filled by the user.
I would expect the form-control to have an error instead of beeing in a `valid` state.

![grafik](https://user-images.githubusercontent.com/104614401/165897868-5e55b323-ef1b-4dce-a4cd-ece71423293f.png)


### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-ivy-rqhjhr?file=src/app/app.component.html

### Please provide the exception or error you saw

```true
Eventhough the native input element is in an invalid state, the form-control does not report an error or beeing invalid!
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 13.3.4
Node: 14.18.2
Package Manager: npm 6.14.15
OS: win32 x64

Angular: 13.3.5
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1303.4
@angular-devkit/build-angular   13.3.4
@angular-devkit/core            13.3.4
@angular-devkit/schematics      13.3.4
@angular/cli                    13.3.4
@schematics/angular             13.3.4
rxjs                            7.5.5
typescript                      4.6.
```


### Anything else?

_No response_
Repository: vscode
Issue: View multiple debug consoles side by side in editor areas
Labels: feature-request,debug

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Example Scenario: cross referencing two related consoles.
- Debug Console 1: viewing attached Kubernetes Controller Manager (process A) debug logs
- Debug Console 2: viewing end to end tests (process B) debug logs which tests/triggers code in (process A) debug console 1.
Repository: ant-design
Issue: Form.Item 的 shouldUpdate 函数返回false 不会中断更新，造成死循环
Labels: 🐛 Bug,Inactive

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/antd-form-item-shouldupdate-9jtbev)

### Steps to reproduce
```
<Form.Item key = 'pSelect' name = 'pSelect' label="ZKSelect">
	<Select >
		<Option value="">请选择</Option>
		<Option value="c1">c1</Option>
		<Option value="c2">c2</Option>
	</Select>
</Form.Item>
<Form.Item key = 'linkSelect-2-noStyle' noStyle
	shouldUpdate={ (prevValues, curValues) => {
		return false;
		// return prevValues[`pSelect`] != curValues[`pSelect`] 
	}}
>
	{({ getFieldValue, setFieldsValue, isFieldTouched })=>{
		// 组件内容更新代码片段
		let svParent = getFieldValue('pSelect');
		let isOptParent = isFieldTouched('pSelect');
		// console.log("[^_^:20220427-1615-002]", isOptParent, pSelectValue);
		if(isOptParent){
			// 操作过上级节点
			let v = {'linkSelect-2':''};
			// form.setFieldsValue(v);
			form.resetFields(['linkSelect-2']);
		}

		return (
			<Form.Item key = {'linkSelect-2'} name = 'linkSelect-2' label="联动 linkSelect-2" >
				<Select>
					<Option value="">请选择</Option>
				</Select>		
			</Form.Item>	
		);
	}}
</Form.Item>
```

### What is expected?

shouldUpdate 返回 false 时不更新组件；即不执行 组件内容更新代码片段

### What is actually happening?

shouldUpdate 返回 false 时；执行了 组件内容更新代码片段

| Environment | Info |
| --- | --- |
| antd | 4.20.1 |
| React | 16.14.0 |
| System | macOS Monterey 12.2 |
| Browser | Chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: vscode
Issue: Loaded scripts view should use label service
Labels: debug,debt

Just came across this code:

https://github.com/microsoft/vscode/blob/2cf8ae8a1394e7428c840000a48c621f986a4660/src/vs/workbench/contrib/debug/browser/loadedScriptsView.ts#L335-L359

Isn't this something the label service should take over?

Especially since the label service already seems to be used here:

https://github.com/microsoft/vscode/blob/2cf8ae8a1394e7428c840000a48c621f986a4660/src/vs/workbench/contrib/debug/browser/loadedScriptsView.ts#L327

If the reason is that there is no formatter for the resource, please note that I recently pushed quite a few changes to produce good path labels even when no formatter is available, respecting remote environments etc.
Repository: create-react-app
Issue: 666
Labels: needs triage

If you have a general question about Create React App or about building an app with Create React App we encourage you to post in GitHub Discussions instead of this issue tracker. The maintainers and other community members can provide help and answer your questions there: https://github.com/facebook/create-react-app/discussions

If you're looking for general information on using React, the React docs have a list of resources: https://reactjs.org/community/support.html

If you've discovered a bug or would like to propose a change please use one of the other issue templates.

Thanks!
Repository: deno
Issue: Support reverse DNS API
Labels: public API,suggestion

Feature request to support address to name translation ("reverse DNS"), a.k.a. wrapper around https://man7.org/linux/man-pages/man3/getnameinfo.3.html (e.g. using https://docs.rs/dns-lookup/latest/dns_lookup/#getnameinfo) or equivalent, so that users of Deno can translate an IP and port into a hostname and service.

E.g. 

```ts
interface NameInfoRecord {
  hostname: string;
  service: string;
}

function Deno.resolveNameInfo(ipAddr: string, port: number): Promise<NameInfoRecord>;
```

_API shape and names just as example - suspect we can devise better alternatives! Answers on a postcard 🙃_

```ts
const { hostname, service } = await Deno.resolveNameInfo('127.0.0.1', 22);

console.log(hostname, service); // "localhost" "ssh"
```

---

This would provide a sibling to the existing [`Deno.resolveDns()`](https://doc.deno.land/deno/stable/~/Deno.resolveDns) API which offers DNS resolution currently.

This would increase parity with existing Node APIs:

- https://nodejs.org/api/dns.html#dnslookupserviceaddress-port-callback
- https://nodejs.org/api/dns.html#dnspromiseslookupserviceaddress-port

And is required to support the `dns` and `dns/promises` modules in the Deno std library compat layer.

---

**Alternatives considered**

1) PTR + service lookup

Could use `PTR` records with existing `Deno.resolveDns()` but more limited in capability (don’t get the port to service mapping without additional work) and requires the user or any wrapper to handle IPv4 vs IPv6 address construction (incl. hex for IPv6) - overheads / features that could be provided by core if use `getnameinfo`.

E.g.

```ts
const ipv4Results = await Deno.resolveDns("4.4.8.8.in-addr.arpa", "PTR");

console.log(ipv4Results); // [ "dns.google." ]
```

To then get the service information could write a wrapper in TS to either interrogate the services db direct (e.g. parse /etc/services), or spawn execution of `getservbyport`.

2) Overload `Deno.resolveDns()`

Introduce some faux record type, or just an overloaded interface where ip + port args internally mapped to getnameinfo like behaviour.

Complicates an otherwise stable and clear interface so leaning away from this kind of idea.
Repository: PowerToys
Issue: Schedule wake up and/or sleep the computer
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

A tool to schedule computer wake-up and/or sleep (similar to the "awake" tool).
With this tool it would be possible to schedule a time when the computer wakes up from sleep, or when to go to sleep. Obviously, if the computer is shut down, this tool would not be able to wake up it.
This tool would avoid having to mess with BIOS settings.

### Scenario when this would be used?

This would be useful in cases like in remote work, where you need to connect to your work computer. It is not necessary to have the computer on all the times waiting for incoming connections (with the awake PowerToys tool). Instead, the computer could be set to,for exemple, sleep at 9:00PM and wake at 7:00PM on weekdays, and sleep all the weekend.

### Supporting information

_No response_
Repository: terminal
Issue: [Epic] Improved High Contrast support
Labels: Area-Accessibility,Product-Terminal,Issue-Scenario,HCL-E+D,HCL-WindowsTerminal,A11ySev3,InclusionBacklog,InclusionBacklog-Windows TerminalWin32,A11yMAS,Disability-LowVision

_written and maintained by @carlos-zamora_
High contrast mode is something that Windows Terminal can just be smarter about. Here's a few ideas and relevant issues for this discussion...

## Features
- [ ] #3066 
- [ ] #14940
- [x] Color scheme should leverage Delta E algorithm from #11095 to improve contrast
- [ ] Transparency should automatically be disabled

## Other relevant issues
### High Contrast-specific
- [x] #13070 
- [x] #13069 
- [x] #13068 
- [x] #13067 
- [x] #13065
- [x] #11257


### High Contrast-adjacent
- #3327 
- #7118
Repository: terminal
Issue: [megathread] Snippets
Labels: Product-Terminal,Needs-Tag-Fix,Issue-Scenario

_maintained by @zadjii-msft_


```[tasklist]
### 1.22 Tasks
- [x] #1595
- [x] #16063
- [x] #15664
- [x] #17329
- [x] #17330
- [x] #17388  Add support for local snippets (`.wt.json`, `.wtconfig`)
- [x] #16513
- [x] https://github.com/microsoft/terminal/issues/12857
- [x] https://github.com/microsoft/terminal/issues/17366
```
```[tasklist]
### 1.23
- [ ] #17805
- [ ] Search results existing inside nested snippets should expand them
```


### WIP Branches:

* Local snippets:
  * [`dev/migrie/fhl/local-tasks-2024`](https://github.com/microsoft/terminal/tree/dev/migrie/fhl/local-tasks-2024) was the branch from the last day of Spring FHL 2024, but that branched off the md-pane prototype.
  *  ~[`dev/migrie/f/just-local-tasks`](https://github.com/microsoft/terminal/tree/dev/migrie/f/just-local-tasks)~ is me trying to isolate that commit
  * [`dev/migrie/f/just-local-snippets`](https://github.com/microsoft/terminal/tree/dev/migrie/f/just-local-snippets) I started working on, till I realized I'd need to work on top of #17281
  *  [`dev/migrie/f/local-snippets-on-action-refactor`](https://github.com/microsoft/terminal/tree/dev/migrie/f/local-snippets-on-action-refactor)
      * I think https://github.com/microsoft/terminal/compare/dev/pabhoj/action_new_tab_menu...dev/migrie/f/local-snippets-on-action-refactor1 is ready, but turns out that `action_new_tab_menu` _didn't_ have main merged in, so the history is confusing now
      * https://github.com/microsoft/terminal/compare/dev/pabhoj/action_new_tab_menu...dev/migrie/f/local-snippets-cleaner has a cleaner delta, I think
    


### Related

* #15845 
* #17344
Repository: pytorch
Issue: `torch.linalg.cond` has different results for tensor requiring autograd
Labels: module: autograd,triaged,module: linear algebra

### 🐛 Describe the bug

`torch.linalg.cond` has different results for tensor requiring autograd if torch version is 1.11.0

```python
import torch
results = dict()
A_tensor = torch.rand([2485, 2485], dtype=torch.float32)

A1 = A_tensor.clone().detach()
results["res_1"] = torch.linalg.cond(A1)

A2 = A_tensor.clone().detach()
results["res_2"] = torch.linalg.cond(A2)

A3 = A_tensor.clone().detach().requires_grad_()
results["res_3_grad"] = torch.linalg.cond(A3)

print(results)
# {'res_1': tensor(1267001.1250), 'res_2': tensor(1267001.1250), 'res_3_grad': tensor(1266998.8750, grad_fn=<SqueezeBackward1>)}
```
They will output the same results when torch is 1.10.0

### Versions

torch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @jianyuh @mruberry @walterddr @IvanYashchuk @xwang233
Repository: godot
Issue: [3.x] Rendering thread synchronization in Particles (GLES3)
Labels: bug,topic:rendering,needs testing,performance,topic:particles

### Godot version

d62166f68f8a54520b102ab26b32bc8f37776ef9

### System information

OS: Arch Linux, CPU: Ryzen 5, GPU: RX 6600

### Issue description

Reading the "is_emitting" property in Particles nodes causes synchronisation of the main thread with the rendering thread.
The property is read internally at each frame for one-shot particles, always causing synchronisation.
In projects where both threads are under heavy load (like in mine), this will cause significant performance degradation.

The solution should be to cache the "is_emitting" property in the Particles object.

### Steps to reproduce

- Create a Particle node in a scene with emitting = false.
- Set it to "one-shot".
- Add enough load for both the rendering and the main thread.
- Add a script to activate the particle system after a delay.
- Run the scene and see the performance tank when the particle system is emitting.

### Minimal reproduction project

[particles_performace_test.zip](https://github.com/godotengine/godot/files/8590359/particles_performace_test.zip)