sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: incompatible module path check doesn't apply for gopkg.in/yaml.v2
Labels: NeedsInvestigation,GoCommand

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version
go version go1.20.1 darwin/amd64
</pre>

### What did you do?

```
-- go.mod --
module w

go 1.20

require gopkg.in/yaml.v2 v2.4.0

replace gopkg.in/yaml.v2 => gopkg.in/yaml.v3 v3.0.0

-- main.go --
package main

import "gopkg.in/yaml.v2"

func main() {
        var t struct{ A string }
        _, _ = yaml.Marshal(&t)
}
```

And run `go build`

Note: the go.mod isn't tidy. 

### What did you expect to see?

Error related to mismatching module paths. (gopkg.in/yaml.v2 vs gopkg.in/yaml.v3)

### What did you see instead?

No error.

go list sees the replacement.

```
$ go list -f '{{.Module}}' gopkg.in/yaml.v2
gopkg.in/yaml.v2 v2.4.0 => gopkg.in/yaml.v3 v3.0.0
```

`go mod tidy`  adds gopkg.in/yaml.v3 to indirect require group. 
`go build` was ok as long as go.sum has an entry for v2.

```
module w

go 1.20

require gopkg.in/yaml.v2 v2.4.0

require gopkg.in/yaml.v3 v3.0.1 // indirect

replace gopkg.in/yaml.v2 => gopkg.in/yaml.v3 v3.0.0
```

On the other hand, 

```
--- go.mod ---
module e

go 1.20

require (
        github.com/go-logr/logr v1.2.0 // indirect
        k8s.io/klog v1.0.0
)
--- main.go ---
package main

import "k8s.io/klog/v2"

func main() {
        _ = klog.Info
}
--- go.sum ---
github.com/go-logr/logr v1.2.0 h1:QK40JKJyMdUDz+h+xvCsru/bJhvG0UxvePV0ufL/AcE=
github.com/go-logr/logr v1.2.0/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A=
k8s.io/klog/v2 v2.90.0 h1:VkTxIV/FjRXn1fgNNcKGM8cfmL1Z33ZjXRTVxKCoF5M=
k8s.io/klog/v2 v2.90.0/go.mod h1:y1WjHnz7Dj687irZUWR/WLkLc5N1YHtjLdmgWjndZn0=
```

`go build` returns an error (however, not explicitly talks about this path issue)

```
go build
main.go:3:8: no required module provides package k8s.io/klog/v2; to add it:
        go get k8s.io/klog/v2
```

`go mod tidy` update go.mod to the following without error.

```
module e

go 1.20

require k8s.io/klog/v2 v2.90.0

require github.com/go-logr/logr v1.2.0 // indirect

replace k8s.io/klog => k8s.io/klog/v2 v2.90.0
```

After that `go build` succeed. (I don't know why).
But `go list -f '{{.Module}}' k8s.io/klog` reports an error

```
$ go list -f '{{.Module}}' k8s.io/klog
module k8s.io/klog provides package k8s.io/klog and is replaced but not required; to add it:
        go get k8s.io/klog
$ go get k8s.io/klog
go: k8s.io/klog/v2@v2.90.0 used for two different module paths (k8s.io/klog and k8s.io/klog/v2)
```
Repository: vscode
Issue: Error notification shown in addition to modal error dialog
Labels: bug,remote,remote-connection

Testing microsoft/vscode-remote-release#8061

1) Trying to reopen a remote-ssh window without Internet connection

Since I'm already getting a model error dialog, I wouldn't expect an error notification.

<img width="1416" alt="image" src="https://user-images.githubusercontent.com/4674940/220503436-129384bb-6098-48ca-8985-738f291a0346.png">
Repository: go
Issue: cmd/link: allow specifying the macOS SDK in internal linking mode
Labels: NeedsInvestigation,compiler/runtime

It appears that the linker hardcodes the LC_BUILD_VERSION[^1] to target a min SDK of 10.13.0 for amd64 and 11.0 for arm64.

Is there a way to set this during "go build"?

[^1]: https://github.com/golang/go/blob/203e59ad41bd288e1d92b6f617c2f55e70d3c8e3/src/cmd/link/internal/ld/macho.go#L486
Repository: flutter
Issue: Fuchsia pointer injector has logspam on unexpected child view teardown
Labels: engine,platform-fuchsia,P2,team-engine,triaged-engine

Fuchsia pointer injector has logspam on unexpected child view teardown. The reason is that the validator checks for View.pointerinjector.inject is a little too strict, returning "false" for the platform message.
Repository: TypeScript
Issue: Investigate removing the concept of object allocators
Labels: Suggestion,Committed,Infrastructure,Domain: Performance,Experimentation Needed

Today we have the concept of an "object allocator". This is basically a set of functions, each which returns a constructor function for a commonly used data structure in the compiler.

```ts
/** @internal */
export interface ObjectAllocator {
    getNodeConstructor(): new (kind: SyntaxKind, pos: number, end: number) => Node;
    getTokenConstructor(): new <TKind extends SyntaxKind>(kind: TKind, pos: number, end: number) => Token<TKind>;
    getIdentifierConstructor(): new (kind: SyntaxKind.Identifier, pos: number, end: number) => Identifier;
    getPrivateIdentifierConstructor(): new (kind: SyntaxKind.PrivateIdentifier, pos: number, end: number) => PrivateIdentifier;
    getSourceFileConstructor(): new (kind: SyntaxKind.SourceFile, pos: number, end: number) => SourceFile;
    getSymbolConstructor(): new (flags: SymbolFlags, name: __String) => Symbol;
    getTypeConstructor(): new (checker: TypeChecker, flags: TypeFlags) => Type;
    getSignatureConstructor(): new (checker: TypeChecker, flags: SignatureFlags) => Signature;
    getSourceMapSourceConstructor(): new (fileName: string, text: string, skipTrivia?: (pos: number) => number) => SourceMapSource;
}
```

Why do this? Because for our batch compiler, TypeScript uses constructors with more bare-bones objects. For the most part, there are no members on the prototype, and we work purely with instance-set data.

On the other hand, the language service and TypeScript's API provides constructors that are attached to richer prototypes. For example, `Node`s constructed by the language service have methods like `getStart()`, `getEnd()`, `getSourceFile()`, etc. These are partially for convenience and if my memory serves correctly, partially to power backwards-compatibility ***going back to TypeScript 1.0's tree API***.

However, managing the two is slightly annoying, and creates layers of indirection. It would be nice to see if we can move away from this indirection and whether it can eliminate runtime overhead at all.
Repository: PowerToys
Issue: Numpad shortcuts that switch layouts whilst dragging a window no longer work - Ruining FancyZones
Labels: Issue-Bug,Product-FancyZones,Priority-2,Status-Reproducible

### Microsoft PowerToys version

0.67.1

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

This just stopped working. No idea why - version 0.59.0 works on my laptop still - this latest update autodownloaded and I must've clicked install. It ruined FancyZones completely.

When dragging a window using the titlebar, FancyZones used to show the custom setups (or any setup assigned to a numpad key for that matter). So I could switch between layouts without having to remember a ridiculous shortcut combination - just move the window and hit Numpad keys until I the best layout flashed up. This has stopped working and I don't know if you have removed this ability since an auto-update? This feature was brilliant. Without it, FancyZones becomes a total pain in the butt to use.

### ✔️ Expected Behavior

Fancy Zone layouts flash up whilst dragging a window and hitting the numpad shortcut keys - brilliant in its simplicity.

### ❌ Actual Behavior

Hitting the numpad buttons to switch between the layouts whilst dragging a window now does absolutely nothing.

Fancy Zones / Powertoys is now nowhere near as usable for me.

### Other Software

_No response_

### ✔️ Quick Fix for Others

I went through the GitHub repository and found the download for 0.59.0, after backing up settings I uninstalled 0.67.1, re-installed 0.59.0 from the downloaded exe - it automatically found all my settings.

[https://github.com/microsoft/PowerToys/releases/download/v0.59.0/PowerToysSetup-0.59.0-x64.exe](url)

Other versions here for anyone else wanting to go back: [https://github.com/microsoft/PowerToys/releases/](url)
Just open up the "Assets" drop down for each release and the exe should be there.

It works perfectly again. 0.67.2 really needs this window dragging shortcut back - I've had to turn off all auto-update/download features.
Repository: go
Issue: x/tools/go/packages: "files=" queries don't seem to work
Labels: NeedsInvestigation,Tools

### What version of Go are you using (`go version`)?

```
go version go1.20.1 linux/amd64
```

### Does this issue reproduce with the latest release?

Yes

### What did you do?

x/tools/go/packages is [documented](https://pkg.go.dev/golang.org/x/tools/go/packages#pkg-overview) as taking a special `files=` query to ask for a list of packages containing a set of Go source files. In all my tests, file-based queries always return zero packages.

Here's a small example program: https://github.com/cespare/misc/blob/main/pkgfilesquery/pkgfilesquery.go

If you want to run this, clone the repo and then, from the repo root, run

    go run ./pkgfilesquery

### What did you expect to see?

```
packages.Load returned 1 packages
github.com/cespare/misc/columns
```

### What did you see instead?

```
packages.Load returned 0 packages
```

---

I tried a variety of things including absolute paths but I always get 0 packages.

If I use a normal Go list pattern like `./columns` or `github.com/cespare/misc/columns` rather than a `file=` query, then it works fine.

I traced the inner workings of x/tools/go/packages briefly and it looks like the code initially gets the correct set of packages but no "roots" and then the subsequent "refinement" step filters the package list to zero.

There's also a documentation issue here. The docs say:

> The query "file=path/to/file.go" matches the package or packages enclosing the Go source file path/to/file.go. For example "file=~/go/src/fmt/print.go" might return the packages "fmt" and "fmt [fmt.test]".

But (a) it doesn't indicate how the filenames are resolved (are they relative to the cwd or config.Dir?) and (b) it suggests that `~` might work but I don't see any evidence that `~` is implemented in the code.

/cc @matloob, the owner according to s/owners
Repository: vscode
Issue: Default themes should also provide colours for the native bracket pair colourisation
Labels: feature-request,themes

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

The default themes, especially the new experimental V2 light and dark themes should also “theme” the native bracket pair colourisation. As far as I can tell, they just use the default colours which to my eye at least do not blend well with the other colours in the themes. I do appreciate that the bracket colourisation is intended to make the brackets more visible and stand in contrast to surrounding code, but I do think that that could be done in keeping with the colour palette of the selected theme.
Repository: tensorflow
Issue: Support for int32 variables
Labels: stat:awaiting tensorflower,type:feature,comp:ops,TF 2.11

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Feature Request

### Have you reproduced the bug with TF nightly?

No

### Source

binary

### Tensorflow Version

2.11

### Custom Code

Yes

### OS Platform and Distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?
Tensorflow currently does not support `int32` variables being placed on the GPU.
I've found an old [stackoverflow](https://stackoverflow.com/questions/37439299/no-gpu-kernel-for-an-int32-variable-op) post that argued this was because typically, `int32`  Tensors often represent sizes of shapes, which would be needed in host memory. 

If that is still a concern, maybe automatically placing any int32 Tensors with e.g. less than 1KiB size on the CPU, and larger ones on the GPU, might be the way to go?

For large integer tensors (e.g. indices for sparse operations), the current situation requires a trade-off between two undesireable situations:
* Either use `int64`, which wastes both GPU memory, and also memory bandwidth during kernel calls
* Or use `int32`, but then each step has to invoke a host-to-device data transfer.

Declaring the Variable as `float32` and bitcasting to `int32` before each use also does not allow to work around this issue, as the `bitcast` op also lacks a GPU kernel, and thus requires two memory transfers.

This request is somewhat related to #51728, as supporting int32 as index type for `SparseTensor` would run into the aforementioned data transfer problem if the index Tensor was backed by a Variable. 
Even now, [`SparseTensorDenseMatMul`](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/kernels/sparse_tensor_dense_matmul_op_gpu.cu.cc#L151) provides a kernel for `int32`, but again it cannot be used efficiently with indices supplies by a Variable.


### Standalone code to reproduce the issue

```shell
import tensorflow as tf
tf.config.set_soft_device_placement(False)

with tf.device("gpu:0"):
    v = tf.Variable(initial_value=tf.zeros((50, 50), dtype=tf.int32))
```


### Relevant log output

```shell
tensorflow.python.framework.errors_impl.InvalidArgumentError: Could not satisfy device specification '/job:localhost/replica:0/task:0/device:GPU:0'. enable_soft_placement=0. Supported device types [CPU].
```
</details>
Repository: material-ui
Issue: Provide a way to specify default theme for printing
Labels: customization: theme,enhancement

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [x] I have tested the latest version

### Summary 💡

In my app, I have support for light and dark themes.
When I initiate printing with `window.print()` I want the default light theme to be used regardless if the current displed theme is dark or light.

I tried to work around this by using `useMediaQuery('print')` and setting the theme to light but it does not work with `window.print()` only on `Ctrl+P`.

I also tried experimental CssVariables color schemas and if you would add the ability to specify media property for injected global stylesheets that may solve the issue.

### Examples 🌈

_No response_

### Motivation 🔦

It does not make sense to print pages on a dark theme because you will use a lot of ink for printing.
Repository: rust
Issue: Closure lifetime inference influenced by non-conflicting trait impl
Labels: A-lifetimes,A-trait-system,A-closures,A-inference

This is a variation of the other closure lifetime issues, but it triggers when adding a non-conflicting impl.

[Here's a minimized example of the issue](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1eae18b1204be6b49f70d2b254725b02)

```rust
struct Buffer<'a>(&'a ());

trait Encodable<'a, T> {
    fn encode(buffer: &mut Buffer<'a>, value: T);
}

struct Writer<'a> {
    buffer: Buffer<'a>,
}

struct Message<T = ()>(T);

impl<'a> Message<Writer<'a>> {
    fn foo(&mut self) {}
}

impl<'a, T: FnOnce(&mut Message<Writer<'a>>)> Encodable<'a, T> for Message {
    fn encode(buffer: &mut Buffer<'a>, _: T) {}
}

struct Wrapper<T>(T);

// Uncomment for type inference failure:
// impl<'a, T> Encodable<'a, Wrapper<T>> for Message {
//     fn encode(buffer: &mut Buffer<'a>, _: Wrapper<T>) {}
// }

fn main() {
    // Fails to infer msg parameter's type:
    Message::encode(&mut Buffer(&()), |msg| {
        msg.foo();
    });
    
    // "Implementation not general enough" when Encodable<'a, Wrapper<T>> impl
    // uncommented and previous call to encode commented out:
    Message::encode(&mut Buffer(&()), |_msg| {});
    
    // Works with and without Encodable<'a, Wrapper<T>> impl
    fn encoder<'a>(_msg: &mut Message<Writer<'a>>) {}
    Message::encode(&mut Buffer(&()), encoder);
}
```
Repository: godot
Issue: TileMap terrain system gives different results depending the order you place the tiles
Labels: bug,topic:core,confirmed,topic:2d

### Godot version

4.0 rc5

### System information

Ubuntu 22.04, Vulkan renderer, gforce 1650ti

### Issue description

Im making use of the terrain system for a side-scroller. I set the terrain and when i start painting, i find that the results are not always the same depending in the order i paint the tiles (and many of the results should not be valid).

Im ussing "match corners and sides". This video shows the issue:

https://user-images.githubusercontent.com/46932830/221331754-11542a33-375d-40ca-8e34-3def33020043.mp4


### Steps to reproduce

1- Set up the terrain system.
2- Paint 2x2 squares in different order.

### Minimal reproduction project

[TilemapTest.zip](https://github.com/godotengine/godot/files/10830100/TilemapTest.zip)
Repository: godot
Issue: Window.visibility_changed is emitted before _enter_tree, _ready
Labels: discussion,topic:gui

### Godot version

4.0 RC5

### System information

Windows 10

### Issue description

The `Window.visibility_changed` signal is emitted before and after `_enter_tree` and `_ready` with `visible == true`. Since it is no longer possible to override the `show` method to trigger content updates when the window is opened this is kinda problematic as all child nodes of the window are not yet available. It is also incorrect since the Window cant very well be visible if it hasn't entered the tree.

### Steps to reproduce

- Create a Window and connect the `visibility_changed` signal via the editor
- Try to access child nodes in the handler

### Minimal reproduction project

```
extends Window

func _enter_tree():
	print("enter")

func _ready():
	print("ready")

func _on_visibility_changed():
	print("visible")
	print(visible)
```

prints
```
visible
true
enter
ready
visible
true
```
Repository: TypeScript
Issue: Unexpected type inference for parameters in Function|object union
Labels: Needs More Info

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

union function parameter argument callback

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried
Version 4.9.5 and nightly

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link](https://www.typescriptlang.org/play?ts=5.0.0-dev.20230224#code/LAKFBcE8AcFMAIBiBLANuWAnAwgQ1agEa4DGA1gDwAqANPAMrywAeGAdgCYDO8V8AvLwB8A0PHgAfeAAppyDAFsAXLzrIOzFWwCuCwljq5MmXJBVUA2gF0AlAJHzYC+Mh70bYyfAD2hAFawJOCgEDAIKOhYAPL+geDUdIws7Ny8AsLpAN6eAGZoGJgqEQV4BMTkCQxCoAC+ANwhIAD0TT5koKiw4PAk+ESkZEX50bFBFFzgmMhsAOZeOnoG8Av6mCKC2SDieZGFMo4KahqGxqY2KgcuPCtY9vCb4uKYXdqYbPCT2rANW-A1tY0WvAAOoAC0gVw+oIQUDgPhyUIQ0CMuAUXVu00RPT65TI8By2jYQWQ3ne0xyWGeHAA-KAgfJ4KRwK8+hCFLhwCRoTxwND4AADXwBIL8jpdbFlAYAJiGuxiwviEyms3mulW63uuWGezkiiOzBOJkgdn4Igej2ezLeH0wXx+4n+IBqQA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type FilterCallback<T, S extends T = T> =
  | ((item: T, idx: number, array: T[]) => item is S)
  | object

type FilterObject<T, S extends T = T> = {
  filter: FilterCallback<T, S>
};

// ok
let callback: FilterObject<string | number, number> = {
  filter: (item, idx, array): item is number => {
    return true;
  }
}

// ?? Why is the type of the parameter in the callback function inferred?
// it acturally matches the `object`
let callback2: FilterObject<string | number> = {
  filter: (item, idx, array) => {
    return true;
  }
}
```

### 🙁 Actual behavior

parameters in `callback2` uses type inference from the unmatched one

### 🙂 Expected behavior

parameters in `callback2` should be implict any
Repository: godot
Issue: Allow decals to override Sub-Surface Scattering
Labels: feature proposal,topic:rendering,topic:3d

### Godot version

4.0 RC5

### System information

Windows 11, Vulkan

### Issue description

If you use a decal texture on a mesh that has subsurface scattering on the material the decal has undesired results, and gains the subsurface scattering on the decal.

Images with and without subsurface scattering;
![image](https://user-images.githubusercontent.com/100494538/221346166-b8c5d9b7-0895-4024-b974-313c3effafd6.png)
![image](https://user-images.githubusercontent.com/100494538/221346177-43f1937d-f49e-426a-bc66-53b3324406e6.png)


### Steps to reproduce

1. Create a new scene
2. Create a mesh instance and assign any mesh
3. Create a new material on the mesh and make sure it uses subsurface scattering, with a strength of 1, and skin mode toggled on.
4. Apply a decal onto the surface of the mesh from another node.

### Minimal reproduction project

N/A
Repository: godot
Issue: [Godot 4rc5] Error in Initialize
Labels: bug,topic:rendering,needs testing,topic:shaders

### Godot version

v4.0.rc5.official [6296b4600]

### System information

Debian 11

### Issue description

When  I run the project I have this error in tab errors:

```
E 0:00:01:0281   initialize: Condition "err != OK" is true.
  <C++ Source>   servers/rendering/renderer_rd/shader_rd.cpp:675 @ initialize()

```

### Steps to reproduce

run the example from https://godotengine.org/storage/blog/multiplayer-in-godot-4-0-scene-replication/project.zip

Got from https://godotengine.org/article/multiplayer-in-godot-4-0-scene-replication/

### Minimal reproduction project

https://godotengine.org/storage/blog/multiplayer-in-godot-4-0-scene-replication/project.zip
Repository: godot
Issue: MultiplayerSynchronizer paths to itself broken.
Labels: documentation,needs testing,topic:multiplayer

### Godot version

4.0 rc5

### System information

Windows 10

### Issue description

I tried making a script that extends the MultiplayerSynchronizer and exports some properties to be synced.
if I sync those variables it complains that it is unable to find the properties.
This also happens if the MultiplayerSynchronizer is a child node instead of the root and is renamed (does not matter if the root node is renamed as long as its not the synchronizer)


### Steps to reproduce

Use the included project, level.gd is what takes care of spawning the MultiplayerSynchronizers in `add_replicator()`.
I added two examples, one where the synchronizer is the root node and one where it is the child.

In the first example removing the `replicator.get_child(0).name = "test"` makes it work with no issues, even though the root node is also renamed and that is the node the synchronizer is pointing at.

The second example fails with the same error no matter if you rename it or not.

### Minimal reproduction project

[scene_replication.zip](https://github.com/godotengine/godot/files/10830615/scene_replication.zip)