sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Clarify how to test for errors in effects
Labels: area: testing,area: core,P3,core: reactivity,cross-cutting: signals,area: docs

### Describe the problem that you experienced

Given a component that has an effect that throws an error, it's not clear what is the correct way to write a unit test to test for that error. Please see the code below. This is a standard way to test that something throwing an error. However, this unit test does not pass saying that exception was not thrown. Notably, the expected thrown error is visible in the terminal.

```ts
class MyComponent {
  name = input.required<string>();
  
  private validateNameEffect = effect(() => {
    if (this.name() !== 'Tom') {
      throw new Error('Not Tom')
    }
  });
}

it('should throw error', () => {
  expect(() => {
    const fixture = TestBed.configureTestingModule({
      imports: [MyComponent],
    }).createComponent(MyComponent);
	
    fixture.detectChanges();
	
    TestBed.flushEffects();
  }).toThrow()
});
```

I figured out a way to make test pass using custom `ErrorHandler`. However, that seems very hacky:

```ts
class TestErrorHandler extends ErrorHandler {
  caughtError: any;
  
  override handleError(error: any) {
    this.caughtError = error;
    // not calling original error handling to avoid
    // terminal being polluted
    // super.handleError(error);
  }
}

it('should throw error', () => {
  const fixture = TestBed.configureTestingModule({
    imports: [MyComponent],
    providers: [
      { provide: ErrorHandler, useClass: TestErrorHandler },
    ],
  }).createComponent(MyComponent);

  const errorHandler = TestBed.inject(ErrorHandler) as unknown as TestErrorHandler;
  
  expect(errorHandler.caughtError).toBeDefined();
});
```

### Enter the URL of the topic with the problem

https://twitter.com/dmitryaefimenko/status/1788714569420173689

### Describe what you were looking for in the documentation

Clear instructions on how to test for errors in effects

### Describe the actions that led you to experience the problem

_No response_

### Describe what you want to experience that would fix the problem

_No response_

### Add a screenshot if that helps illustrate the problem

_No response_

### If this problem caused an exception or error, please paste it here

_No response_

### If the problem is browser-specific, please specify the device, OS, browser, and version

_No response_

### Provide any additional information here in as much as detail as you can

_No response_
Repository: vscode
Issue: Redundant `Open Workspace` button appears after `Preferences: Open Workspace Settings (JSON)`
Labels: bug,settings-editor,confirmation-pending

Type: <b>Bug</b>

1. Open a workspace from a .code-workspace file.
2. Use Command Palette to run `Preferences: Open Workspace Settings (JSON)`
3. The lower right corner of the file editor offers a button with which to open the workspace, despite it being already open.

![image](https://github.com/microsoft/vscode/assets/6726799/d4cde6fc-10a0-42a2-a787-ba50bcbef1aa)

VS Code version: Code - Insiders 1.90.0-insider (1facdf8117ba7aa833fa90539414e310a581e74c, 2024-05-10T05:50:12.930Z)
OS version: Windows_NT x64 10.0.22631
Modes:


<!-- generated by issue reporter -->
Repository: godot
Issue: ColorPickerButton toggle mode has no effect on color picker visibility
Labels: bug,confirmed,topic:gui

### Tested versions

- Reproducible in v3.5.3.stable.official [6c814135b], v4.0.1.stable.mono.official [cacf49999], v4.2.2.stable.official [15073afe3]

### System information

Godot v4.2.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (8 Threads)

### Issue description

Setting `toggle_mode` to true (by default) on a `ColorPickerButton` will not actually make the button togglable. When first pressing the button it will show the color picker but pressing the button again will not hide it; the user must click elsewhere to hide the picker.

As is said in the [documentation](https://docs.godotengine.org/en/stable/classes/class_colorpickerbutton.html#description):
> Pressing the button will toggle the [ColorPicker](https://docs.godotengine.org/en/stable/classes/class_colorpicker.html#class-colorpicker)'s visibility.

but that's not the case, the picker is always shown when clicking on the button.

### Steps to reproduce

- Run the scene in the MRP
- Click the color picker button => the color picker is shown
- Click the button again => the color picker is still visible
- Click outside the button => the color picker is hidden

### Minimal reproduction project (MRP)

[bug_color_picker_button.zip](https://github.com/godotengine/godot/files/15279424/bug_color_picker_button.zip)
Repository: go
Issue: x/text/collate: ignores case and diacritics by default
Labels: NeedsInvestigation

### Go version

go version go1.22.2 linux/amd64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/q3cpma/.cache/go-build'
GOENV='/home/q3cpma/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/q3cpma/.go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/q3cpma/.go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.2'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='x86_64-pc-linux-gnu-gcc'
CXX='x86_64-pc-linux-gnu-g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build4078013636=/tmp/go-build -gno-record-gcc-switches'
```


### What did you do?

https://go.dev/play/p/hkm5UYyP1Sx

### What did you see happen?

Output is `-1 -1 -1 1`. It seems the options `collate.IgnoreCase` and `collate.IgnoreDiactrics` are set by default with no way for the user to unset them.

### What did you expect to see?

`1 -1 1 -1` or at least a different value for the first two.
Repository: next.js
Issue: NextJS server is intercepting POST requests that _should_ be handled by rewrites, and treating them as GET
Labels: bug,Navigation,Pages Router

### Link to the code that reproduces this issue

https://github.com/etnichols/nextjs-rewrite-bug-repro

### To Reproduce

1. clone repro repo: https://github.com/etnichols/nextjs-rewrite-bug-repro.
2. `npm i`
3. `npm run dev`
4. Server will be up and running on `localhost:3000`. The server exposes a single page at `/checkout/billing/[id]`.
5. In the browser, visit `localhost:3000/checkout/billing/1234` and observe the following page is rendered as expected:
![Screenshot 2024-05-10 at 3 50 43 PM](https://github.com/vercel/next.js/assets/4588531/bf0cc12b-c216-4f97-a723-9ae9e9528937)
6. Using the CLI, perform a POST request to the same endpoint:

```bash
$ curl -H 'Content-Type: application/json' \
-d '{ "title":"foo","body":"bar", "id": 1}' \
-X POST \
http://localhost:3000/billing/1234
```
7. Observe that the server _returns HTML as a response to the POST_, when it should instead be using the `rewrite` fallback block defined in `next.config.mjs`.


### Current vs. Expected behavior

The NextJS server is treating POST requests to endpoints as GET requests, and incorrectly serves back HTML to the POST request, instead of either 1) using the next js fallback rewrite config or 2) simply returning a 404.

Expected behavior: given a POST request to some NextJS server which does not have an API route configured, appropriately using rewrite config, or return a 404.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:28:45 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6020
  Available memory (MB): 16384
  Available CPU cores: 12
Binaries:
  Node: 18.17.1
  npm: 9.6.7
  Yarn: N/A
  pnpm: 8.7.6
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Navigation, Pages Router

### Which stage(s) are affected? (Select all that apply)

next dev (local), Vercel (Deployed)

### Additional context

We have a production app exhibiting this behavior as well.
Repository: pytorch
Issue: scalar_tensor call with symbolic bool input does not work in inductor
Labels: triaged,oncall: pt2,module: dynamic shapes,module: inductor

### 🐛 Describe the bug

Internal xref: https://fb.workplace.com/groups/469587837192818/posts/1638909336927323/

```
import torch

@torch.compile(fullgraph=True, dynamic=True)
def f(x):
    return torch.tensor(x.size(0) // 100 == 20)

f(torch.randn(8))
```

fails with

```
  File "/data/users/ezyang/b/pytorch/torch/_inductor/compile_fx.py", line 784, in fx_codegen_and_compile
    graph.run(*example_inputs)
  File "/data/users/ezyang/b/pytorch/torch/_dynamo/utils.py", line 273, in time_wrapper
    r = func(*args, **kwargs)
  File "/data/users/ezyang/b/pytorch/torch/_inductor/graph.py", line 730, in run
    return super().run(*args)
  File "/data/users/ezyang/b/pytorch/torch/fx/interpreter.py", line 145, in run
    self.env[node] = self.run_node(node)
  File "/data/users/ezyang/b/pytorch/torch/_inductor/graph.py", line 1199, in run_node
    result = super().run_node(n)
  File "/data/users/ezyang/b/pytorch/torch/fx/interpreter.py", line 202, in run_node
    return getattr(self, n.op)(n.target, args, kwargs)
  File "/data/users/ezyang/b/pytorch/torch/_inductor/graph.py", line 977, in call_function
    raise LoweringException(e, target, args, kwargs).with_traceback(
  File "/data/users/ezyang/b/pytorch/torch/_inductor/graph.py", line 974, in call_function
    out = lowerings[target](*args, **kwargs)
  File "/data/users/ezyang/b/pytorch/torch/_inductor/lowering.py", line 304, in wrapped
    out = decomp_fn(*args, **kwargs)
  File "/data/users/ezyang/b/pytorch/torch/_inductor/lowering.py", line 2299, in tensor
    elif len(data) == 0 or isinstance(data[0], (float, int)) and len(data) <= 8:
torch._dynamo.exc.BackendCompilerFailed: backend='inductor' raised:
LoweringException: TypeError: object of type 'Equality' has no len()
  target: aten.scalar_tensor.default
  args[0]: Eq((s0//100), 20)
  kwargs: {'dtype': torch.bool, 'device': device(type='cpu'), 'pin_memory': False}

Set TORCH_LOGS="+dynamo" and TORCHDYNAMO_VERBOSE=1 for more information

```

### Versions

main

cc @gchanan @zou3519 @kadeng @msaroufim @chauhang @penguinwu @bobrenjc93 @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @muchulee8 @ColinPeppler @amjames @desertfire @bdhirsh @anijain2305
Repository: godot
Issue: Animation Tree panel: zooming on Animation Blend Tree nodes show blurry text
Labels: bug,topic:gui

### Tested versions

- Reproducible in v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Ubuntu 22.04.4 LTS 22.04 - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 860M (nvidia; 535.161.07) - Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (8 Threads)

### Issue description

When working on an Animation Node Blend Tree on an Animation Tree, zooming on nodes will show blurry text as if scaled up and interpolated, instead of rendering text at the target size and being crisp as expected.

![image](https://github.com/godotengine/godot/assets/1067772/bb656272-1af4-4bbf-b3f1-8844087c9171)

### Steps to reproduce

1. Create an AnimationTree node
2. Inspector > Tree Root > Create new AnimationNodeBlendTree
3. AnimationTree panel should now show a node editor
4. Right-click > Animation to add some node
5. Mouse scroll to zoom in

### Minimal reproduction project (MRP)

N/A
Repository: pytorch
Issue: Support AOT Autograd level Caching
Labels: triaged,oncall: pt2,module: startup-tracing-compile

### 🚀 The feature, motivation and pitch

`torch.compile` can takes order of seconds to compile a decent size model like Llama2 7B with a `aot-autogra` enabled backend. Note that I only include the `dyanmo` + `aot_autograd` time, this does not include the backend compiler(like inductor) compilation time. It would be ideal if dynamo can cache the `torch.compile` to speed up development time.

We(PyTorch/XLA) are trying to integrate with the `VLLM`. @WoosukKwon reports that in the warm up phase of the `VLLM`, it needs to pre-compile ~30 different input shape combinations. PyTorch/XLA does not support dynamic shapes today so `torch.compile` will keep compiling the model code which slows down the development speed(@WoosukKwon needs to wait for 10 minutes before warm up is finished). PyTorch/XLA already cache the XLA compilation but `torch.compile` itself is pretty expensive.

### Alternatives

Reduce `torch.compile` time for a model with only batch dimension changes.

### Additional context

cc @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang @yanboliang
Repository: go
Issue: x/build: add LUCI aix-ppc64 builder
Labels: Builders,NeedsInvestigation,OS-AIX,new-builder,arch-ppc64x

There currently isn't a LUCI builder that tests the aix/ppc64 port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.
Repository: go
Issue: x/build: add LUCI freebsd-arm builder
Labels: OS-FreeBSD,Builders,NeedsInvestigation,new-builder,arch-arm

There currently isn't a LUCI builder that tests the freebsd/arm port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.
Repository: go
Issue: x/build: add LUCI freebsd-arm64 builder
Labels: OS-FreeBSD,Builders,NeedsInvestigation,new-builder,arch-arm64

There currently isn't a LUCI builder that tests the freebsd/arm64 port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.
Repository: go
Issue: x/build: add LUCI illumos-amd64 builder
Labels: Builders,NeedsInvestigation,new-builder,OS-illumos,arch-amd64

There currently isn't a LUCI builder that tests the illumos/amd64 port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.
Repository: go
Issue: x/build: add LUCI linux-mips builder
Labels: OS-Linux,Builders,NeedsInvestigation,new-builder,arch-mips

There currently isn't a LUCI builder that tests the linux/mips port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.

CC @golang/mips.
Repository: go
Issue: x/build: add LUCI linux-mipsle builder
Labels: OS-Linux,Builders,NeedsInvestigation,new-builder,arch-mips

There currently isn't a LUCI builder that tests the linux/mipsle port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.

CC @golang/mips.
Repository: go
Issue: x/build: add LUCI linux-mips64 builder
Labels: OS-Linux,Builders,NeedsInvestigation,new-builder,arch-mips

There currently isn't a LUCI builder that tests the linux/mips64 port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.

CC @golang/mips.
Repository: go
Issue: x/build: add LUCI linux-mips64le builder
Labels: OS-Linux,Builders,NeedsInvestigation,new-builder,arch-mips

There currently isn't a LUCI builder that tests the linux/mips64le port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.

CC @golang/mips.
Repository: go
Issue: x/build: add LUCI linux-s390x builder
Labels: OS-Linux,Builders,NeedsInvestigation,new-builder,arch-s390x

There currently isn't a LUCI builder that tests the linux/s390x port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.
Repository: go
Issue: x/build: add LUCI windows-arm builder
Labels: OS-Windows,Builders,NeedsInvestigation,new-builder,arch-arm

There currently isn't a LUCI builder that tests the windows/arm port (other than the misc-compile builder, which tests only that the port compiles). This is the tracking issue for it.

The next steps that a builder owner will need to follow to make progress here are documented https://go.dev/wiki/DashboardBuilders#luci-builders.

Edit: Issue #57960 is related.
Repository: go
Issue: x/text/message/pipeline: unrecognized failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/text/message/pipeline" && test == ""
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/d77693b89796eabb24292ba2f4a21271f3c2fb26)):

    panic: Cannot range over: func(yield func(E) bool)
    
    goroutine 592 [running]:
    golang.org/x/tools/go/ssa.(*builder).rangeStmt(0xc000b43df8, 0xc0020fe000, 0xc001261140, 0x0)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2096 +0x774
    golang.org/x/tools/go/ssa.(*builder).stmt(0xc000b43df8, 0xc0020fe000, {0xf8cc2d8?, 0xc001261140?})
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2315 +0x205
    golang.org/x/tools/go/ssa.(*builder).stmtList(...)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:946
    golang.org/x/tools/go/ssa.(*builder).stmt(0xc000b43df8, 0xc0020fe000, {0xf8cc158?, 0xc00133a300?})
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2277 +0xe47
    golang.org/x/tools/go/ssa.(*builder).buildFunctionBody(0xc000b43df8, 0xc0020fe000)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2391 +0x433
    golang.org/x/tools/go/ssa.(*builder).buildFunction(0xf61fc80?, 0xc0020fe000)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2326 +0x28
    golang.org/x/tools/go/ssa.(*builder).buildCreated(0xc000b43df8)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2413 +0x25
    golang.org/x/tools/go/ssa.(*Package).build(0xc006466480)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2606 +0xc25
    sync.(*Once).doSlow(0xc0002181e0?, 0x0?)
    	/tmp/buildlet/go/src/sync/once.go:74 +0xb4
    sync.(*Once).Do(...)
    	/tmp/buildlet/go/src/sync/once.go:65
    golang.org/x/tools/go/ssa.(*Package).Build(...)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2477
    golang.org/x/tools/go/ssa.(*Program).Build.func1(0xc00021a3e0?)
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2462 +0x45
    created by golang.org/x/tools/go/ssa.(*Program).Build in goroutine 33
    	/tmp/buildlet/gopath/pkg/mod/golang.org/x/tools@v0.6.0/go/ssa/builder.go:2461 +0x187


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: flutter
Issue: Close the search by pressing escape
Labels: a: text input,c: new feature,framework,f: material design,c: proposal,f: focus,P2,team-design,triaged-design

### Use case

I'm using the [`showSearch()`](https://api.flutter.dev/flutter/material/showSearch.html) method with a custom [`SearchDelegate`](https://api.flutter.dev/flutter/material/SearchDelegate-class.html) this works fine so far, I just would like to close the search by pressing the escape key. Since this is an internal _SearchPageRoute this feature requires a lot of code duplication for this small feature. Therefore it would be nice to have that feature build in.

### Proposal

I would like to close the search with the escape button.
Repository: next.js
Issue: optimizePackageImports' caches index.ts files (dev and build) when they resolve to source files outside node_modules.
Labels: bug,SWC

### Link to the code that reproduces this issue

https://github.com/threehams/next-optimize-caching

### To Reproduce

Dev caching:
1. Run `npm run dev`
2. Add a syntax error to `ui/index.ts`

Build caching:
1. Run `npm run build`
2. Rename `ui/Button.tsx` to `ui/CounterButton.tsx`, and update imports in `ui/index.ts`
3. Run `npm run build` again

### Current vs. Expected behavior

Current:
Dev caching: The syntax error is not reported. The dev server caches the contents of `index.ts` file until server restart.

Build caching:
```
./ui/index.ts
Module not found: Can't resolve './Button'
```
The build caches the `index.ts` file permanently, and will fail until the `.next` directory is deleted.

Expected:
The [Next.js 14.2 release notes](https://nextjs.org/blog/next-14-2#tree-shaking) encourage using `optimizePackageImports: ['package-name']` to optimize barrel files. When these files are outside `node_modules`, the imports should be re-evaluated when those `index.ts` files have changed on disk, in both dev and production builds.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.10.0
  npm: 10.2.5
  Yarn: 1.22.19
  pnpm: 9.1.0
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Developer Experience, SWC

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local)

### Additional context

_No response_