sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: parallel/test-domain-error-types is flaky
Labels: flaky-test

| Reason | <code>parallel/test-domain-error-types</code> |
| - | :- |
| Type | JS_TEST_FAILURE |
| Failed PR | 14 ([https://github.com/nodejs/node/pull/51912/](https://ci.nodejs.org/job/node-test-pull-request/57572/), [https://github.com/nodejs/node/pull/51977/](https://ci.nodejs.org/job/node-test-pull-request/57594/), [https://github.com/nodejs/node/pull/51463/](https://ci.nodejs.org/job/node-test-pull-request/57595/), [https://github.com/nodejs/node/pull/51998/](https://ci.nodejs.org/job/node-test-pull-request/57604/), [https://github.com/nodejs/node/pull/51999/](https://ci.nodejs.org/job/node-test-pull-request/57606/), [https://github.com/nodejs/node/pull/51996/](https://ci.nodejs.org/job/node-test-pull-request/57608/), [https://github.com/nodejs/node/pull/52000/](https://ci.nodejs.org/job/node-test-pull-request/57617/), [https://github.com/nodejs/node/pull/51880/](https://ci.nodejs.org/job/node-test-pull-request/57619/), [https://github.com/nodejs/node/pull/52005/](https://ci.nodejs.org/job/node-test-pull-request/57621/), [https://github.com/nodejs/node/pull/51992/](https://ci.nodejs.org/job/node-test-pull-request/57628/), [https://github.com/nodejs/node/pull/52016/](https://ci.nodejs.org/job/node-test-pull-request/57637/), [https://github.com/nodejs/node/pull/52024/](https://ci.nodejs.org/job/node-test-pull-request/57638/), [https://github.com/nodejs/node/pull/51791/](https://ci.nodejs.org/job/node-test-pull-request/57642/), [https://github.com/nodejs/node/pull/52010/](https://ci.nodejs.org/job/node-test-pull-request/57648/)) |
| Appeared | [test-equinix-ubuntu2004_sharedlibs_container-arm64-5](https://ci.nodejs.org/job/node-test-commit-arm-debug/nodes=ubuntu2004_debug-arm64/11877/console), [test-equinix-ubuntu2004_sharedlibs_container-arm64-6](https://ci.nodejs.org/job/node-test-commit-arm-debug/nodes=ubuntu2004_debug-arm64/11876/console), [test-equinix-ubuntu2004_sharedlibs_container-arm64-3](https://ci.nodejs.org/job/node-test-commit-arm-debug/nodes=ubuntu2004_debug-arm64/11873/console), [test-equinix-ubuntu2004_sharedlibs_container-arm64-2](https://ci.nodejs.org/job/node-test-commit-arm-debug/nodes=ubuntu2004_debug-arm64/11819/console) |
| First CI | https://ci.nodejs.org/job/node-test-pull-request/57572/ |
| Last CI | https://ci.nodejs.org/job/node-test-pull-request/57648/ |

<details>
<summary><a href="https://ci.nodejs.org/job/node-test-commit-arm-debug/nodes=ubuntu2004_debug-arm64/11877/console">Example</a></summary>

```
not ok 946 parallel/test-domain-error-types
  ---
  duration_ms: 1428.72700
  severity: crashed
  exitcode: -11
  stack: |-
  ...

```
</details>

From https://github.com/nodejs/reliability/issues/807

This started to show up since 03-05 (https://github.com/nodejs/reliability/issues/802) and it seems to be crashing due to segmentation fault on arm debug builds.
Repository: godot
Issue: animation tree root node instance bug
Labels: topic:editor,needs testing,topic:animation

### Tested versions

4.2.stable

### System information

windows10 godot4.2.1

### Issue description

If you use an Animation Tree to edit animations and save it as an external scene (which is common in networked games), and then create an Animation Tree scene for each character scene to control their Animation Player, you may encounter a bug where the Animation Tree root node is the same instance. Even if the Animation Tree instances are not the same, anim_tree.get_tree_root() will return the same instance regardless of whether "Local to Scene" is enabled or not. This causes an issue where modifying the bone filters of a specific Animation Tree can inadvertently modify the bone filters of other instances.

In this scenario, when modifying the bone filters of one Animation Tree, if there are locally named bones that exist in other instances, it will unintentionally modify the bone filters of those Animation Trees as well.

### Steps to reproduce

animation_tree is different instance 。but anim_tree.get_tree_root() is same

### Minimal reproduction project (MRP)

![image](https://github.com/godotengine/godot/assets/33251075/523ef742-3157-4bec-9826-1c553bd5f655)
![image](https://github.com/godotengine/godot/assets/33251075/b8b32a49-0e0c-4502-b62a-b499ad450843)
![image](https://github.com/godotengine/godot/assets/33251075/25f59227-2916-4d11-ab56-831e39466b77)
Repository: godot
Issue: "Pick Color" script menu option has issues.
Labels: bug,topic:editor

### Tested versions

Reproducible in 4.3.dev4

### System information

Godot v4.3.dev4 - Pop!_OS 22.04 LTS - X11 - GLES3 (Compatibility) - Mesa Intel(R) Graphics (ADL GT2) () - 12th Gen Intel(R) Core(TM) i5-1235U (12 Threads)

### Issue description

After you use Pick Color once, it starts considering the last color you picked instead of the one you right-clicked. It seems like only if the color syntax is Color(R, G, B[, A]) this updates.

![image](https://github.com/godotengine/godot/assets/85438892/15324974-dd78-4dc7-a857-6b4ec2a4e761)

The colors it produces are so crazy precise that they make the option essentially unusable if I don't copy the color from it.

![image](https://github.com/godotengine/godot/assets/85438892/38d8b464-ad79-4810-bd81-19bffd9a4bb7)


### Steps to reproduce

Type `var lmofa = Color()`, right-click "Color", and try out the things I described above.

### Minimal reproduction project (MRP)

N/A
Repository: PowerToys
Issue: Github actions need to be Transitioning from Node 16 to Node 20
Labels: Area-GitHub workflow

![Image](https://github.com/microsoft/PowerToys/assets/65828559/61a4c7f4-6293-43f5-abe0-55031b66e2f5)

> Node 16 has reached its [end of life](https://github.com/nodejs/Release/#end-of-life-releases), prompting us to initiate its deprecation process for GitHub Actions. Our plan is to transition all actions to run on Node 20 by Spring 2024. We will actively monitor the migration's progress and gather community feedback before finalizing the transition date. Starting October 23rd, workflows containing actions running on Node 16 will display a warning to alert users about the upcoming migration.


https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/
https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/
Repository: tensorflow
Issue: tf.raw_ops.FusedPadConv2D: Aborted (core dumped)
Labels: type:bug,comp:ops,TF 2.15

### Issue type

Bug

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

Yes

### Source

binary

### TensorFlow version

tf 2.15

### Custom code

Yes

### OS platform and distribution

Ubuntu 20.04

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific input, `tf.raw_ops.FusedPadConv2D` encounters "Aborted (core dumped)".

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

# Generate input data
input_data = tf.random.normal([3, 10, 10])

# Define paddings
paddings = tf.constant([[0, 0], [1, 1], [1, 1]])

# Define filter
filter = tf.random.normal([3, 3, 3, 16])

# Define mode
mode = "REFLECT"  # Change mode to "REFLECT" or "SYMMETRIC"

# Define strides
strides = [1, 1, 1, 1]

# Define padding
padding = "VALID"

# Invoke tf.raw_ops.FusedPadConv2D
output = tf.raw_ops.FusedPadConv2D(input=input_data, paddings=paddings, filter=filter, mode=mode, strides=strides, padding=padding)

print(output)
```


### Relevant log output

```shell
2024-03-10 14:49:28.555826: F tensorflow/core/framework/tensor_shape.cc:357] Check failed: d < dims() (3 vs. 3)
Aborted (core dumped)
```
Repository: tensorflow
Issue: tf.raw_ops.TensorScatterSub: Aborted (core dumped)
Labels: type:bug,comp:ops,TF 2.15

### Issue type

Bug

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

Yes

### Source

binary

### TensorFlow version

tf 2.15

### Custom code

Yes

### OS platform and distribution

Ubuntu 20.04

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific input, `tf.raw_ops.TensorScatterSub` encounters "Aborted (core dumped)".

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

# Generate input data
tensor = tf.constant([1, 2, 3, 4, 5])
indices = tf.constant([[[1], [3]], [[0], [2]]])  # Nested structure for indices
updates = tf.constant([10, 20])

# Invoke tf.raw_ops.TensorScatterSub
result = tf.raw_ops.TensorScatterSub(tensor=tensor, indices=indices, updates=updates)

# Print the result
print(result)
```


### Relevant log output

```shell
2024-03-10 14:55:41.958738: F tensorflow/core/framework/tensor_shape.cc:357] Check failed: d < dims() (1 vs. 1)
Aborted (core dumped)
```
Repository: tensorflow
Issue: tf.tensor_scatter_nd_add: Aborted (core dumped)
Labels: stat:awaiting tensorflower,type:bug,comp:ops,TF 2.15

### Issue type

Bug

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

Yes

### Source

binary

### TensorFlow version

tf 2.15

### Custom code

Yes

### OS platform and distribution

Ubuntu 20.04

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific input, `tf.tensor_scatter_nd_add` encounters "Aborted (core dumped)".

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

# Generate input data
input_tensor = tf.zeros([15, 15, 15])
indices = tf.constant([[[0, 0, 0], [1, 1, 1]], [[2, 2, 2], [3, 3, 3]], [[4, 4, 4], [5, 5, 5]], [[6, 6, 6], [7, 7, 7]], [[8, 8, 8], [9, 9, 9]], [[10, 10, 10], [11, 11, 11]], [[12, 12, 12], [13, 13, 13]], [[14, 14, 14], [0, 0, 0]], [[1, 1, 1], [2, 2, 2]], [[3, 3, 3], [4, 4, 4]], [[5, 5, 5], [6, 6, 6]], [[7, 7, 7], [8, 8, 8]], [[9, 9, 9], [10, 10, 10]], [[11, 11, 11], [12, 12, 12]], [[13, 13, 13], [14, 14, 14]]])
updates = tf.constant([1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0, 13.0, 14.0, 15.0])  # Cast updates to float

# Invoke tf.tensor_scatter_nd_add
result = tf.tensor_scatter_nd_add(input_tensor, indices, updates)

# Print the result
print(result)
```


### Relevant log output

```shell
2024-03-10 14:59:51.853766: F tensorflow/core/framework/tensor_shape.cc:357] Check failed: d < dims() (1 vs. 1)
Aborted (core dumped)
```
Repository: godot
Issue: Typing a color with the Color(str) syntax causes parsing error spam while typing
Labels: bug,topic:gdscript,topic:editor

### Tested versions

4.3.dev4

### System information

Godot v4.3.dev4 - Pop!_OS 22.04 LTS - X11 - GLES3 (Compatibility) - Mesa Intel(R) Graphics (ADL GT2) () - 12th Gen Intel(R) Core(TM) i5-1235U (12 Threads)

### Issue description

Let's say I want to type `Color("abcdef09")`, but I'm a bit slow so I spend 0.4sec typing each letter. This isn't enough for the parser to start checking me for errors and give me the red background, but I get error spam nonetheless: "Invalid color name: {color}."

![image](https://github.com/godotengine/godot/assets/85438892/907f577e-c77a-4e29-87bc-13efeca4156b)

Also weird, but I'm not even getting an actual parsing error from this. No red background on the line where I had an invalid color, just the message in output that you normally don't look at while writing code.

### Steps to reproduce

Type `var lmofa = Color("abcdef09")` somewhat slowly.

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: Inheriting custom class duplicates some signals in the editor
Labels: bug,platform:macos,topic:gdscript,topic:editor,topic:porting,needs testing

### Tested versions

- Reproducible in 4.2.1-stable. 4.2.2-stable,  4.3 beta1

### System information

Godot v4.2.1.stable - macOS 14.2.1 - Vulkan (Forward+) - integrated Intel(R) Iris(TM) Plus Graphics 645 - Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz (8 Threads)

### Issue description

When inheriting from a class that defines custom signals, some of the signals seem to get duplicated in the child class in the editor.

The simplest way in which this can be demonstrated is when you "override" the attached script on a node in the scene tree, but it also happens if you define a derived class (with extends and with or without class_name), and instantiate them as separate nodes.

In the examples I have been able to whittle down, it seems that all signals except the first one get duplicated.

When you connect up the signals, the duplicated signals in the list both get connected at the same time, so I suspect it's just an editor problem, nothing deeper.

Some screen shots:

The scene tree: 
<img width="274" alt="Scene Tree" src="https://github.com/godotengine/godot/assets/839370/08994a9a-5e71-48a9-8ea8-fed82ccaca4a">

The signals for the Droppable class (see below)
<img width="255" alt="Droppable" src="https://github.com/godotengine/godot/assets/839370/47b81cda-0f92-4c50-b8ff-5fc21cf66190">

And the signals in the derived node:
<img width="272" alt="DerivedDroppable" src="https://github.com/godotengine/godot/assets/839370/e02ec2d9-a8d8-4d22-84fb-cdc229783868">

I would have expected the `targeted` and `untargeted` signals to not be duplicated in the child class. But as I said, I am pretty sure this is only in the editor, and not anything more problematic. The test I have included in the MRP seems to confirm signals get called once.

### Steps to reproduce

Summarising:

Create a class similar to

    class_name Droppable
    extends Area2D

    signal received_drop(node: Node2D)
    signal targeted
    signal untargeted

Add a node to the scene tree of this type. Attach a script to that node, which simply looks like this:

    extends Droppable

Observe the signals available for the two nodes.

### Minimal reproduction project (MRP)

I have uploaded a sample project with all this information to https://github.com/mgjv/godot-4.2.1-signal-inheritance.

Some more experiments have shown that this also happens with classes derived from Node (not just Area2D)
Repository: vscode
Issue: Feature request: Add search bar per each opened tab with its own search value
Labels: info-needed

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Feature request: Add search bar per tab so each opened file has its own search field **opened or not** and **each search field has its own value**

![зображення](https://github.com/microsoft/vscode/assets/1023918/f957c68f-797f-4176-a98f-0b250732c943)
Repository: pytorch
Issue: LibTorch-Lite 2.1.0 Libs missing x86_64
Labels: module: binaries,oncall: mobile

### 🐛 Describe the bug

We wanted to upgrade our [pytorch-lite-multiplatform](https://github.com/voize-gmbh/pytorch-lite-multiplatform) project to LibTorch-Lite 2.1.0. But we realized that the libs `install/lib/*.a` are all missing the x86_64 arch.

LibTorch-Lite 1.13.0 libs where all both x86_64 and arm64.

```
wget https://ossci-ios.s3.amazonaws.com/libtorch_lite_ios_1.13.0.zip
unzip libtorch_lite_ios_1.13.0.zip
lipo -archs install/lib/libtorch.a
=> x86_64 arm64 
```

```
wget https://ossci-ios.s3.amazonaws.com/libtorch_lite_ios_2.1.0.zip
unzip libtorch_lite_ios_2.1.0.zip
lipo -archs install/lib/libtorch.a
=> arm64
```

Is there a reason for not including the x86_64 arch? If it's not intended, could you do a patch package? 

PS: I also noticed that you are using C++17 language features but the [2.1.0 podspec specifies C++14](https://github.com/CocoaPods/Specs/blob/master/Specs/c/c/3/LibTorch-Lite/2.1.0/LibTorch-Lite.podspec.json#L21)

Thank you!


### Versions

LibTorch-Lite 2.1.0

cc @seemethere @malfet @osalpekar @atalman
Repository: rust
Issue: What are the guarantees around which constants (and callees) in a function get monomorphized?
Labels: T-lang,A-const-generics,C-discussion,I-lang-radar

Currently this compiles in stable.

```rust
struct Foo<T, const N: usize>(T);

impl<T, const N: usize> Foo<T, N> {
    const BAR: () = if N == 0 {
        panic!()
    };
}

struct Invoke<T, const N: usize>(T);

impl<T, const N: usize> Invoke<T, N> {
    const FUN: fn() = if N != 0 {
        || Foo::<T, N>::BAR
    } else {
        || {}
    };
}

fn main() {
    Invoke::<(), 0>::FUN();
}
```


This is a [useful property](https://github.com/rust-lang/rfcs/issues/3582)¹ but if the panic path were not completely excluded this could lead to monomorphization-time errors which are undesirable since they only show up in `cargo build` and not in `cargo check`. But not as undesirable as #107503 where the errors are optimization-dependent.

Still, @RalfJung indicated that the current behavior [might not be intentional](https://github.com/rust-lang/rust/pull/112879#issuecomment-1987200469) so I'm filing this issue for clarification.

(Also see https://github.com/rust-lang/rfcs/issues/3582 for more discussion of the same question.)

----

¹actual use could look like this:

```rust

// library-provided function:

/// Fails to compile if N == 0
fn chunks<const N: usize>(foo: Foo) -> &[[u8; N]] {
   const {
       assert!(N > 0)!
   }

   todo!()
}

// user-code, generic over all N
fn library_user_code<const N: usize>(foo: Foo) ->  {

   // this could be generated by a `const_if!()` macro or use inline const blocks
   struct ConstIf< const N: usize>;

   impl<const N: usize> ConstIf<N> {
     const FUN: fn() = if N != 0 {
         |foo| chunks::<N>(foo)
     } else {
         |foo| { /* fallback code here */ }
     };
   }
   
   ConstIf::<N>::FUN(foo)
}
Repository: react-native
Issue: Uncontrolled input value clears when color is changed
Labels: Issue: Author Provided Repro

### Description

Setting `color` in `style` prop for an uncontrolled input based on focus clears the `TextInput`'s value.
example:

```tsx
...
    <TextInput
      onBlur={onBlur}
      onFocus={onFocus}
      placeholder={placeholder}
      style={[
        {
          color: isFocused ? "#f00" : "#000",
        },
      ]}
    />
...
```
`isFocused` is set based on `onBlur` and `onFocus`.


 This same issue is not noticed for a controlled input. I have also linked a repro link with both cases side by side.

Affected platform: `Android`

### Steps to reproduce

1. Run the application with `npx react-native run-android`
2. Interact with controlled input (notice normal behaviour)
3. Interact with uncontrolled input, notice value of input disappearing when you blur the focus

### React Native Version

0.73.5

### Affected Platforms

Runtime - Android

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

```text
System:
  OS: macOS 14.2.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 179.17 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.19.1
    path: ~/.nvm/versions/node/v18.19.1/bin/node
  Yarn:
    version: 1.22.21
    path: ~/.bun/bin/yarn
  npm:
    version: 10.2.4
    path: ~/.nvm/versions/node/v18.19.1/bin/npm
  Watchman:
    version: 2023.12.04.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - watchOS 10.2
  Android SDK: Not Found
IDEs:
  Android Studio: 2022.3 AI-223.8836.35.2231.10811636
  Xcode:
    version: 15.1/15C65
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.10
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.5
    wanted: 0.73.5
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: false
```


### Stacktrace or Logs

```text
N/A
```


### Reproducer

https://github.com/BalogunofAfrica/react-native-textinput-bug

### Screenshots and Videos

https://github.com/facebook/react-native/assets/45393944/91a05b3e-06c1-4ca5-ac39-74d0da2522d7
Repository: godot
Issue: Engine crashes ERROR: FATAL: Index p_index = 0 is out of bounds (count = 0) when you delete points in the tile set occlusion layer in version 4.2.2 rc1 
Labels: bug,topic:editor,crash,topic:2d

### Tested versions

Reproducible in 4.2.2 rc1 version

### System information

Windows 10 Pro Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz   2.20 GHz Ram 16.0 GB

### Issue description

This bug is similar to one that happened before in version 4.2.1 and 4.2.2 rc1 download. When you paint a 2D polygon on a tile set, like when you set the points that correspond to collisions, eventually the engine crashes. The following error occurs: 

`ERROR: FATAL: Index p_index = 0 is out of bounds (count = 0).
   at: operator[] (./core/templates/local_vector.h:161) `

### Steps to reproduce

1. Open a tile set 
2. Click on the TileSet button at the bottom of the screen.
3. Choose the corresponding art map. 
4. Click on paint to open the occlusion layer to draw. This is mostly physics.   
5. select one random tile and try to paint the points. You can also delete points by clicking on the 3 dots button and click Clear or pressing C on your keyboard.
6. The crash also happens sometimes when you right-click on the small tile map area and move it around. 
7. Crash

### Minimal reproduction project (MRP)


[New Game Project2.zip](https://github.com/godotengine/godot/files/14551532/New.Game.Project2.zip)



Note: This is a project I've been doing. It already happened before and I open a bug report. The previous bug happened with version 4.2.1 and before that I was using 4.0.1. I downloaded version 4.2.2 rc1 and it stop happening for some time. Then it happened again.
Repository: go
Issue: database/sql/driver: convertAssignRows not all nilPtr destinations covered in the switch cases
Labels: NeedsInvestigation

### Go version

latest

### Output of `go env` in your module/workspace:

```shell
latest
```


### What did you do?

I was reading through the source code of database/sql/driver to learn to write better go and out of interest how a language is designed.


### What did you see happen?

I suspect no errNilPtr will be returned in 
https://github.com/golang/go/blob/master/src/database/sql/convert.go#L272-L278
```golang
         case time.Time:
		switch d := dest.(type) {
		case *time.Time:
			*d = s
			return nil
		case *string:
			*d = s.Format(time.RFC3339Nano)
			return nil
		case *[]byte:
			if d == nil {
				return errNilPtr
			}
			*d = []byte(s.Format(time.RFC3339Nano))
			return nil
```
To confirm this i didn't see any tests for the returning of a nilptr err. 

### What did you expect to see?
Since dest has to be pointer it would be best to first test if the dest is a nil ptr at the top level of the function.
https://github.com/golang/go/blob/master/src/database/sql/convert.go#L219-L221
```golang
func convertAssignRows(dest, src any, rows *Rows) error {
	if d == nil {
		return errNilPtr
	}
	// Common cases, without reflect.
```