sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [flutter_tools] The getter 'name' was called on null
Labels: tool,t: flutter driver,P2,team-tool,triaged-tool

Version: beta/2.5.0-5.2.pre
Command: `flutter drive --driver=test_driver/integration_test.dart --target=integration_test/app_test.dart`

```
Thread 0 main threadNoSuchMethodError: NoSuchMethodError: The getter 'name' was called on null.Receiver: nullTried calling: name
at Object.noSuchMethod(object_patch.dart:63)
at IOSDevice.startApp(devices.dart:323)
at FlutterDriverService.start(drive_service.dart:179)
at <asynchronous gap>(async)
at DriveCommand.runCommand(drive.dart:237)
at <asynchronous gap>(async)
at FlutterCommand.run.<anonymous closure>(flutter_command.dart:1125)
at <asynchronous gap>(async)
at AppContext.run.<anonymous closure>(context.dart:150)
at <asynchronous gap>(async)
at CommandRunner.runCommand(command_runner.dart:209)
at <asynchronous gap>(async)
at FlutterCommandRunner.runCommand.<anonymous closure>(flutter_command_runner.dart:288)
at <asynchronous gap>(async)
at AppContext.run.<anonymous closure>(context.dart:150)
at <asynchronous gap>(async)
at FlutterCommandRunner.runCommand(flutter_command_runner.dart:236)
at <asynchronous gap>(async)
at run.<anonymous closure>.<anonymous closure>(runner.dart:62)
at <asynchronous gap>(async)
at AppContext.run.<anonymous closure>(context.dart:150)
at <asynchronous gap>(async)
at main(executable.dart:92)
at <asynchronous gap>(async)
```
Repository: rust
Issue: No help message for missing const_trait_impl + const_trait_impl
Labels: A-diagnostics,T-compiler

This code compiles:

```rust
#![feature(const_num_from_num)]
#![feature(const_trait_impl)]
fn main() {
    const N: u64 = u64::from(1_u32);
}
```

And this gives an useful help to fix the problem (on Nightly):

```rust
#![feature(const_trait_impl)]
fn main() {
    const N: u64 = u64::from(1_u32);
}

error: `convert::num::<impl From<u32> for u64>::from` is not yet stable as a const fn
 --> ...\test.rs:3:20
  |
3 |     const N: u64 = u64::from(1_u32);
  |                    ^^^^^^^^^^^^^^^^
  |
  = help: add `#![feature(const_num_from_num)]` to the crate attributes to enable
```

But I think there's some diagnostic problem here, if I remove the other of those feature annotations there's no useful help:

```rust
#![feature(const_num_from_num)]
fn main() {
    const N: u64 = u64::from(1_u32);
}

error[E0015]: calls in constants are limited to constant functions, tuple structs and tuple variants
 --> ...\test.rs:3:20
  |
3 |     const N: u64 = u64::from(1_u32);
  |                    ^^^^^^^^^^^^^^^^

error: aborting due to previous error
```
Repository: bitcoin
Issue: RPC documentation cleanup ideas
Labels: Feature,Docs,RPC/REST/ZMQ

* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks (RPCTypeCheck)
* De-duplicate default values (Started in #20017)
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
Repository: next.js
Issue: Nextjs and sass @extend
Labels: bug

### What version of Next.js are you using?

11

### What version of Node.js are you using?

14.17.4

### What browser are you using?

Chrome

### What operating system are you using?

Windows 10

### How are you deploying your application?

dev

### Describe the Bug

Nextjs doesn't support sass `@extend` properly in `.module.scss` files.

### Expected Behavior

I should be able to use `styles\globals.scss`
```
.centerTransform {
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}
``` 
class in `pages\settings\some-module.scss` via `@extend`
```
.someClass {
  @extend .centerTransform;
}
```

### To Reproduce

Check the ongoing discussion in this "closed" issue.

https://github.com/vercel/next.js/issues/10475
Repository: tauri
Issue: Compile error for async stateful commands that don't return a `Result`
Labels: type: bug,scope: core

### **Describe the bug**
Stateful async commands that don't return a `Result` give a compiler error.

### **To Reproduce**
Example:
```rust
#[command]
pub async fn get_info(app: State<'_, Data>) -> bool {
  true
}
```
There's no error if you remove `async`, remove the `app` argument, or change the return type to a `Result` works.

### Platform and Versions
<details>
<summary>Details</summary>

```
Operating System - Mac OS, version 10.15.7 X64

Node.js environment
  Node.js - 14.16.0
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - 1.0.0-beta.8

Global packages
  npm - 6.14.11
  yarn - 1.22.10

Rust environment
  rustc - 1.54.0
  cargo - 1.54.0

App directory structure
/node_modules
/src-tauri
/build
/.git
/src

App
  tauri.rs - 1.0.0-beta.8
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../build
  devPath - http://localhost:8000
  framework - Svelte
```

</details>

### **Stack Trace**
```
error[E0597]: `__tauri_message__` does not live long enough
  --> src/cmd.rs:93:1
   |
93 |   #[command]
   |   ^^^^^^^^^-
   |   |        |
   |   |        `__tauri_message__` dropped here while still borrowed
   |   borrowed value does not live long enough
   |   argument requires that `__tauri_message__` is borrowed for `'static`
```
Repository: godot
Issue: `ERR_CANT_CREATE` at `VulkanContext::swap_buffers` error at Godot startup
Labels: bug,topic:rendering,needs testing,crash

### Godot version

4.0.dev(ae3a4224271fa058fd8424c6142a2357bd7624b2)

### System information

Windows 10, Vulkan, GTX 1080, Driver 471.68

### Issue description

Sometimes at startup Godot freezes and Vulkan stops working. The following error is detected:

ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
   at: VulkanContext::swap_buffers (drivers\vulkan\vulkan_context.cpp:1860)

Further investigation shows that Vulkan returns VK_ERROR_DEVICE_LOST, which is a symptom of resource corruption.

### Steps to reproduce

Extract and run the attached project:

godot.windows.tools.64 --game --path C:\godot_swapchain

It will produce some script errors that can be ignored. Sometimes it will freeze the computer and show the ERR_CANT_CREATE (very random and unpredictable)

### Minimal reproduction project

[godot_swapchain.zip](https://github.com/godotengine/godot/files/7050043/godot_swapchain.zip)
Repository: rust
Issue: Tracking Issue for `#![feature(c_size_t)]` (`std::os::raw::c_size_t`/`std::os::raw::c_ssize_t`)
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(c_size_t)]`.

This is a tracking issue for `std::os::raw::{c_size_t, c_ssize_t}`, which are guaranteed to be the same size as the underlying C `size_t` and `ssize_t` types from `stddef.h`.

Currently, on all targets, this is equivalent to `usize` and `isize`, however Rust has historically gone somewhat out of its way to avoid promising this. There are some targets with vaguely-planned support where this is not true ([W65](https://en.wikipedia.org/wiki/WDC_65C816), used for SNES homebrew, for example)

Further reading here is available:
- https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60
- https://internals.rust-lang.org/t/abi-discussion-for-w65/15092
- https://github.com/rust-lang/rust-bindgen/issues/1671

And probably more.

### Public API

```rust
// std::os::raw

pub type c_size_t = usize;
pub type c_ssize_t = isize;
```

### Steps / History

- [x] Implementation: #88340
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

### Unresolved Questions

- Do we want to instead guarantee `usize` and `size_t` are the same? See https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369
- Should this instead live in `libcore` somehow, given that probably `libstd` may never support platforms where this is not true. (This may not be true, since I imagine CHERI will support libstd)
- Do we need both the signed and unsigned version, given that `size_t` is more common in function signatures.
- ...
Repository: neovim
Issue: cursorline highlight doesn't apply to virt_text  (hl_mode='replace')
Labels: bug-regression,marks,highlight

### Neovim version (nvim -v)

0.6.0 @ 10d7d73b2dc6db081a8a1f405204d35cccb85196

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

Not applicable

### Operating system/version

Arch Linux @ Kernel 5.13.12-arch1-1

### Terminal name/version

kitty 0.23.1 + tmux 3.2a

### $TERM environment variable

tmux-256color

### Installation

build from repo

### How to reproduce the issue

`nvim -u minimal.vimrc --noplugin`

with the following `minimal.vimrc`:
```vim
hi clear CursorLine
hi CursorLine ctermbg=Black
set cursorline
```

`:call nvim_buf_set_virtual_text(0, -1, 0, [["virtual text", "NonText"]], {})`


In the screenshots below I also inserted "normal text" into the buffer to differentiate it clearly from the virtual text.

### Expected behavior

I expect that the background specified by the `CursorLine` highlight does not get overwritten by the virtual text background.
Like in the screenshot below:

![screenshot_1629930164](https://user-images.githubusercontent.com/21973473/130872799-3588cb3d-6cc6-43f0-ae20-2fc7b4550c21.png)

Based on a `git bisect` this commit (1495d36d63305862da3c4106455667d51b578707) is the last good commit for which the expected behavior worked.

### Actual behavior

Since commit a4d81a800, I instead observe the following:

![screenshot_1629930226](https://user-images.githubusercontent.com/21973473/130872897-c0c3809e-3271-40a8-a9a1-accfba9dcae4.png)
Repository: pytorch
Issue: Direct inversion and linear systems solutions for small matrices
Labels: module: performance,module: cuda,triaged,module: linear algebra

## 🚀 Feature
Performance improvements to linalg in GPUs

## Motivation
After noticing that one of my functions was running unusually slow and timing line per line I noticed that a batched inversion of 2 x 2 matrices was hundreds of time slower than a 8k-point FFT on GPU. Experiments show that the a 2 x 2 inversion formula implemented in python may be hundreds of time faster on GPU than the linal implementatinos for inv and solve, of pytorch 1.9.0.

## Pitch
The linalg module is an active development area in pytorch, it may have many opportunities for improvements, and it seems I identified one important.

## Alternatives
Probably implementing this feature in a wrapper as I did is not a good idea since it would probably affect the performance for small batches.

## Additional context

I prepared a notebook that can be visulised [here](https://gist.github.com/o-alexandre-felipe/dedcbc88c89ed52601fb2dfb884a2608#file-linalg-solve-2x2-experiment-ipynb), where I describe the implementation with the analytic inversion formula and run the experiments, so that you can review my methodology.

Just to give an ide, here I show the performance of a batched solve, in number of 2x2 matrix inversions per microseconds.

computation|float32 | float64 | complex64 | complex128
-- | -- | -- | -- | --
custom@cuda|3533.943528 | 4137.873960 | 3723.701359 | 3645.776368
linalg@cuda|22.632545 | 22.065084 | 22.591386 | 16.020514
custom@cpu|117.163244 | 47.921409 | 43.829660 | 12.162328
linalg@cpu|9.671292 | 7.813403 | 7.009462 | 6.682558

The proposed implementation is not very appealing for CPU but it gives massive gains for the GPU backend. But, the only scenario where the proposed implementation is considerably worse than the linalg implementation was the CPU with back propagation for complex128, I don't believe this is a very important case, since in general when training GPUs are available.

The proposed method gains with a significant margin, this suggests that there may be gains for larger systems as well, but I did not test.


cc @VitalyFedyunin @ngimel @heitorschueroff @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
Repository: deno
Issue: Expose console primitives to Workers
Labels: public API,suggestion

This is a probably a pretty niche use case, but maybe there's some useful general feature to arise from it.

I have the following situation:
* I am running some code in a `Worker`
* I would like to capture console output that happens in the worker (exactly as it would be written to stdout/stderr, ideally)
* The worker loads user-provided and semi-trusted code, so I don't want to give it `Deno` privileges

I tried to copy/paste the guts of the [console implementation](https://github.com/denoland/deno/blob/v1.13.2/ext/console/02_console.js), but in addition to being quite complex, it's not possible to replicate fully without some internal hooks, notably to inspect `Promise` values (and maybe other stuff).

Other approaches I tried or considered:
* The low-tech solution of just consuming the Deno process's output stream, but once there's more than one such worker it's not possible to distinguish between them.
* A convoluted implementation that uses message passing to the main thread to call `Deno.inspect`, but there's no guarantee that logged objects can be transferred over the boundary.

I got stuck at this point, and ended up forking Deno to solve this. (I added a `runtime/js` script that exports the `Console` class, and do `console = new Console(myInterceptorFunc)` in the Worker module). This was quite a simple change and ended up with exactly the behavior I want, but naturally I'd rather not have to maintain a fork.

Would any of these features be considered for Deno (in order of how useful they'd be to me)?
* Exposing the `Console` class constructor to workers somehow
* Providing a CLI option that allows injecting scripts while the global context is being set up (so I could do what my fork does without rebuilding the binary)
* Providing an option in the `Worker` constructor to redirect its output/error streams
* Making it possible to give a worker access to `Deno.inspect` but nothing else (maybe #8174 implies this, but it's not clear to me if it goes far enough)

Open to any other alternatives that achieve the same result as well!
Repository: TypeScript
Issue: Sourcemap for async function with target es2015 has missing line
Labels: Bug

# Bug Report

`Async` functions are downleveled to a generator, using the `__awaiter` wrapper.
If an async function throws an exception, the stack trace includes the call to `__awaiter` and then the internals of `__awaiter` in the following frames. The problem is with how to map those to source code.

Using `importHelpers` and `noEmitHelpers` helps with producing stable stack frames for the `__awaiter` internals, that can be mapped back to `tslib`.
However, the very call to `__awaiter` in my app code is still inlined, and it currently doesn't have any mapping.

This makes it a problem with tools that rely on stable stack traces. Logging tools, such as Sentry, heavily use mapped stack traces to group multiple occurrences of the same error into a single bucket. Inability to map some frames prevents such grouping, which results in all sorts of problems when monitoring the app in production (false alarms, noise on the dashboard).

Similar issues about async sourcemaps - which I still believe describe different problems than mine:
- https://github.com/microsoft/TypeScript/issues/13522
- https://github.com/microsoft/TypeScript/issues/14506

### 🔎 Search Terms

sourcemap, async, awaiter, generator

### 🕗 Version & Regression Information

I tested it in 3.5, 4.2 and 4.3. Probably it has always been the case.

### ⏯ Playground Link
[Playground link with relevant code](https://www.typescriptlang.org/play?noEmitHelpers=true&importHelpers=true&target=2&inlineSourceMap=true&ts=4.3.5#code/IYZwngdgxgBAZgV2gFwJYHsIysANrgQXGgAoBKGAbwCgYZkALAJ3QHcYIBTdgUSZaYkA5MShCy1AL7VqOfEUhRy1IA)

Here I enabled source maps. If you decode it, you can see that there is no mapping for line (2) (the `__awaiter(this, void 0, void 0, function* () ` call). Yet, this line is present in the stack trace.

### 💻 Code
```ts
// original.ts

async function callAsync() {
  throw new Error('sync')
}

callAsync()
```

```js
// compiled.js

function callAsync() {
    return __awaiter(this, void 0, void 0, function* () { // <----- This line (2) is present in error stack trace
        throw new Error('sync');
    });
}
callAsync();
```

### 🙁 Actual behavior

Stack trace includes line (2) (the one with the awaiter call). However, the sourcemap doesn't have a mapping for this line

### 🙂 Expected behavior

I don't know, frankly. Why don't we map this line to the declaration of our async function (source line 1)? Or to the declaration of the awaiter helper?
Repository: go
Issue: cmd/compile: shorter slicing instruction sequence on x86/amd64
Labels: Performance,NeedsInvestigation,binary-size,compiler/runtime

Compiling on tip:
```
func Slice(x []int, y int) []int {
    return x[y:]
}
```

and cutting out the function prologue on amd64 we get:
```
CMPQ    BX, DI
JCS     panicpath
SUBQ    DI, CX
SUBQ    DI, BX
MOVQ    CX, DX
NEGQ    CX
SHLQ    $3, DI
SARQ    $63, CX
ANDQ    CX, DI
ADDQ    DI, AX
MOVQ    DX, CX
```

We should be able to slim that down to (not tested):
```
CMPQ    BX, DI
JCS     panicpath
SUBQ    DI, CX
SUBQ    DI, BX
SHLQ    $3, DI
TESTQ   CX, CX
CMOVZ   CX, DI
ADDQ    DI, AX
```

by pulling the AND and OpSlicemask operation in the [ssa generation phase](https://github.com/golang/go/blob/de1c934b9709728b15cc821a055155ee13e1d0ab/src/cmd/compile/internal/ssagen/ssa.go#L5762) into a single new OpSlicedelta operation:

before:
```
mask := s.newValue1(ssa.OpSlicemask, types.Types[types.TINT], rcap)
delta = s.newValue2(andOp, types.Types[types.TINT], delta, mask)
```
after:
```
delta = s.newValue2(ssa.OpSlicedelta, types.Types[types.TINT], delta, rcap)
```

By either making the compiler SSA optimizations smarter or pulling even more operations into a special SSA Op we could save the TESTQ and be able to get to:
```
CMPQ    BX, DI
JCS     panicpath
SUBQ    DI, BX
SUBQ    DI, CX
CMOVE   CX, DI
SHLQ    $3, DI
ADDQ    DI, AX
```

However it is unclear if this will be any faster (or worth the complexity) without benchmarking when the scaling of the index for the delta happens after the CMOV.

A further reduction in instructions is possible by moving the panic jumps to be dependent on the SUB instructions:

```
SUBQ    DI, BX
JS      panicpath
SUBQ    DI, CX
CMOVE   CX, DI
SHLQ    $3, DI
ADDQ    DI, AX
```

That then will need extra handling in recovering the original slice len/cap in the panicpath.

At last for this specific case the SHL and ADD can be folded into a LEA:
```
SUBQ    DI, BX
JS      panicpath
SUBQ    DI, CX
CMOVE   CX, DI
LEAQ    [AX+DI*8], AX
```


/cc @randall77 @josharian @mdempsky
Repository: next.js
Issue: [NEXT-579] Router.push() does not fully route when dynamic route has hash (static export)
Labels: bug

### What version of Next.js are you using?

11.1.0

### What version of Node.js are you using?

14.7.0

### What browser are you using?

Chrome

### What operating system are you using?

Windows

### How are you deploying your application?

next export

### Describe the Bug

When using `Router.push()` on a static-exported site with dynamic routes, I am not re-routed correctly if my current URL and the to-be-routed-to URL differ by hash alone, or by part of the pathname alone.

I have a router page that I use to route client-side to various pages (many of which have dynamic routes). When hitting the static server, it returns the router page, which then routes client-side to any other page in the app (depending on the URL). When trying to route to a dynamic route with a hash after the pathname, `Router.push()` updates the URL, but does not actually route me to the correct page (I am visually still on the router page).

I'm calling Router.push() like this (pretend the `asPath` and `query.id` and `hash` parameters aren't hardcoded):
```js
useEffect(() => {
  Router.push({
    pathname: '/posts/view',
    query: {
      id: 'first-post',
    },
    hash: 'so-cool'
  }, '/posts/first-post#so-cool')
}, [])
```

I have only seen this issue with a static HTML export.

### Expected Behavior

I expect `Router.push()` to route me to the correct next.js page, even if my current pathname and/or hash matches the `asPath` value I pass to it.

### To Reproduce

1. Clone this repo: https://github.com/skitterm/nextjs-routing-issue
2. Follow instructions on README for setup
3. Navigate to `http://localhost:3000/posts/first-post#so-cool`. Observe that the URL is updated but the router page is still shown ("Routing") -- _bug_.
4. Change the URL to `http://localhost:3000/posts/first-post`. Observe that the URL is updated but the router page is still shown ("Routing") -- _bug_.
5. Change the URL to `http://localhost:3000/posts`. Observe that you are routed correctly to the `/posts/first-post#so-cool` page -- _works as intended_.

<sub>[NEXT-579](https://linear.app/vercel/issue/NEXT-579/routerpush-does-not-fully-route-when-dynamic-route-has-hash-static)</sub>
Repository: godot
Issue: Vulkan: VoxelGI does not take SpatialMaterial UV scale/offset into account in reflection
Labels: bug,topic:rendering,confirmed,topic:3d

### Godot version

v4.0.dev.calinou [b4cea1077]

### System information

Mx Linux (Debian Based)

### Issue description

When baking VoxelGI only albedo got reflected

![image](https://user-images.githubusercontent.com/1168582/130886789-59698f2b-aea1-48c9-9d5f-0a2bb19f166e.png)


### Steps to reproduce

Use the Main.tscn from the Minimal reproduction project

### Minimal reproduction project

[Voxel.zip](https://github.com/godotengine/godot/files/7050929/Voxel.zip)