sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: Diagnostic sign: `linehl` highlight groups conficts with `Search` hl when using `:substitute`
Labels: bug,lsp,highlight,diagnostic

### Problem

This PR: https://github.com/neovim/neovim/pull/26555 adds `linehl` highlight groups for highlighting whole line background in diagnostic.

But I noticed when I `Substitude` like `:%s/te`, `:'<,'>s/te`, the highlight group seems not show correctly.

An example:
![image](https://github.com/neovim/neovim/assets/39915562/6e3e0411-64ff-43ec-8b71-2092f727230e)

Also I noticed when using `:substitude`, the highlights like: `CursorLine`, `Visual`, will be disabled temperory.
So maybe the `linehl` should also be disabled temporary in subsitute mode?

Related PR: https://github.com/neovim/neovim/pull/26555
cc @gpanders @glepnir @wookayin 

### Steps to reproduce

Minimal reproduction config:
```lua
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)
require("lazy").setup({
  {
    "neovim/nvim-lspconfig",
    config = function()
      vim.opt.termguicolors = true
      vim.api.nvim_set_hl(0, "DiagnosticErrorLn", { bg = "#dc143c" })
      vim.api.nvim_set_hl(0, "DiagnosticWarnLn", { bg = "#b8860b" })
      vim.api.nvim_set_hl(0, "DiagnosticInfoLn", { bg = "#00afaf" })
      vim.api.nvim_set_hl(0, "DiagnosticHintLn", { bg = "#00af00" })
      vim.api.nvim_set_hl(0, "Search", { bg = "#00af00", fg = "#000000" })

      vim.diagnostic.config({
        signs = {
          linehl = { "DiagnosticErrorLn", "DiagnosticWarnLn", "DiagnosticInfoLn", "DiagnosticHintLn" },
        },
      })
      require("mason").setup()
      require("mason-lspconfig").setup({ ensure_installed = { "lua_ls" } })
      require("lspconfig").lua_ls.setup({})
    end,
  },
  { "williamboman/mason.nvim" },
  { "williamboman/mason-lspconfig.nvim" },
})
```

### Expected behavior

The highlight of `Search` should applied properl in `subsitute` mode with `linehl` of diagnostic.

Or temporary disable `linehl` of diagnostic in `subsitute` mode.

### Neovim version (nvim -v)

NVIM v0.10.0-dev-2296+gcca8a78ea

### Vim (not Nvim) behaves the same?

idk

### Operating system/version

Ubuntu 20.04 in WSL2

### Terminal name/version

Windows Terminal Preview 1.20

### $TERM environment variable

tmux-256color

### Installation

build from repo
Repository: ant-design
Issue: There is no any ability to customize size of inputs in DatePicker.RangePicker
Labels: Inactive,unconfirmed

### What problem does this feature solve?

Right now the one possible way to customize size of inputs (to display them on the start of the line, for example) is to cut it by setting width for .ant-picker-input class.
And due to the reason that inputs inside of the DatePicker.RangePicker have 'size' attribute which is set to 12, we can't use dynamic width characteristics ('fit-content', for example).
The problem is also actual for cases, when a developer wants to set a custom date pattern which can have more symbols, than the actual size.
![image](https://github.com/ant-design/ant-design/assets/152303565/c40287a5-5a13-44f5-af11-ef47c046c39b)

In conclusion, if inputs have this 'size' attribute, it would be nice to have an ability to change attribute 'size' of inputs inside of DatePicker.RangePicker. It would solve the issue with static width and give an ability for more various customizations.

### What does the proposed API look like?

Add 'inputSize' argument to DatePicker.RangePicker which will update the HTML attribute 'size' of inputs inside Range

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: vscode
Issue: The Context does not set hasSearchResult when searching directly in the SearchEditor
Labels: bug,search,confirmed

The Context does not set `hasSearchResult` when searching directly in the `SearchEditor`.

---

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.86.0
- OS Version: macOS 14.3

Steps to Reproduce:

1. run `search.action.openNewEditorToSide` Search for any existing character
2. open `Developer Tools` and run `workbench.action.inspectContextKeys` get context
3. `hasSearchResult:false` in context json
Repository: godot
Issue: Initially dragging textures (PNG, JPG) from FileSystem into shader parameters lags
Labels: discussion,topic:editor,topic:3d

### Tested versions

- Reproducible in 4.2.1 b09f793f5

### System information

Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Ti Laptop GPU (NVIDIA; 31.0.15.5123) - 12th Gen Intel(R) Core(TM) i5-12500H (16 Threads)

### Issue description

After dragging a texture from FileSystem to a shader parameter for the first time, the lag was something like 10 seconds -I thought Godot was going to crash. If you drag and hold and wait long enough you can actually drop into the shader parameter but the UI is noticeably laggy during this portion.

After clearing the shader parameter and dragging it in again, there was no lag. So it only happens on the first time.

Happens with JPG, PNG

It does NOT happen with DDS, so I think this points to some sort of problem with the import pipeline.


### Steps to reproduce

To reproduce, copy/paste the shader below into a new ShaderMaterial, load the texture into the FileSystem, and try dragging the `pebbles_01.jpg` from the FileSystem into the Texture 2 parameter.

```
shader_type spatial;

uniform sampler2D texture1;
uniform sampler2D texture2;
uniform sampler2D splatMap;

void fragment() {
	// Called for every pixel the material is visible on.
}
```

![pebbles_02](https://github.com/godotengine/godot/assets/23486102/65856d47-ae01-4305-8954-c89283c07d44)

### Minimal reproduction project (MRP)

[DragTextureIssue.zip](https://github.com/godotengine/godot/files/14195065/DragTextureIssue.zip)
Repository: material-ui
Issue: [material-ui][Accordion] `AccordionDetails` is not visible when passing custom component through slotProps.transition
Labels: bug 🐛,component: accordion,package: material-ui

### Steps to reproduce



Steps:
1. Replace below code[ in this demo ](https://mui.com/material-ui/react-accordion/#transition)and click on 1st accordion

```
 import * as React from 'react';
import Accordion, { AccordionSlots } from '@mui/material/Accordion';
import AccordionSummary from '@mui/material/AccordionSummary';
import AccordionDetails from '@mui/material/AccordionDetails';
import Typography from '@mui/material/Typography';
import ExpandMoreIcon from '@mui/icons-material/ExpandMore';
import Fade from '@mui/material/Fade';

export default function AccordionTransition() {
  const [expanded, setExpanded] = React.useState(false);

  const handleExpansion = () => {
    setExpanded((prevExpanded) => !prevExpanded);
  };

  return (
    <div>
      <Accordion
        expanded={expanded}
        onChange={handleExpansion}
      
        slotProps={{ transition: { timeout: 400,component:Fade } }}
        sx={{
          '& .MuiAccordion-region': { height: expanded ? 'auto' : 0 },
          '& .MuiAccordionDetails-root': { display: expanded ? 'block' : 'none' },
        }}
      >
        <AccordionSummary
          expandIcon={<ExpandMoreIcon />}
          aria-controls="panel1-content"
          id="panel1-header"
        >
          <Typography>Custom transition using Fade</Typography>
        </AccordionSummary>
        <AccordionDetails>
          <Typography>
            Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse
            malesuada lacus ex, sit amet blandit leo lobortis eget.
          </Typography>
        </AccordionDetails>
      </Accordion>
      <Accordion>
        <AccordionSummary
          expandIcon={<ExpandMoreIcon />}
          aria-controls="panel2-content"
          id="panel2-header"
        >
          <Typography>Default transition using Collapse</Typography>
        </AccordionSummary>
        <AccordionDetails>
          <Typography>
            Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse
            malesuada lacus ex, sit amet blandit leo lobortis eget.
          </Typography>
        </AccordionDetails>
      </Accordion>
    </div>
  );
}

```


### Current behavior

AccordionDetails is not visible

### Expected behavior

AccordionDetails is  visible

### Context

Opened PR to resolve the issue, but first wanted to check if this is a valid bug.

**PR:** https://github.com/mui/material-ui/pull/40961 

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>


**Search keywords**: accordion
Repository: go
Issue: x/tools/internal/refactor/inline: simplify control statements when the operand is known
Labels: gopls,Tools,Refactoring

When inlining a call `f(true)` to a function such as this one:
```
func f(x bool) {
    if x {
        fmt.Println("hello")
    } else {
        fmt.Println("goodbye")
    }
}
```
the inliner should apply logical simplifications to the body when the argument value (here "true") is known. The result would then be simply `fmt.Println("hello")`.

Logical simplification is conceptually orthogonal to inlining: all it requires is a piece of code and some extra knowledge about the values or variables (e.g. x = true). But unfortunately the inliner doesn't get to see the typed syntax after the inlining, so the analysis would need to be integrated into the callee portion of the inliner analysis.

A good starting point would be to tabulate the set of statements of the form `for range x {...}` or `if x {...} else {...}` where the operand x depends only on constants and parameters. The expression can then be retained  and reevaluated (similar to the approach in the [falcon](https://cs.opensource.google/go/x/tools/+/refs/tags/v0.17.0:internal/refactor/inline/falcon.go) analysis), and if it is degenerate (true, false, zero, empty, a singleton, etc) then the statement can be reduced according to a set of rules:

- if true S1 else S2 => S1
- if false S1 else S2 => S2
- for x := range []T{} S => nothing
- for x := range []T{v} S => { x := v; S }  (assuming no break/continue)
- for i := 0; i < 0; i++ S => nothing
- etc

@stapelberg
Repository: vscode
Issue: Adding variable with special characters in variable name to watch
Labels: bug,php

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: No, but testing with php_xdebug disabled is reasonable in this case. All other extensions have been disabled.

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: VS Code: January 2024 (version 1.86)
- OS Version: Windows 11 X64 [Version 10.0.22631.3085]

Steps to Reproduce:

Use code 
```
<?php

$Sää = "something";

$Temperature_In_°C = 100;

echo "Set breakpoint on this line and add those two variables above to watch";
```

1. With the code above, click on a variable name on the code  and add to watch. Do not select the variable name, just click on it before adding to watch.
2. On watch, instead on $Sää there is $S, and instead of $Temperature_In_°C there is $Temperature_In_
3. On watch, I can edit the expression e.g. change $S to $Sää and see the correct result
4. If I select the variable name, it is added to watch correctly
5. On local variables both are correct. If I add them to watch from local variables, it works ok.
6. I have tested disabling PHP Intelephense, no effect.
7. This has been discussed in https://bugs.xdebug.org/view.php?id=2243 and it seems that it is VS Code issue, or plugin issue.
8. Testing without php_xdebug is not possible in this case.


php_xdebug-3.3.1-8.3-vs16-nts-x86_64.dll
PHP 8.3.2
Windows 11 X64
Repository: TypeScript
Issue: ts2556 is too restrictive when generics are involved
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

"generic", "tuple", "spread", "rest", "ts2556", "a spread argument must either have a tuple type or be passed to a rest parameter"

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about spreading into argument lists

### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEYD2A7AzgF3gMwFzwAoBKeAXgD54A3JAS2AFgAoZ0SWBZdLAD3zijBUEAJ7wA2gF1m2AgDoFPEgHpl8AO5IYAazTNmXTPAwgjpeAB4AKvBA8TKYGngChKURMnkCfeFZIUzPA48ooqakKm8ChIWJo6QA

### 💻 Code

```ts
declare const f: () => void

declare const x: readonly []
f(...x) // works

const test = <T extends readonly []>(x: T) =>
  f(...x) // does not work
```


### 🙁 Actual behavior

Attempting to spread a generically-typed value whose constraint guarantees tuple-ness into a compatible argument list is forbidden.

### 🙂 Expected behavior

I should be allowed to do this.

### Additional information about the issue

Possibly-related issues:
- https://github.com/microsoft/TypeScript/issues/29919
- https://github.com/microsoft/TypeScript/issues/49802
- https://github.com/microsoft/TypeScript/issues/53541
Repository: godot
Issue: Setting MSAA 3D to 8x blurs everything when using DOF
Labels: bug,platform:macos,topic:rendering,topic:3d

### Tested versions

v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - macOS 14.2.1 - Vulkan (Forward+) - integrated Apple M1 Max - Apple M1 Max (10 Threads)

### Issue description

When using DOF, setting MSAA 3D to 8x is doing something weird:

https://github.com/godotengine/godot/assets/60579014/1b470c60-1f50-4c27-8954-0723ec092604



### Steps to reproduce

1. Create a project
2. Create an environment with either `CameraAttributesPhysical` or `CameraAttributesPractical`
3. Set MSAA to 8x

### Minimal reproduction project (MRP)

[MRP_MSAA.zip](https://github.com/godotengine/godot/files/14195886/MRP_MSAA.zip)
Repository: pytorch
Issue: Asked to report bug by a `UserWarning`
Labels: triaged

### 🐛 Describe the bug

`lib/python3.10/site-packages/torchrl/data/replay_buffers/samplers.py:23`:` UserWarning`: Failed to import torchrl C++ binaries. Some modules (eg, prioritized replay buffers) may not work with your installation. If you installed TorchRL from PyPI, please report the bug on TorchRL github.

### Versions

Collecting environment information...
PyTorch version: 2.2.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 14.2.1 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-1500.1.0.2.5)
CMake version: version 3.27.9
Libc version: N/A

Python version: 3.10.10 (main, Sep 14 2023, 16:59:47) [Clang 14.0.3 (clang-1403.0.22.14.1)] (64-bit runtime)
Python platform: macOS-14.2.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1

Versions of relevant libraries:
[pip3] flake8==7.0.0
[pip3] mypy==1.8.0
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.4
[pip3] pytest-mypy==0.10.3
[pip3] pytorch-lightning==2.1.4
[pip3] torch==2.2.0
[pip3] torchmetrics==1.3.0.post0
[pip3] torchrl==0.2.1
[conda] Could not collect
Repository: deno
Issue: REPL fails to parse a function which contains a regular expression
Labels: bug,repl

Version: Deno 1.40.2

```ts
function test(input: string): string {
  return input.replace(/a/, 'b');
}
```

Pasting the above code into a Deno REPL causes a parser error:

```ts
$ deno
Deno 1.40.2
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
> function test(input: string): string {
  return input.replace(/a/, 'b');
parse error: Expected '}', got '<eof>' at 2:33
> }
```

Defining the regular expression on a separate line does not help, the REPL only errors one line earlier:

```ts
> function test(input: string): string {
  const regex = /a/;
parse error: Expected '}', got '<eof>' at 2:20
>   return input.replace(regex, "b");
Uncaught SyntaxError: Illegal return statement
> }
```

The only thing which works is defining a global variable:

```ts
> const regex = /a/;
undefined
> function test(input: string): string {
  return input.replace(regex, "b");
}
undefined
```
Repository: rust
Issue: Tracking Issue for changing rustc target docs
Labels: T-compiler,A-docs,C-tracking-issue,A-targets

This is the tracking issue for changing rustc target docs to be generated based on the existing target triple patterns, ensuring that there's a doc page for every single target.

Discussion in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generating.20target.20documentation with a draft implementation in https://github.com/Nilstrieb/target-tier-docs-experiment.

### Steps

- [ ] Figure out the best format to store the target docs
  - Original idea: TOML 
  - Current choice: Markdown with fixed sections and YAML frontmatter
- [x] Move some of the information into the complier
  - [x] Add empty target metadata to every target
    - #121905
    - #122157
    - #122305
  - [x] Add unstable way to print descriptions
    - As it's contained in the target spec, we can just print the target spec JSON.
- [ ] Implement infrastructure for new docs (without using it yet) #121051
- [ ] Migrate existing docs to the new format (over several PRs)
  - #127265
- [ ] Use the new format for the shipped docs
- [ ] Delete the old docs

### Future possibilities

- [ ] Keep tier, host_tools and std in sync with reality
Repository: electron
Issue: [Bug]: [AudioWorklet] value of `globalThis` differs between first and second calls to the worklet.
Labels: platform/macOS,bug :beetle:,status/confirmed,has-repro-repo,27-x-y,28-x-y,29-x-y,30-x-y,31-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

27.0.0

### What operating system are you using?

macOS

### Operating System Version

macOS 14.3

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

26.6.8

### Expected Behavior

The value of the `globalThis` variable, inside an `AudioWorklet`, is supposed to be stale.

### Actual Behavior

Since v27.0.0, the value of `globalThis` is changing from the first to the second call to the AudioWorklet, only when `nodeIntegrationInWorker` is set to `true`.

You can find attached screenshots that will give you more context about this issue, as well as a fork of the `electron-quick-start` project with the changes to reproduce the issue easily.

The biggest side-effect of this bug is that we no longer have access to node env (like require etc ...)

<img width="1368" alt="Screenshot 2024-02-07 at 5 34 50 PM" src="https://github.com/electron/electron/assets/426749/fc1dbe67-ef0b-44aa-9a39-e5f829d84de3">
<img width="1366" alt="Screenshot 2024-02-07 at 5 34 01 PM" src="https://github.com/electron/electron/assets/426749/3adc50de-34e0-4986-b997-f84adc8a4a96">

### Testcase Gist URL

https://github.com/rmnbrd/electron-quick-start/compare/master...rmnbrd:electron-quick-start:issue-globalThis-value

### Additional Information

Reproduction steps:

1. Checkout the branch (link just above),
2. Run the `electron-quick-start` project,
3. Click on the "Start AudioWorklet" button 2 times,
4. The value of `globalThis` differs between the first and second call to the AudioWorklet.
Repository: PowerToys
Issue: power toy run doesn't displays two 0 in the result of a ecuation
Labels: Issue-Bug,Product-PowerToys Run,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.78.0

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

press alt+spacebar
type 571200/1.19


### ✔️ Expected Behavior

The result should be 480000

### ❌ Actual Behavior

![image](https://github.com/microsoft/PowerToys/assets/26771293/459f29e8-579f-416f-adfc-205c1d576e12)


### Other Software

_No response_
Repository: pytorch
Issue: Lazy Tensor GetBackendDevice is not working at all
Labels: triaged,lazy

The current templated constructor https://github.com/pytorch/pytorch/blob/088d538a8d37621e9cacbc37f7120b94874e2481/torch/csrc/lazy/backend/backend_device.h#L89 is going to infinite recurse when used (as suggested by the compiler warning that it has been throwing).
The thing is, because it accepts anything, any call to it is valid today. And for example codegen will happily generate things  like `auto common_device = torch::lazy::GetBackendDevice(self, start, end, step);` that calls it with a SymInt. This compiules just fine even though we clearly don't have any implementation for it there.

You can fix it by having the generic templated constructor have a different name from the one off constructors as suggested in  https://github.com/pytorch/pytorch/pull/119381 (where I added the optional Tensor overload already).
But there seems to be more work there to actually support all the other arguments that are sent there so I'm giving up.