sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: context: document that WithoutCancel may not be sufficient for asynchronous use
Labels: Documentation,Proposal

### Proposal Details

In #40221, a `WithoutCancel` function was added to the `context` package.

However, as noted in https://github.com/golang/go/issues/40221#issuecomment-660273706, a `Context` created by a call to `WithoutCancel` is in general only safe to use synchronously:
- The original parent context may contain values (from packages like those listed in https://github.com/golang/go/issues/40221#issuecomment-660270769) that are no longer usable — and perhaps not even safe to use! — after the return from the function call to which the context was passed.
- The values contained in the parent context may refer to large amounts of memory (such as for logging datastructures), which will not be garbage-collected while that context remains reachable.

So in order to safely use `context.WithoutCancel` for an _asynchronous_ call, one must have global information about both the callees (to ensure that the callee does not access a value with a call-scoped) and the callers (to ensure that the context does not close over a large, irrelevant value). Unfortunately, the [current documentation](https://pkg.go.dev/context@go1.21.4#WithoutCancel) for `WithoutCancel` doesn't prompt the reader to consider that subtlety at all, and when users do think about it they often don't have enough context (ha!) to think of these caveats on their own.

Indeed, some of the very first mentions of this new API — such as the SO answer linked in https://github.com/golang/go/issues/40221#issuecomment-1539683747 — suggest its use for asynchronous calls and neglect to consider or mention these factors.

I have already fielded multiple questions in Google-internal forums about whether `context.WithoutCancel` is safe to use in asynchronous code. I would like to answer those questions preemptively in the documentation rather than individually after the fact.

I propose that we add the following paragraph to the `context.WithCancel` documentation:
```go
// WithoutCancel returns a copy of parent that is not canceled when parent is canceled.
// The returned context returns no Deadline or Err, and its Done channel is nil.
// Calling [Cause] on the returned context returns nil.
//
// Note that the returned context might not be suitable for asynchronous use.
// The child context continues to refer to the parent for its implementation of the
// [Context.Value] method, which will prevent memory reachable from the parent from
// being garbage-collected while the child remains reachable.
// In addition, some of the parent's values (particularly for logging and tracing libraries)
// may be flushed or closed when control returns from the function to which the parent
// was originally passed, rendering those values invalid to use.
```
Repository: flutter
Issue: Drawing RTree DisplayList into another RTree DisplayList ferries all of the rectangles
Labels: engine,P3,team-engine,triaged-engine

In order to compute the most accurate pixel coverage for embedded platform layers the DisplayList will include the exact RTree coverage of a DisplayList when you draw one into another - only if both are calculating an RTree (see https://github.com/flutter/engine/pull/37451). In order to accomplish this exact accounting we copy all of the rectangles from the child DL's RTree into the parent DL's RTree. This involves a lot of duplication of data and the parent RTree now has many rectangles that all reference the same "rendering ID" which is redundant while traversing the tree for rendering.

The impact of this was discovered during a local Impeller profiling session and led to turning off the `prepare_rtree` flag for at least one Canvas in the system that wouldn't need to produce this exact pixel coverage (see https://github.com/flutter/engine/pull/48422).

One thought on improving the performance of this operation would be to include the child RTrees by reference into the parent RTree. This would involve far less copying, but it would complicate the traversal. This would save storage overall and when we are using the RTree for culling we don't need to test every single sub-rectangle for the culling test, we just need to test the overall bounds of the child RTree. The only time we need to look at every sub-rectangle is collecting coverage info for the platform view, which is a relatively rare operation since many apps do not embed platform widgets.
Repository: vscode
Issue: SCM - Diff editor breaks UX when there are a large amount of diffs
Labels: bug,diff-editor,scm

- VS Code Version: Insiders
- OS Version: Windows 11

Steps to Reproduce:

1. Check out microsoft/vscode-docs.
2. Overwrite api/references/vscode-api.md with the attached file. The SCM viewlet should pick up on the modification.
3. Click on the modified file to view the diff. The diff should time out after five seconds.
4. Open devtools. There should be a warning about too many listeners being registered.
5. In the SCM viewlet, press the revert button for the file.
6. :bug: The file cannot be reverted via the SCM viewlet.

![Devtools console showing many messages about listener leaks, followed by a message about the extension host becoming unresponsive](https://github.com/microsoft/vscode/assets/7199958/944f5a26-11ea-41f7-8bdc-25a42e0d10f7)

![The start of the diff editor showing that it's in side-by-side view and not the multi-diff editor](https://github.com/microsoft/vscode/assets/7199958/31565209-147f-4b1e-983a-120674b8d9a9)

[vscode-api.md](https://github.com/microsoft/vscode/files/13517111/vscode-api.md)
Repository: godot
Issue: Editor freeze when selecting Forward+ on old computer
Labels: bug,platform:macos,topic:porting

### Godot version

4.2 (today's release)

### System information

macOS 10.13.6 on 2017 Macbook Air

### Issue description

When I set the project to the Forward+ renderer, the editor locks up with a continuous loading icon. I have to force quit the app, but even worse now this project is stuck unless one happens to know the setting text to put in project.godot

On this system I have to use Compatibility mode, which isn't a problem in and of itself, since this is an old computer and I would expect that. However having the editor lock up with no error message, and hose my project in the process, is not fun. Setting to the Mobile renderer at least produces an error message and the editor still works.


(btw for reference if anyone else has this same issue, here's the setting to put in project.godot:)
[rendering]

renderer/rendering_method="gl_compatibility"
renderer/rendering_method.mobile="gl_compatibility"

### Steps to reproduce

This problem is probably specific to this computer, or at least any computer this old. Simply switching the editor's renderer menu from Compatibility to Forward+ will cause the editor to restart, at which point is locks up while loading.

### Minimal reproduction project

N/A
Repository: godot
Issue: Lights do not work correctly in Compatibility renderer
Labels: bug,platform:macos,topic:rendering,topic:thirdparty,topic:3d

### Godot version

4.2 (today's release)

### System information

macOS 10.13.6 on 2017 Macbook Air

### Issue description

Both directional and omni lights behave oddly for me. I am using an older computer that requires Compatibility mode. I made a simple scene with a character for testing.

To start with, I put in a directional light pointed at the character. When I only rotate the light on the X axis, no light appears in the play scene
![direct1](https://github.com/godotengine/godot/assets/1004316/b2c02820-a36e-46ba-86fa-86420d35dd1d)
![direct2](https://github.com/godotengine/godot/assets/1004316/46659828-04c7-4344-9f5a-446bb8bc758f)

Now I rotate the light on all axes, and light suddenly appears in the scene.
![direct3](https://github.com/godotengine/godot/assets/1004316/7d5e3826-a663-4c0e-9300-983f5f8b451e)
![direct4](https://github.com/godotengine/godot/assets/1004316/2bca689d-87a5-4ac1-acfb-0c6d0031ca7f)

The light is still pretty dim though, considering it's facing the front of the character. I set the material to Unlit for comparison.
![unlit1](https://github.com/godotengine/godot/assets/1004316/3b944eea-b2c5-4a12-89e8-5432744f6bf0)
![unlit2](https://github.com/godotengine/godot/assets/1004316/01bad0e0-9390-4346-a825-2f3a35da3342)

Anyway that's all with a directional light. Now I turned that off to test an omni light instead. Here it is with the default range value:
![omni1](https://github.com/godotengine/godot/assets/1004316/cfb82ebf-fa25-4b2e-9261-466bde0d4e75)
![omni2](https://github.com/godotengine/godot/assets/1004316/0bbf1bdc-731c-4ec6-ac98-8faae9e96c09)

Perhaps I'm misunderstanding that value, but here it is after increasing the range. Note the lighting looks exactly the same:
![omni3](https://github.com/godotengine/godot/assets/1004316/3f523414-a511-43dc-aa67-05aa4d5f93c2)
![omni4](https://github.com/godotengine/godot/assets/1004316/2816a760-3586-4eb8-9f07-37cb74444d16)

Given that I require Compatibility renderer on this computer, I'm certainly looking forward to lighting improvements, plus the addition of shadows!

### Steps to reproduce

Reproduction steps are part of the issue description. In summary, with the Compatibility renderer active I tested out both directional and omni lights, and they did not behave correctly.

### Minimal reproduction project

[FirstTest.zip](https://github.com/godotengine/godot/files/13517445/FirstTest.zip)
Repository: go
Issue: os: TestPipeIOCloseRace timeout on Windows blocked in `syscall.CancelIoEx`
Labels: OS-Windows,NeedsInvestigation

```
#!watchflakes
post <- goos == "windows" && pkg == "os" && ((log ~ `panic: test timed out` && log ~ `^\s*syscall\.CancelIoEx`) || status == "ABORT" )
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/4870f5963675cb60dc69f3e0e7526be02431da60)):

    panic: test timed out after 3m0s
    running tests:
    	TestPipeIOCloseRace (2m59s)
    
    goroutine 879 gp=0x4000174340 m=10 mp=0x4000180708 [running]:
    panic({0x7ff7b437a3a0?, 0x4000400040?})
    	C:/workdir/go/src/runtime/panic.go:779 +0x140 fp=0x400017bf00 sp=0x400017be50 pc=0x7ff7b4229d10
    testing.(*M).startAlarm.func1()
    	C:/workdir/go/src/testing/testing.go:2366 +0x30c fp=0x400017bfd0 sp=0x400017bf00 pc=0x7ff7b42f001c
    runtime.goexit({})
    ...
    
    goroutine 273 gp=0x4000443860 m=nil [GC worker (idle), 2 minutes]:
    runtime.gopark(0x8501acdde81b4?, 0x0?, 0x0?, 0x0?, 0x0?)
    	C:/workdir/go/src/runtime/proc.go:402 +0xc8 fp=0x400034bf30 sp=0x400034bf10 pc=0x7ff7b422d398
    runtime.gcBgMarkWorker()
    	C:/workdir/go/src/runtime/mgc.go:1310 +0xd8 fp=0x400034bfd0 sp=0x400034bf30 pc=0x7ff7b420c1c8
    runtime.goexit({})
    	C:/workdir/go/src/runtime/asm_arm64.s:1222 +0x4 fp=0x400034bfd0 sp=0x400034bfd0 pc=0x7ff7b4263734
    created by runtime.gcBgMarkStartWorkers in goroutine 308
    	C:/workdir/go/src/runtime/mgc.go:1234 +0x28


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: next.js
Issue: Non-public environment variables from env.*.local files in standalone build with Docker are undefined.
Labels: bug,Output (export/standalone)

### Link to the code that reproduces this issue

https://github.com/aamikus/reproducible-example

### To Reproduce

1. Build the example using `docker build -t nextjs-docker .`
2. Run the container with `docker run -p 3000:3000 nextjs-docker`
3. Navigate to http://localhost:3000/ and look at the console. Non-pubic variables from in env.*.local files are undefined

### Current vs. Expected behavior

After following the above steps, I expected the server-only environment variables defined in the env.*.local files to be correctly loaded and utilized within the Docker build process. However, it seems that these variables are not being loaded, while variables prefixed with NEXT_PUBLIC_ are functioning as expected.

### 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 23.1.0: Mon Oct  9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000
Binaries:
  Node: 18.17.1
  npm: 9.6.7
  Yarn: 1.22.21
  pnpm: N/A
Relevant Packages:
  next: 14.0.4-canary.28
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: standalone
```


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

Standalone mode (output: "standalone")

### Additional context

_No response_
Repository: PowerToys
Issue: FancyZones Zones automatically activated when dragging a window
Labels: Issue-Bug,Product-FancyZones,Priority-2

### Microsoft PowerToys version

0.75.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

Whenever a window is dragged, zones are automatically activated. My Zones settings: 
![image](https://github.com/microsoft/PowerToys/assets/38897937/5bb91687-264e-40e4-902e-7ddf52c4fdd3)
[log_2023-11-30.txt](https://github.com/microsoft/PowerToys/files/13517774/log_2023-11-30.txt)



### ✔️ Expected Behavior

When dragging a window, zones should be unactivated unless one of the activation keys (in my case, non-primary mouse button and middle mouse button) are pressed. The documentation mentions 

![image](https://github.com/microsoft/PowerToys/assets/38897937/824c8959-a9c2-4a33-8e7d-9fefb35751f4)
however, it seems like having "Use non-primary mouse button to toggle zone activation" toggled on **does not** matter, zones will auto-activate **unless** "Hold Shift key to activate zones while dragging" is toggled on.

### ❌ Actual Behavior

Zones are auto-activated. Pressing non-primary mouse will then disable activation. Middle mouse works as intended.

### Other Software

_No response_
Repository: next.js
Issue: Unable to use postcss-modules-values
Labels: bug

### Link to the code that reproduces this issue

https://github.com/bglaz2/postcss-values-bug

### To Reproduce

Start the application in development mode (pnpm dev).
Observe the error:
```
./app/styles.module.css
TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))
```
```
TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))
Import trace for requested module:
./app/styles.module.css.webpack[javascript/auto]!=!./node_modules/.pnpm/next@14.0.4-canary.28_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/build/webpack/loaders/css-loader/src/index.js??ruleSet[1].rules[12].oneOf[7].use[2]!./node_modules/.pnpm/next@14.0.4-canary.28_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/build/webpack/loaders/postcss-loader/src/index.js??ruleSet[1].rules[12].oneOf[7].use[3]!./app/styles.module.css
./app/styles.module.css
 ⨯ ./app/styles.module.css.webpack[javascript/auto]!=!./node_modules/.pnpm/next@14.0.4-canary.28_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/build/webpack/loaders/css-loader/src/index.js??ruleSet[1].rules[12].oneOf[7].use[2]!./node_modules/.pnpm/next@14.0.4-canary.28_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/build/webpack/loaders/postcss-loader/src/index.js??ruleSet[1].rules[12].oneOf[7].use[3]!./app/styles.module.css
TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))
Import trace for requested module:
./app/styles.module.css.webpack[javascript/auto]!=!./node_modules/.pnpm/next@14.0.4-canary.28_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/build/webpack/loaders/css-loader/src/index.js??ruleSet[1].rules[12].oneOf[7].use[2]!./node_modules/.pnpm/next@14.0.4-canary.28_biqbaboplfbrettd7655fr4n2y/node_modules/next/dist/build/webpack/loaders/postcss-loader/src/index.js??ruleSet[1].rules[12].oneOf[7].use[3]!./app/styles.module.css
./app/styles.module.css
```

### Current vs. Expected behavior

App should be able to build and use the @value syntax

### 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: x64
  Version: Darwin Kernel Version 22.6.0: Wed Oct  4 21:25:26 PDT 2023; root:xnu-8796.141.3.701.17~4/RELEASE_X86_64
Binaries:
  Node: 18.17.0
  npm: 9.6.7
  Yarn: 1.22.19
  pnpm: 7.33.5
Relevant Packages:
  next: 14.0.3
  eslint-config-next: N/A
  react: N/A
  react-dom: N/A
  typescript: N/A
Next.js Config:
  output: N/A
```


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

Not sure

### Additional context

It appears that the postcss-modules-values plugin should be configured by default, since you receive a warning when trying to add it to a custom postcss.config file (https://nextjs.org/docs/messages/postcss-ignored-plugin). However, following the repro steps, the app doesn't want to compile.
Repository: flutter
Issue: [Impeller] Set a cap for the maximum polygon count for tessellating a circle
Labels: engine,P3,e: impeller,team-engine,triaged-engine

Right now the circle tessellator will generate a polygonal approximation that stays within .1 pixels (settable with a source constant) of the true circle. But, after a certain diameter the polygon vertices change the direction by a very small angle and so there will no longer be a visible polygon corner. That suggests that we should avoid tessellating more than a certain upper limit of polygon edges.

Note that at 1024 pixels, the number of edges per quadrant is only 57 so the number of sides grows much slower than the radius.

On the flip side, even if the angle at each vertex is no longer noticeable a user zoomed in on one of the flat edges of an extreme circle might notice that it falls more than a few pixels short of where it should be covering.

What's the best practice here?
- Leave it and be aware that we might consume a lot more memory with extreme radii
- Put a cap on it and live with the missing pixels on huge radii, but at least there may be no noticeable polygon corner
- Implement clipping during the triangle strip generation so that while we may determine a large number of sides are needed, we don't actually generate all of the triangles for the full circle, just enough to cover the clip coverage.
Repository: flutter
Issue: Need option for flutter-gold check to run despite failing/running shards
Labels: team-infra,P2,triaged-infra

According to https://github.com/flutter/flutter/wiki/Writing-a-golden-file-test-for-package:flutter#flutter-gold-check (and in practice), the `flutter-gold` check will not proceed until all shards report success. In a perfect world where nothing is flaky and fast, this is fine. In the real world where shards can be slow and/or flaky this makes it difficult to iterate on changes that only affect one part of the system. For example, a change in the web engine has no effect on iOS, but a slow/flaky iOS shard will hold up goldens for web. And vice versa.

This is a request to have a way to not wait for all shards to finish before performing the golden check. I have no particular preference for how it should be done, but I can imagine a few ways:

- Add a Github label, e.g. `force_golden_check`, that can be added manually to initiate the golden check on a PR irrespective of the current status of CI checks.
- Make the build platform aware (sort of like the [runIf](https://github.com/flutter/engine/blob/56fa63cb9f5c3f48fe5baa2b6d9b89e701b42777/.ci.yaml#L95)). When a web-only change is make, `flutter-gold` will start comparing web goldens as soon as all web shards are done, and vice versa.
- Add an option to a config file (e.g. `.ci.yaml`) where one can specify when to run golden checks.
Repository: godot
Issue: GLTF import crash with "Embed as Basis Universal" and missing texture
Labels: bug,topic:import,crash

### Godot version

4.2-stable

### System information

Windows 11, gl_compatibility, NVidia RTX 3070 TI

### Issue description

Setting GLTF "Embedded Image Handling" to "Embed as Basis Universal" with a missing image results in a null-dereference crash.

### Steps to reproduce

Add the basemodule_C.bin and basemodule_c.gltf files (in the attached zip) [basemodule_C.zip](https://github.com/godotengine/godot/files/13518501/basemodule_C.zip) (originally from https://godotengine.org/asset-library/asset/2124)

The gltf is expecting a "spacebits_texture.png" but we omit it as we're planning on eventually supplying an external exture-atlas material.

Click on the gltf file, set the "Embedded Image Handling" to "Embed as Basis Universal" and click on [Reimport].

The crash occurs in GLTFDocument::_get_texture with the following call stack:
```
godot.windows.editor.dev.x86_64.exe!GLTFDocument::_get_texture(Ref<GLTFState> p_state, const int p_texture, int p_texture_types) Line 3500	C++
godot.windows.editor.dev.x86_64.exe!GLTFDocument::_parse_materials(Ref<GLTFState> p_state) Line 3997	C++
godot.windows.editor.dev.x86_64.exe!GLTFDocument::_parse_gltf_state(Ref<GLTFState> p_state, const String & p_search_path) Line 7600	C++
godot.windows.editor.dev.x86_64.exe!GLTFDocument::_parse(Ref<GLTFState> p_state, String p_path, Ref<FileAccess> p_file) Line 7151	C++
godot.windows.editor.dev.x86_64.exe!GLTFDocument::append_from_file(String p_path, Ref<GLTFState> p_state, unsigned int p_flags, String p_base_path) Line 7656	C++
godot.windows.editor.dev.x86_64.exe!EditorSceneFormatImporterGLTF::import_scene(const String & p_path, unsigned int p_flags, const HashMap<StringName,Variant,HashMapHasherDefault,HashMapComparatorDefault<StringName>,DefaultTypedAllocator<HashMapElement<StringName,Variant>>> & p_options, List<String,DefaultAllocator> * r_missing_deps, Error * r_err) Line 62	C++
```

Specifically on line 3500:
```c++
		portable_texture->set_keep_compressed_buffer(true);
		Ref<Image> new_img = p_state->source_images[image]->duplicate();
		ERR_FAIL_COND_V(new_img.is_null(), Ref<Texture2D>());
```

It's trying to duplicate source_images[0], however this is value is null.

The reason source_images[0] is null is from gltf_document.cpp line 3379:
```c++
					WARN_PRINT(vformat("glTF: Image index '%d' couldn't be loaded as a buffer of MIME type '%s' from URI: %s because there was no data to load. Skipping it.", i, mime_type, uri));
					p_state->images.push_back(Ref<Texture2D>()); // Placeholder to keep count.
					p_state->source_images.push_back(Ref<Image>());
					continue;
```

### Minimal reproduction project

N/A - instructions included in reproduction steps.