sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Consider unifying the `SourceFile` lookup strategy between incr comp cache and metadata decoding
Labels: T-compiler,A-incr-comp,E-medium

In both the incremental compilation cache and crate metadata decoding, we need to lookup the `SourceFile` for a decoded `Span`.

In incremental compilation, this is accomplished by looking up the `StableSourceFileId` in a hashmap stored in our `SourceMap`:

https://github.com/rust-lang/rust/blob/e100ec5bc7cd768ec17d75448b29c9ab4a39272b/compiler/rustc_query_impl/src/on_disk_cache.rs#L493-L503

In metadata decoding, this is accomplished by binary searching through the `SourceFile`s imported from that crate specifically:

https://github.com/rust-lang/rust/blob/e100ec5bc7cd768ec17d75448b29c9ab4a39272b/compiler/rustc_metadata/src/rmeta/decoder.rs#L539-L559

I suspect that the hashmap lookup will be much faster, and that we could switch the metadata decoder to use that strategy.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: SoftBody breaks when being paused, resumed, or having its transform changed
Labels: bug,topic:physics,topic:3d

### Godot version

Originally found in: `Godot_v3.4.1-stable_win64`
Can reproduce in all versions since `Godot_v3.4-stable_win64` inclusive (and likely earlier)

### System information

Windows 10, GLES3, GTX 1660

### Issue description

When a SoftBody's `PhysicsEnabled`, `scale`, `rotation`, or `translation` is changed, the mesh and physics state for that SoftBody is re-initialized, resulting in the following behaviors:
* The SoftBody deforms, stretches, and twists further than normally possible had this not been the case.
* The mesh is re-optimized each time, which may remove vertices and therefore cause errors, including assertion failures of `0 > node_index || bt_soft_body->m_nodes.size() <= node_index` and `p_node_index, bt_soft_body->m_nodes.size()` depending on the pinned vertices.

I would expect the SoftBody to retain as much of the physics state as it can when being paused or resumed (`PhysicsEnabled`) and when its `Spatial` transform is changed (i.e. `scale`, `rotation`, `translation`).

Possible workarounds:
`PhysicsEnabled`: No feasible workaround. The physics state will need to be fully preserved even when paused so that it can be resumed without any distortion.
`Scale`: The current workaround is to parent the SoftBody to a Spatial and change the scale there, but that only affects points on the SoftBody that are pinned to that Spatial, while the rest of the SoftBody remains the same scale. A better workaround (i.e. one that actually changes the size of the SoftBody without breaking it) requires https://github.com/godotengine/godot-proposals/issues/3535 to be implemented.
`Rotation`: Parent the SoftBody to a Spatial, then change the rotation there.
`Translation`: Parent the SoftBody to a Spatial, then change the translation there.

### Steps to reproduce

1. Open the Minimal reproduction project below.
2. Run the project in editor.
3. Hold E for a few seconds or press T a few times.
4. Notice the resulting distortion, which stays.

### Results of above steps
Control:
![image](https://user-images.githubusercontent.com/37945304/146999297-2cf7f1a8-7597-47b7-8acb-304779203ae2.png)


After holding E (constantly toggling `self.PhysicsEnabled` for the SoftBody):
![image](https://user-images.githubusercontent.com/37945304/146999080-27f8dfbb-ee27-4e0b-a1fb-4e0e26a7b7da.png)

After holding T (growing the SoftBody's `scale`):
![image](https://user-images.githubusercontent.com/37945304/146999233-4bb7c735-43ac-4241-b8c1-748dabdbef23.png)



### Minimal reproduction project

[Softbody3d Test.zip](https://github.com/godotengine/godot/files/7758237/Softbody3d.Test.zip)
Repository: nvm
Issue: Really REALLY slow time for node install
Labels: needs followup

Rasbian (Linux) 

#### `nvm ls` output:  
Just system

#### How did you install `nvm`?
With curl command in .readme

#### What steps did you perform?
nvm install node

#### What happened?
Been 2 hours and it just keeps running g++ stuff

#### What did you expect to happen?
Node to actually install in maybe 10 minutes max?

#### Is there anything in any of your profile files that modifies the `PATH`?
Nope
Repository: opencv
Issue: `LineIterator` poorly supported in bindings
Labels: feature,category: python bindings

##### System information (version)
- OpenCV => 4.5.3
- Operating System / Platform => Linux/Python3
- Compiler => GCC

##### Detailed description

Getting Bresenham algorithm from 3rd party sources is a poor substitute. While it's not possible to directly translate `LineIterator` into other languages like Python, a substitute could be provided by OpenCV such as a generator in python which indirectly allows the similar functionality

 - [x] I report the issue, it's not a question
   <!--
   OpenCV team works with forum.opencv.org, Stack Overflow and other communities
   to discuss problems. Tickets with question without real issue statement will be
   closed.
   -->
 - [x] I checked the problem with documentation, FAQ, open issues,
       forum.opencv.org, Stack Overflow, etc and have not found solution
   <!--
   Places to check:
   * OpenCV documentation: https://docs.opencv.org
   * FAQ page: https://github.com/opencv/opencv/wiki/FAQ
   * OpenCV forum: https://forum.opencv.org
   * OpenCV issue tracker: https://github.com/opencv/opencv/issues?q=is%3Aissue
   * Stack Overflow branch: https://stackoverflow.com/questions/tagged/opencv
   -->
 - [x] I updated to latest OpenCV version and the issue is still there
   <!--
   master branch for OpenCV 4.x and 3.4 branch for OpenCV 3.x releases.
   OpenCV team supports only latest release for each branch.
   The ticket is closed, if the problem is not reproduced with modern version.
   -->
 - [x] There is reproducer code and related data files: videos, images, onnx, etc (None needed since the functionality is missing)

Related: #6095
Repository: pytorch
Issue: Shape parameter inconsistency in torch.Tensor.view, torch.reshape, torch.Tensor.reshape
Labels: module: docs,triaged,module: viewing and reshaping

### 📚 The doc issue

I find the documentation is very inconsistent across different functions. E.g., compare the shape parameter description of these functions:
https://pytorch.org/docs/stable/generated/torch.Tensor.view.html#torch-tensor-view
https://pytorch.org/docs/stable/generated/torch.reshape.html
https://pytorch.org/docs/stable/generated/torch.Tensor.reshape.html#torch.Tensor.reshape

1. In the [view](https://pytorch.org/docs/stable/generated/torch.Tensor.view.html#torch-tensor-view) function, it says:
```
Parameters
shape (torch.Size or int...) – the desired size
```
But it doesn't mention it accepts "-1" as a parameter to infer the dimension size from others, unlike explicitly mentioning this in torch.reshape function. It only mentions that in the example below.
```
z = x.view(-1, 8)  # the size -1 is inferred from other dimensions
```
It doesn't mention it accepts variable number of ints ("int..." is quite ambitious for such a large open-source project with many users).
Tensor.view(*shape) → Tensor - *shape suggest it should unpack an iterable? Then how can you unpack an int if shape is an int? This inconsistency only adds more confusion.

2. torch.Tensor.reshape - it mentions half of the details of torch.reshape and then references torch.reshape itself. I would suggest either to write a complete parameter description or not to mention it at all and leave just the reference. Because otherwise, a developer might miss half of the thing you don't mention if they don't follow the referenced link.

### Suggest a potential alternative/fix

Overall, I feel PyTorch should have more strict definition of parameters, e.g., take a look at IMO good example of numpy:
https://numpy.org/doc/stable/reference/generated/numpy.reshape.html
https://numpy.org/doc/stable/reference/generated/numpy.ndarray.resize.html

cc @brianjo @mruberry
Repository: create-react-app
Issue: Allow import and content hashes in index.html to allow cache busting
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

I want my favicon (and other files in index.html) to be cache busted with content-hash in its name.
When I change my favicon it should be loaded not from cache.

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

In index.html we do:
`<link rel="icon" href="%PUBLIC_URL%/favicon.ico">`

When the index.html is built, I want it to be converted to:
`<link rel="icon" href="%PUBLIC_URL%/favicon.theHash.ico">`.

We might need a special import syntax?:
`<link rel="icon" href="___###import(../src/assets/favicon.ico)###___">`.
Repository: godot
Issue: ColorPicker in VisualShader is scaled based on zoom
Labels: bug,topic:editor

### Godot version

v3.4.1.stable.official [aa1b95889]

### System information

Windows 11, macOS 11.6

### Issue description

![image](https://user-images.githubusercontent.com/3468354/147016389-c73f15c6-399a-455c-8c88-1e0b68673bef.png)
![image](https://user-images.githubusercontent.com/3468354/147016405-fdec733c-2d3a-4f7b-b2d8-fc1c9cbaebe5.png)


### Steps to reproduce

1. Open VisualShader editor
2. Create a ColorConstant node
3. Zoom in/out
4. Click color button in node


### Minimal reproduction project

[BugTest_001.zip](https://github.com/godotengine/godot/files/7759109/BugTest_001.zip)
Repository: neovim
Issue: message "Swap file xxx already exists" does not respect the MoreMsg highlight during startup
Labels: bug,startup,highlight

### Neovim version (nvim -v)

0.5.1

### Vim (not Nvim) behaves the same?

no, vim 8.2.3575

### Operating system/version

Solus Linux

### Terminal name/version

Alacritty 0.9.0

### $TERM environment variable

alacritty

### Installation

System package manager

### How to reproduce the issue

This is the content of my `init.vim` file:

```vim
colorscheme nord
set termguicolors
```

Then I first open file `a.cc` in one `nvim` instance. Then I open another terminal and run `nvim a.cc`. The following is what I saw:
![Screenshot from 2021-12-20 18-36-54](https://user-images.githubusercontent.com/16892446/147023295-5275c6df-a6d2-4020-9e1a-84d329e2ff0d.png)

However, this is the `MoreMsg` highlight group defined by the `nord` colorscheme:
![Screenshot from 2021-12-20 18-38-11](https://user-images.githubusercontent.com/16892446/147023350-2715b2b5-d5d8-47dd-ba65-f17f8f7e5fd8.png)

As can be seen, the highlight colors used by `nvim` for the `Swap file xxxx already exists` message does not match the `MoreMsg` highlight group defined by my colorscheme.

I did the same experiment with vim, with `.vimrc` identical to the `init.vim` shown above. This is the result in vim:
![Screenshot from 2021-12-20 18-36-04](https://user-images.githubusercontent.com/16892446/147023537-4e339383-e8cb-4308-8823-9fefc8f604f7.png)

`vim` uses correct highlight colors for the `Swap file xxxx already exists` message.


### Expected behavior

The highlight color for the `Swap file xxxx already exists` message should match the `MoreMsg` highlight group of the selected colorscheme.

### Actual behavior

The highlight color for the `Swap file xxxx already exists` message do not match the `MoreMsg` highlight group of the selected colorscheme.
Repository: rust
Issue: Proc Macro Crate and Workspace Miri and Clippy Malloc Error
Labels: I-crash,O-macos,C-bug,A-proc-macros

When compiling a workspace that has a proc macro crate in it, rustc emits a malloc error causing tools such as miri and clippy to fail.  This bug affects nightly versions 2021-12-05+.

I tried this code:

[playground_workspace.zip](https://github.com/rust-lang/rust/files/7759461/playground_workspace.zip)

I expected to see this happen: 
Miri and clippy successfully assess my code

Instead, this happened:
the following crashes (I can supply the actual Mac IPS files if it would be more helpful than these txt copies):
[clippy.txt](https://github.com/rust-lang/rust/files/7759467/clippy.txt)
[miri.txt](https://github.com/rust-lang/rust/files/7759468/miri.txt)


### Meta

`rustc --version --verbose`:
```
rustc 1.59.0-nightly (23f69235a 2021-12-20)
binary: rustc
commit-hash: 23f69235ad2eb9b44ac1a55eeaa3f9b484d9de4a
commit-date: 2021-12-20
host: x86_64-apple-darwin
release: 1.59.0-nightly
LLVM version: 13.0.0
```
Repository: rust
Issue: Conflicting implementation of trait with `generic_const_exprs` feature
Labels: C-bug,A-const-generics,requires-nightly,F-generic_const_exprs,requires-incomplete-features

<!--
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.
-->

I tried this code:

```rust
#![allow(incomplete_features)]
#![feature(adt_const_params)]
#![feature(generic_const_exprs)]

use std::marker::PhantomData;

pub struct Foo<const P: Protocol, T> {
    _marker: PhantomData<T>,
}

#[derive(PartialEq, Eq)]
pub enum Protocol {
    Variant1,
    Variant2,
}

pub trait Bar {}

impl<T> Bar for Foo<{ Protocol::Variant1 }, T> {}
impl<T> Bar for Foo<{ Protocol::Variant2 }, T> {}
```

I expected to see this happen: This is the result when I commented `generic_const_exprs` feature.

```
$ cargo build
   Compiling test-nightly v0.1.0
    Finished dev [unoptimized + debuginfo] target(s) in 0.22s
```

Instead, this happened:

```
$ cargo build
   Compiling test-nightly v0.1.0
error[E0119]: conflicting implementations of trait `Bar` for type `Foo<{ Protocol::Variant1 }, _>`
  --> src/lib.rs:28:1
   |
27 | impl<T> Bar for Foo<{ Protocol::Variant1 }, T> {}
   | -------------------- first implementation here
28 | impl<T> Bar for Foo<{ Protocol::Variant2 }, T> {}
   | ^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Foo<{ Protocol::Variant1 }, _>`

For more information about this error, try `rustc --explain E0119`.
error: could not compile `test-nightly` due to 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.59.0-nightly (23f69235a 2021-12-20)
binary: rustc
commit-hash: 23f69235ad2eb9b44ac1a55eeaa3f9b484d9de4a
commit-date: 2021-12-20
host: x86_64-unknown-linux-gnu
release: 1.59.0-nightly
LLVM version: 13.0.0
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
$ RUST_BACKTRACE=1 cargo build
   Compiling test-nightly v0.1.0
error[E0119]: conflicting implementations of trait `Bar` for type `Foo<{ Protocol::Variant1 }, _>`
  --> src/lib.rs:20:1
   |
19 | impl<T> Bar for Foo<{ Protocol::Variant1 }, T> {}
   | -------------------- first implementation here
20 | impl<T> Bar for Foo<{ Protocol::Variant2 }, T> {}
   | ^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Foo<{ Protocol::Variant1 }, _>`

For more information about this error, try `rustc --explain E0119`.
error: could not compile `test-nightly` due to previous error
```

</p>
</details>
Repository: react
Issue: In Strict Mode, function component and class component are inconsistent with scenes that produce side effects
Labels: Type: Discussion

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version:

17.0.2

## Steps To Reproduce

```js
import React from 'react';

const TestFunc = () => {
  debugger
  const myRef = React.useRef(true)
  if (myRef.current) {
    myRef.current = false
  }

  return <div>666</div>
}

class TestClass extends React.Component {
  myRef = React.createRef()
  constructor(props) {
    super(props);
    this.myRef.current = true
  }

  render() {
    debugger
    if (this.myRef.current) {
      this.myRef.current = false
    }
    return <div>888</div>
  }
}

function App() {
  return (
    <React.StrictMode>
      <TestFunc />
      <TestClass />
    </React.StrictMode>
  );
}

export default App;
```

1. Use strict mode
2. Observe the changes of the myRef.current variable when the two components are rendered for the second time
3. In the function component, the value of the myRef.current variable is "true" in the two renders before and after, so the two renders will go to the "myRef.current = false" logic. But in the class component, when rendering twice, the myRef.current variable is "true" in the first rendering, but the "false" that was modified in the first rendering is retained in the second rendering.



Reason:
I looked at the source code and found that for the function component, although renderWithHooks was called twice before and after and the same workInProgress was used, but every time in the "renderWithHooks" method, the value of "workInProgress.memoizedState" is set to null, and in the useRef function of the mounting phase, the "workInProgress.memoizedState" property on "alternate" will not be reused, therefore, in the mounting phase in strict mode, during the second rendering, the state saved by ref during the first rendering cannot be obtained in the function component.
![4641640144553_ pic](https://user-images.githubusercontent.com/28889103/147032139-9a08127e-0ca5-411e-8c84-8d4cb79904db.jpg)

But in the scenario of the class component, the same "instance" is used when the render method is called twice before and after, so the "this" in the render method two times before and after all points to the same one "instance".
![4651640144635_ pic](https://user-images.githubusercontent.com/28889103/147032156-063e3a2c-9c0f-4e59-8f0f-5948d0fde6c0.jpg)


Expected:
I think that since the role of strict mode is to make multiple calls so that developers can find that using side effects in some life cycles may cause some problems, should the phenomenon of the class component be consistent with the phenomenon of the function component?

Thanks~:pray::pray::pray:
Repository: godot
Issue: area2d collisionshape2d disabled can not use normally under editable children mode
Labels: bug,topic:editor,topic:physics

### Godot version

3.4.1 stable

### System information

windows7 32bit

### Issue description

 when i create a scene including area2d and create a collosion2d, I use it in another scene and set its collision2d as editable children mode,  I set the collision2d disable as true on the right dashboard.but the property can not use to close collision function. so I have  to write "$collisionShape2D.disabled=true" to close its function.
I try it under godot_v3.3.4 ,it's no ploblem

### Steps to reproduce

1st  ,create a secene  including  area2d and create a collosionShape2d,
2nd,  add to  another scene 
3rd,  set area2d   editable children
4th,  set  the collosionShape2d disable as true
5th, can not take any effects,  collision shape  is still visible
6th, I try it under godot_v3.3.4 ,it's no ploblem

### Minimal reproduction project

_No response_
Repository: material-ui
Issue: [docs] Adding `prepend: true` to emotion cache breaks remix example
Labels: examples

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

Adding `prepend: true` to the [emotion cache used in the remix-with-typescript](https://github.com/mui-org/material-ui/blob/master/examples/remix-with-typescript/app/src/createEmotionCache.ts ) example to modify the injection order of mui styles and global css styles causes DOMExceptions.

![remix-prepend](https://user-images.githubusercontent.com/60080324/147051699-139c8f7d-2f85-470e-a56c-014a618ac3d2.PNG)

Removing `CssBaseline` from `entry.client.tsx` will remove the DOMException, but the hydration warning remains.

Moving the style tag generator in `root.tsx` also does not help to remove the hydration warning.

### Expected behavior 🤔

Expected the mui styles to move from the bottom of the `head` element to the top of the `head` element, and the DOM to render without exceptions.

### Steps to reproduce 🕹

Steps:

1. Clone the https://github.com/mui-org/material-ui/blob/master/examples/remix-with-typescript/ example
2. Add the prepend: true option to createCache in https://github.com/mui-org/material-ui/blob/master/examples/remix-with-typescript/app/src/createEmotionCache.ts

```
import createCache from '@emotion/cache';

export default function createEmotionCache() {
  return createCache({ key: 'css', prepend: true });
}
```

3. npm install, npm run dev and open in the browser


### Context 🔦

Trying to reduce the precedence of mui when interoperating with other style methods (e.g. using global styles)

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
 System:
    OS: Linux 4.4 Ubuntu 18.04.4 LTS (Bionic Beaver)
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.10 - /mnt/c/Program Files (x86)/Yarn/bin/yarn
    npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @emotion/react: latest => 11.7.1 
    @emotion/styled: latest => 11.6.0 
    @mui/base:  5.0.0-alpha.61 
    @mui/material: latest => 5.2.5 
    @mui/private-theming:  5.2.3 
    @mui/styled-engine:  5.2.5 
    @mui/system:  5.2.5 
    @mui/types:  7.1.0 
    @mui/utils:  5.2.3 
    @types/react: latest => 17.0.37 
    react: latest => 17.0.2 
    react-dom: latest => 17.0.2 
    typescript: latest => 4.5.4 

Browser used: Firefox
```
</details>
Repository: ant-design
Issue: 图标组件LoadingOutlined能否增加strokeWidth属性
Labels: 💡 Feature Request,Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
能够自定义图标的粗细

### What does the proposed API look like?
strokeWidth: number


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: AudioStreamPlayer emits `finished` signal inconsistently.
Labels: bug,topic:audio,regression

### Godot version

Godot_v4.0-dev.20211004_linux.64

### System information

5.4.0-91-generic #102-Ubuntu SMP  x86_64 x86_64 x86_64 GNU/Linux

### Issue description

Godot master branch emits `finished` signal inconsistently for different audio files.

Audios `001001.mp3`, `001001.ogg` does not emit `finished` while `002030.mp3` does emit.

Godot 3.4 behaves correctly. Meaning all files emit `finished` signal.

### Steps to reproduce

Load project https://github.com/abdlquadri/GodotAudioPlayerSignalDemo/tree/main/TestingAudioPlayerSignals in Godot_v4.

Expect to see `fini` printed in console after audio stops.

This expected behavior is true for some files ( `002030.mp3`) but not others (`001001.mp3`, `001001.ogg`)

You can load https://github.com/abdlquadri/GodotAudioPlayerSignalDemo/tree/main/TestingAudioPlayerSignals_v3 in Godot_v3 to see that it works for Godot 3

### Minimal reproduction project

https://github.com/abdlquadri/GodotAudioPlayerSignalDemo/tree/main/TestingAudioPlayerSignals