sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/vet: spurious "context leak" due to imprecise 'defer' control-flow analysis in lostcancel
Labels: help wanted,NeedsFix,Analysis

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.10 windows/amd64

### Does this issue reproduce with the latest release?
yes, tested on go1.10.2 as well

### What operating system and processor architecture are you using (`go env`)?
```
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\micro\AppData\Local\go-build
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=F:\goenv\
set GORACE=
set GOROOT=F:\go
set GOTMPDIR=
set GOTOOLDIR=F:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\micro\AppData\Local\Temp\go-build748724598=/tmp/go-build -gno-record-gcc-switches
```

### What did you do?

run `go vet` on https://play.golang.org/p/X_vRJbYf7rO

### What did you expect to see?

no errors

### What did you see instead?

```
issue.go:12: the cancel function is not used on all paths (possible context leak)
issue.go:14: this return statement may be reached without using the cancel var defined on line 12
```
Repository: rust
Issue: compiler error message shows the error path containing parent directory identifier ( `/../` )
Labels: C-enhancement,A-diagnostics,E-mentor,T-compiler,E-help-wanted

```
error[E0599]: no method named `map` found for type `std::iter::Map<postgres::rows::Iter<'_>, for<'r, 's> fn(postgres::rows::Row<'r>, &'s extract::CmdOptions) -> std::result::Result<<Q as extract::query::Query>::Message, postgres::Error> {<Q as extract::query::Query>::map}>` in the current scope
  --> extract/tests/query/../helper.rs:40:10
   |
40 |         .map(Result::unwrap)
```

the actual error is in `extract/tests/helper.rs` and that's what I would expect to be displayed instead of `extract/tests/query/../helper.rs`.

```rustc 1.26.1 (827013a31 2018-05-25)
binary: rustc
commit-hash: 827013a31b88e536e85b8e6ceb5b9988042ec335
commit-date: 2018-05-25
host: x86_64-unknown-linux-gnu
release: 1.26.1
LLVM version: 6.0
```
Repository: vscode
Issue: Filter "Problems" by the extension which generated them (Markers Panel Filter)
Labels: feature-request,error-list,papercut :drop_of_blood:

I'd love to be able to declutter the "Problems" Markers Panel by hiding/showing logs generated by only certain extensions. 

Right now, if I type `[ts]` into the filtering box, I get `No results found with provided filter criteria. Clear Filter.`

If I then delete the filter, I can clearly see plenty of warnings and errors generated by `[ts]`. After tinkering with it for a while, I've not been able to figure out how to filter by the extension name. (Maybe it just needs some documentation or UI to help the user write filters?)

Also, for other users finding this issue, after a bit of searching around I realized I could also filter roughly by using the keywords `warning`, `error`, and `info`. E.g: enter `warning, error` into the filter to hide `info` markers. This helps a bit, but doesn't help much when you're trying e.g. to filter out a particularly noisy extension (like a spell checker) generating the same type of marker you're looking for.
Repository: pytorch
Issue: PyTorch multiprocessing using single CPU core
Labels: todo,module: multiprocessing,triaged

## Issue description

I was trying to load data with DataLoader with multiple workers, and I noticed that although it creates the processes they all run on the same CPU core, thus the data loading is very slow.

I succeeded in creating a minimal example (below). If I run the script below, it uses 4 CPU cores. If I uncomment the "import torch" line, only single core is used. If I also uncomment the taskset command, it will use 4 cores again.

## Code example

```python
#!/usr/bin/env python3

#import torch
import os
def loop():
    while True:
        pass

#os.system("taskset -p 0xff %d" % os.getpid())
from multiprocessing import Process
for i in range(4):
    Process(target=loop).start()
```

## System Info
Although the collect_env.py prints gcc 8.1.0, it was overridden to 7.3.1 during build. Also cudnn detection failed, its version is 7.1.3.

Built from source (commit f24d715e235eb7d188cb610d7b29386b9eaf0ab9), command: "CC=gcc-7 CXX=g++-7 python setup.py bdist_wheel", package installed with pip install --user.

PyTorch version: 0.5.0a0+f24d715
Is debug build: No
CUDA used to build PyTorch: 9.2.88

OS: Antergos Linux
GCC version: (GCC) 8.1.0
CMake version: version 3.11.2

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 9.2.88
GPU models and configuration: 
GPU 0: TITAN X (Pascal)
GPU 1: GeForce GTX 1070

Nvidia driver version: 396.24
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy (1.13.1)
[pip3] torch (0.5.0a0+f24d715)
[pip3] torchfile (0.1.0)
[pip3] torchvision (0.1.8)
[conda] Could not collect
Repository: rust
Issue: RFE: debug pretty printers for Rc/Arc
Labels: T-dev-tools,C-feature-request

It would be nice if `rust-gdb`/etc. could pretty-print the inner value of `Rc` and `Arc`.  Right now you only get the raw details, like:

```
(gdb) p foo
$1 = Rc<i32> = {ptr = NonNull<alloc::rc::RcBox<i32>> = {
    pointer = NonZero<*const alloc::rc::RcBox<i32>> = {0x555555783a40}},
  phantom = PhantomData<i32>}
```

Getting the actual value requires manual field access, `foo.ptr.pointer.0.value`, which could also change if `Rc` internals change.

Maybe this could be approached as more general `Deref` support, so you could `p *foo` here, but right now that just says "Attempt to take contents of a non-pointer value."
Repository: pytorch
Issue: Cmake is getting permission denied when installed system wide
Labels: caffe2

Hi,

Trying to build from source, compiled fine when disabling the `-DBUILD_TEST=OFF` but now I'm trying to use `caffe2` from my own CMakeLists.txt and I get the following interesting error:

```
-- Caffe2: Cannot find gflags automatically. Using legacy find.
-- Caffe2: Found gflags  (include: /usr/include, library: /usr/lib/x86_64-linux-gnu/libgflags.so)
-- Caffe2: Cannot find glog automatically. Using legacy find.
-- Caffe2: Found glog (include: /usr/include, library: /usr/lib/x86_64-linux-gnu/libglog.so)
-- Caffe2: Found protobuf with new-style protobuf targets.
-- Caffe2: Protobuf version 3.5.0
-- Caffe2: CUDA detected: 9.0
-- Caffe2: CUDA nvcc is: /usr/local/cuda/bin/nvcc
-- Caffe2: CUDA toolkit directory: /usr/local/cuda
CMake Error at /usr/local/share/cmake/Caffe2/public/cuda.cmake:26 (file):
  file failed to open for writing (Permission denied):

    /detect_cuda_version.c
Call Stack (most recent call first):
  /usr/local/share/cmake/Caffe2/Caffe2Config.cmake:74 (include)
  CMakeLists.txt:36 (find_package)


CMake Error: The source directory "CMAKE_FLAGS" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
CMake Error: Internal CMake error, TryCompile configure of cmake failed
CMake Error: TRY_COMPILE attempt to remove -rf directory that does not contain CMakeTmp:/detect_cuda_version.c
CMake Error at /usr/local/share/cmake/Caffe2/public/cuda.cmake:41 (message):
  Caffe2: Couldn't determine version from header:
Call Stack (most recent call first):
  /usr/local/share/cmake/Caffe2/Caffe2Config.cmake:74 (include)
  CMakeLists.txt:36 (find_package)
```

I've looked under `/usr` with `find . -name "detect_cuda_version.c"` and indeed it is nowhere to be found.
Where is it expected to be?

BTW, all did was `sudo make install`.
System is Ubuntu 16.04
Repository: go
Issue: cmd/asm: how to test?
Labels: Testing,NeedsInvestigation,compiler/runtime

The current tests are an inconsistent mess. Some files are hand-written. Others are auto-generated and enormous, and could be generated on the fly instead of being checked in. Some architectures are well tested. Others are not. Some subsets of architectures (AVX) are exhaustively tested.  Others are not.

I would like a proper discussion about how to test the assembler (and the compiler, if you like). Without a clear picture, the tests will become enormous, wildly inconsistent, messy, and difficult to maintain.
Repository: flutter
Issue: FlutterHeadlessDartRunner should return an error on invalid launches.
Labels: engine,P2,team-engine,triaged-engine

Proposed API: `-[FlutterHeadlessDartRunner initWithProject:(FlutterDartProject*) project completion: (LaunchResult) result];`

with `typedef void(^LaunchResult)(NSError*);`
Repository: pytorch
Issue: GRU is implementation of GRU v1 draft rather than final GRU paper algo
Labels: module: docs,module: rnn,triaged

GRU is implementation of v1 https://arxiv.org/pdf/1406.1078v1.pdf rather than final v3 https://arxiv.org/pdf/1406.1078.pdf

Concretely, in v1, the reset gate is applied to the result of applying a linear layer to the incoming state, equation 8:

<img width="287" alt="screen shot 2018-06-05 at 1 33 21 pm" src="https://user-images.githubusercontent.com/123560/40958883-108947ac-68c5-11e8-88b4-70ecda354f69.png">

... wheras the final v3 first applies the reset gate, and then passes through a linear layer:

<img width="301" alt="screen shot 2018-06-05 at 1 34 19 pm" src="https://user-images.githubusercontent.com/123560/40958904-2e6eb018-68c5-11e8-9ae3-01fed5319651.png">

A few minutes informal testing gave me better results on final v3 than draft v1. I imagine that pytorch is using v1 partly for execution speed, and partly because that's what cudnn uses:

https://docs.nvidia.com/deeplearning/sdk/cudnn-developer-guide/index.html#cudnnRNNMode_t

<img width="376" alt="screen shot 2018-06-05 at 1 36 22 pm" src="https://user-images.githubusercontent.com/123560/40958992-77e050e4-68c5-11e8-9813-ff9e2582cd34.png">

I'm not sure if that's a good reason though. I think it might be good to at least document that this approximation is being used?
Repository: rust
Issue: to_lowercase only uses unconditional parts of unicode.org's special-casing
Labels: C-enhancement,A-Unicode,T-libs-api

https://github.com/rust-lang/rust/blob/f9157f5b869fdb14308eaf6778d01ee3d0e1268a/src/libcore/unicode/unicode.py#L168-169

Since #25800, to_lowercase uses unicode.org's SpecialCasing.txt.
However, it only follows unconditional rules from this file. One "interesting" case is:
1. The main UnicodeData.txt file says that the lowercase of 'İ' (0130, Latin capital letter I with dot above) should be 'i' (0069, good-old boring ASCII Latin small letter i).
2. SpecialCasing.txt adds an unconditional rule that 'İ' (0130) should in fact be lowercased to 'i̇' (0069 Latin small letter i + 0307 combining dot above).
3. SpecialCasing.txt then adds a rule for tr (Turkish) and az (Azerbaijani) where 'İ' (0130) should now be lowercased to just 'i' (0069 Latin small letter i) -- There are other related rules, dotted-i's match and non-dotted-i's match too.

I think that (2) only makes sense when accompanied by (3): They are in the same file, touching the same character; (3) for tr/az and (2) for other languages.
But because only unconditional rules are handled, we end up with something hybrid that was intended for non-tr/az languages in contrast with tr/az, while ignoring the default language-independent specification from UnicodeData.txt.

I realize that it's quite a corner case, and open to interpretation.
Also, SpecialCasing.txt contains other useful unconditional rules that are worth having, so it would be unfortunate to lose those.
And (2) does have the advantage of making lowercasing reversible; though it's not a goal of unicode AFAIK.

So in the end, I'm not sure if&how this should be fixed -- other than implementing conditions, which would require handling languages.

A compromise would be to ignore this one rule, by hard-coding an exception.
This restriction could be made less arbitrary, by saying: Unconditional rules are only accepted for characters that do **not** also have conditional rules.

I understand if this won't be fixed, I at least wanted to bring attention to this case.
Repository: go
Issue: cmd/compile: detect divisions that always result in 0
Labels: Performance,NeedsDecision,compiler/runtime

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version devel +b7f3c178a3 Mon May 14 04:42:45 2018 +0000 darwin/amd64

### Does this issue reproduce with the latest release?

yes

### What operating system and processor architecture are you using (`go env`)?

darwin/amd64

### What did you do?
```
func f(p, q uint) uint {
        return p + (q%6)/9
}

go run -gcflags=-S moddiv.go
```
### What did you expect to see?

Something akin to
```
"".f STEXT nosplit size=69 args=0x18 locals=0x0
        0x0000 00000 (/Users/dfc/src/moddiv.go:5)       TEXT    "".f(SB), NOSPLIT, $0-24
        0x0000 00000 (/Users/dfc/src/moddiv.go:5)       FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (/Users/dfc/src/moddiv.go:5)       FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (/Users/dfc/src/moddiv.go:6)       MOVQ    $-6148914691236517205, AX
        0x000a 00010 (/Users/dfc/src/moddiv.go:6)       MOVQ    "".q+16(SP), CX
        0x003f 00063 (/Users/dfc/src/moddiv.go:6)       MOVQ    CX, "".~r2+24(SP)
        0x0044 00068 (/Users/dfc/src/moddiv.go:6)       RET
```

### What did you see instead?
```
"".f STEXT nosplit size=69 args=0x18 locals=0x0
        0x0000 00000 (/Users/dfc/src/moddiv.go:5)       TEXT    "".f(SB), NOSPLIT, $0-24
        0x0000 00000 (/Users/dfc/src/moddiv.go:5)       FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (/Users/dfc/src/moddiv.go:5)       FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (/Users/dfc/src/moddiv.go:6)       MOVQ    $-6148914691236517205, AX
        0x000a 00010 (/Users/dfc/src/moddiv.go:6)       MOVQ    "".q+16(SP), CX
        0x000f 00015 (/Users/dfc/src/moddiv.go:6)       MULQ    CX
        0x0012 00018 (/Users/dfc/src/moddiv.go:6)       SHRQ    $2, DX
        0x0016 00022 (/Users/dfc/src/moddiv.go:6)       LEAQ    (DX)(DX*2), DX
        0x001a 00026 (/Users/dfc/src/moddiv.go:6)       SHLQ    $1, DX
        0x001d 00029 (/Users/dfc/src/moddiv.go:6)       SUBQ    DX, CX
        0x0020 00032 (/Users/dfc/src/moddiv.go:6)       MOVQ    $-4099276460824344803, AX
        0x002a 00042 (/Users/dfc/src/moddiv.go:6)       MULQ    CX
        0x002d 00045 (/Users/dfc/src/moddiv.go:6)       ADDQ    DX, CX
        0x0030 00048 (/Users/dfc/src/moddiv.go:6)       RCRQ    $1, CX
        0x0033 00051 (/Users/dfc/src/moddiv.go:6)       SHRQ    $3, CX
        0x0037 00055 (/Users/dfc/src/moddiv.go:6)       MOVQ    "".p+8(SP), DX
        0x003c 00060 (/Users/dfc/src/moddiv.go:6)       ADDQ    DX, CX
        0x003f 00063 (/Users/dfc/src/moddiv.go:6)       MOVQ    CX, "".~r2+24(SP)
        0x0044 00068 (/Users/dfc/src/moddiv.go:6)       RET
```
The value of q is in the range [0-6) because of the modulo, which divided by 9 is always 0. So the result of `f(x, y)` is always `x`
Repository: material-ui
Issue:  [Menu] Support cascading / nested menu
Labels: new feature,waiting for 👍,component: menu

Hello,

I wrote some two advanced components, who can handle Submenuitems.
I defined an anchorElement, which will be passed as property to the Mui Menu Component.
Is there a way to define where the Popup Element should be displayed? Because now it will just overlap. Maybe I want to calculate it more left or more right.

Here is an demo: https://codesandbox.io/s/9ywowy18k4

### Benchmark

- https://blueprintjs.com/docs/#core/components/menu
- https://reakit.io/docs/menu/#submenu
- https://www.telerik.com/kendo-react-ui/components/layout/menu/
- https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html
- https://ant.design/components/dropdown/#components-dropdown-demo-sub-menu
Repository: TypeScript
Issue: Missing error when awaiting dynamic import of module with 'then' export
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.0.0-dev.20180605

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** 

**Code**

```ts
// a.ts
export function then() { return true; }

// b.ts
async function test() {
  await import('./a');
}

// c.ts
// this is basically the same as b.ts
import * as ns from './a';
function myImport() {
  return Promise.resolve(ns);
}
async function test() {
  await myImport();
}
```

**Expected behavior:**
in b.ts: `[ts] Type of 'await' operand must either be a valid promise or must not contain a callable 'then' member.`
This would catch a lot of bugs with dynamic imports of modules that contain a `then` function. The resulting Promise will never resolve: https://github.com/tc39/proposal-dynamic-import/issues/47

**Actual behavior:**
No error in `b.ts`. The resulting type of the `await` is `{}`.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> 

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: rust
Issue: 'static lifetime elision in associated constants should mirror normal non-associated constants
Labels: A-lifetimes,A-associated-items,T-lang,C-feature-request,needs-rfc

https://play.rust-lang.org/?gist=8fb655fdb61666de91bd38bfedb537b6&version=stable&mode=debug
```rust
const A: &str = "A"; // defaults to 'static

trait Foo {
	const S: &str; // should behave the same
}

impl Foo for () {
	const S: &str = "bar";
}

fn main() {}
```
```
error[E0106]: missing lifetime specifier
 --> src/main.rs:4:11
  |
4 |     const S: &str; // should behave the same
  |              ^ expected lifetime parameter

error[E0106]: missing lifetime specifier
 --> src/main.rs:8:14
  |
8 |     const S: &str = "bar";
  |              ^ expected lifetime parameter
```
Repository: go
Issue: proposal: tools for more readable stacktraces
Labels: Proposal,Proposal-Hold

As a Go beginner, I've benefitted a lot from using visual aides to assist reading dense panics and stacktraces. In particular, @maruel's [panicparse](https://github.com/maruel/panicparse) has been helpful for reading panics while I work (even though the information is basically the same). Example from the project's README:
![screenshot from 2018-06-05 11-01-43](https://user-images.githubusercontent.com/3827393/40984560-38bd8db0-68b0-11e8-8dac-8aa66233a76a.png)
![screenshot from 2018-06-05 11-01-55](https://user-images.githubusercontent.com/3827393/40984570-3c1786a0-68b0-11e8-91de-dc198ca63290.png)




This style of tool/output seems like it could be useful in the Go standard distribution; as a command line tool in the family of debugging tools, as a toggleable flag somewhere to pretty-print panics, or maybe as inspiration for some kind of dense tab-delimited panic format.
Repository: flutter
Issue: Open the persistent bottom sheet programmatically
Labels: framework,f: material design,d: api docs,P2,team-design,triaged-design

Any way to do this?
Repository: TypeScript
Issue: API: incorrect declarations in types.ts
Labels: Breaking Change,Help Wanted,Infrastructure

The `--strictNullChecks` PR changed some declarations in `types.ts` to avoid frequent assertions in the compiler's code. Unfortunately these changes make it really unsafe for API users because they no longer contain the actually nullable types: https://github.com/Microsoft/TypeScript/pull/22088#discussion_r184149465 https://github.com/Microsoft/TypeScript/pull/22088#discussion_r184155027

* `ts.Node#parent` is no longer optional (which is definitely wrong for `SourceFile`)
* `ts.Symbol#declarations` and `ts.Symbol.valueDeclaration` are no longer optional, but can still be undefined
* `ts.Type#symbol` is no longer optional, but I guess this comment is still up to date: `// Symbol associated with type (if any)`

These changes should either be reverted or replaced in the published declaration files.
/cc @andy-ms @weswigham
Repository: go
Issue: x/build/maintner: new empty milestones are not detected
Labels: Builders,NeedsInvestigation

A new milestone with no issues does not show up in the corpus.

(Also, don't mind me while I use this issue to prime the corpus.)
Repository: TypeScript
Issue: Migration refactorings after renaming from `.js` to `.ts` files
Labels: Suggestion,Needs Proposal,Awaiting More Feedback,Domain: Refactorings

At least week's design meeting, @sheetalkamat had the idea that we should consider applying refactorings for when you rename a `.js` file to a `.ts` file.

I think this is definitely worth experimenting with. From the refactoring pipeline, I could imagine things like

* moving from CommonJS to ES Modules
* lifting JSDoc annotations
* moving to classes
* inferring from usages

Then there's project configuration. I could see

* Generating a `tsconfig.json`
* Installing `@types` dependencies for packages that need them.

@mjbvz @amcasey
Repository: TypeScript
Issue: Migration suggestions after *introducing* a .ts file
Labels: Suggestion,Needs Proposal,Awaiting More Feedback

After I brought #24713 up with @chrisdias, he mentioned his thinking was more about the "I'm going to introduce a `.ts` file into a JS project" scenario. I think once you have some `.ts` files around a project, you're going to want to migrate the `.js` files eventually too, so both scenarios are valid.

But things we could do include

* Generating a `tsconfig.json`
* Installing `@types` dependencies for packages that need them.

@mjbvz @amcasey
Repository: rust
Issue: Can't implement Drop on a type with a higher ranked lifetime as a trait bound.
Labels: C-enhancement,A-trait-system,A-destructors,T-compiler,T-types,A-higher-ranked

Example:

```rust
trait Foo<'id> {}

struct Bar<T>(T) where T: for<'id> Foo<'id>;

impl<T> Drop for Bar<T> where T: for<'id> Foo<'id> {
    fn drop(&mut self) {
    }
}

fn main() {
    
}
```
We get the following error:

```backtrace
error[E0367]: The requirement `for<'id> T: Foo<'id>` is added only by the Drop impl.
 --> src/main.rs:5:1
  |
5 | / impl<T> Drop for Bar<T> where T: for<'id> Foo<'id> {
6 | |     fn drop(&mut self) {
7 | |     }
8 | | }
  | |_^
  |
note: The same requirement must be part of the struct/enum definition
 --> src/main.rs:3:1
  |
3 | struct Bar<T>(T) where T: for<'id> Foo<'id>;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```


If you take the bound away from the `Drop` implementation, you still get an error saying the bound is missing.  I don't *think* this should be unsound (you would always have to specialize on some particular lifetime to use any of the associated types, and in the use case I have in mind there's another equality constraint around that would prevent the lifetime from being used in the destructor) so I assume it's a bug, but I wasn't able to find any reported issue about this.