sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Unable to run sandboxed process when run as elevated under applocker
Labels: bug,windows,webview,workbench-run-as-admin,chromium,sandbox

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
- VS Code Version: 1.56.0-insider (user setup)
- OS Version: Windows_NT x64 10.0.19042
- Electron: 12.0.4
- Chrome: 89.0.4389.114
- Node.js: 14.16.0
- V8: 8.9.255.24-electron.0

Steps to Reproduce:

1. Open a markdown file, and click the "Open preview to the side" button
2. The preview window is blank, and an error notification pops up in the bottom right:
> Error loading webview: Error: Could not register service workers: TypeError: Failed to register a ServiceWorker for scope ('vscode-webview://36f8a74c-37c6-4d60-9d4c-87414f69ebcc/') with script ('vscode-webview://36f8a74c-37c6-4d60-9d4c-87414f69ebcc/service-worker.js?platform=electron&id=36f8a74c-37c6-4d60-9d4c-87414f69ebcc&vscode-resource-origin=https%3A%2F%2F36f8a74c-37c6-4d60-9d4c-87414f69ebcc.vscode-webview-test.com'): ServiceWorker cannot be started.

The same thing happens for other WebViews, like opening an extension from the Extensions sidebar, or using the "Issue Reporter".

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Repository: material-ui
Issue: [Slider] Cannot drag slider to end when 100% width and window is full screen
Labels: waiting for 👍,component: slider

<!-- Provide a general summary of the issue in the Title above -->

<!-- Checked checkbox should look like this: [x] -->

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

<!-- Describe what happens instead of the expected behavior. -->

When Chrome has been full screened on Mac OS, the slider is 100% width, and the slider is dragged all the way to the right of the screen it does not reach the "max" value. The native HTML slider works as expected.

I have seen this in Chrome on Mac OSX.

## Expected Behavior 🤔

It should be able to be dragged to the max value as the native HTML slider works.

## Steps to Reproduce 🕹

Here is a codesandbox that demonstrates the issue and shows the difference in behavior with the HTML slider:

https://codesandbox.io/s/nostalgic-elgamal-6nm4m?file=/src/App.js

Steps:

1. Open the code sandbox
2. Click the "open in new window" button to show the demo in a new window. 
3. Click the the green "full screen" button on the top left of the window (in Mac OSX)
4. Click and drag the MUI slider all the way to the right of the screen. Notice it does not reach "100.00" while doing the same with the native HTML slider does.

## Context 🔦

Slider is being used to scrub charting / telemetry visualization timeline and when the app is full screened the slider cannot be scrubbed to the end of the data stream.

## Your Environment 🌎

**Browser**

Google Chrome Version 90.0.4430.85 (Official Build) (x86_64)

**Material UI Version**

@material-ui/core v4.11.4

**Hardware**

2017 Mac Laptop

OSX 10.15.7
Repository: TypeScript
Issue: Support import types in JSDoc links
Labels: Suggestion,Experience Enhancement

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

- JSDoc
- link / see

### 🕗 Version & Regression Information

4.3.0-dev.20210503


### 💻 Code

For some JavaScript:

```js
// foo.js

export class Foo {}
```

```js
// index.js

/**
 * {@link import('./foo').Foo Foo}
 * 
 * @param {import('./foo').Foo} foo 
 */
function withFoo(foo) { }
```

### 🙁 Actual behavior

The parameter type is resolved but the `@link` is not


### 🙂 Expected behavior

Both links should be resolved
Repository: TypeScript
Issue: typesVersions should support aliasing specific files (or document this will not be supported)
Labels: Needs Investigation,Rescheduled

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

typesVersions, backwards compatibility, path alias

## ✅ Viability 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. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

Enable aliasing a single file with Advanced Types or document this isn't possible. The language on the docs currently says: 

> File redirects
> 
> When you want to only change the resolution for a single file at a time, you can tell TypeScript the file to resolve differently by passing in the exact filenames:

However, passing _any_ exact filename doesn't seem to work. For example, if `dist/index.d.ts` imports `dist/helpers/advanced-types.d.ts`, which should fall back to `helpers/legacy-types.d.ts` for older TS versions, this doesn't seem to work. I've tried:

- `dist/helpers/advanced-types.d.ts`
- `dist/helpers/advanced-types`
- `helpers/advanced-types.d.ts`
- `helpers/advanced-types`
- `*/advanced-types.d.ts`
- `*/advanced-types`
- `advanced-types.d.ts`
- `advanced-types`

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

Using something like template literals, I would like to create a single file that contains these, with some fallbacks with legacy code for TypeScript users who do not have the ability to update right away. 

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

The only workaround I've found is to create another package which exports a different index.d.ts to be used with the main project. There would be too many different uses of the types exported to re-create the entire project with the different imports.
Repository: go
Issue: x/pkgsite: make import paths in Examples into links
Labels: NeedsInvestigation,pkgsite

<!--
Please answer these questions before submitting your issue. Thanks!
-->
 
### What is the URL of the page with the issue?
 
 https://pkg.go.dev/gonum.org/v1/gonum/graph/encoding/dot
 
### What is your user agent?
 
<!-- 
You can find your user agent here:
https://www.whatismybrowser.com/detect/what-is-my-user-agent
-->
 
 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
 
### Screenshot
 
<!--
Please paste a screenshot of the page.
-->
 
 
![image](https://user-images.githubusercontent.com/9734877/117075201-6fabc500-ad02-11eb-811c-db438b0ac627.png)

 
### What did you do?
 
<!--
If possible, provide a recipe for reproducing the error.
-->
 
 I clicked "gonum.org/v1/gonum/graph/simple"
 
### What did you expect to see?
 
Browser opens https://pkg.go.dev/gonum.org/v1/gonum/graph/simple
 
### What did you see instead?

Nothing. It's plain text. 😞
Repository: flutter
Issue: Allow add-to-app Flutter.xcframework to be consumed as a Swift Package
Labels: c: new feature,platform-ios,tool,a: existing-apps,t: xcode,c: proposal,P2,team-ios,triaged-ios

Add `flutter build ios-framework --swift-package` flag to generate a Swift package manifest for the Flutter.xcframework to be consumed by the host app without the Flutter SDK installed, as an alternative to CocoaPods.

Would look something like:
```swift
// swift-tools-version:5.3

import PackageDescription

let package = Package(
  name: "Flutter",
  platforms: [
    .iOS(.v9)
  ],
  products: [
    .library(
      name: "Flutter",
      targets: ["Flutter"]),
  ],
  targets: [
    .binaryTarget(
      name: "Flutter",
      url: "https://storage.googleapis.com/flutter_infra_release/flutter/5d8bf811b3072390933d69f3e289a4bb673636c4/ios-release/artifacts.zip",
      checksum: "746f02ffe75c030e98d028be45917da0bd04327eef6207e48e008ea5933861e9"
  ]
)
```
This requires that the Swift checksum be calculated for the iOS engine artifacts zip containing the XCFramework
https://developer.apple.com/documentation/swift_packages/distributing_binary_frameworks_as_swift_packages#3578966

Note `swift package compute-checksum` annoyingly requires a `Package.swift` file in the working directory, even if it's empty.

```
$ touch Package.swift
$ swift package compute-checksum artifacts.zip
746f02ffe75c030e98d028be45917da0bd04327eef6207e48e008ea5933861e9
```

This could be calculated as part of downloading the artifacts locally on the developer's machine before the zip is deleted, or it could be done on the engine publishing side.
Repository: flutter
Issue: Document Headless mode Rendering setup
Labels: tool,d: wiki,P3,team-tool,triaged-tool

## Current docs

Going through the [wiki on Flutter's modes](https://github.com/flutter/flutter/wiki/Flutter's-modes), you will find a mention of **headless mode**:

>Headless test mode on desktop: Same as debug mode except headless and for desktop platforms. Used by flutter test. Built with sky/tools/gn.

This is also mentioned [in the docs](https://flutter.dev/docs/testing/build-modes).  
From what I can tell, this is generally lacking documentation, but I think we can deduce from this that headless mode can only be accessed using `flutter test`.

### Debug/Release/Profile Rendering setup

`flutter help run` will spit out the following information:

```
    --enable-software-rendering                   Enable rendering using the
                                                  Skia software backend. This is
                                                  useful when testing Flutter on
                                                  emulators. By default, Flutter
                                                  will attempt to either use
                                                  OpenGL or Vulkan and fall back
                                                  to software when neither is
                                                  available.
    --skia-deterministic-rendering                When combined with
                                                  "--enable-software-rendering",
                                                  this should provide completely
                                                  deterministic (i.e.
                                                  reproducible) Skia rendering.
                                                  This is useful for testing
                                                  purposes (e.g. when comparing
                                                  screenshots).
```

This suggests that there are **three** rendering modes in Flutter:

1. Non-deterministic GPU rendering (using OpenGL or Vulkan).
2. Non-deterministic software rendering
3. Deterministic software rendering

## What is missing?

Which of these three modes is `flutter test` using?

This is important to know when working with the headless mode to either write **Goldens** tests or make use of this headless mode for other purposes (exporting animations e.g.).  
Therefore, this should be documented.

---

Note that `flutter test` does not accept any of the rendering flags mentioned above. It would also be good to have documented why that is.
Repository: rust
Issue: Rust is inconsistently re-exporting rlib symbols from a binary
Labels: A-linkage,A-codegen,T-compiler,C-bug

I noticed some strange behavior while trying to optimize file size. Consider this cargo setup:

Cargo.toml:
```
[package]
name = "foo"
version = "0.1.0"
authors = ["Erick Tryzelaar <etryzelaar@google.com>"]
edition = "2018"
```

src/lib.rs:
```rust
#[no_mangle]
pub fn big1() {}

#[no_mangle]
pub fn big2() {}

#[no_mangle]
pub fn big3() {}
```

examples/big1.rs:
```rust
fn main() {
    foo::big1();
}
```

examples/big2.rs:
```
fn main() {
    foo::big2();
}
```

examples/big3.rs:
```
fn main() {
    foo::big3();
}
```


On my mac using both `rustc 1.51.0 (2fd73fabe 2021-03-23)` and `rustc 1.53.0-nightly (42816d61e 2021-04-24)`, I found that the rust binary for the two examples will be different:

```
% rustup run stable cargo build --release --all-targets && ls -l target/release/examples/{big1,big2,big3}
-rwxr-xr-x  1 etryzelaar  primarygroup  432536 May  4 17:02 target/release/examples/big1
-rwxr-xr-x  1 etryzelaar  primarygroup  432576 May  4 17:02 target/release/examples/big2
-rwxr-xr-x  1 etryzelaar  primarygroup  432608 May  4 17:02 target/release/examples/big3
```

Those handful of bytes of difference appears to be because for some reason, `big2` binary is re-exporting the `_big2` function, but the `big1` binary does not re-export `_big1`:

```
% diff <(nm -g target/release/examples/big1) <(nm -g target/release/examples/big2)
192a193
> 00000001000037e0 T _big2
200c201
< 0000000100003740 T _main
---
> 0000000100003720 T _main

% diff <(nm -g target/release/examples/big1) <(nm -g target/release/examples/big3)
192a193,194
> 00000001000037e0 T _big2
> 00000001000037e0 T _big3
200c202
< 0000000100003740 T _main
---
> 0000000100003770 T _main
```

Ideally we'd optimize away all these symbols to shave off some bytes, but if that's difficult, we probably should at least make things consistent.
Repository: rust
Issue: Surprising missing stability attribute error
Labels: A-macros,A-stability,C-bug

On master (as of 716394d6581b60c75cfdd88b8e5b876f2db88b62) I can currently successfully compile stage1 std by running `./x.py build --stage 1`.

Before https://github.com/rust-lang/rust/pull/81837 merged, applying the following patch would still allow me to successfully compile stage1 std:

```diff
diff --git a/compiler/rustc_builtin_macros/src/lib.rs b/compiler/rustc_builtin_macros/src/lib.rs
index d7926ed0e0b..95f398aee1e 100644
--- a/compiler/rustc_builtin_macros/src/lib.rs
+++ b/compiler/rustc_builtin_macros/src/lib.rs
@@ -101,6 +101,7 @@ pub fn register_builtin_macros(resolver: &mut dyn ResolverExpand) {
 
     register_derive! {
         Clone: clone::expand_deriving_clone,
+        DWH: clone::expand_deriving_clone,
         Copy: bounds::expand_deriving_copy,
         Debug: debug::expand_deriving_debug,
         Default: default::expand_deriving_default,
diff --git a/compiler/rustc_span/src/symbol.rs b/compiler/rustc_span/src/symbol.rs
index b2dac10c83f..47cf56cf7af 100644
--- a/compiler/rustc_span/src/symbol.rs
+++ b/compiler/rustc_span/src/symbol.rs
@@ -136,6 +136,7 @@
         Clone,
         Copy,
         Count,
+        DWH,
         Debug,
         DebugStruct,
         DebugTuple,
diff --git a/library/core/src/num/mod.rs b/library/core/src/num/mod.rs
index 6032dc9a2d3..3cdf570e600 100644
--- a/library/core/src/num/mod.rs
+++ b/library/core/src/num/mod.rs
@@ -39,6 +39,19 @@
 mod nonzero;
 mod wrapping;
 
+#[unstable(feature = "dwh", issue = "none")]
+/// Docs.
+pub mod enums {
+    /// Docs.
+    #[cfg(not(bootstrap))]
+    #[rustc_builtin_macro]
+    #[unstable(feature = "dwh", issue = "none")]
+    #[allow_internal_unstable(core_intrinsics)]
+    pub macro DWH($item:item) {
+    /* compiler built-in */
+    }
+}
+
 #[stable(feature = "rust1", since = "1.0.0")]
 pub use wrapping::Wrapping;
```

After https://github.com/rust-lang/rust/pull/81837, which added a non-`pub` `const` to that module, applying the above patch gives me the following error:

```
error: constant has missing stability attribute
   --> library/core/src/num/mod.rs:169:1
    |
170 | const ASCII_CASE_MASK: u8 = 0b0010_0000;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: could not compile `core`
```

If I revert https://github.com/rust-lang/rust/pull/81837 the error goes away.

This is surprising - I wouldn't expect the presence of an unrelated, but properly marked unstable, macro in a module to change whether a `const` needs to be marked stable. I'm not sure what's wrong here - maybe the `const` does need a stability attribute and a bug means that wasn't flagged, or maybe the lint checking for missing stability attributes is getting tripped up somehow, but _something_ is wrong...

This reliably reproduces whether the added module is inline or a separate file. It does not reproduce if the macro isn't present in the module (e.g. it doesn't reproduce for an empty module).
Repository: godot
Issue: Changing node type to custom TileMap class discards random tile data.
Labels: bug,topic:core,topic:2d

**Godot version:**
3.3


**OS/device including version:**
Windows 10 Home, version 20H2, build 19042.928, HP Pavilion Gaming Laptop 16-a0xxx.
nVidia GeForce GTX 1660 Ti Max-Q, driver version 457.63, any backend.


**Issue description:**
When changing a node's type from `TileMap` to a `CustomTileMap` class, which is a GDScript class that only `extends TileMap` and has no other code, the expectation is that the behavior should be exactly the same as assigning the same GDScript file as the node's script without changing its type.

What happens instead, is that seemingly random tiles are discarded. The tilemap appears to be editable as usual, but about 50% of the preexisting tiles are wiped away.

This does not occur when setting the node's script to the same `CustomTileMap.gd` script file. The tile data is not modified at all.


**Steps to reproduce:**
1. Add a `TileMap` node to a scene.
2. Set the TileMap's "Tile Set" property to a valid `TileSet` resource with any arbitrary tiles in it.
3. Scribble around in the TileMap with that TileSet.
4. Create the following `CustomTileMap.gd`:
    ```gdscript
    extends TileMap
    class_name CustomTileMap
    ```
5. Right-click on the TileMap node in the scene, click on "Change Type", select the new `CustomTileMap` node type, and click "Change".
6. Observe that an arbitrary number of tiles have become blank.


**Minimal reproduction project:**
[CustomTileMapTest.zip](https://github.com/godotengine/godot/files/6424922/CustomTileMapTest.zip)
Repository: go
Issue: time: Parse not setting Location to Local when TZ=UTC
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16.3 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build3471220289=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
https://play.golang.org/p/p7UiZXcefMp


### What did you expect to see?
```
time.Time{wall:0xbab699fc00000000, ext:1, loc:(*time.Location)(0x5666c0)} "2009-11-10T23:00:00Z" time.Time{wall:0x0, ext:63393490800, loc:(*time.Location)(0x5666c0)}
```


### What did you see instead?
```
time.Time{wall:0xbab699fc00000000, ext:1, loc:(*time.Location)(0x5666c0)} "2009-11-10T23:00:00Z" time.Time{wall:0x0, ext:63393490800, loc:(*time.Location)(nil)}
```

### Summary
It looks like when `time.Local` reflects utc, unmarshaling is different than to when a timezone is present. play.golang.org may seem like a poor reproducer, since time and clocks are so heavily mocked, but my system does the same thing (either without `/etc/timezone` or with it pointed at `/usr/share/zoneinfo/Etc/UTC`). When I provide `TZ=NZ` or `/etc/localtime`, we get the desired output.
Repository: pytorch
Issue: `jit.trace` fails to capture single-element tensor passed into op requiring scalar-type argument
Labels: oncall: jit

## 🐛 Bug

```
class M(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.p = torch.tensor(1.0)

    def forward(self, x):
        return torch.dropout(x, self.p, False) 

m = M()
traced = torch.jit.trace(m, torch.rand(2, 3))
print(traced.graph)
```

Output:
```
graph(%self : __torch__.M,
      %x : Float(2, 3, strides=[3, 1], requires_grad=0, device=cpu)):
  %8 : float = prim::Constant[value=1.]() # simple_trace_const.py:9:0
  %9 : bool = prim::Constant[value=0]() # simple_trace_const.py:9:0
  %10 : Float(2, 3, strides=[3, 1], requires_grad=0, device=cpu) = aten::dropout(%x, %8, %9) # simple_trace_const.py:9:0
  return (%10)
```

We can see that second argument to `aten::dropout` is baked in as a constant float when it should have been `self.p`.

cc @gmagogsfm
Repository: rust
Issue: Support instrumenting only selected files or functions with -Z instrument-coverage
Labels: C-enhancement,A-code-coverage

Sometimes it’s useful to only instrument certain files or functions. For example in automated testing infrastructure, it may be desirable to only instrument files or functions that were modified by a patch to reduce the overhead of instrumenting a full system.

Clang supports this via [the `-fprofile-list==<pathname>` option](https://clang.llvm.org/docs/UsersManual.html#instrumenting-only-selected-files-or-functions) where the argument is a file in the [Sanitizer special case list](https://clang.llvm.org/docs/SanitizerSpecialCaseList.html) format which selects which files and functions to instrument. At the IR level, for any function that's _not_ instrumented, Clang attaches the `noprofile` attribute.

It'd be useful if Rust supported the same option. It'd be also nice if Rust could use the same file format but it's not strictly necessary.