sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Next.js doesn't revert to client rendering if `useSyncExternalStore` is used without a 3rd argument
Labels: bug

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 20.5.0
      npm: 9.8.0
      Yarn: 3.6.3
      pnpm: N/A
    Relevant Packages:
      next: 13.4.20-canary.11
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A
```


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

_No response_

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/github/vercel/next.js/tree/canary/examples/reproduction-template-pages

### To Reproduce

1. Create a new Next.js application
2. Create a page (e.g. `pages/index.js`)
3. Import and use `useSyncExternalStore` hook with **only 2 arguments**.
4. Review error when loading page.

### Describe the Bug

When using the `useSyncExternalStore` hook without a third argument (`getServerSnapshot`), Next.js throws the following error:
```
Error: Missing getServerSnapshot, which is required for server-rendered content. Will revert to client rendering.
```

According to [the React documentation](https://react.dev/reference/react/useSyncExternalStore#adding-support-for-server-rendering), the third argument for `useSyncExternalStore` should be optional. If it's not provided, the affected components should revert to client-side rendering.

### Expected Behavior

I expect components affected by this issue to revert to client-side rendering.

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

_No response_

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

_No response_
Repository: next.js
Issue: Get "modularize-import-loader" errors when running next 13 with turbo flag
Labels: bug,Lazy Loading

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.14.2
      npm: 9.5.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.20-canary.11
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A
```


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

App Router, Dynamic imports (next/dynamic)

### Link to the code that reproduces this issue or a replay of the bug

https:github.com/dannygooze/test-turbo-reo

### To Reproduce

1.  `yarn create next-app --experimental-app`
2.  `yarn add @headlessui/react`
3.  Edit dev script in package.json to be `"next dev --turbo"`
4. Add a headlessui component to page.tsx, see repo for example
5. Run `yarn dev`
6. See error in browser

### Describe the Bug

When running a next 13 app with turbo, yarn packages are having a hard time resolving due to the way turbo tries to modularize imports. I have tried updating the next config to get this to work and find the correct modules with no luck. 

Here is what I have tried adding in my next config:

`modularizeImports: {
    "@headlessui/react": {
      transform: "@headlessui/react/dist/components/{{kebabCase member}}/{{kebabCase member}}"
    }
  }`



### Expected Behavior

Expect this to run and import the components from yarn packages.

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

Chrome

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

Vercel
Repository: flutter
Issue: [google_maps_flutter] Allow us to not animate the camera to the marker when clicking the marker
Labels: c: new feature,p: maps,package,c: proposal,team-ecosystem,P2,triaged-ecosystem

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

On web it does not automatically animate the camera to center around the marker when tapping the marker, but on iOS and Android it does. I don't want to animate the camera when clicking the marker. On iOS we can hack it by doing `controller.moveCamera(CameraUpdate.scrollBy(0, 0));` in `Marker.onTap` but on Android this hack causes Y axis movement and the Y value changes on each device so we cannot workaround. To make matters worse there is an [existing bug](https://github.com/flutter/flutter/issues/39868) causing `Marker.consumeTapEvents` to stop working which was the [fix on Stack Overflow](https://stackoverflow.com/a/70619158/3935156). 

### Proposal

To be honest why not just remove the animateToMarker on marker tap, since we can easily just do that ourselves. This would be much more flexible than automatically doing it. But for backwards compatibility I guess add a flag for the option and default it to move the camera.
Repository: pytorch
Issue: _sampled_addmm_kernel cause 'misaligned address' with new triton pin
Labels: module: sparse,triaged

### 🐛 Describe the bug

This issue tracks the test failure for 
```
python test/test_sparse_csr.py -k test_triton_scaled_dot_product_attention_block_size_16_cuda_bfloat16
```
with new triton commit: 0410652666ddcad54aa4c403276b478a36379b90

Right after calling `_sampled_addmm_kernel` kernel, printing the tensor arguments result in 'misaligend address' error.

Note that test `test_triton_sampled_addmm` passes even though it runs 18 parametrized tests calling `_sampled_addmm_kernel` kernel. So the issue only happens with very specific input to the kernel.

We disable the test to unblock the triton pin upgrade. Use this issue to track it.

### Versions

..

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer
Repository: tensorflow
Issue: tf.data.Dataset.save deadlocks on error 
Labels: stat:awaiting tensorflower,type:bug,comp:data,TF 2.13

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

v2.13.0-rc2-7-g1cb1a030a62 2.13.0

### Custom code

Yes

### OS platform and distribution

Linux

### Mobile device

_No response_

### Python version

3.8.17

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

When saving a dataset to disk, TF will silently brick if there's an error in the data input pipeline. Methinks it should rather raise on the save instead of deadlocking.

Here's a reproducible example:

```python
import tensorflow as tf
# '2.13.0'

dataset = tf.data.Dataset.from_tensor_slices([1., 2., 0., 4.])
dataset = dataset.map(lambda x: tf.debugging.check_numerics(1. / x, "error"))
dataset.save('/tmp/hello')
# => deadlock
```

You can add an `ignore_errors` to the pipeline and it'll rightfully ignore, but it's nonintuitive to track down why the input bricks. 

```python
dataset = dataset.ignore_errors()
# => OK save
```

### Standalone code to reproduce the issue

```shell
See above.
```


### Relevant log output

_No response_
Repository: rust
Issue: This may be a me thing: No error generated if didn't flush buffer
Labels: A-lints,T-compiler,C-feature-request,A-io

### Code

```Rust
use std::io;
//use std::io::Write;

fn main() {
    print!("Guess the number!\n");
    //io::stdout().flush().unwrap();
    print!("\n Please intput your guess");
    //io::stdout().flush().unwrap();
    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");
    print!("\nYour number is {guess}");   
}
```


### Current output

```Shell
Guess the number!
```


### Desired output

```Shell
Warning: The print! macro doesn't automatically flush the output buffer. This means the output might not be displayed immediately on the screen. The println! macro, on the other hand, does flush the buffer because it appends a newline at the end. In situations where you're using print! and you need to ensure that the output is displayed immediately, you might need to flush the buffer manually. 

print! macro followed by either another print! macro or initialization of a variable can result in unexpected behavior. 
Consider changing print! to println!  
or consider adding use std::io::Write; after the use::std::io; and adding:  io::stdout().flush().unwrap();  after each print! instance.
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Anything else?

I just started Rust, so if this is a me thing, please let me know. I love this language!
Repository: pytorch
Issue: [inductor] soft_actor_critic training is slower than eager
Labels: triaged,oncall: pt2,module: inductor,internal ramp-up task

Our [perf dashboard](https://hud.pytorch.org/benchmark/torchbench/inductor_with_cudagraphs?startTime=Mon,%2021%20Aug%202023%2023:38:56%20GMT&stopTime=Mon,%2028%20Aug%202023%2023:38:56%20GMT&granularity=hour&mode=training&dtype=amp&lBranch=main&lCommit=138e2895d08a6517c5718b2a0118c1b23ff4664c&rBranch=main&rCommit=134d415615e39fb4a54420e58a508236a0614610) shows that soft_actor_critic is ~5% slower than eager for AMP training.

Running locally with float32 precision is even worse
```
TORCHINDUCTOR_MAX_AUTOTUNE=1 ./benchmarks/dynamo/torchbench.py --training --performance --no-skip --inductor --only soft_actor_critic
```
with a speedup of `0.82x`.

This is one of the only slowdowns inductor generates.  We should investigate what is going on here and fix it.  Looking at float32 might be easier to debug since the slowdown is more dramatic.




cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @Xia-Weiwen @ngimel
Repository: godot
Issue: Pop-up windows don't appear after switching the workspace on bspwm
Labels: platform:linuxbsd,topic:porting,needs testing,topic:gui

### Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

### System information

arch linux (6.4.11-arch2-1), bspwm (0.9.10-3)

### Issue description

if a pop-up window (such as a color selector) is opened, and the workspace is switched off the one the pop-up window is on, after switching back, no pop-up windows can be opened again, and the original pop-up window is also gone

to make pop-up windows open again i need to close and reopen godot

### Steps to reproduce

1. open pop-up window, such as a color selector
2. switch workspace
3. switch workspace back to godot

### Minimal reproduction project

N/A
Repository: pytorch
Issue: [inductor] Minifier fails on resnet50_quantized_qat
Labels: triaged,oncall: pt2,module: inductor

```
TORCHDYNAMO_REPRO_AFTER=dynamo ./benchmarks/dynamo/torchbench.py --training --performance --no-skip --inductor --only resnet50_quantized_qat
...
torch._dynamo.exc.BackendCompilerFailed: backend='inductor' raised:
RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation: [torch.cuda.FloatTensor [64]] is at version 2; expected version 1 instead. Hint: enable anomaly detection to find the operation that failed to compute its gradient, with torch.autograd.set_detect_anomaly(True).

Set TORCH_LOGS="+dynamo" and TORCHDYNAMO_VERBOSE=1 for more information

Minifier script written to /data/users/jansel/pytorch/torch_compile_debug/run_2023_08_28_17_07_24_508190-pid_3449892/minifier/minifier_launcher.py. Run this script to find the smallest traced graph which reproduces this error.
```

The generated script contains invalid syntax:
```python
python /data/users/jansel/pytorch/torch_compile_debug/run_2023_08_28_17_07_24_508190-pid_3449892/minifier/minifier_launcher.py
  File "/data/users/jansel/pytorch/torch_compile_debug/run_2023_08_28_17_07_24_508190-pid_3449892/minifier/minifier_launcher.py", line 27
    (activation_post_process): MovingAverageMinMaxObserver(min_val=-5.017982006072998, max_val=4.760481357574463)
                             ^
SyntaxError: invalid syntax
```


```python
class Repro(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.L__mod___activation_post_process_0 = FusedMovingAvgObsFakeQuantize(
  fake_quant_enabled=tensor([1], device='cuda:0'), observer_enabled=tensor([1], device='cuda:0'), scale=tensor([0.0770], device='cuda:0'), zero_point=tensor([65], device='cuda:0', dtype=torch.int32), dtype=torch.quint8, quant_min=0, quant_max=127, qscheme=torch.per_tensor_affine, reduce_range=True
  (activation_post_process): MovingAverageMinMaxObserver(min_val=-5.017982006072998, max_val=4.760481357574463)
)
        self.L__mod___conv1 = ConvBnReLU2d(
  3, 64, kernel_size=(7, 7), stride=(2, 2), padding=(3, 3), bias=False
  (bn): BatchNorm2d(64, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)
  (weight_fake_quant): FusedMovingAvgObsFakeQuantize(
```



cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov
Repository: next.js
Issue: High-cardinality HTTP span names
Labels: bug,Output (export/standalone),Navigation,Runtime

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.17.1
      npm: 9.8.1
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.12
      eslint-config-next: 13.4.12
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: standalone
```


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

Middleware / Edge (API routes, runtime), Routing (next/router, next/navigation, next/link), Standalone mode (output: "standalone")

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/BarryThePenguin/nextjs-otel-high-cardinality

### To Reproduce

- Run the OpenTelemetry Collector `docker-compose up -d` (copied from https://github.com/vercel/opentelemetry-collector-dev-setup)
- Build and run the reproduction with `npm run start:otel-verbose` (copied from https://github.com/vercel/next.js/tree/canary/examples/with-opentelemetry)
- Visit a dynamic route - both the app router and pages route have the same issue
- View the collected spans
	Jaeger at http://0.0.0.0:16686/
	Zipkin at http://0.0.0.0:9411/
	Prometheus at http://0.0.0.0:9090/

### Describe the Bug

Operations collected include dynamic segments values, which makes grouping similar spans impossible

The issue is similar to this topic https://github.com/open-telemetry/opentelemetry-js/issues/897

This is what we see in Jaeger

![image](https://github.com/vercel/next.js/assets/1351912/eba087d6-d8b9-492e-a24b-9c75af5f338e)

Note that the operation select input incudes `GET /legacy/vercel/next.js`

### Expected Behavior

According to the linked OpenTelemetry issue, I'd expect to see the operation name to be `GET /legacy/[...repoName]`, or something similar

> Names are not meant to uniquely identify a trace, but a class of traces. for instance, `GET /user/:id` is a good name, but `GET /user/123` is bad because you can't easily search for all traces for the same route.

It's also pointed out in the linked issue that the spec mentions

> Instrumentation MUST NOT default to using URI path as span name, but MAY provide hooks to allow custom logic to override the default span name.
https://opentelemetry.io/docs/specs/otel/trace/semantic_conventions/http/

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

_No response_

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

output standalone + k8s
Repository: go
Issue: proposal: syscall/js: Add `SetSymbol` method on `js.Value`
Labels: Proposal

This method should works as same as `js.Value.Set`, but it uses `Symbol` as the key.  
It's useful because we can use more js syntax sugar with symbols, such as `for ... of`, and we don't have to write extra javascripts to wrap them.  

A suggestion signature:
```go
func (js.Value)SetSymbol(symbol js.Value, value any)
```
Repository: rust
Issue: Inapplicable "add explicit lifetime bound" suggestion for trait with GAT bound
Labels: A-diagnostics,T-compiler,D-invalid-suggestion,A-GATs

### Code

```Rust
pub trait HasGat {
    type Gat<'a>
    where
        Self: 'a;
}

pub trait NoGat: for<'a> HasGat<Gat<'a> = Self::At> {
    type At;
}
```


### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0311]: the parameter type `Self` may not live long enough
 --> src/lib.rs:7:33
  |
7 | pub trait NoGat: for<'a> HasGat<Gat<'a> = Self::At> {
  |                                 ^^^^^^^^^^^^^^^^^^
  |
note: the parameter type `Self` must be valid for the lifetime `'a` as defined here...
 --> src/lib.rs:7:22
  |
7 | pub trait NoGat: for<'a> HasGat<Gat<'a> = Self::At> {
  |                      ^^
  = help: consider adding an explicit lifetime bound `Self: 'a`...
note: ...so that the type `Self` will meet its required lifetime bounds...
 --> src/lib.rs:7:33
  |
7 | pub trait NoGat: for<'a> HasGat<Gat<'a> = Self::At> {
  |                                 ^^^^^^^^^^^^^^^^^^
note: ...that is required by this bound
 --> src/lib.rs:4:15
  |
4 |         Self: 'a;
  |               ^^

error[E0311]: the parameter type `Self` may not live long enough
 --> src/lib.rs:8:5
  |
8 |     type At;
  |     ^^^^^^^^
  |
note: the parameter type `Self` must be valid for the lifetime `'a` as defined here...
 --> src/lib.rs:7:22
  |
7 | pub trait NoGat: for<'a> HasGat<Gat<'a> = Self::At> {
  |                      ^^
  = help: consider adding an explicit lifetime bound `Self: 'a`...
note: ...so that the type `Self` will meet its required lifetime bounds...
 --> src/lib.rs:8:5
  |
8 |     type At;
  |     ^^^^^^^^
note: ...that is required by this bound
 --> src/lib.rs:4:15
  |
4 |         Self: 'a;
  |               ^^

For more information about this error, try `rustc --explain E0311`.
error: could not compile `playground` (lib) due to 2 previous errors
```


### Desired output

_No response_

### Rationale and extra context

The message contains the suggestion

> consider adding an explicit lifetime bound `Self: 'a`...

...but there is nowhere I can see that would be syntactically valid to do this.

One solution is to have `trait NoGat: 'static + for<'a> ...`, but I don't know that it should be _the_ suggestion here, because it's potentially stricter than necessary.

This seems related to #96465, but note that this is not about whether this bound is a reasonable one or not, or how to express it if it is, but that the "help" message is not applicable (and quite confusing when more complex types and traits are involved).

### Other cases

_No response_

### Anything else?

_No response_
Repository: godot
Issue: Print and debugging not working
Labels: bug,platform:windows,topic:editor,needs testing

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 1070 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (8 Threads)

### Issue description

The output console displays some information.
1. Upon launch it displays Godot Engine info string
2. When stopping a project '--- Debugging process stopped ---' is displayed

During running of the program, the print function does not print anything to the output console.

It seems no debugging is working. Setting a breakpoint and running the project has no effect.

No visible errors are being produced.

If I run the Godot_v4.1.1-stable_win64_console executable instead, that console window *will* display output from print functions.

### Steps to reproduce

1. Create a project
2. Add a Node2D
3. Add a Sprite2D child
4. Add image as sprite texture
5. Add script to Sprite2D (see image)
6. Run project - Nothing is displayed in output console.

![editor_screenshot](https://github.com/godotengine/godot/assets/47288884/99b30ee8-42f6-4fd8-a5bd-447f39b93a32)

Likewise, try setting a breakpoint and project runs normally without stopping.

### Minimal reproduction project

N/A
Repository: neovim
Issue: Add support for "f-args-style" completion in `input()`
Labels: enhancement,completion

It would be nice to be able to interpret an `input()` prompt the same way a command line's arguments are interpreted when completion is available w.r.t. multiple arguments. Right now if you try to complete directories, for example, the second directory won't complete because it tries to complete "path/to/first path/to/secon" as opposed to just completing "path/to/secon". This would probably need to be an additional flag that indicates that you want to interpret the line as a series of arguments.
Repository: pytorch
Issue: nccl:all_reduce is not profiled correctly
Labels: oncall: distributed,oncall: profiler

### 🐛 Describe the bug

I am reading the source code or PyTorch DDP and using PyTorch profiler to measure the performance of NCCL allreduce operation. I understand the ncclAllReduce is an async call. 
In https://github.com/pytorch/pytorch/blob/6648880aca3914cc7995535fa0813ae580582492/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp#L1710, work is created in collective method(in my case, it's ncclAllReduce), and add a callback to the work at https://github.com/pytorch/pytorch/blob/6648880aca3914cc7995535fa0813ae580582492/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp#L1809. In the callback, it records the function end.
Then at https://github.com/pytorch/pytorch/blob/00eed6f36759323c70c6e05ccb1561367921eee0/torch/csrc/distributed/c10d/reducer.cpp#L1565, the Future waits for the CUDA stream to be completed, then the callback will be triggered and record the end time of nccl:all_reduce. 

Questions:

1. Is my above understanding correct?
2. If I understand the code correctly, why the duration of nccl:all_reduce the profiler captured looks incorrect? E.g., the duration is very short, and it's not the end time of CUDA allreduce kernel.
![image](https://github.com/pytorch/pytorch/assets/97820520/ad7f8f92-ac8d-42ce-9982-c22e536df63e)




### Versions

https://github.com/pytorch/pytorch.git

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @robieta @chaekit @aaronenyeshi @nbcsm @guotuofeng @guyang3532 @gaoteng-git @tiffzhaofb @dzhulgakov @davidberard98