sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust 
Labels: A-FFI,B-RFC-approved,T-lang,B-unstable,C-tracking-issue,F-c_variadic,S-tracking-ready-to-stabilize

This is a tracking issue for the RFC "Support defining C-compatible variadic functions in Rust" (rust-lang/rfcs#2137).

**Steps:**

- [x] Implement the RFC (PR https://github.com/rust-lang/rust/pull/57760)
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation

**Unresolved questions:**

- "When implementing this feature, we will need to determine whether the compiler
can provide an appropriate lifetime that prevents a `VaList` from outliving its
corresponding variadic function."
- Continuing bikeshed on the `...` syntax.
- Ensure that even when this gets stabilized for regular functions, it is still rejected on `const fn`.
- What even is the semantics of this? What exactly is allowed and disallowed? Would be good to have a Miri implementation.
- borrowck problems: https://github.com/rust-lang/rust/issues/125431
- What exactly are the ABI requirements around variadic calls? What are the ABI compatibility rules? Do we have to be concerned about LLVM target features affecting variadic ABI?
Repository: TypeScript
Issue: TS Server: Send error event when a plugin fails to load
Labels: Bug,VS Code Tracked

**Problem**
When a TS Server plug-in is not loaded, the TS Server currently fails silently. This results in a confusing experience for users since intellisense or other expected plugin features will not work. You currently have to check the TS Server logs to see that a plugin was not loaded

**Request**
Send an error event to the client when a plugin fails to load. I imagine the interface would look like:

```ts
type PluginInitializationFailedEventName = "pluginInitializationFailed";

interface PluginInitializationFailedEvent extends Event {
    event: PluginInitializationFailedEventName;
    body: PluginInitializationFailedEventBody;
}

interface PluginInitializationFailedEventBody {
    name: string;
    project?: string; // Path to the js/tsconfig file that registered this plugin
}
````
Repository: angular
Issue: HostBinding does not support asynchronous structures (Observables and Promises)
Labels: feature,area: core,core: binding & interpolation,core: host and host bindings,cross-cutting: observables,feature: under consideration

<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ X] 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
If the component has the following line

  @HostBinding('class.async-class') private asyncClass: Observable<boolean> = new Subject<boolean>;

 the element representing the component will always have the CSS class "async-class" set

## Expected behavior

What I would expect is that the CSS class "async-class" set until and unless the Subject emits true

## Minimal reproduction of the problem with instructions

## What is the motivation / use case for changing the behavior?

As it is, it's not clear what the change-detection strategy is.  Worse, if the state of the component is maintained in a observables (otherwise an efficient strategy), the code has to manual subscribe to (and then unsubscribe from) the relevant observables and hand-update an otherwise unnecessary variables

## Environment

<pre><code>
Angular version: 4.1

Browser:
All
 
For Tooling issues:
- Node version:
- Platform:


</code></pre>
Repository: rust
Issue: overflow during drop-check on a recursive type
Labels: E-hard,C-enhancement,A-diagnostics,P-low,T-compiler

I get a pretty strange error when trying to compile this: ([playground link](https://play.rust-lang.org/?gist=5490697a4e08dd949d7a6abbc58a2bd1&version=stable))
```Rust
enum Stuff<T> {
    Value(T),
    Nested(Box<Stuff<Stuff<T>>>),
}

fn main() {
    let a = Stuff::Value(1);
}
```
output:
```
error[E0320]: overflow while adding drop-check rules for Stuff<i32>
 --> src/main.rs:7:9
  |
7 |     let a = Stuff::Value(1);
  |         ^
  |
  = note: overflowed on Stuff<Stuff<Stuff<Stuff<Stuff<Stuff< ...
```
If the type isn't used, the program compiles fine. Don't know if the type is actually representable or not, the error is misleading.
Repository: angular
Issue: ng-deep breaks CSS on components with no encapsulation
Labels: type: bug/fix,freq1: low,area: core,core: CSS encapsulation,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. -->

If you use `::ng-deep` in a component where view encapsulation is turned off, it stays there. Since this is invalid CSS, some rules break. It's silent _and_ partial failure because CSS parser simply sees `::ng-deep` as unknown selector.

## Expected behavior
<!-- Describe what the desired behavior would be. -->

`::ng-deep` should be stripped down from CSS.

## 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).
-->

https://stackblitz.com/edit/angular-ng-deep-bug?file=app%2Fapp.component.css

- If you comment out the `::ng-deep`, it works.
- If you (alternatively) comment out the settings for no encapsulation, it also works.

## What is the motivation / use case for changing the behavior?
<!-- Describe the motivation or the concrete use case. -->

This is super-annoying when used with SCSS mixins.

## Workaround

- Have a flag in SCSS mixins which conditional uses `::ng-deep` or not when needed. Developer is in charge of manual orchestration of its usage only in components where view encapsulation is enabled.
- Not using ViewEncapsulation.None and wrapping whole file in `::ng-deep`. Much easier to do with a preprocessor which allows nesting rules, though

## Environment

<pre><code>
Angular version: 4.4.3
<!-- Check whether this is still an issue in the most recent Angular version -->
Repository: go
Issue: cmd/compile: move DWARF go.info.* symbol generation out of the linker
Labels: NeedsInvestigation,compiler/runtime

The linker generates go.info.* symbols for Go types. It does so by parsing the contents of type.* symbols. It also depends on the names of these type.* symbols to successfully find other others.

All of this makes the linker quite fragile. The logic in decodesym.go has to be kept in sync with the compiler's rtype code generation, the runtime, and the reflect package. Depending on the type. symbol names interacts poorly with other things the linker wants to do, like rename symbols.

An easier place to generate these go.info.* symbols is in the compiler, right next to the code that generates the type.* symbols. The data structures are all nicely laid out in memory and don't require the hairy partial-decoding we do in the linker.

It looks like a tiny part of this has already been done, the compiler generates go.info symbols for vars. It should be possible to move the rest of the type symbols to the compiler piecemeal.

cc @heschik @dr2chase
Repository: rust
Issue: It's often not possible to implement ToOwned for user composite types
Labels: T-lang,C-feature-request

`&str` and `&[u8]` seems to work by internal magic but it is hard to implement `ToOwned` for user composite types. Consider:

```rust

struct Foo<'a> {
    foo: &'a str,
    bar: &'a str,
    foobar: &'a str
}

struct FooBuf {
    foo: String,
    bar: String,
    foobar: String
}
```

It is not possible to mark that `FooBuf` is an owned version of `Foo` as it would require implementing `Borrow` for `FooBuf`. However it is not possible to implement `fn borrow(&FooBuf) -> &Foo` as we don't have anywhere we can store `Foo`. Built-in types workaround it by handling `&str` and similar types separately from `&T` and packing the actual structure there.

(I know too little about type system to create any RFR which would fix it)
Repository: kubernetes
Issue: Also include namespace in encoding for --append-hash?
Labels: area/security,area/kubectl,priority/awaiting-more-evidence,kind/feature,sig/cli,area/secret-api,lifecycle/frozen

In a comment on [Generated Names for Generated Data](https://docs.google.com/document/d/1x1fJ3pGRx20ujR-Y89HUAw8glUL8-ygaztLkkmQeCdU/edit?ts=59d0846a) yesterday, @anguslees suggested including the name and namespace in the hashes. While the current implementation includes the name, it does not include the namespace. We should consider including the namespace as well, because it makes dictionary attacks less portable. The tradeoff is that this will be a backwards-incompatible change to kubectl (new encoding backing the hash).

/cc @anguslees @liggitt @mikedanese @bgrant0607
Repository: awesome-mac
Issue: Alphabetize and curate each subsection
Labels: organization,high-priority

I'm curious what everyone thinks--would it be worthwhile to go back and alphabetize all the entires?
Repository: TypeScript
Issue: Augmenting external module that is re-exported?
Labels: Suggestion,Needs Proposal

**TypeScript Version:** 2.5.2

**Code**

This can't be demonstrated with a simple 1-file code example so I made a trivial project to demo it:
https://github.com/chriseppstein/typescript_module_augmentation_bug

Instructions for how to run the demo and work around the issue are included on the README there.

When I include an interface in a node module's main `index.ts` file, then it is open for merging with a `declare module "my_npm_module" {}` but when I move that interface into a local submodule and export it in the main `index.ts` with a `export * from "./local_module";` then the downstream consumer breaks.

**Expected behavior:**

It seems to me that the point of being able to export from other modules is to keep downstream consumers protected from internal refactors and maintain an existing public API. So I expect to be able to augment an interface and have it behave the same whether or not it has been re-exported.

**Actual behavior:**

It looks like the interface gets forked into two definitions, the downstream module sees only the interface surface that was added and the upstream module only sees the interface surface it defined.
Repository: go
Issue: os: OpenFile issue on darwin: 100% CPU on pty master read
Labels: OS-Darwin,NeedsInvestigation

Go version: `go version go1.9 darwin/amd64`

os.OpenFile calls os.newFile with `pollable` always true. (https://github.com/golang/go/blob/9f7fd893dc455339233a8e081f5fb5e2c51e7b5d/src/os/file_unix.go#L186)

On darwin, open `/dev/ptmx` fails to set the non-blocking flag, however, the subsequent slaves work fine. (https://github.com/golang/go/blob/9f7fd893dc455339233a8e081f5fb5e2c51e7b5d/src/os/file_unix.go#L105-L119)

My guess is that having the slave in non-blocking mode is the reason why read on the master takes 100% CPU.

Details of the issue: kr/pty#52
Quickfix: kr/pty#53

Is it expected always set the poller when using os.OpenFile? Maybe we should take a look at the flags and see if there is O_NONBLOCK instead of forcing it or maybe introduce a new flag to toggle the poller?

To reproduce on darwin: https://play.golang.org/p/rq8pJGL3ey
Repository: rust
Issue: Add vi movement keys for navigating rust documentation
Labels: T-rustdoc,P-low,C-feature-request

Adding vi movements keys would make it much faster to navigate the documentation while programming, since it would avoid having to resort to the mouse or arrow keys as frequently. Moving hands around can be annoying and is the reason many optimise their setups to avoid doing so.
Repository: neovim
Issue: Timer/job callback not triggered in "normal get additional char" state
Labels: needs:design,job-control,event-loop

I've noticed a difference to Vim, when I wanted to test for handling of operator pending mode in Neomake: Neovim does not trigger the timer callback that would be required to end the mode started with `feedkeys`.

This will hang after the `feedkeys` call:

```diff
diff --git a/src/nvim/testdir/test_autocmd.vim b/src/nvim/testdir/test_autocmd.vim
index 835df42a1..d55c1bed3 100644
--- a/src/nvim/testdir/test_autocmd.vim
+++ b/src/nvim/testdir/test_autocmd.vim
@@ -47,6 +47,13 @@ if has('timers')
     au! CursorHoldI
     set updatetime&
   endfunc
+
+  func Test_exit_insert_mode_from_operator_pending()
+    let g:triggered = 0
+    call timer_start(100, 'ExitInsertMode')
+    call feedkeys("da", 'x!')
+    call assert_equal(1, g:triggered)
+  endfunc
 endif
 
 function Test_bufunload()
```

The same seems to apply to job callbacks.

This seems to be good in general (to not potentially interrupt the user), but I've wondered if this is intended, and if there is a test for this.

Would there be another way to simulate this in a test myself?
Repository: godot
Issue: Having Trouble Compiling a module .dll
Labels: bug,topic:buildsystem,confirmed,documentation

After cloning the master branch of godot yesterday (9/30/17) and building the engine for windows I tried going through the module tutorial. I was able to statically build and use the 'sumator' module (as in the tuorial) without problems, however, when trying to build a dll version of the module through VS2015, I get these error messages:

```
Severity	Code	Description	Project	File	Line	Suppression State
Error	LNK1181	cannot open input file 'sumator.windows.tools.32.windows.tools.32.lib'	godot	F:\godot\LINK	1	

Severity	Code	Description	Project	File	Line	Suppression State
Error	MSB3073	The command "echo Starting SCons && cmd /V /C set "plat=x86" ^& (if "x86"=="x64" (set "plat=x86_amd64")) ^& set "tools=yes" ^& (if "debug"=="release" (set "tools=no")) ^& call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" !plat! ^& scons platform=windows target=debug tools=!tools! -j1" exited with code 2.	godot	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets	41	
```
The only file that changed between my successful build of static module and this one was the SCsub file which was setup like the tutorial:

```
Import('env')

sources = [
    "register_types.cpp",
    "sumator.cpp"
]

module_env = env.Clone()
module_env.Append(CXXFLAGS='-fPIC')  # Needed to compile shared library
module_env['LIBS'] = []

shared_lib = module_env.SharedLibrary(target='#bin/sumator', source=sources)

shared_lib_shim = shared_lib[0].name.rsplit('.', 1)[0]
env.Append(LIBS=[shared_lib_shim])
env.Append(LIBPATH=['#bin'])
```

I know some of the tutorials are becoming dated with version 3.0, so is there something wrong with the file above or is there something else I need to do to get a .dll to show up in the bin folder?
Repository: rust
Issue: macros sometimes allow expr followed by ident
Labels: C-enhancement,P-medium,A-macros,T-lang

You can use a repetition to get around the future proofer.

```rust
macro_rules! bad {
    ($e:expr $i:ident) => {} //~ERROR
}

macro_rules! sneaky {
    ($($i:ident $e:expr)*) => {} // no error
}

fn main() {
    sneaky!(a b c d);
}
```

I feel that both of these should be accepted, or neither. BTW, I am using the equivalent of `sneaky!` in brainmunch (found this while preparing my RustFest talk).

Fixing this by disallowing both macros would require cratering.

cc @jseyfried @LeoTestard
Repository: opencv
Issue: Documentation: eliminate absolute paths
Labels: category: documentation

Observed for classes from opencv_contrib.

[Example](http://docs.opencv.org/master/d4/db2/classcv_1_1aruco_1_1Board.html):

> The documentation for this class was generated from the following file:
/build/master-contrib_docs-lin64/opencv_contrib/modules/aruco/include/opencv2/aruco.hpp
Repository: kubernetes
Issue: Cronjobs - failedJobsHistoryLimit not reaping state `Error`
Labels: kind/bug,sig/apps,area/workload-api/cronjob,area/workload-api/job,lifecycle/frozen

/kind bug
/sig apps

Cronjob limits were defined in #52390 - however it doesn't appear that `failedJobsHistoryLimit` will reap cronjob pods that end up in a state of `Error`

     kubectl get pods --show-all | grep cronjob | grep Error | wc -l
     566
Cronjob had `failedJobsHistoryLimit` set to 2

**Environment**:
- Kubernetes version (use `kubectl version`):

Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6", GitCommit:"4bc5e7f9a6c25dc4c03d4d656f2cefd21540e28c", GitTreeState:"clean", BuildDate:"2017-09-15T08:51:09Z", GoVersion:"go1.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"d6f433224538d4f9ca2f7ae19b252e6fcb66a3ae", GitTreeState:"clean", BuildDate:"2017-05-19T18:33:17Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

- OS (e.g. from /etc/os-release):

Centos7.3

- Kernel (e.g. `uname -a`):

4.4.83-1.el7.elrepo.x86_64 #1 SMP Thu Aug 17 09:03:51 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
Repository: TypeScript
Issue: Expose configuration hook for custom module resolution
Labels: Suggestion,In Discussion

Following on from #6012 and #5039, it'd be nice to have the ability to add TypeScript to projects with heterogeneous module resolution/packaging systems and have typechecking work. 

The `paths` and `baseUrl` configuration options get us a long way, but they don't deal well with module loaders that are less widely used, frequently changing, or that allow for complex module resolution rules. Letting the user entirely outsource all module resolution concerns using the configuration would allow type checking to work regardless of the user's preference of npm, bower, requirejs, browserify, jspm, webpack, etc. 

A simple approach might be to have a `tsconfig` option for a parametrized command line invocation (similar to npm scripts) that is able to resolve modules. Each package manager can distribute a tool that implements module resolution according to its own needs, which the users can install and point to in their `tsconfig.json`.

Exactly how extensive the API needs to be is up for debate. It could be something as simple as a function that maps requested module names to file system paths, or a more abstract implementation of something like `System` from [here](https://github.com/Microsoft/TypeScript/blob/51e9aef2a7362cd82fce55901d0de82c521a8a89/src/compiler/sys.ts#L33), which could open up more interesting use cases (e.g. "virtual" modules built using code generation, or F# style [type providers](https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/type-providers/)).
Repository: opencv
Issue: solvePnPRansac does not work on some doc stated input shapes (Python bindings)
Labels: category: documentation

##### System information (version)

- OpenCV => 3.3.0 and 3.1.0
- Operating System / Platform => macOS
- Compiler => Python bindings

The current `solvePnPRansac()` documentation states that the function works on `Nx3/3xN` single-channel `src` input and `Nx2/2xN` single-channel `dst` input (as well as `Nx1x3` and `Nx1x2`multi-channel inputs) but the function only works on the multi-channel inputs in Python. `solvePnP()` seems to work with both types, however.

See the [Stack Overflow question](https://stackoverflow.com/questions/46534126/solvepnp-object-points-image-points-shape/46538877?noredirect=1#comment80032402_46538877) that brought this up. Note that issue #6304 brought this up but is now closed with no PR attached to it as far as I can see.

Either a change to the Python bindings would fix the issue, or an update to the documentation.
Repository: rust
Issue: Avoid volatile loads to preserve the gdb pretty printer section
Labels: A-linkage,A-debuginfo,C-enhancement,P-medium,T-compiler,WG-embedded

Right now when you compile a program with debuginfo on Linux we'll emit a volatile load of a gdb pretty printer section which is intended on ensuring that the linker forces a section in the executable. 

Apparently, though, this has caused some problems for embedded work (cc @japaric) where the section doesn't always make it to the final image that's flashed to devices, meaning that this stray load near the beginning of the program can sometimes cause problems.

We should look into other solutions to force the linker to keep this symbol I think. Right now we're passing a version script on Linux to preserve symbols in cdylibs and I think the same would work for this? Worth trying out!

cc @michaelwoerister
Repository: TypeScript
Issue: Don't extract constant to an unreachable location
Labels: Bug,Domain: Refactorings

```ts
function Outer() {
    return 1;
    function Inner() {
        1; // Extract this
    }
}
```

Right now, the new local is inserted after the `return`, where it is unreachable.
Repository: TypeScript
Issue: Allow Extract Constant in expression-bodied arrow functions
Labels: Suggestion,Domain: Refactorings,Experience Enhancement

```ts
const f = () => 1 + [#|(2 + 3)|] + 4;
```

Expected:
```ts
const f = () => {
    const newLocal = (2 + 3);
    return 1 + newLocal + 4;
};
```

We can detect this scenario, but `ChangeTracker` doesn't support overlapping transformations (i.e. substituting `newLocal` into the expression and then putting the result into a return statement).
Repository: react
Issue: Performance enhancements in niche situations
Labels: Type: Discussion,Component: Reconciler

I hit on a couple things that were a bit surprising to me... not sure what I'm really asking here, other than if these things are documented somewhere. Also kinda just going with the flow where this seems to be the place to raise generic "issues" even if they're not bugs :)

1. keys can make things slower

I had a bunch of items, and the only thing that changed was their x/y positions. adding a key with index made rendering slower. It's possible this is short-sighted though since it could very well change once that "layer" has more items changing above/below it, but I found it interesting.

2. rendering null makes a _huge_ difference

I had two test cases - a full graphics pipeline vs. an essentially empty POJO renderer. The difference in speed didn't matter about the data or graphics, but rather about what was returned in the components `render()`. For DOM this doesn't work of course - but for custom renderers, when it's known that a certain type of element will be an edge node - doing the side effects in render() (or some other lifecycle) and then returning `null` is _significantly_ faster than even a straight functional component that returns a simple element (which does the same side effects). This makes sense, since react then has less branches to consider (even if those branches point to nothing other than simple objects).