sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Document intended semantics behavior on each Flutter widget - whether standalone or building block
Labels: a: text input,framework,d: api docs,P2,team-framework,triaged-framework

### 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)

### Steps to reproduce

**Context:** I ran into `TextField` merging its semantics into the parent, resulting into an incorrect semantics tree. This has already been filed as an issues at: https://github.com/flutter/flutter/issues/26336.

**Issue:** One of the challenges I run into with Flutter component documentation is that it's not clear for each widget whether it is intended to be
- **standalone** (and provides `Semantics(container: true)`) or
- a **building block** (provides `Semantics`, but without `container: true`, intending to be merged with its parent)

This has to be determined by trial and error or digging to various abstractions in the code. Sometimes it's clear from the examples given, but this is confusing for cases like `IconButton` whose behavior depends on whether `theme.useMaterial3` is enabled:
* `theme.useMaterial3=true`: [emits `container: true` via another widget](https://github.com/flutter/flutter/blob/353b8bc87d297295069ae1b47885920f07d16e9e/packages/flutter/lib/src/material/icon_button.dart#L712-L719)
* `theme.useMaterial3=false`: [doesn't emit `container: true`](https://github.com/flutter/flutter/blob/353b8bc87d297295069ae1b47885920f07d16e9e/packages/flutter/lib/src/material/icon_button.dart#L772-L775) (possibly a bug)

This means that if the app uses `theme.useMaterial3=true`, but tests have that set as false (using the default theme), then tests don't test the correct semantics behavior - I realized this pitfall by running into it last week.

One worrisome thing is that when these are set unintentionally one way or another, I'm not sure how easily they can be fixed after the fact without potential accessibility breakage (which is not visually obvious): e.g., if users use `TextField` or `IconButton` as building-blocks, but if the flutter team intend them to be standalone widgets, then fixing the bug so that they become stand-alone might break existing semantics.

### Request

Ideally, the distinction between **standalone** or **building block** would be stated up front in each Flutter widget's description.
Repository: neovim
Issue: Cmake version tracking issue
Labels: build

A tracking issue of pros and cons of upgrading the minimum cmake version
(currently 3.16).

See also: https://cmake.org/cmake/help/latest/release/index.html

Note: "Drops support" sounds worse than it actually is; it only means that
neovim can't be built with the cmake that is provided by the package manager by
default. It's still very easy to build and download any cmake version (either
manually or with something like PPA/backports).

---

## 3.17
- Didn't find anything useful
#### Drops support for
- Ubuntu 20.04

## 3.18
- CheckLinkerFlag module
- `REQUIRED` option for all "find_" commands.
#### Drops support for
- Fedora 32

## 3.19
- `string` gained `JSON` subcommands
    - Allows us to specify dependencies in JSON instead of our bespoke format in `cmake.deps/deps.txt`
- cmake presets are introduced
- `find_package` gets support for version ranges, aka it allows setting a maximum required version as well as minimum required version. This could be useful for more change-prone dependencies such as wasmtime.
#### Drops support for
- Debian 11
- Fedora 33

## 3.20
- Extended path manipulation with `cmake_path`.
- `target_sources()` now supports targets created by `add_custom_target()`.
- `EXPORT_COMPILE_COMMANDS` target property, allows us to remove little bit of
  code.
- `CPACK_THREADS` packaging goes brrrr.
- `presets` gained support for build and test presets.
#### Drops support for

## 3.21
- Extended support for presets
- `--install-prefix` flag to specify install location
- `PROJECT_IS_TOP_LEVEL` variable to check if neovim is used as a dependency by
  another cmake project.
#### Drops support for

## 3.22
- Nothing useful
#### Drops support for

## 3.23
- File sets which is an exciting new feature that does...something. I'll need
  to check on what later in more detail.
#### Drops support for
- Ubuntu 22.04
- Fedora 36

## 3.24
- `--fresh` flag to remove old builds.
- Platform independent `CMAKE_COMPILE_WARNING_AS_ERROR`
- `CMAKE_COLOR_DIAGNOSTICS` variable to adjust color output.
#### Drops support for

## 3.25
- Workflow presets
#### Drops support for
- Fedora 37

## 3.26
- `CMAKE_<LANG>_CLANG_TIDY_EXPORT_FIXES_DIR` could be useful. Probably not, but maybe.
#### Drops support for
- Debian 12 (bookworm)
- Ubuntu 23.04

## 3.27
- "Apple text-based stubs (i.e. .tbd files) may now be created for shared
  libraries on macOS". Unsure if this is relevant for us, but writing it here
  for now so we can check on it later.
#### Drops support for
- Fedora 38

## 3.28
- Nothing useful
#### Drops support for
- Fedora 39

## 3.29
- Nothing useful
#### Drops support for
- Ubuntu 24.04
- Fedora 40

## 3.30
- Nothing useful
#### Drops support for
Repository: godot
Issue: "connect: Caller thread can't call this function" when a co-routine uses await internally
Labels: bug,topic:core,topic:gdscript

### Godot version

Godot v4.1.beta (2d6b88098)

### System information

Arch Linux - Vulkan (Forward+)

### Issue description

I have an async function, using the keyword await, like so:

```gdscript
# PhysicsHelper

func execute(tasks) -> Array:
	# [...] Run the tasks

	await job_completed # Emited from _physics_process()

	return _results
```

And I have another script, that requires the result of this function, **but from a thread**:

```gdscript

func _run_threaded() -> void:
	var results = await physics_helper.execute( random_work )
        print(results)
```

This triggers an error in the debugger:
```
E 0:00:00:0496   connect: Caller thread can't call this function in this node (/root/minimal_scene/PhysicsHelper). Use call_deferred() or call_thread_group() instead.
  <C++ Error>    Condition "!is_accessible_from_caller_thread()" is true. Returning: (ERR_INVALID_PARAMETER)
  <C++ Source>   scene/main/node.cpp:3605 @ connect()
```

When removing `await job_completed` from the first script, the error does not occur.

I suspect this comes from the recent thread safety PRs: the async keyword uses the signal.connect() function internally, which is no longer allowed from a thread without using call_deferred.

Is this a regression, am I using it wrong, or is it by design?


### Steps to reproduce

+ Create a Node with a function using the `await` keyword
+ Add the Node to the scene tree
+ Call this function from a thread

### Minimal reproduction project

Minimal reproduction project: [threaded_await_minimal_project.zip](https://github.com/godotengine/godot/files/11725975/threaded_await_minimal_project.zip)

+ Open the project.
+ Open the `minimal_scene.tscn` and run the project.
+ Check the debugger, you will see the error message there.

Additional information:

+ This project generates random PhysicsRayQueries and sends them to a PhysicsHelper class. This class runs the queries during the _physics_process before saving the results.

+ In the current state, you can see the await keyword (from the `execute` function in physics_helper.gd) is completely ignored. The threaded function returns immediately after calling `execute`. 
+ The expected behavior is that it should wait for the signal `job_completed` before trying to print the results.
Repository: rust
Issue: Suggestion from `error[E0034]: multiple applicable items in scope` don't always apply
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub mod the_module {
    pub trait A {
        fn xx(&self, _: u32) {}
    }
    pub trait B : A {
        fn xx(&self, _: u64) {}
    }
}

pub mod another_module {
    pub fn hallo(foo: std::rc::Rc<&dyn crate::the_module::B>) {
        foo.xx(0u32);
    }
}
```


### Current output

```Shell
error[E0034]: multiple applicable items in scope
  --> src/lib.rs:13:13
   |
13 |         foo.xx(0u32);
   |             ^^ multiple `xx` found
   |
note: candidate #1 is defined in the trait `A`
  --> src/lib.rs:4:9
   |
4  |         fn xx(&self, _: u32) {}
   |         ^^^^^^^^^^^^^^^^^^^^
note: candidate #2 is defined in the trait `B`
  --> src/lib.rs:7:9
   |
7  |         fn xx(&self, _: u64) {}
   |         ^^^^^^^^^^^^^^^^^^^^
help: disambiguate the method for candidate #1
   |
13 |         A::xx(foo, 0u32);
   |         ~~~~~~~~~~~~~~~~
help: disambiguate the method for candidate #2
   |
13 |         B::xx(foo, 0u32);
   |         ~~~~~~~~~~~~~~~~
```


### Desired output

```Shell
[...]
help: disambiguate the method for candidate #1
   |
13 |         crate::the_module::A::xx(&foo, 0u32);
   |         ~~~~~~~~~~~~~~~~
help: disambiguate the method for candidate #2
   |
13 |         crate::the_module::B::xx(&foo, 0u32);
   |         ~~~~~~~~~~~~~~~~
```


### Rationale and extra context

The suggestion to disambiguate don't apply cleanly because

 1. The module path is not correct  (maybe related to #100683 ?)
 2. it is missing a dereference (`&`) before the foo.

### Other cases


Note that if we change the code to use `&dyn` instead of `Rc`:

```Rust
    pub fn hallo(foo: &dyn crate::the_module::B) {
        foo.xx(0u32);
    }
```


The suggestion becomes 
```
help: disambiguate the method for candidate #1
   |
13 |         A::xx(&foo, 0u32);
   |         ~~~~~~~~~~~~~~~~~
```

Now the suggestion adds a `&` while it shouldn't. That's the reversed problem.
Repository: flutter
Issue: [integration_test] UIApplication `windows` is deprecated
Labels: platform-ios,framework,f: integration_test,P2,c: tech-debt,team-ios,triaged-ios

IntegrationTestPlugin.m is using `UIApplication.sharedApplication.windows` for screenshotting, but `windows` is deprecated in iOS 15. While it's not an immediate concern, it would be good to add an iOS 15+ codepath with an availability check.
Repository: flutter
Issue: [file_selector] `initWithDocumentTypes:inMode:` is deprecated
Labels: platform-ios,package,P2,c: tech-debt,p: file_selector,team-ios,triaged-ios

The `UIDocumentPickerViewController` initializer that we are using is deprecated in iOS 14; we should add an availability-gated codepath for iOS 14+ that uses the replacement. It's not immediately clear to me from the docs which of the new initializers is the one we want so that will need a bit of investigation.
Repository: go
Issue: cmd/go/internal/modload: clean up checksum-saving logic
Labels: NeedsFix,GoCommand,modules

In [CL 502015](https://go.dev/cl/502015), I noticed a longstanding problem with the way `cmd/go` determines which checksums need to be saved in the `go.sum` file. Namely, the `keepSums` helper function assumes that a module's checksum is needed if:
1. the module's checksum was consulted in the course of executing the command, and
2. the module is the selected version of its path in the module graph.

That may have been true originally, but it's a very fragile assumption especially given [module graph pruning](https://go.dev/ref/mod#graph-pruning) and [lazy module loading](https://go.dev/ref/mod#lazy-loading). In particular, commands like `go get` and `go list -u -m all` may download module contents or `go.mod` files in order to compute their output, even when those inputs are not otherwise relevant and do not result in any persistent changes to the module's requirements.

For now, we allow those extra checksums to be recorded and rely on `go mod tidy` to clean them up again later, but it would be better still not to record the irrelevant checksums in the first place. To do that, we probably need to make `go get` and `go mod download` more explicit about which modules they want to save, and make everything else less aggressive about saving checksums for modules in the build list.

See previously:
- #60001
- #60667
Repository: go
Issue: x/tools/go/analysis/passes: opt: skip each ast.File that doesn't import the package of interest
Labels: NeedsDecision,Tools,Analysis,gopls/performance,gopls/analysis

Many go/analysis checkers start by inspecting the import map of the package, and making an early return if a specific package of interest is not found, for example:
```
	if !analysisutil.Imports(pass.Pkg, "sync/atomic") {
		return nil, nil // doesn't directly import sync/atomic
	}
```

This check is a substantial optimization. Indeed, in recent experiments we discovered that all the traversals done by static checkers can be quite significant relative to type checking---so much so that gopls' separation of analyzer sets into "all" (for root packages) and "fact-only" (for dependencies) is well worth doing.

We could take it a step further by skipping individual files if they don't import the package of interest. That's easy when the traversal uses ast.Inspect, but harder if it uses the Inspector, since the latter searches all files of the package.

The task of this issue is to try to find a convenient way to skip traversal of files that lack the necessary import, and measure the benefit.
Repository: vscode
Issue: Shell integration run recent command shows an error when run in a remote
Labels: bug,remote,terminal-shell-integration

Repro:

1. Run `code tunnel`
2. Connect to it via desktop
3. Open terminal
4. Hit ctrl+alt+r

![image](https://github.com/microsoft/vscode/assets/2193314/e3e98c05-6bf4-4ca0-af2f-0764908900f7)
Repository: pytorch
Issue: Deprecation warning on lr_scheduler.step(num_steps)
Labels: module: optimizer,triaged,actionable

### 🐛 Describe the bug

`step(num_steps)` produces a deprecation warning currently. However, there is a legitimate use case for this API in learning rate schedulers — if reloading a trained model and continuing to train, it is necessary to advance the number of steps inside the scheduler to match the current model state.

The scheduler does not provide an alternative way to advance the number of steps. And it is not possible to use `state_dict()`  + `load_state_dict()` because they also prevent changing the learning rate and other hyperparameters during transitions, unless the user manually changes the state dict, which is a hacky.

```
UserWarning: The epoch parameter in `scheduler.step()` was not necessary and is being deprecated where possible. Please use `scheduler.step()` to step the scheduler. During the deprecation, if epoch is different from None, the closed form is used instead of the new chainable form, where available. Please open an issue if you are unable to replicate your use case: https://github.com/pytorch/pytorch/issues/new/choose.
```

### Versions

Versions of relevant libraries:
[pip3] torch==2.0.1


cc @vincentqb @jbschlosser @albanD @janeyx99
Repository: pytorch
Issue: Asynchronous CUDA AveragedModel
Labels: module: optimizer,triaged,needs research

### 🚀 The feature, motivation and pitch

This is a proposal to improve the efficiency of CUDA `AveragedModel` used in EMA and SWA. (Follow-up of https://github.com/pytorch/pytorch/pull/94820). I would provide the implementation but would like feedback/approval before opening a PR.

Currently the EMA/SWA weight update is done on the default stream, same as all the other GPU work.

Because EMA/SWA weights are typically updated at the end of a training iteration (after an optimizer step), and are not needed until the end of the next iteration, we can actually run the EMA/SWA update in parallel of the forward/backward/optimizer step, virtually eliminating the overhead of EMA/SWA in many cases.

This can be done by using a separate dedicated CUDA stream to perform the weight update.

This is how it is done in the NeMo framework:
- Stream creation: https://github.com/NVIDIA/NeMo/blob/a87702a522387da0aac62dc1f90a88a8e0bfc7cc/nemo/collections/common/callbacks/ema.py#L234
- Synchronization between the dedicated stream and the main stream: https://github.com/NVIDIA/NeMo/blob/a87702a522387da0aac62dc1f90a88a8e0bfc7cc/nemo/collections/common/callbacks/ema.py#L259
- Weight update in the dedicated stream: https://github.com/NVIDIA/NeMo/blob/a87702a522387da0aac62dc1f90a88a8e0bfc7cc/nemo/collections/common/callbacks/ema.py#L261
- API to manually synchronize the dedicated stream: https://github.com/NVIDIA/NeMo/blob/a87702a522387da0aac62dc1f90a88a8e0bfc7cc/nemo/collections/common/callbacks/ema.py#L310

If the team is interested in extending the current `AveragedModel` class with an optional asynchronous feature, let me know and I'll work on a PR.

### Alternatives

_No response_

### Additional context

_No response_

cc @vincentqb @jbschlosser @albanD @janeyx99 @crcrpar
Repository: godot
Issue: `change_scene_to_file()` does not work correctly in terms of VRAM
Labels: bug,topic:core,topic:rendering

### Godot version

4.1 beta1

### System information

Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 (NVIDIA; 30.0.15.1403) - Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 Threads)

### Issue description

The description of `change_scene_to_file()` says:
> This ensures that both scenes are never loaded at the same time, which can exhaust system resources if the scenes are too large or if running in a memory constrained environment.

That's not really true. When you have 2 scenes with heavy textures, there's a visible VRAM spike when they are both loaded:
![image](https://github.com/godotengine/godot/assets/2223172/111cb25d-1fad-47e8-8a9c-3895b2589d83)

It kind of makes sense when looking at the implementation, but the same does not happen with RAM. When you have 2 heavy scenes (no textures), there is no spike. It's even more surprising that you can do:
```
var scene2 := load("res://HugeSceneRAM2.scn")
get_tree().change_scene_to_packed(scene2)
```
and there is still no RAM spike. There is some optimization behind the scenes here (if you use timer between load and change, the spike is visible).

### Steps to reproduce

1. Load a heavy scene
2. Change to another heavy scene
3. Notice a VRAM jump while the scenes are switched

### Minimal reproduction project

I prepared a project with both RAM and VRAM scenario:
[HeavyScenes.zip](https://github.com/godotengine/godot/files/11728265/HeavyScenes.zip)

For the record, I tried fixing this by making the scene change more deferred, but it just results in empty frame. The VRAM spike disappears only when you defer the scene change with a timer. Here's my attempt:
[0001-Fix-_change_scene_to_file.patch](https://github.com/godotengine/godot/files/11728278/0001-Fix-_change_scene_to_file.patch)
Repository: flutter
Issue: flutter/engine contains some deprecated SharedApplication status bar related APIs
Labels: platform-ios,engine,P3,c: tech-debt,team-ios,triaged-ios

**To reproduce the deprecation warning**

1. Go to local build root folder, typically located one level up of the engine directory. Then change the `ios_deployment_target` to 17.0: https://github.com/flutter/buildroot/blob/master/build/config/ios/ios_sdk.gni#L19 
1. Add -Wdeprecated-declarations and -Wdeprecated-implementations in flutter_clags_objc https://github.com/flutter/engine/blob/main/common/config.gni#L60 
1. Build the local engine like you normally would.


**List of deprecated APIs**

'statusBarHidden' is deprecated: first deprecated in iOS 13.0 - Use the statusBarManager property of the window scene instead. [-Werror,-Wdeprecated-declarations]

'setStatusBarStyle:' is deprecated: first deprecated in iOS 9.0 - Use -[UIViewController preferredStatusBarStyle] [-Werror,-Wdeprecated-declarations]
    [[UIApplication sharedApplication] setStatusBarStyle:statusBarStyle];

'statusBarOrientation' is deprecated: first deprecated in iOS 13.0 - Use the interfaceOrientation property of the window scene instead. [-Werror,-Wdeprecated-declarations]

Flutter does not support iOS 9 anymore so we should be able to remove `setStatusBarStyle` completely.
Repository: flutter
Issue: flutter/engine contains Deprecated KeyWindow API
Labels: platform-ios,engine,P3,c: tech-debt,team-ios,triaged-ios

**To reproduce the deprecation warning**

1. Go to local build root folder, typically located one level up of the engine directory. Then change the `ios_deployment_target` to 17.0: https://github.com/flutter/buildroot/blob/master/build/config/ios/ios_sdk.gni#L19 
1. Add -Wdeprecated-declarations and -Wdeprecated-implementations in flutter_clags_objc https://github.com/flutter/engine/blob/main/common/config.gni#L60 
1. Build the local engine like you normally would.


**List of deprecated APIs**

'keyWindow' is deprecated: first deprecated in iOS 13.0 - Should not be used for applications that support multiple scenes as it returns a key window across all connected scenes [-Werror,-Wdeprecated-declarations]
Repository: go
Issue: proposal: os/signal: Provide a new error type to communicate the signal triggered context cancellation
Labels: Proposal

<!--
Our proposal process is documented here:
https://go.dev/s/proposal-process
-->

This comes from the need to fix #60733.

In order to provide the information of which signal triggered context cancellation in `signal.NotifyContext` using `context.Cause`, we need a new error type (as that's the only type allowed by context cause) to communicate that info back to the user.

The proposal is to define it as a simple struct that can only be used by pointer as an error:

```go
// CanceledBySignalError represents the error can be retrieved via context.Cause
// on the context returned by NotifyContext to inspect which signal caused the
// cancellation.
type CanceledBySignalError struct {
	// The signal caused the context cancellation.
	Signal os.Signal
}

func (cse *CanceledBySignalError) Error() string {
	return fmt.Sprintf("context canceled by signal %v", cse.Signal)
}
```

So users can inspect the signal via code like:

```go
select {
case <-ctx.Done():
  cause := context.Cause(ctx)
  var cse *signal.CanceledBySignalError
  if errors.As(cause, &cse) {
    sig := cse.Signal
    // Do something with sig
  }
}
```
Repository: flutter
Issue: flutter/engine uses deprecated UIText APIs
Labels: platform-ios,engine,P3,c: tech-debt,team-ios,triaged-ios

**To reproduce the deprecation warnings**

1. Go to local build root folder, typically located one level up of the engine directory. Then change the `ios_deployment_target` to 17.0: https://github.com/flutter/buildroot/blob/master/build/config/ios/ios_sdk.gni#L19 
1. Add -Wdeprecated-declarations and -Wdeprecated-implementations in flutter_clags_objc https://github.com/flutter/engine/blob/main/common/config.gni#L60 
1. Build the local engine like you normally would.


**List of deprecated APIs**

'UITextWritingDirection' is deprecated: first deprecated in iOS 13.0 [-Werror,-Wdeprecated-declarations]
(NSWritingDirection)

'UITextWritingDirectionNatural' is deprecated: first deprecated in iOS 13.0 [-Werror,-Wdeprecated-declarations]
(NSWritingDirectionNatural)

'UI_USER_INTERFACE_IDIOM' is deprecated: first deprecated in iOS 13.0 - Use -[UIDevice userInterfaceIdiom] directly. [-Werror,-Wdeprecated-declarations]
Repository: flutter
Issue: In flutter/engine  'attemptRotationToDeviceOrientation' is deprecated in iOS 16
Labels: platform-ios,engine,P3,c: tech-debt,team-ios,triaged-ios

 'attemptRotationToDeviceOrientation' is deprecated: first deprecated in iOS 16.0 - Please use instance method `setNeedsUpdateOfSupportedInterfaceOrientations`. [-Werror,-Wdeprecated-declarations]

We should call the new method in iOS 16 above and keep the usage of the old method for lower versions.
The old method usage should be removed after Flutter's min iOS version is iOS 16.