sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: reflect/v2: remove Value.Bytes
Labels: v2,Proposal

**Background**

As noted in https://github.com/golang/go/issues/24746#issuecomment-383720056, `(reflect.Value).Bytes` is the only `reflect.Value` methods that return mutable values without enforcing `CanSet` or `CanInterface`.

That makes dangerous mutations through `[]byte` (and slices of defined types with `byte` as the underlying type) more difficult to detect, since they do not involve `unsafe` or `syscall` in the way that other dangerous mutations must.

This is a proposal to close that mutability loophole and make the handling of `byte` slice types more consistent with other slices.

**Proposal**

This proposal consists of two parts:

1. Remove `Value.Bytes`, making it accessible only to Go 1 code.
2. Relax `reflect.Copy`, `reflect.Append`, and `reflect.AppendSlice` to allow the source argument (but not the destination) to be obtained through unexported fields, *provided that* the element type of the slice does not contain any pointers or interfaces.
   * Today, those functions panic if any argument was obtained through unexported fields.

Users could replace a call to `Bytes` on an exported field of known element type with a call to `Interface` and a type-assertion (https://play.golang.org/p/9LJIDW7ftZx).
   * If #19778 is accepted, they could do the same for unknown element types by adding a `Convert` call (https://play.golang.org/p/gMGApEvicM-).

To examine slices obtained via unexported fields (and slices of defined types with `byte` or as their underlying type), users could employ any of four strategies:
   * Copy the contents of the slice to a new slice of the same type (https://play.golang.org/p/R5gEasA35hS).
   * Copy the contents of the slice to an immutable string (https://play.golang.org/p/rrry8qv2Nxg).
   * Access the elements of the slice individually (https://play.golang.org/p/1xcsFOHwaJB).
   * Use `unsafe` to alias the contents of the slice to a slice variable (https://play.golang.org/p/LZTiDZz1FAl).

Note that the latter three are already possible today: part (2) of this proposal only affects the clarity of the code, not what is possible to express.

**Alternatives**

We could keep the `Bytes` method, but make it panic if `CanInterface` returns false.

* That would allow more existing code to continue to compile, but at the risk of introducing a run-time error. I prefer to make it a complie-time error in order to prompt the user to consider whether to introduce a run-time check, make a copy, or use an `unsafe` operation.

We could go even further and remove `SetBytes`, since it is redundant with `Copy`.

* That would make the treatment of `[]byte` more like every other slice type.
* Since that method doesn't introduce any loopholes in the usual mutability rules, removing it does not seem worth the code churn.

If we had read-only slices (#22876 and associated issues), we could make `Bytes` return a read-only slice.

* In contrast, this proposal does not rely on any new language features.
Repository: flutter
Issue: Flutter's AppLifecycleState does not match Android/iOS's Activity/UIViewController lifecycle states
Labels: c: new feature,platform-android,platform-ios,framework,engine,customer: alibaba,customer: money (g3),P3,team-engine,triaged-engine

Internal: b/146299589

Hi,
We want to get notified when UIViewController/Activity's lifecycle method invoked, such as `viewWillAppear`, `viewDidAppear` in iOS, or `onPause()`, `onResume()` in Android, so that we are able to add some features there.
For example, we have to record user track data at flutter side just at the time of method viewWillAppear is called.

However, we found that Flutter returns the same state when UIViewController/Activity's different lifecycle method invoked, for example:

in iOS:
- (void)viewWillAppear:(BOOL)animated 
- (void)viewWillDisappear:(BOOL)animated
(source code in file FlutterViewController.mm)
they both return the same state `AppLifecycleState.inactive` so we can not determine which method was called.

And in android we found the same situation(in `FlutterView.java`):
```dart
public void onStart() {
    this.mFlutterLifecycleChannel.send("AppLifecycleState.inactive");
}

public void onPause() {
    this.mFlutterLifecycleChannel.send("AppLifecycleState.inactive");
}
```

We can not determine wether `onStart()` or `onPause()` was called when we received state `AppLifecycleState.inactive`.

So could you please add more states to distinguish these methods?
Repository: go
Issue: x/mobile: minimal support of obj C generics
Labels: mobile

Please answer these questions before submitting your issue. Thanks!


### 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/tadovas/work/go/openvpnv3-go-bindings"
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/_j/73ymsvw56v989xyfwn6q18_m0000gn/T/go-build533420179=/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?
binding ObjC method with accept or return generalized types like NSArray<NEPacket *>

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.


### What did you expect to see?
succesful bind

### What did you see instead?
Method not found, which is expected.

This issue is more like feature request/discussion. Are there any plans to provide at least minimal support of generics in Obj C? There are some very nice iOS apis which expect NSArrays of concrete objects and it's sad, that we cannot bind them?
I would like to try to create a POC myself, so maybe someone else has done some investigation, have some thoughts etc?

As there is no generics concept in golang, so I see a biggest problem here is how to distinquish lets say NSArray<NEPacket *> from NSArray<NSDate *>

Current import which looks like this "Objc/Foundation/NSArray" generates golang interface NSArray with methods which are not typed (like Count) which is fine. So perhaps we can do something like
"ObjC/Foundation/NEPacket_NSArray" to generate distinct go interfaces with methods which accept or return NEPacket type parameters? I know it looks ugly, but I didn't find out any other options how to encode type name of array into interface as only to as part of interface name.

Any help, ideas, suggestions would be much appreciated
Repository: opencv
Issue: Redesign of the ElemType register for OpenCV v4
Labels: category: core,RFC

The current magic register is designed as:
```
FEDCBA987654321
---------------
            ddd 	depth
   nnnnnnnnn    	channels - 1
  r             	reserved (unset)
 c              	continuous flag
s               	submatrix flag
```
However, it is slightly space inefficient, so allow me to redesign it as:
```
FEDCBA987654321
---------------
          ddddd 	depth
      nnnn      	channels base - 1
   mmm          	channels exponent
  r             	reserved (unset)
 c              	continuous flag
s               	submatrix flag
```

### Depth
32 different depth types are allowed, and the order can be recovered again (given that user code will not be broken - e.g. by choosing new names and mapping old ones). Furthermore, we allow some discontinuity for future extensions

### Channels
By utilizing `cn = (nnnn + 1) << mmm`, we can have the following channels:
1-16, 18, 20, 22, 24, 26, 28, 30, 32, 36, 40, 44, 48, 52, 56, 60, 64, 72, 80, 88, 96, 104, 112, 120, 128, 144, 160, 176, 192, 208, 224, 240, 256, 288, 320, 352, 384, 416, 448, 480, 512, 576, 640, 704, 768, 832, 896, 960, 1024, 1152, 1280, 1408, 1536, 1664, 1792, 1920, 2048
which I believe is a reasonable way of division

There are some channels that can be formed in multi-ways, which are:
- 2 ways: 2, 6, 10, 14, 20, 28, 40, 56, 80, 112, 160, 224, 320, 448, 640, 768, 896, 1024
- 3 ways: 4, 12, 24, 48, 96, 192, 384, 512
- 4 ways: 8, 256
- 5 ways: 16, 32, 64, 128
These are in some sense a waste of valuable encoding space, but since we want to have the first 1-16 all available channels, it cannot be helped!

As for computing the channel base and exponent from the number of channels (e.g. user input), it can be done efficiently using:
```
mmm = (0x45263107U >> ((((cn & -cn) * 0x17) >> 2) & 0x1C)) & 7
nnnn = (cn >> mmm) - 1
```
where channel is deemed invalid if `mmm  >= 8 || nnnn >= 16`.
If user choose unsupported number of channels, the next acceptable `cn` can be easily obtained by iteratively right-shifting the invalid `nnnn` and incrementing the corresponding `mmm` until a valid `nnnn` appears, then suggested to the user.

Update: using the following is guaranteed to allocate at least `cn` channels without any need for iterations:
```
mmm = floor(log2((cn - 1) >> 3))
nnnn = ((cn - 1) >> mmm)
```

### Backwards compatibility
Guaranteed via fail-over! If parser fails to interpret a sequence, it should try the legacy format before reporting an error.
Repository: go
Issue: encoding/json: incorrect usage of sync.Pool
Labels: Performance,NeedsFix

https://golang.org/cl/84897 introduces a denial-of-service attack on `json.Marshal` via a live-lock situation with `sync.Pool`.

Consider [this snippet](https://play.golang.org/p/htet7ILi9oJ):
```go
type CustomMarshaler int

func (c CustomMarshaler) MarshalJSON() ([]byte, error) {
	time.Sleep(500 * time.Millisecond) // simulate processing time
	b := make([]byte, int(c))
	b[0] = '"'
	for i := 1; i < len(b)-1; i++ {
		b[i] = 'a'
	}
	b[len(b)-1] = '"'
	return b, nil
}

func main() {
	processRequest := func(size int) {
		json.Marshal(CustomMarshaler(size))
		time.Sleep(1 * time.Millisecond) // simulate idle time
	}

	// Simulate a steady stream of infrequent large requests.
	go func() {
		for {
			processRequest(1 << 28) // 256MiB
		}
	}()

	// Simulate a storm of small requests.
	for i := 0; i < 1000; i++ {
		go func() {
			for {
				processRequest(1 << 10) // 1KiB
			}
		}()
	}

	// Continually run a GC and track the allocated bytes.
	var stats runtime.MemStats
	for i := 0; ; i++ {
		runtime.ReadMemStats(&stats)
		fmt.Printf("Cycle %d: %dB\n", i, stats.Alloc)
		time.Sleep(time.Second)
		runtime.GC()
	}
}
```

This is a variation of https://github.com/golang/go/issues/23199#issuecomment-353193866 of a situation suggested by @bcmills.

Essentially, we have a 1-to-1000 ratio of a routines that either use 1KiB or 256MiB, respectively. The occasional insertion of a 256MiB buffer into the `sync.Pool` gets continually held by the 1KiB routines. On my machine, after 300 GC cycles, the above program occupies 6GiB of my heap, when I expect it to be 256MiB in the worst-case.

\cc @jnjackins @bradfitz
Repository: flutter
Issue: Text selection vertical extent should be defined per line (not per glyph)
Labels: a: text input,framework,engine,a: fidelity,a: quality,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-engine,triaged-engine

As [reported by @_mono on Twitter]( https://twitter.com/_mono/status/1023733699614060545), the Flutter text selection highlight rect should be computed at the line level as opposed to per glyph. To see this effect, paste the sequence `(　´･‿･｀)` into a Flutter text field and select it.

Example images below:

Flutter selection:
![flutter](https://user-images.githubusercontent.com/351029/45705368-424c8180-bb2e-11e8-9502-3fa404afc066.png)

iOS OEM selection:
![ios](https://user-images.githubusercontent.com/351029/45705373-45e00880-bb2e-11e8-930a-156f02e88a15.png)

Android OEM selection:
![android](https://user-images.githubusercontent.com/351029/45706301-bdaf3280-bb30-11e8-9ee6-07384c82395c.png)
Repository: kubernetes
Issue: Setup call to volume plugins should include user and plugin provided mount options
Labels: sig/storage,lifecycle/frozen

When we create bind mounts in `Setup` function - we should also include user provided mount options coming from PV or StorageClass. 

This will ensure that bind and remount operations have access to full mount options rather than a partial list.

related to https://github.com/kubernetes/kubernetes/pull/68626#discussion_r218534387

/sig storage

/assign
Repository: go
Issue: x/tools/cmd/present: add support for sub bullets
Labels: NeedsDecision,FeatureRequest,Tools

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
go version go1.11 linux/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jerrin/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jerrin/gocode"
GOPROXY=""
GORACE=""
GOROOT="/home/jerrin/go-go1.11"
GOTMPDIR=""
GOTOOLDIR="/home/jerrin/go-go1.11/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build014264932=/tmp/go-build -gno-record-gcc-switches"

Go present tool does not currently support sub bullets. This proposal is to add a new syntax to support sub bullets. Lines prefixed with '-- ' will be displayed as a sub bullet.

For example, the following code block produces the slide shown below.

```
* Title

- bullet 1
-- sub bullet 1.1
- bullet 2
-- sub bullet 2.1
-- sub bullet 2.2

```
![screenshot](https://user-images.githubusercontent.com/883541/45707665-6743f300-bb34-11e8-827a-155064a4dbb2.png)
Repository: TypeScript
Issue: Renaming a module with a default export should rename default imports which match the filename
Labels: Suggestion,Awaiting More Feedback

## Search Terms

rename default import 

## Suggestion

I noticed that recently it became possible to auto-import default exports of modules:

```ts
// foo.ts

export default 42;
```

```ts
// bar.ts

const x = 3 + foo
//               ^ control-space here will offer to `import foo from './foo'`
```

This is great and finally makes default exports worth using in TypeScript, so thank you!

Also recently, TypeScript got native support for refactoring names of modules. Now, what would be really awesome is if the rename refactor for modules could take into account default exports, so that when we rename `foo.ts` to `baz.ts` this would happen in `bar.ts`:

```diff
-import foo from './foo';
+import baz from './baz';

-const x = 3 + foo;
+const x = 3 + baz;
```

Basically, try to preserve the cases where the name given to a default import matches that of the module being imported. For cases where a default export is imported with a name not matching the module, it would leave it alone:

```diff
-import customName from './foo';
+import customName from './baz';

const x = 3 + customName;
```

This would really make default exports exceptionally useful in TypeScript, because it would potentially reduce by half the number of refactoring gestures needed to rename a set of terms which are 1-to-1 with modules.

## Checklist

My suggestion meets these guidelines:
* [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: rust
Issue: Same trait in dyn / impl trait should give a warning
Labels: A-lints,T-lang,C-bug

Having the same trait specified multiple time in the list of traits a function returns, does not give a warning:

```Rust

fn example() -> impl Copy + Copy + Copy {  }

fn main() {

}
```

It should perhaps give a warning like:
```
warning: found multiple identical traits: `fn example() -> impl Copy + Copy + Copy`
```
Repository: rust
Issue: return impl Trait should only permit unique lifetimes
Labels: C-enhancement,A-lints,A-diagnostics,T-lang,T-compiler

Providing more than 1 exactly the same lifetime to a return impl Trait, does not give a warning, nor does it give a compiler error:

```Rust
fn example() -> impl Send + 'static + 'static { }

fn main() {
    example();
}
```

The box version does error:
```Rust
fn dyn_example() -> Box<dyn Send + 'static + 'static> {
    Box::new(())
}

fn main() {
    dyn_example();
}
```
```
Compiling playground v0.0.1 (/playground)
error[E0226]: only a single explicit lifetime bound is permitted
 --> src/main.rs:1:46
  |
1 | fn dyn_example() -> Box<dyn Send + 'static + 'static> {
  |                                              ^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0226`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.
```
Repository: kubernetes
Issue: Support an image pull credential flow built on bound service account tokens
Labels: priority/backlog,sig/node,kind/feature,sig/auth,lifecycle/frozen

ImagePullSecret is a mechanism to provide kubelet with credentials to pull images for pods running as a specific service account. This provides segmentation of image access between tenants of a cluster. Now that Kubernetes has a more featureful service acccount token issuer, we can leverage bound service account tokens rather than static secrets to authenticate kubelet to docker registries.

Strawman flow:
1. Pod running as service account `foo` with image `bar.io/baz` is bound to a node
1. Kubelet on node requests a service account token for service account `foo` with audience `bar.io`
1. (Optional) Kubelet does an [OAuth token exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-15) which is a general approach to what we [already do in CRI](https://github.com/kubernetes/kubernetes/blob/76518f154b717c977b1bfb506aeb7cd4b176fde0/pkg/kubelet/apis/cri/runtime/v1alpha2/api.proto#L1045)
1. Kubelet passes resulting token to as a `registry_token` (which is just an access token of type Bearer) to the CRI.

@smarterclayton talked about this in the pod-identity-wg meeting a while ago.

@kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests 

/kind feature
/sig auth
Repository: go
Issue: go2draft-error-handling-overview: Double io.Closer calls
Labels: NeedsInvestigation

The examples in https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md arrange for w.Close() to be called more than once. https://golang.org/pkg/io/#Closer says
_The behavior of Close after the first call is undefined. Specific implementations may document their own behavior_.

The text before the code, and the problem:

    On the other hand, the equivalent actual Go code today would be
    Defers w.Close() and then calls w.Close().

    For example, the corrected code above shortens to
    checks w.Close() but also does that in an above handler.

It's OK for the double-Close to be one of the faults with the 'before', but it would be nice if the improved 'after' version didn't also do it. The _more robust version with more helpful errors would be_ one in between doesn't.

CC: @rsc
Repository: TypeScript
Issue: Visual Studio Code intellisense on React component using typescript with union types
Labels: Bug

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**3.0.3**  also checked on 3.1.0-dev.20180919 

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
typescript visual studio code union types intellisense

**Code**

```ts
interface IA { name: string }
interface IB extends IA { type: 'B'; myProp: string }
interface IC extends IA { type: 'C'; secondProp: string }

const MyComponent: React.SFC<IB | IC> = props => {
  return <span>test</span>
  }

class App extends React.Component {
  public render() {
    return (
      <MyComponent type='B' />
    );
  }
}
```

**Expected behavior:**
When rendering MyComponent if i set <MyComponent type='B' /> then i should get an autocomplete option for 'myProp'.

**Actual behavior:**

![typescript_issue](https://user-images.githubusercontent.com/1786291/45746280-c4a27780-bbfa-11e8-9823-37690f2fd620.gif)

no intellisense shown for 'myProp'. If i don't give a value for 'myProp' the compiler does error, but no intellisense autocomplete option is ever shown.

**Related Issues:** 
i posted the issue generally on [stackoverflow ](https://stackoverflow.com/questions/52386145/visual-studio-code-intellisense-on-react-component-using-typescript-with-union-t/52396229#52396229)and a response was that it may be worth logging here and it may be related to bug: [TypeScript issue #26004](https://github.com/Microsoft/TypeScript/issues/26004)
Repository: rust
Issue: Check if we can get away with making `fn()` conflict with `&T`
Labels: T-lang

There's the idea that the `fn(...) -> R` types should be unsized types (like `extern type`) and function pointers should be proper pointers (e.g. `&'a fn()`). On its face this appears backwards incompatible in ways editions can't paper over, e.g. if we desugar `fn()` to `&'static fn()` in 2015 these two impls would suddenly start conflicting:

```rust
trait Foo {}
impl<'a, T: ?Sized> Foo for &'a T {}
impl Foo for fn() {}
```

@eddyb wants to try implementing it quickly and hackily it to see what breaks:

> I think we can do this in type unification, and treat `fn()` like `&SomeLibCoreLangItem` there, without changing `fn()` itself
Repository: rust
Issue: Confusing `multiple matching crates` error caused by 2018 edition
Labels: C-enhancement,A-diagnostics,T-compiler

I tried to `use rand` when I hadn't added it to `Cargo.toml`.

```
error[E0464]: multiple matching crates for `rand`
 --> src\worker_utils\polling_worker_pool.rs:7:5
  |
7 | use rand::{self, Rng};
  |     ^^^^
  |
  = note: candidates:
          crate `rand`: \\?\C:\Users\diggs\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librand-8a8c92c0d9bc43b9.rlib
          crate `rand`: \\?\C:\Users\diggs\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librand-74b492d2b987a1e5.rlib

error[E0463]: can't find crate for `rand`
 --> src\worker_utils\polling_worker_pool.rs:7:5
  |
7 | use rand::{self, Rng};
  |     ^^^^ can't find crate
```

The first error is just misleading.