sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Types should be inferrable across bit boolean operators
Labels: T-compiler,A-inference,T-types

I have not been able to find an issue documenting this (perhaps I haven't been looking for the right thing), but it is a bit surprising that type inference doesn't seem to carry across boolean operators well. Example code:

```rust
fn main() {
    let x: u8 = 100;              // setup
    let y: u32 = x.into();        // example
    let z: u32 = 1u32 | x;           // option 1
    let z: u32 = 1u32 | x.into();    // option 2
    let z: u32 = 1u32 | (x as u32);  // working solution

    println!("{y}");
}
```

With only option 1 enabled, we get the following:

```
error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
 --> src/main.rs:6:25
  |
6 |     let z: u32 = 1u32 | x;           // option 1
  |                         ^ expected `u32`, found `u8`
```

So, the compiler is aware of the expected type, seems like the perfect case for `into` rather than a cast. However, when switching to option 2:

```
error[[E0284]](https://doc.rust-lang.org/stable/error-index.html#E0284): type annotations needed
 --> src/main.rs:7:27
  |
7 |     let z: u32 = 1u32 | x.into();    // option 2
  |                       -   ^^^^
  |                       |
  |                       type must be known at this point
```

it is unable to infer the type. Which is a bit unexpected, because true booleans operators like `if true && 1u8.into()` work enough that it knows there is no `From<u8>` for `bool`.

Maybe there is some restriction for why this couldn't be implemented for all types, but it would be quite handy to have for integers.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: next.js
Issue: Next bundles language features newer than what browserlist should allow
Labels: bug,SWC

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```
    Operating System:
      Platform: linux
      Arch: x64
      Version: #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023
    Binaries:
      Node: 16.19.0
      npm: 8.19.3
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.1.7-canary.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
```

### Which area(s) of Next.js are affected? (leave empty if unsure)

SWC transpilation

### Link to the code that reproduces this issue

https://github.com/karl-run/next-bundle-bug-repro

### To Reproduce

1. Build the linked repro repo: `yarn && yarn build`
2. Observe that the output file `.next/static/chunks/pages/index-<hash>.js` has the following operator: `?.` included in the bundle.

### Describe the Bug

When a library ships unsupported language features, for example [optional chaining operator](https://caniuse.com/mdn-javascript_operators_optional_chaining) (not supported on Safari 12), Next will still bundle this operator, even though [the default browser list says Safari 12+](https://nextjs.org/docs/basic-features/supported-browsers-features).

A more specific scenario is that [filter-obj](https://github.com/sindresorhus/filter-obj/blob/main/index.js#L7) uses the [optional chaining operator](https://caniuse.com/mdn-javascript_operators_optional_chaining), and this was accidentally included in our bundle as part of a transitive of a transitive of a transitive dependency, so users on older iPhones suddenly started seeing white pages (except for the parts that were SSR-ed).

I have checked the behavior of other build pipelines, and default Vite and CRA setups both transpile away this operator when building for production.

We feel that this is a pretty serious bug, because it happens without any warning/crashing build. Even if the build would yell at me, so I could add `transpilePackages: ['filter-obj']` to `next.config.js`. But as it stands today, I won't know until someone discovers it.

### Expected Behavior

That no language features above what browserlist should allow end up in my production bundle, even though it comes from a library.
Repository: go
Issue: runtime: allocate no-escape map buckets to the stack more aggressively
Labels: Performance,NeedsInvestigation

## Context 
Whenever a map is created and identified as not escaping the called function,
I observe that the first bucket (8 entries) comes literally for free on the stack.

However, when the map is grown to a higher number of buckets (e.g. make(map[int]string,9) or grown dynamically),
the next buckets are allocated on the heap, then garbage-collected.

This makes a huge difference for relatively small maps, but not as small as the tiny 8 slots.

The same occurs, whether the map size is known or not known at compile time, yet correctly detected as not escaping the function.

## Proposal
I suggest allocating buckets of unescaped maps to the stack more aggressively and only resorting to the heap
when the stack is getting close to its max.

The criterion to switch from stack to heap should be determined at runtime and could be either when the stack is maxed out (super aggressive) or merely when allocating the new bucket would require a new stack segment (super conservative).

In either case, I believe this improvement would largely speed up the dozens of small map-based utility functions that we use routinely (see an example below).


## Example
In the 3 simplistic examples below (all inspired by real-life utilities, such as "deduplicate an input slice", but much simplified here...), the compiler correctly identifies the map as not escaping the func.

In all examples, if the input size (variable or const) is <= 8, no allocation on the heap takes place (the first bucket comes for free).
In all examples, if an extra bucket is needed, either by calling make with a hint or by growing the map, it is always allocated on the heap.

```golang
const ok = "ok"

// dynamic allocation, up to a capacity not known at build time
func mapAllocString(n int) int {
	index := make(map[int]string) // does not escape: ok

	for i := 0; i < n; i++ { // if n>8, dynamic allocation of new buckets occurs on the heap
		index[i] = ok
	}

	return len(index)
}

// pre-allocation with hint, up to a capacity not known at build time
func mapAllocMakeString(n int) int {
	index := make(map[int]string, n) // does not escape: ok if n>8, pre-allocation of new buckets occurs on the heap

	for i := 0; i < n; i++ {
		index[i] = ok
	}

	return len(index)
}

// pre-allocation with hint, up to a capacity known at build time
func mapAllocMakeConstString(_ int) int {
	const size = 32

	index := make(map[int]string, 32) // does not escape: ok if size>8, pre-allocation of new buckets occurs on the heap

	for i := 0; i < size; i++ {
		index[i] = ok
	}

	return len(index)
}
```
Repository: ant-design
Issue: Steps component Icons missalighnment 
Labels: help wanted,Inactive,unconfirmed

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/antd-reproduction-template-forked-vmfb9m?file=/index.js)

### Steps to reproduce

Use the "Steps" component with the property "size='small'"

### What is expected?

Step number aligned in the middle of the circle

### What is actually happening?

Steps number is misaligned to the bottom a little

| Environment | Info |
| --- | --- |
| antd | 5.1.6 |
| React | 18.2 |
| System | Windows |
| Browser | Chrome |

---
The issue is reproducible only on Windows machines. On Macs and Linux, everything was fine.
This is happening because of some specialties of the Font rendering.  Issue disappearing if we change line-height to 22px. But Ant component API doesn't provide such an option.
And changing line-height is not too reliable and can produce bugs on Macs and Linux then. 

We ovveride Ant style to use inline-flex on .ant-steps-item-icon with align and justify center.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: go
Issue: runtime: allow no-escape slices of unknown capacity to be allocated to the stack more aggressively
Labels: Performance,NeedsInvestigation

## Context

Whenever a slice is allocated with a variable capacity (e.g. make([]int, 0, n)), the compiler concludes it escapes to the heap,
even though the slice does not actually escape.

Examples:
```golang
func sliceAllocInt(n int) int {
	index := make([]int, 0) // does not escape, even though the append makes it allocate on the heap

	for i := 0; i < n; i++ {
		index = append(index, i)
	}

	return len(index)
}

func sliceAllocMakeInt(n int) int {
	index := make([]int, n) // escapes, since n is unknown

	for i := 0; i < n; i++ {
		index[i] = i
	}

	return len(index)
}

func sliceAllocMakeConstInt(_ int) int {
	const size = 32
	index := make([]int, size) // does not escape: size is known at build time: correctly allocated to the stack

	for i := 0; i < size; i++ {
		index[i] = i
	}

	return len(index)
}
```

Notice that this contrasts with escaping conclusions about similar constructs with maps:
* snippet (i) no escape, but will allocate on the heap because of the need to grow
* snippet (ii) escape (even if it actually doesn't), because the capacity to allocate is not known at build time
* snippet (iii): no escape & alloc on the stack as expected


## Proposal
I propose to adopt a more aggressive strategy to allocate slices on the stack whenever possible,
whether the capacity is known at build time or not.

Snippet (ii) should be detected as no escape (I believe it is at some point, and we revert to escaping because of the
variable capacity). This would make the escape analysis consistent with maps. 

The decision to allocate non-escaping slices to the stack or to the heap should be deferred to runtime,
favoring stack whenever the capacity fits and resorting to heap only for the larger slices.

At the very least, this should favor well-abiding functions that provide a predictable capacity in the call to make (such as snippet (ii)). Growing dynamically the slice is probably a case we could still leave to the heap.
Repository: godot
Issue: GDScript VM could theoretically jump outside of _code_ptr-buffer? (ip == _code_size)
Labels: discussion,topic:gdscript

### Godot version

master-branch, 2023-02-01, 5909f9f07547895de24fb6965d44c859b69a54a2

### System information

N/A

### Issue description

- Seems to me, the JUMP opcodes in the GDScript VM allows the `ip` to point beyond the`_code_ptr`-buffer?
- Example: https://github.com/godotengine/godot/blob/afe3b94ab28a28d562fd96f3daf41a22cb26757a/modules/gdscript/gdscript_vm.cpp#L2382
- Longer excerpt:
```c++
#define DISPATCH_OPCODE goto *switch_table_ops[_code_ptr[ip]]

// ...

OPCODE(OPCODE_JUMP) {
	CHECK_SPACE(2);
	int to = _code_ptr[ip + 1];

	GD_ERR_BREAK(to < 0 || to > _code_size);     // <---- This
	ip = to;
}
DISPATCH_OPCODE;
```
- Shouldn't it be:

```c++
	GD_ERR_BREAK(to < 0 || to >= _code_size);
```

- I haven't dug deeper into this, sorry. I could very well be understanding it wrong.
- Either way, there are more JUMP-opcodes and more comparisons with `_code_size` than shown above.

### Steps to reproduce

- This is all theoretical.

### Minimal reproduction project

N/A
Repository: vscode
Issue: SCM - add support for horizontal scrolling
Labels: feature-request,ux,scm

setting:

```json
"workbench.list.horizontalScrolling": true
```

```
Version: 1.74.3 (Universal)
Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534
Date: 2023-01-09T17:07:18.579Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin x64 22.3.0
Sandboxed: No
```

@lszomoru
Repository: next.js
Issue: Cannot serve files from node_modules using copy-webpack-plugin
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```
$ npx --no-install next info

    Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Home
    Binaries:
      Node: 18.12.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.1.7-canary.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
```

### Which area(s) of Next.js are affected? (leave empty if unsure)

Routing (next/router, next/navigation, next/link)

### Link to the code that reproduces this issue

https://github.com/jameshfisher/nextjs-fetch-node-modules

### To Reproduce

Use a `next.config.js` like this:

```js
const CopyPlugin = require("copy-webpack-plugin");

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config) => {
    config.plugins.push(
      new CopyPlugin({
        patterns: [
          {
            from: 'node_modules/pyodide/pyodide.asm.data',
            to: 'public/pyodide-data/',
          },
        ],
      }),
    );
    return config;
  },
  reactStrictMode: true,
}

module.exports = nextConfig
```

(Note: this approach was taken from [this answer](https://stackoverflow.com/a/71887848/229792).)

Run `npm run dev`. The copied files appear in `.next/public`:

```
$ find .next/public/
.next/public/
.next/public/pyodide-data
.next/public/pyodide-data/pyodide.asm.data
```

In the browser, open http://localhost:3000/pyodide-data/pyodide.asm.data

### Describe the Bug

The URL http://localhost:3000/pyodide-data/pyodide.asm.data resolves to a 404, despite the file at `.next/public/pyodide-data/pyodide.asm.data` existing.

### Expected Behavior

The URL http://localhost:3000/pyodide-data/pyodide.asm.data resolves to the file at `.next/public/pyodide-data/pyodide.asm.data` which was created by `copy-webpack-plugin` configured in `next.config.js`.

### Which browser are you using? (if relevant)

Chrome 109.0.5414.120 (Official Build) (64-bit)

### How are you deploying your application? (if relevant)

next dev
Repository: storybook
Issue: [Bug]: Decorator HMR does not re-render the story
Labels: bug,help wanted,builder-vite,sev:S3

### Describe the bug

**Setup**
* Storybook latest 7 beta across the board, with Vite as the builder
* Chakra UI v2.4.9 plus related dependencies
```
    "@chakra-ui/react": "^2.4.9",
    "@emotion/react": "^11.10.5",
    "@emotion/styled": "^11.10.5",
    "framer-motion": "^8.5.5",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
```

**Expected behavior**
When we update a Chakra theme file, the decorator should hot-reload and apply the new styling to the story.

**Observed behavior**
When we update the theme file, Vite hot-reloads the decorator but Storybook does not apply the changes.
Vite log: `11:51:47 [vite] hmr update /.storybook/ThemeDecorator.tsx`

**Other notes**
This works fine if we do the same process within our actual application, but specifically doesn't work in Storybook.


### To Reproduce

Reproduction repo: https://github.com/simon-poole/storybook-decorator-bug-demo

Key files: 
* `src/stories/Button.theme.ts`
* `src/theme.ts`
* `.storybook/ThemeDecorator.tsx` (referenced in `preview.ts`)
* `src/stories/Button.stories.ts`

I haven't published a Chromatic or similar because the bug is with HMR, so wouldn't apply to a published site.


### System

```shell
Environment Info:

  System:
    OS: macOS 13.2
    CPU: (8) arm64 Apple M1 Pro
  Binaries:
    Node: 16.16.0 - ~/.nvm/versions/node/v16.16.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.16.0/bin/yarn
    npm: 9.1.1 - ~/.nvm/versions/node/v16.16.0/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Safari: 16.2
  npmPackages:
    @storybook/addon-essentials: ^7.0.0-beta.38 => 7.0.0-beta.38
    @storybook/addon-interactions: ^7.0.0-beta.38 => 7.0.0-beta.38
    @storybook/addon-links: ^7.0.0-beta.38 => 7.0.0-beta.38
    @storybook/blocks: ^7.0.0-beta.38 => 7.0.0-beta.38
    @storybook/react: ^7.0.0-beta.38 => 7.0.0-beta.38
    @storybook/react-vite: ^7.0.0-beta.38 => 7.0.0-beta.38
    @storybook/testing-library: ^0.0.14-next.1 => 0.0.14-next.1
```


### Additional context

_No response_
Repository: godot
Issue: Physics process delayed when adding camera to viewport
Labels: bug,topic:physics

### Godot version

3.5.1.stable.arch_linux

### System information

Linux 6.1.8-arch1-1, Nvidia 3080 525.85.05-2, GLES3

### Issue description

I have a scene that already has a camera in it. That 3D scene is a child of a `Viewport` which is displayed to a `TextureRect`. That camera is `current`. When I add a second camera to that scene (non-current), the whole game hangs for ~500ms, meaning my next _physics_process call is ~500ms from the last one. Adding more cameras after that does not have any impact. If I remove the Viewport and rely on the builtin Viewport instead, the issue goes away. As far as I'm aware though, displaying a child viewport to a TextureRect is the suggested way to implement resolution scaling in Godot3.

My main script looks like this:

```
extends Control

onready var last_physics_frame := Time.get_ticks_msec()

func _unhandled_key_input(event: InputEventKey) -> void:
	if event.scancode == KEY_SPACE and event.is_pressed():
		var dup = Camera.new()
		get_tree().current_scene.add_child(dup)

func _physics_process(_delta: float) -> void:
	var time := Time.get_ticks_msec()
	var delay := time - last_physics_frame
	if delay > 200:
		print("Long physics delay ", delay, "ms")
	last_physics_frame = time
```

After pressing SPACE the first time, I see `Long physics delay 436ms`.

### Steps to reproduce

1. Open example project
2. Run `Main` scene
3. Press SPACE to spawn a new camera

### Minimal reproduction project

[example.zip](https://github.com/godotengine/godot/files/10556843/example.zip)
Repository: PowerToys
Issue: Fanzy Zones - shortcut + arrow for changing active window
Labels: Idea-Enhancement,Product-FancyZones

### Description of the new feature / enhancement

There is win + arrow shortcut for changing zone for active window, but it will be very usefull to have shortcut + arrow for toggling between windows in zones.

### Scenario when this would be used?

Much faster than alt + tab, where windows are showed not in order regarding to zones. Especially awsome feature for people who dont using mouse much.

### Supporting information

_No response_
Repository: next.js
Issue: Swiper sample does not work with Next 13 out of the box
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: linux
      Arch: x64
      Version: #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023
    Binaries:
      Node: 18.13.0
      npm: 9.4.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.1.7-canary.1
      eslint-config-next: 13.1.6
      react: 18.2.0
      react-dom: 18.2.0


### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue

https://github.com/Nefcanto/SwiperNext13Problem

### To Reproduce

Steps to reproduce:

Use this command to create a bare-bone Next 13 app:

`npx --yes create-next-app next --use-npm --js --eslint --no-src-dir --experimental-app --import-alias @/*`

Then remove the global style from `layout.js`.

Then replace the entire `page.js` content with Swiper's default example for react.

Add `'use client'` to the top of `page.js`

Now run using `npm run dev`.

You should see that slides are stacked one above the other.

### Describe the Bug

Swiper does not work with Next 13. The default React example of Swiper + 'use client' at the top of the page does not work.



### Expected Behavior

Swiper should work. Especially the default react example should work just by adding a simple 'use client' line to the top of the page.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_
Repository: transformers
Issue: How to sending my request about parameters in inference API?
Labels: New model

### Model description

<img width="999" alt="image" src="https://user-images.githubusercontent.com/61076726/216067290-7969e29b-8c83-41fa-80a6-6c71bc4bac16.png">

I can't find where I can modify, and, does generating inference not include beam search?

### Open source status

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

### Provide useful links for the implementation

_No response_
Repository: godot
Issue: `XMLParser` handles XML Declaration node incorrectly.
Labels: bug,topic:core

### Godot version

4.0.beta16

### System information

Linux 5.15.89-1 x86_64 (Manjaro XFCE)

### Issue description

Take the following XML as an example:
```xml
<?xml version="1.0" encoding="utf-8"?>
<library>
    <book name="Pirates" genre="sci-fi" author="pew;" />
    <bookseries book_count="2">
        <book name="ABC" genre="education" author="also pew;" />
        <book name="DEF" genre="education" author="also pew;" />
    </bookseries>
</library>
```
According to the [spec](https://www.w3.org/TR/xml/#sec-prolog-dtd), XML files begin with an XML declaration. When trying to parse it, Godot fails and gives `NodeType.NODE_UNKNOWN`, making a lot of the functions on `XMLParser` return invalid data. The core problem might be the nonexistence of something like `NodeType.NODE_XMLDECL`, but doesn't matter in most cases; an acceptable and convenient solution would be `XMLParser` treating XML declaration as an [empty element](https://www.w3.org/TR/xml/#dt-empty), but a separate node type would be nice too.

### Steps to reproduce

Try to parse the above XML and `print()` a few properties for the xml declaration node: you'll see a lot of weird and incorrect stuff, for example, `XMLParser.get_node_name()` returning `"?xml version="1.0" ..."`.

### Minimal reproduction project

[XMLParserIssue.zip](https://github.com/godotengine/godot/files/10558387/XMLParserIssue.zip)
Repository: PowerToys
Issue: File Locksmith Feature Request
Labels: Needs-Triage

### Description of the new feature / enhancement

If this is possible, enhance the utility to be able to sense what files are in use and by which processes on files contained in network shares.

### Scenario when this would be used?

As an I.T. Administrator I frequently need to edit or move files that are located on a server and find that they are open and in use.  Installing PowerToys on each server is not practical for me and having this ability would greatly simplify doing my job.

### Supporting information

_No response_
Repository: pytorch
Issue: Enable CUPTI
Labels: module: windows,triaged

Pytorch for Windows does not support CUPTI (Cuda Profiling Tools Interface) at this moment.
This is needed for Kineto (Pytorch Profiling library).

There was a try to enable it in [this PR](https://github.com/pytorch/pytorch/pull/65608), but after merge CI/CD started to fail so PR was reverted.

Expectations
- Enable CUPTI for Pytorch on Windows

cc @peterjc123 @mszhanyi @skyline75489 @nbcsm