sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Expose Layer#_needsAddToScene to subclass
Labels: c: new feature,framework,c: proposal,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)

### Use case

When overloading a `ContainerLayer`, I want my subclass of `ContainerLayer` to be aware of when it will be `addToScene`, so my layer would be able to invalidate some cached values in `updateSubtreeNeedsAddToScene`.
The cached values are computed from its child layers' status.
Specificaly, I'm writing a subclass of `OffsetLayer` which computes its offset from its children (more specificaly, from its child layer's corresponding `RenderObject`s), implementing an effect similar to the `FollowerLayer`/`LeaderLayer` in Flutter repo, while  allowing the FollowerLayer to be an ancestor of the LeaderLayer. Sprisingly, there appears no way for a layer to know its dirty status.
Is this kind of practice not supported?

### Proposal

Add a getter for `_needsAddToScene` in `Layer`.
Repository: rust
Issue: [rustdoc] When using `-Zbuild-std`, documentation does not link to `core`/`std` and does not attempt to build docs for them
Labels: T-rustdoc,C-bug,requires-nightly,A-rustdoc-ui,-Zbuild-std

I tried this code:

```rust
/// [`usize`]
///
/// [`usize`][core::usize]
pub struct Foo;
```
Built with `cargo +nightly doc --target x86_64-unknown-linux-gnu -Zbuild-std`

I expected to see this happen: Rustdoc links properly to traits and intra-doc links, as shown when built with `cargo +nightly doc --target x86_64-unknown-linux-gnu`
![image](https://github.com/rust-lang/rust/assets/12666617/9947362b-9663-402a-855f-0bd6a4fdb2b6)

Instead, this happened: When built with `-Zbuild-std`, rustdoc does not link to these traits or properly resolve intra-doc links, and does not attempt to rectify this by building docs for `core` or `std`:
![image](https://github.com/rust-lang/rust/assets/12666617/7d7be374-135a-4638-a834-e40752ef080e)


### Meta
This bug is not applicable to stable due to its use of `-Zbuild-std`

`rustc --version --verbose`:
```
rustc 1.75.0-nightly (fcab24817 2023-10-13)
binary: rustc
commit-hash: fcab24817c72ffbd6ffb66d92b7ddc0d3ee4d2f0
commit-date: 2023-10-13
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.2
```

@rustbot modify labels: +A-rustdoc-ui +-Z-build-std +requires-nightly
Repository: react-native
Issue: iOS border radius not working when using transparent border color
Labels: Platform: iOS,Issue: Author Provided Repro,Needs: Triage :mag:,Newer Patch Available

### Description

iOS border radius not working when using transparent border color

### React Native Version

0.72.5

### Output of `npx react-native info`

System:
  OS: macOS 13.0
  CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  Memory: 2.30 GB / 16.00 GB
  Shell:
    version: 5.8.1
    path: /bin/zsh
Binaries:
  Node:
    version: 16.15.1
    path: ~/.nvm/versions/node/v16.15.1/bin/node
  Yarn:
    version: 1.21.1
    path: /usr/local/bin/yarn
  npm:
    version: 8.11.0
    path: ~/.nvm/versions/node/v16.15.1/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.11.3
    path: /Users/erich/.rvm/gems/ruby-2.7.5/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 22.1
      - iOS 16.1
      - macOS 13.0
      - tvOS 16.1
      - watchOS 9.1
  Android SDK: Not Found
IDEs:
  Android Studio: 2022.2 AI-222.4459.24.2221.10121639
  Xcode:
    version: 14.1/14B47b
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.16.1
    path: /usr/local/opt/openjdk@11/bin/javac
  Ruby:
    version: 2.7.5
    path: /Users/erich/.rvm/rubies/ruby-2.7.5/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.5
    wanted: 0.72.5
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

### Steps to reproduce

1. Add a parent container with transparent border color, border radius and `overflow: hidden` set
```react
      <View
        style={{
          margin: 150,
          borderWidth: 4,
          borderColor: 'transparent',
          borderRadius: 16,
          overflow: 'hidden',
          height: 80,
          width: 60,
        }}>
        <View
          style={{
            width: '100%',
            height: '100%',
            backgroundColor: 'red',
          }}></View>
      </View>
```
2. On iOS, the child view is not clipped by the parent container.

### Snack, screenshot, or link to a repository

See snack: https://snack.expo.dev/@eh2077/4c412a?platform=ios

<img width="334" alt="Screenshot 2023-10-14 at 1 35 18 PM" src="https://github.com/facebook/react-native/assets/117511920/5fd367a5-418c-4691-b980-e1be2f66a1fd">
<img width="334" alt="Screenshot 2023-10-14 at 1 30 03 PM" src="https://github.com/facebook/react-native/assets/117511920/3f92b3d1-bb26-4557-a24b-c781aedfead3">
Repository: godot
Issue: Texture is distorted in Line2D when width_curve applied
Labels: enhancement,topic:rendering,confirmed,topic:2d

### Godot version

v4.1.2.stable.official [399c9dc39]

### System information

Windows 11 Home  Vulkan API 1.2.170 - Forward+ - Using Vulkan Device #0: Intel - Intel(R) UHD Graphics

### Issue description

Textures are distorted in a strange way when applied as a fill on a Line2D with a width_curve applied.

![image](https://github.com/godotengine/godot/assets/82291606/8312c771-9c5b-4a53-981f-ff6ed9ceaaf5)




### Steps to reproduce

1. Create a Line2D of any length with 2 points.
2. Create a linear width_curve for the Line2D.
3. Apply a texture fill.



### Minimal reproduction project

[line2D_texture_bug.zip](https://github.com/godotengine/godot/files/12902737/line2D_texture_bug.zip)
Repository: rust
Issue: Subtrait blanket implementation error inferring associated type bounds
Labels: A-type-system,A-trait-system,A-associated-items,T-compiler,C-bug,T-types,fixed-by-next-solver

This might be known behavior but I found the result rather unexpected and hard to track down. So if this is defined behavior and not a bug, at least this report might help someone figure that out.

It might be a weird pattern to define a blanket implementation of a supertrait for a subtrait, but it does seem to normally work. One benefit of doing so is that one does not need to cast when using types of the subtrait (see `W` below). However, if you do so with a certain setup of associated type bounds, you get into a pretty odd state.

I tried this code:

```rust
use std::ops::Mul;

pub trait M<P>: Mul<P, Output = Self> {}

pub trait J: M<Self::P> {
    type P;
}

trait S {
    type P;
    type V: M<Self::P>;
}

trait T: S { // only happens if T: S
    type J: J;
}

impl<I: J, U: T<J = I>> S for U { // requires I: J + M<<U as S>::P>
    type P = I::P;
    type V = I;
}

trait W<U: T> {
    fn j() -> U::P; // if T: S, otherwise <U as S>::P
}
```

I expected to this to compile. I can get it to do so by dropping the `T: S` (and casting in W appropriately), or by adding an additional bound to I in the impl, but it seems redundant and like it should be unnecessary.

Instead, the compiler fails to recognize that `I` must be `M<<U as S>::P>`. As the compiler is able to know this under other circumstances (namely without explicit `T: S`), this seems like a bug due to the circularity and errant behavior.

### Meta

This happens on both `+nightly` and `+stable`.

```
$ rustc +stable --version --verbose
rustc 1.72.1 (d5c2e9c34 2023-09-13)
binary: rustc
commit-hash: d5c2e9c342b358556da91d61ed4133f6f50fc0c3
commit-date: 2023-09-13
host: x86_64-apple-darwin
release: 1.72.1
LLVM version: 16.0.5

$ rustc +nightly --version --verbose
rustc 1.75.0-nightly (187b8131d 2023-10-03)
binary: rustc
commit-hash: 187b8131d4f760f856b214fce34534903276f2ef
commit-date: 2023-10-03
host: x86_64-apple-darwin
release: 1.75.0-nightly
LLVM version: 17.0.2
```

<details><summary>Backtrace</summary>
<p>

```
error[E0277]: the trait bound `I: M<<U as S>::P>` is not satisfied
  --> assoc-bounds.rs:20:14
   |
20 |     type V = I;
   |              ^ the trait `M<<U as S>::P>` is not implemented for `I`
   |
note: required by a bound in `S::V`
  --> assoc-bounds2.rs:11:13
   |
11 |     type V: M<Self::P>;
   |             ^^^^^^^^^^ required by this bound in `S::V`
help: consider further restricting this bound
   |
18 | impl<I: J + M<<U as S>::P>, U: T<J = I>> S for U { // requires I: J + M<<U as S>::P>
   |           ++++++++++++++++

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
```

</p>
</details>
Repository: PowerToys
Issue: FanzyZones (and other tools?): Disable Shortcut Keys
Labels: Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

If it doesn't exist already, please provide a way to completely disable the "Launch layout editor" shortcut key. Better yet, please provide a way to completely disable any and ALL keyboard shortcuts for ALL PowerToys. 

Thank you!!

### Scenario when this would be used?

Always. Disabling the shortcut key will prevent accidental activation of the FancyZones layout editor (or whatever feature a given shortcut key is for). Also, it will prevent conflicts with other desired usage of the same shortcut combination.

### Supporting information

_No response_
Repository: transformers
Issue: [Feature Request] We might need a function to change the sampler used in trainer dataloader
Labels: Feature request

### Feature request

we need a function to custom the sampler used in trainer dataloader.

### Motivation

for sometimes, we might want to use https://github.com/imoneoi/multipack_sampler/blob/master/multipack_sampler.py#L94 for efficient reasoning

another example is DoReMi paper， we might also change the  sample distribution  for different task source

### Your contribution

I
Repository: rust
Issue: Unhelpful error when defining a function pointer that returns a struct with lifetime bound 
Labels: A-diagnostics,T-compiler

### Code

```Rust
struct T {
    foo: fn(&T) -> T + 'a,
}
```
```


### Current output

```Shell
error[E0178]: expected a path on the left-hand side of `+`, not `fn(&T) -> T`
 --> src/lib.rs:2:10
  |
2 |     foo: fn(&T) -> T + 'a,
  |          ^^^^^^^^^^^^^^^^ perhaps you forgot parentheses?

For more information about this error, try `rustc --explain E0178`.
error: could not compile `playground` (lib) due to previous error
```


### Desired output

```Shell
error[E0782]: trait objects must include the `dyn` keyword
 --> src/lib.rs:2:21
  |
2 |     foo: fn(&T) -> T + 'a,
  |                    ^^^^^^
  |
help: add `dyn` keyword before this trait
  |
2 |     foo: fn(&T) -> (dyn T + 'a),
  |                     +++

Some errors have detailed explanations: E0261, E0404, E0782.
For more information about an error, try `rustc --explain E0261`.

OR 

error[EXXXX]: lifetime bounds are invalid in function pointer contexts
 --> src/lib.rs:2:10
  |
2 |     foo: fn(&T) -> T + 'a,
  |          ^^^^^^^^^^^^^^^^
  |
help: Function pointers are different than the Fn trait family
  |
2 |     foo: dyn Fn(&T) -> T + 'a,
  |          ~~~~~~

For more information about an error, try `rustc --explain EXXXX`.
error: could not compile `playground` (lib) due to 2 previous errors
```


### Rationale and extra context

This is a complicated issue... the user (read: me) was misguided to add a lifetime bounds to a function pointer with the intent that the returned object had a lifetime bounds, but that's clearly invalid. However, the correct/intended Rust isn't clear: The user could have intended to use a Fn trait object instead or could have meant to return a trait object.

Either way though, the original message is very confusing here.

### Other cases

_No response_

### Anything else?

Repros on Nightly 1.75.0 2023-10-13 fcab24817c72ffbd6ffb
Repository: godot
Issue:  `TextEdit.get_rect_at_line_column` looses precision due to returning `Rect2i`
Labels: enhancement,discussion,topic:gui

### Godot version

v4.1.2.stable.official [399c9dc39]

### System information

Fedora Linux 38

### Issue description

I was trying to display colored boxed over the script editor which mark certain code. To do so I used `TextEdit.get_rect_at_line_column` to get the dimensions. However my boxes appeared to be to short on some scroll levels inside the code edit. After some searching I found that this happens when `get_theme_font(&"font").get_char_size(32, __current_base_editor.get_theme_font_size(&"font_size")).x` isn't an integer. As it turns out `get_rect_at_line_column` returns a `Rect2i` and so in that cases it does not return the correct char width which is not necessarily an int.

### Steps to reproduce

- create a `TextEdit`
- print `get_theme_font(&"font").get_char_size(32, text_edit.get_theme_font_size(&"font_size")).x` (When not using a monospace font the char should be changed to the char at the requested position)
- print `get_rect_at_line_column().size.x`
- experiment with the font size until you see both numbers not matching up

OR

- open the MRP start it and look at the console

### Minimal reproduction project

[mrp_text_rect.zip](https://github.com/godotengine/godot/files/12903845/mrp_text_rect.zip)
Repository: godot
Issue: OpenGL: OmniLight3D PCF shadow filtering not implemented
Labels: bug,topic:rendering,confirmed,topic:3d

### Godot version

4.2 beta 1

### System information

Godot v4.2.beta (ee118e7ff) - Windows 10.0.22621 - GLES3 (Compatibility) - AMD Radeon RX 6600 (Advanced Micro Devices, Inc.; 31.0.21031.1005) - Intel(R) Core(TM) i3-10105F CPU @ 3.70GHz (8 Threads)

### Issue description

PCF soft shadow support doesn't exist for Omni lights, the Shadows remain Hard.
Spot Lights and Directional Lights Soft Shadows work fine.

### Steps to reproduce

Switch between Positional Soft Shadow Modes in GL renderer

### Minimal reproduction project

N/A
Repository: transformers
Issue: [i18n-zh] Translating docs to Chinese (Simplified)
Labels: WIP

<!--
Note: Please search to see if an issue already exists for the language you are trying to translate.
-->

Hi!

Let's bring the documentation to all the <languageName>-speaking community 🌐 (currently 0 out of 267 complete)

Who would want to translate? Please follow the 🤗 [TRANSLATING guide](https://github.com/huggingface/transformers/blob/main/docs/TRANSLATING.md). Here is a list of the files ready for translation. Let us know in this issue if you'd like to translate any, and we'll add your name to the list.

Some notes:

* Please translate using an informal tone (imagine you are talking with a friend about transformers 🤗).
* Please translate in a gender-neutral way.
* Add your translations to the folder called `<languageCode>` inside the [source folder](https://github.com/huggingface/transformers/tree/main/docs/source).
* Register your translation in `<languageCode>/_toctree.yml`; please follow the order of the [English version](https://github.com/huggingface/transformers/blob/main/docs/source/en/_toctree.yml).
* Once you're finished, open a pull request and tag this issue by including #issue-number in the description, where issue-number is the number of this issue. Please ping @stevhliu and @MKhalusova for review.
* 🙋 If you'd like others to help you with the translation, you can also post in the 🤗 [forums](https://discuss.huggingface.co/).

And I can see some part of the work has be done (Great work!). I just list all files below.

## Get Started section(keep updating)
Here is what I am working now, you can just skip these docs.
[perf_train_gpu_one.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_train_gpu_one.md)
[perf_train_gpu_many.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_train_gpu_many.md)
[perf_train_cpu.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_train_cpu.md)
[perf_train_cpu_many.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_train_cpu_many.md)
[perf_train_tpu.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_train_tpu.md)
[perf_train_tpu_tf.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_train_tpu_tf.md)
[perf_train_special.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_train_special.md)
[perf_infer_cpu.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/perf_infer_cpu.md)
[deepspeed.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/main_classes/deepspeed.md)
[trainer.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/main_classes/trainer.md) - #29728 

<!--
Keep on adding more as you go 🔥
-->

@stevhliu
Repository: godot
Issue: Setting a custom project setting to a resource file tres cause ConfigFile parse error when opening project manager
Labels: bug,topic:editor,needs testing

### Godot version

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

### System information

Godot v4.1.1.stable.mono - Windows 10.0.19044 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; 31.0.15.3742) - Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz (8 Threads)

### Issue description

Setting a custom project setting with resource type to a file will cause a parser error. The project will show up as a Missing Project and won't open. I wanted to use shortcut resource for my editor plugin and it works perfectly, except when setting it to a tres file. It's just a thing that some future users may try to do and it causes project manager error, but it's not important

It was tested with Shortcut and InputEventKey, but I'm going to guess it also affect all custom project settings with resource type. Mainly because Godot Console says
```
ERROR: Cannot open file 'res://test_res.tres'.
   at: (scene/resources/resource_format_text.cpp:1638)
ERROR: Failed loading resource: res://test_res.tres. Make sure resources have been imported by opening the project in the editor at least once.
   at: (core/io/resource_loader.cpp:273)
ERROR: ConfigFile parse error at C:/Projects/Godot/test_set_settings/project.godot:12: Can't load resource at path: 'res://test_res.tres'..
   at: _parse (core/io/config_file.cpp:304)
Project is missing: C:/Projects/Godot/test_set_settings/project.godot
```

Deleting `test_bug/var=Resource("res://test_res.tres")` from project.godot will erase this setting and the project will show up again without any error

### Steps to reproduce

1. Create new plugin
2. Add this to _enter_tree()
```
var test := InputEventKey.new()
if not ProjectSettings.has_setting("addons/test_bug/var"):
	ProjectSettings.set_setting("addons/test_bug/var", test)

var property := {
	"name": "addons/test_bug/var",
	"type": TYPE_OBJECT,
	"hint": PROPERTY_HINT_RESOURCE_TYPE,
	"hint_string": "InputEventKey"
}
ProjectSettings.add_property_info(property)
```
3. Create a new resource file of type InputEventKey
4. Open plugin's setting and set new value to this file through Load or Quick Load
5. Close project and open project manager

### Minimal reproduction project

[test_set_settings_resource.zip](https://github.com/godotengine/godot/files/12904238/test_set_settings_resource.zip)
Repository: godot
Issue: Glow flashes a lot on reflections with FSR 2.2 enabled.
Labels: bug,topic:rendering,confirmed,topic:3d

### Godot version

4.2 beta 1

### System information

Windows 11 - Vulkan - Nvidia RTX 4070 - intel i5 13600KF

### Issue description

When FSR2.2 is enabled the glow on reflections has some extreme flashing behaviour, it's not related to just this model, you can check more in the lumberyard demo (https://github.com/godotengine/godot/issues/74965), the model in this MRP is taken directly from that demo to a separate scene to isolate it for this report.

I've also set the values to higher ones to make sure no one can miss it.
I did try teh luminance cap, unless it's at 0 (meaning the glow is disabled) it changes nothing - though increasing it increases the flashing more.

Check the video here: https://youtu.be/cPei3-hV40k

### Steps to reproduce

Open the MRP, you should see a black screen with white flashes in the viewport, feel free to change the blend mode for the Glow in the world environment to see it differently, I set it up this way since it's the most obvious example.

### Minimal reproduction project

[GlowTest.zip](https://github.com/godotengine/godot/files/12904256/GlowTest.zip)
Repository: rust
Issue: `cargo clean -p` Suggestion after ICE uses incorrect name
Labels: C-bug,S-blocked

### Summary

When clippy gets and ICE in a package with a `-` in the name, it suggests fixing but with an `_`.

I'm not sure if this happens on the current stable release or not since I don't know how to reliably trigger an ICE, but am willing to test if I could.

### Reproducer

I tried this code:

```toml
[package]                                                                                            
name = "package-name"
```

I expected to see this happen:

```console
error: internal compiler error: encountered incremental compilation error with mir_built(70094b76db2b4923-9e5dabcfe18f14d7)
  |
  = help: This is a known issue with the compiler. Run `cargo clean -p package-name` or `cargo clean` to allow your project to compile
  = note: Please follow the instructions below to create a bug report with the provided information
  = note: See <https://github.com/rust-lang/rust/issues/84970> for more information
```

Instead, this happened:

```console
error: internal compiler error: encountered incremental compilation error with mir_built(70094b76db2b4923-9e5dabcfe18f14d7)
  |
  = help: This is a known issue with the compiler. Run `cargo clean -p package_name` or `cargo clean` to allow your project to compile
  = note: Please follow the instructions below to create a bug report with the provided information
  = note: See <https://github.com/rust-lang/rust/issues/84970> for more information
```

And then, of course:

```console
$ cargo clean -p package_name
error: package ID specification `package_name` did not match any packages

	Did you mean `package-name`?
```

### Version

```text
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2
```


### Additional Labels

_No response_
Repository: godot
Issue: Blender/GLTF material "specular" attribute is ignored
Labels: bug,topic:import,topic:3d

### Godot version

4.1.1 stable

### System information

Linux Mint 21, AMDGPU, Forward+

### Issue description

When using automatic Blender import (or GLB/GLTF export from Blender and import into Godot), material specular values are ignored and set to a default of 0.5.

This issue is also referenced in https://github.com/godotengine/collada-exporter/issues/57 and I can confirm that this issue still exists in Godot 4.1.1.

When using a large set of models imported from Blender, the only sensible way around this issue is to script every object load to correct the materials manually, which is quite annoying, or be stuck with the sheen on every object.

### Steps to reproduce

1. Create any model in Blender which has a material "Specular" set to any value other than 0.5
2. Add the Blender file to a Godot project and open it for viewing
3. The object will have its material Metallic > Specular set to 0.5

### Minimal reproduction project

N/A