sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Git - add of file with unicode name fails in Git panel
Labels: bug,help wanted,git

- VSCode Version: Code 1.19.1 (0759f77bb8d86658bc935a10a64f6182c5a1eeba, 2017-12-19T09:46:02.926Z)
- OS Version: Windows_NT ia32 10.0.16299
- Extensions: 

Extension|Author (truncated)|Version
---|---|---
vscode-base64|ada|0.0.1
vscode-database|baj|1.2.0
toml|be5|0.0.3
vscode-markdownlint|Dav|0.12.0
createuniqueid|don|0.0.3
githistory|don|0.2.3
EditorConfig|Edi|0.11.1
git-project-manager|fel|1.4.0
mdmath|goe|2.1.0
vscode-wordcount-cjk|hol|1.0.0
Ionide-FAKE|Ion|1.2.3
Ionide-fsharp|Ion|3.15.7
Ionide-Paket|Ion|1.8.1
copy-markdown-as-html|jer|1.0.0
golang-tdd|joa|0.0.9
Go|luk|0.6.71
reflow-markdown|mar|1.3.0
azure-account|ms-|0.2.2
csharp|ms-|1.13.1
vscode-docker|Pet|0.0.23
vscode-icons|rob|7.19.0
go-test-outline|Rom|0.1.4
rust|rus|0.3.2
vscode-autohotkey|sle|0.2.1
vscode-helm|tec|0.3.0
vscode-lldb|vad|0.7.3
vim|vsc|0.10.8
debug|web|0.21.2



---

Steps to Reproduce:

1. Initialize a git repository and open the folder in VSCode.
2. Create a new file named `defaŭlto.html`.
3. From the VSCode Git panel, use the "+" icon to stage the new file.
4. Error reported: `fatal: pathspec 'c:\…\defaulto.html' did not match any files`

Git log reports that it ran the following command: "git add -A -- c:\…\defaŭlto.html"

Running the same command from the git command line in Powershell works without a problem, but also fails from the normal Windows command prompt. Reviewing StackOverflow and other locations, it appears that this is a limitation of the Windows command prompt, but I thought I would document it here since it has a knock-on effect for the Git panel.

<!-- Launch with `code --disable-extensions` to check. -->
Reproduces without extensions: Yes
Repository: You-Dont-Know-JS
Issue: Async & Performance: optimize gen-runner in chapter 4
Labels: for second edition

In the promise-aware gen runner, to prevent the unnecessary extra tick at the beginning, change:

```js
return Promise.resolve().then(
   function handleNext(value){ .. }
);
```

...to:

```js
return Promise.resolve(
   (function handleNext(value){ .. })()
);
```
Repository: go
Issue: testing: update documentation to be clear about when parallel subtests run
Labels: Documentation,help wanted,NeedsFix

### What version of Go are you using (`go version`)?
`go version go1.9.2 darwin/amd64`

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/zwass/dev/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.9.2/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/4k/2q3ctn7d5_xb03_zsb3v6lgr0000gn/T/go-build252941481=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
```

### What did you do?
`go test -v` with the following code:
```
package main

import (
	"fmt"
	"sync"
	"testing"
)

func TestHang(t *testing.T) {
	t.Parallel()
	var wg sync.WaitGroup
	wg.Add(1)
	fmt.Println("added wg")
	t.Run("", func(t *testing.T) {
		fmt.Println("deferred done")
		t.Parallel()
		fmt.Println("set parallel")
		wg.Done()
	})

	fmt.Println("waiting")
	wg.Wait()
	fmt.Println("waiting complete")
}
```

### What did you expect to see?
All statements print and test completes

### What did you see instead?
Test hangs after "deferred done" and "waiting" are printed.

This is explained by the following comment in the [blog post introducing subtests](https://blog.golang.org/subtests).
> A parallel test never runs concurrently with a sequential test and its execution is suspended until its calling test function, that of the parent test, has returned.

But I cannot find this mentioned anywhere in the [documentation for the `testing` package](https://godoc.org/testing).

It seems like we at least need to update those docs with the appropriate details.
Repository: rust
Issue: optimization remarks broken, names mangled, no file/line addresses (-C remark=all)
Labels: A-LLVM,T-compiler,C-bug

ad9a1daa819bbeb8e643a01167b3b69055b88d57 added support for optimization remarks ````RUSTFLAGS="-C remark=all" cargo build --release````
however the output is very hard to use since source locations are broken and names are mangled.
````
note: optimization analysis for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog517ha0cfb85674d1470fE can be inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E with cost=-14065 (threshold=275)

note: optimization remark for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog517ha0cfb85674d1470fE inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E

note: optimization analysis for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog617hf4efcc03917e607cE can be inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E with cost=-14065 (threshold=275)

note: optimization remark for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog617hf4efcc03917e607cE inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E

note: optimization analysis for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog717h9a70d5bf4650de27E can be inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E with cost=-13915 (threshold=275)

note: optimization remark for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog717h9a70d5bf4650de27E inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E

note: optimization analysis for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog817h899b896fff77b7eaE can be inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E with cost=-14065 (threshold=275)

note: optimization remark for inline at <unknown file>:0:0: _ZN11pathfinding12test_prolog817h899b896fff77b7eaE inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E

note: optimization missed for inline at <unknown file>:0:0: _ZN11pathfinding20print_shortest_paths17hac2d4d48645262b5E will not be inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E

note: optimization missed for inline at <unknown file>:0:0: _ZN4core3ptr13drop_in_place17h9afff73c9d313742E will not be inlined into _ZN11pathfinding4main17hc3ab21b80a078ef2E

note: optimization floating-point for loop-vectorize at <unknown file>:0:0: loop not vectorized: cannot prove it is safe to reorder floating-point operations

````
  
cargo 0.25.0-nightly (a88fbace4 2017-12-29)
rustc 1.25.0-nightly (ee220daca 2018-01-07)
Repository: pytorch
Issue: descriptor 'add' of 'torch._C._VariableBase' object needs an argument
Labels: module: docs,triaged

the pytorch document said that the add opeartion can be like this
##          ` torch.add(input, value=1, other, out=None)`
but it will rise the error of descriptor 'add' of 'torch._C._VariableBase' object needs an argument
when i do 
##         `torch.add(input=a, value=0.01, other=a)`

a is a Variable  like
Variable containing:
 5.0500
[torch.FloatTensor of size 1]

but torch.add(a, 0.01, a) is fine to work

  

cc @jlin27
Repository: rust
Issue: Rust's stdio should not ignore EBADF error on non-windows platforms
Labels: C-enhancement,T-libs-api,A-io

I've discovered, that `std::io::stdin/out/err()` streams unconditionally ignore `EBADF`-like IO errors on all platforms. This is done by checking the read/write error in a `handle_ebadf()` function.

https://github.com/rust-lang/rust/blob/1ccb50eaa670f86b69e7a64484a8c97e13169183/src/libstd/io/stdio.rs#L123-L128

It appears, that this behavior was first introduced here https://github.com/rust-lang/rust/commit/a7bbd7da4eb98127104fdfd415ad6c746f7e2a12

The commit clearly has Windows in mind, where it appears the standard streams may be unavailable. But on Linux, the streams are expected to be always present, so there's no reason to ignore `EBADF` in the first place, as it indicates that something is very wrong.

Not only that, but due to file descriptor reuse behavior on Unixes, if descriptors 0/1/2 are not open, sometimes the very next calls to `open()` will allocate them. This means, that a program running without properly preallocated 0/1/2 descriptors may start happily `println!()`-ing over its own sqlite database, or send private execution logs across a tcp connection.

So, if `std::io::stdout/err()` happens to discover that something yanked the descriptors from under program's feet, the proper response is not to silently ignore `EBADF`, but to **panic()**, before something else unwittingly allocated it with likely disastrous consequences.
Repository: angular
Issue: [Animations] weird initialisation states
Labels: type: bug/fix,area: animations,freq3: high,P3

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->
The Angular's animation system does not initialize the same component (in the exemple 'test-btn') the same way if it is in a transcluded component (in the exemple 'test-popup').

## Expected behavior
<!-- Describe what the desired behavior would be. -->
The transcluded test-btn should display only one text/state.


## Minimal reproduction of the problem with instructions
<!--
For bug reports please provide the *STEPS TO REPRODUCE* and if possible a *MINIMAL DEMO* of the problem via
https://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).
-->
http://plnkr.co/edit/nnFiPLz0YyLjfc8Ll2HZ?p=preview

You can click on the "Send" button, it works properly. Toggle the popup, you will see the same button component but all possible states are visible. Note: the aria-hidden props are properly set.

Bonus:  if you spam the click, the text come from bottom and not from top as expected via 
```
transition('invisible => visible', [
    style({opacity: 0, transform: 'translateY(-100%)'}),
    animate('0.5s')
])
```

## Environment

<pre><code>
Angular version: 5.1.3 latest
<!-- Check whether this is still an issue in the most recent Angular version -->
</code></pre>
Repository: go
Issue: cmd/pprof: use $GOPATH for source file lookup
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?
go version go1.9.2 darwin/amd64


### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN="/Users/phemmer/.go/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/phemmer/.go:/tmp/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/xk/jhvsfjg14zqfgtwvm0kpsy61p_63g5/T/go-build517300090=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
```

### What did you do?
Attempted to profile a heap dump from a binary built on another host and use `list foo`

### What did you expect to see?
The source code with corresponding data for each line.

### What did you see instead?
```
(pprof) list unmarshalBinary
Total: 1.95GB
ROUTINE ======================== github.com/influxdata/kapacitor/vendor/github.com/influxdata/influxdb/models.(*point).unmarshalBinary in /root/go/src/github.com/influxdata/kapacitor/vendor/github.com/influxdata/influxdb/models/points.go
    1.49GB     1.49GB (flat, cum) 76.51% of Total
 Error: open /root/go/src/github.com/influxdata/kapacitor/vendor/github.com/influxdata/influxdb/models/points.go: no such file or directory
```

On my local system, this source code can instead be found in `/Users/phemmer/.go/...`.

Ref #13231 which is related, but I can't use $GOROOT, as I don't have a full go toolkit in my home directory, only application source.
Repository: go
Issue: cmd/compile: inefficient CALL setup when more than 32bytes of args
Labels: Performance,binary-size,compiler/runtime

```
$ gotip version
go version devel +a62071a209 Sat Jan 6 04:52:00 2018 +0000 linux/amd64
```

```
type T struct {
	s1, s2 string
}

//go:noinline
func foo(t T) { _ = t }

func bar() {
	var t T
	foo(t)
}
```

generates

```
0x0020 00032 (test.go:14)	MOVUPS	X0, (SP)
0x0024 00036 (test.go:14)	MOVUPS	X0, 16(SP)
0x0029 00041 (test.go:14)	CALL	"".foo(SB)
```

but when 

```
type T struct {
	s1, s2, s3 string    // one more string
}
```

```
0x001d 00029 (test.go:13)	XORPS	X0, X0
0x0020 00032 (test.go:13)	MOVUPS	X0, "".t+48(SP)
0x0025 00037 (test.go:13)	MOVUPS	X0, "".t+64(SP)
0x002a 00042 (test.go:13)	MOVUPS	X0, "".t+80(SP)
0x002f 00047 (test.go:13)	MOVQ	SP, DI
0x0032 00050 (test.go:14)	LEAQ	"".t+48(SP), SI
0x0037 00055 (test.go:14)	DUFFCOPY	$854
0x004a 00074 (test.go:14)	CALL	"".foo(SB)
```

The stack is bigger; first we  `MOVUPS` a bunch of zeros to `48/64/80(SP)`, then we call `DUFFCOPY` to move them again to (SP). This seems wasteful. Even if we cross the multiple-MOVs/DUFF threshold, it seems it would be possible to just `DUFFZERO` at `(SP)`, essentially the thing the first snippet does.

This also happen when there's no zeroing going on. For example, for `struct { a, b, c, d int64}`, when initialized as `t = {1, 2, 3, 4}`, the values are moved directly to `(SP)`, but for `struct { a, b, c, d, e int64}`, which is bigger than 32bytes, they aren't. There are 5 moves high into the stack and then a `DUFFCOPY` call moves them to `(SP)`.
Repository: go
Issue: dist: provide one-line installer
Labels: NeedsFix,FeatureRequest,DevExp

We all agree we want a 1-line installer. tools/cmd/getgo is a start but has work to do. This is the tracking bug for shipping it (and advertising it on the install page).
Repository: godot
Issue: UndoRedo error with consecutive create_action calls
Labels: topic:core,confirmed,documentation

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
99da466


**OS/device including version:**
Ubuntu 17.10


**Issue description:**
After this, I'm done torturing UndoRedo, I think.  :)

There doesn't appear to be any way out of a create_action() once you've started it.  There's a commit but no rollback.  If one expects another create_action() to discard the previous commands, they're treated to an error and a now-broken commit.


**Steps to reproduce:**
```
todd@todd-ab28d3:~/repos/remote/brainsick-godot-tests$ cat tests/qa/classes/UndoRedoTest-uncommit.gd 
extends MainLoop

var testobject1
var undoredo

func _initialize():
	testobject1 = TestClass.new()
	testobject1.set_prop(1)
	
	undoredo = UndoRedo.new()

# main test body
func _iteration(delta):
	test_create_uncommit()
	test_create_commit()
	
	return true # exit MainLoop

func _finalize():
	undoredo.free()

func test_create_uncommit():
	undoredo.create_action('first action - method')
	undoredo.add_do_method(testobject1, 'set_prop', 2)
	undoredo.add_undo_method(testobject1, 'set_prop', testobject1.get_prop())
	#undoredo.commit_action()
	# where's rollback?
	
	assert(testobject1.prop == 1)

func test_create_commit():
	undoredo.create_action('second action - property')
	#undoredo.create_action('second action - property', UndoRedo.MERGE_DISABLE)
	#undoredo.create_action('second action - property', UndoRedo.MERGE_ENDS)
	#undoredo.create_action('second action - property', UndoRedo.MERGE_ALL)
	undoredo.add_do_property(testobject1, 'prop', 3)
	undoredo.add_undo_property(testobject1, 'prop', testobject1.prop)
	undoredo.commit_action()
	
	assert(testobject1.prop == 3)

class TestClass:
	var prop
	
	func get_prop():
		return prop
	
	func set_prop(prop):
		self.prop = prop
todd@todd-ab28d3:~/repos/remote/brainsick-godot-tests$ ../brainsick-godot/bin/godot.x11.tools.64 -s tests/qa/classes/UndoRedoTest-uncommit.gd 
No touch devices found
OpenGL ES 3.0 Renderer: AMD Radeon (TM) R9 Fury Series (AMD FIJI / DRM 3.18.0 / 4.13.0-21-generic, LLVM 5.0.0)
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile
SCRIPT ERROR: test_create_commit: Assertion failed.
   At: res://tests/qa/classes/UndoRedoTest-uncommit.gd:40.
ERROR: clear_history: Condition ' action_level > 0 ' is true.
   At: core/undo_redo.cpp:326.
```

I have an updated, more robust test at godotengine/godot-tests#3.
Repository: pytorch
Issue: Carefully audit contiguity requirements of code
Labels: module: cudnn,triaged

While I was working on the cuDNN bindings, I was a bit nervous about when we required things to be contiguous or not (for the most part, I tried to exactly mimic what the API did previously, but I did not feel very confident about it.) The reason I was nervous is that we don't seem to carefully test our algorithms on all combinations of contiguity for each of their inputs.

Now that we most recently discovered and fixed #4500, it might be worth planning to do an in depth contiguity audit of PyTorch's codebase + test coverage, to see if there are other corners we have missed.

I am vaguely reminded of #3170, which was a analogous bug with sparse coalesced.

cc @csarofeen @ptrblck
Repository: opencv
Issue: ORB descriptor cannot use SIFT keypoints
Labels: category: features2d,RFC

##### System information (version)
- OpenCV => 3.4.0-dev
- Operating System / Platform => ALL
- Compiler => ALL

##### Detailed description
Although ORB works with FAST or AKAZE keypoints, it fails to use the SIFT ones!

##### Steps to reproduce
```.py
import cv2

sift = cv2.xfeatures2d.SIFT_create()
orb = cv2.ORB_create()

rgb = cv2.imread('any_image.png')
kps = sift.detect(rgb)
kps, descrs = orb.compute(rgb, kps)
```

##### Actual result
Memory allocation error, and a crash!
Repository: vscode
Issue: [xml] add on enter rules
Labels: feature-request,languages-basic

- VSCode Version: Code 1.19.1 (0759f77bb8d86658bc935a10a64f6182c5a1eeba, 2017-12-19T09:46:23.884Z)
- OS Version: Windows_NT x64 10.0.16299
- Extensions: 

Extension|Author (truncated)|Version
---|---|---
xml|Dot|1.9.2
auto-close-tag|for|0.5.5
auto-complete-tag|for|0.0.2
auto-rename-tag|for|0.0.15
beautify|Hoo|1.1.1
csharp|ms-|1.13.1
qub-xml-vscode|qub|1.2.8



---

Steps to Reproduce:

1. Automatic indentation does not work when writing XML(appending child).
2. Automatic indentation works when writing HTML.

<!-- Launch with `code --disable-extensions` to check. -->
Reproduces without extensions: Yes/No
Repository: pytorch
Issue: Met 'cudnnDestroyDropoutDescriptor' while run multiply gpu-based models in multiply processes
Labels: module: multi-gpu,module: cudnn,triaged

I loaded a model and replicated 3 models which are all on different GPUs, and use torch.multiprocessing to create 4 processes. By this  setting, I run one model in on process, so that I parallel run them. The running is fine, but when the processes were finished, this error occurred:
```
Exception ignored in: <bound method CuDNNHandle.__del__ of <torch.backends.cudnn.CuDNNHandle object at 0x7f86ea1bcf28>>
Traceback (most recent call last):
  File "/home/lgy/installed/anacoda3/lib/python3.6/site-packages/torch/backends/cudnn/__init__.py", line 114, in __del__
AttributeError: 'NoneType' object has no attribute 'cudnnDestroy'
```

The code where the error happens is:
```
class DropoutDescriptor(object):
    def __del__(self):
        check_error(lib.cudnnDestroyDropoutDescriptor(self))
```

My pytorch version:
```
$> pip list
....
torch (0.3.0.post4)
torchtext (0.1.1)
torchvision (0.2.0)
....
```

Is there any ways to fix this?

cc @csarofeen @ptrblck
Repository: flutter
Issue: [google_sign_in] Remove guava dependency 
Labels: c: new feature,team,platform-android,p: google_sign_in,package,c: proposal,P2,team-android,triaged-android

This is no bugreport, more a question.

I started editing the google sign in plugin for android and figured out several problem, I would like to fix.

In order to do so, I would like to know what the getToken method is used for. According to the rest of the implementation, you can get the token out of the GoogleSignInAccount after a successful login. IMHO this method is not necessary, but I guess there's a reason for you to have it in there.

If not, I would like to remove it, since it's not really required and the dependency required (guava) is a [method limit](https://developer.android.com/studio/build/multidex.html#about) killer, since guava comes [with about 15k methods](http://www.methodscount.com/?lib=com.google.guava%3Aguava%3A20.0)

If it is needed for some reason, I created an alternative implementation without the guava dependency using android build in tools. See the PR mentioned below
Repository: opencv
Issue: `KeyPoint` and `vector<KeyPoint>` are not sufficient for detector/descriptor decoupling
Labels: RFC

Sorry for the long report in advance, I hope developers can react to this, and agree to find a better approach.

The existence of `Feature2D::detect` and `Feature2D::compute` advertises for detector/descriptor decoupling, in which detected keypoints by virtually any detector shall be describable using any descriptor. Unfortunately, the underlying implementation gives developers a huge challenge to achieve that. Perhaps a slight modification in the interfaces can improve the developer experience.

Currently, `Keypoint` class provides `pt`, `size`, `angle`, `response`, `octave`, and `class_id` fields, but they are insufficient, and many questions remains unanswered.

- What is the scale factor for a keypoint at the octave level, given its diameter (`size`)?
- What is the scale ratio between different octave levels? How to compute/recompute it? Is it a constant ratio, or does it have a specific form?
- Are negative octaves allowed? What does negative values mean?
- What does huge octave values mean? How to relate that to the scale?
- How to interpret the `response`? Is it unified along all detectors?
- Mixing keypoints from different detectors robustifies the match, but how to solve the ambiguities (e.g. octave scale) then? Can we know which keypoint belongs to what?
- Can detectors pass some callback to solve such ambiguities?

While many descriptors tackles these issues to some extent, some other descriptors (e.g. AKAZE) just reject any foreign keypoints. More importantly, each descriptor strives by its own, at different levels of maturity, to convert the keypoints to a format it expects (e.g. ORB as in #10556).  It is a pity that, for example, SIFT encodes `layer` and `octave` in the same integer using bitwise operators, instead of having separate fields for each (#4554). Such lack of concrete definition for the keypoints attributes and allowed ranges waste developers time and efforts.

Currently, `Keypoint` class is just a container, and so the `vector` that aggregates the keypoint instances!
I wonder why C++ iterable classes are not utilized, rather than just a vector!? Such iterators are capable of provide all the missing information as well ...