sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Support `tsc --build --noEmit`
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->
`tsc --build --noEmit`
build noEmit

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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

<!-- A summary of what you'd like to see added or changed -->
Allow `tsc --build --noEmit`, the relevant types can be emitted to the `tsbuildinfo` for incremental building. This is very useful to allow type checking only for projects using project references and working with a bundler. e.g. A [`create-vue`](https://github.com/vuejs/create-vue) project, which currently has to resort to hackery such as `vue-tsc --noEmit -p tsconfig.vitest.json --composite false` which is not as accurate as type checking each project individually.

## 📃 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?
-->
`tsc --build --noEmit` is now supported, allowing to only run type checking for projects using project references that don't also build types using `tsc`.

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->
Type checking only, for projects using other build tools than `tsc` but still using project references for each of configuration.
Repository: rust
Issue: Unused Fluent messages lint
Labels: T-compiler,A-translation,D-diagnostic-infra

Inspired by #110597 - we should add a check for unused Fluent messages.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"est31"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Incorrect / incomplete information about where you can break with a value
Labels: A-docs

### Location

https://doc.rust-lang.org/std/keyword.break.html

### Summary

The documentation states that "When associated with loop, a break expression may be used to return a value from that loop. This is only valid with loop and not with any other type of loop. If no value is specified, break; returns (). Every break within a loop must return the same type."

"This is only valid with loop" is not true, as one can break with a value from within a non-loop block expression.

## Example:
```rust

let final_value = 'outer: {
    let value: Option<Value> = get_value();
    'inner: {
        if let Some(value) = value { break 'outer value; }
    }
    // do stuff here maybe
};

```
Whilst I admit the example I provide seems a little contrived, I use this practice myself.

For context, the technical reason why you can't break from say a while or for loop is because those loops are expected to yield the `()` type.

I believe that this part of the documentation should be amended/elaborated on as I find this pattern useful and practical for writing readable code.
Repository: PowerToys
Issue: Move Window to Desktop Number X with draganddrop or with menu
Labels: Product-Tweak UI Design,FancyZones-Layouts

### Description of the new feature / enhancement

Please put this function in the menu of the window or make it possible then we can drag the window on Multidesktopicon on the Taskbar when we have the window in the hand. So its possible that the Windows will be placed on the new/other desktop with one move or with one menu click .

Thank you

### Scenario when this would be used?

Always when i work with the window and i want to put the Window to antother desktop. Currently I have to release the window again. Then go to the multidesktop. Then again take the desired window and place it! This is the reason while many users dont use the Multi Desktop! Its to laborious!

### Supporting information

_No response_
Repository: rust
Issue: refuse to borrow when no other reference exists technically 
Labels: A-borrow-checker,C-discussion

The code refuse to compile, though there is no other references existing at the point, technically.
Using the rust stable 1.69.

```rust
fn main() {
    pub fn fx<'a, T: 'a, U>(_: &mut &'a mut T) ->fn(&mut &'a U) {
        fn x1<'b, T: 'b>(_: &mut &'b T) {}
        x1::<U>
    }

    let mut b = &mut 1;
    let n = {
        let c = &mut b;
        let f = fx(c);

        let mut n = &*c;
        f(&mut n);

        n
    };
    drop(n);

    println!("{}", b); // fails to compile
}
```

reporting 
```
   |
45 |         let mut c = &mut b;
   |                     ------ mutable borrow occurs here
...
56 |     println!("{}", b);
   |                    ^
   |                    |
   |                    immutable borrow occurs here
   |                    mutable borrow later used here
   |
   = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
```

**Updated 1:**
_found a reasonable explanation for the following, it is not a problem._
_But the problem above still holds._

**Updated 2:** 
 _The problem is effectively because of a reborrowing of b, introduced by `let mut n = &*c`, having a scope not less than `b`'s. _
 _As a result, anytime b is accessed (e.g. b is alive),  the reborrowing is alive too,  and b is shadowed by the reborrowing._
  
 _It is hard to say it's a bug or not, but it does be confusing in this case._
 _I think it may be the reason why `*(&'short mut  &'long mut ref)  ---> &'short mut ref`_

Another representation of the same root cause, some implicit lifetime, bring in by c, I guess.

```rust
fn main() {
    let mut a = 1;
    let mut b = &mut a;

    let n = {
        let mut c = &mut b;
        let mut n = &*c;  // ---------------> let's qualified it to &'long *c
        drop(c);  // -----------------------> fails to compile
        n
    };  // ---------------------------------> c drops here ok
    
    println!("{}", n);  // ----------------> 'long extends here at least
}
```
Repository: storybook
Issue: [Feature Request]: Automatically type arg mapping + conditional controls
Labels: feature request,typescript,argtypes

### Is your feature request related to a problem? Please describe

It's possible for args to change from the unmapped ("input") args in various ways before reaching the story's render function:
- arg enhancers (undocumented)
  - only currently used by actions, AFAIK, and approximated by our TS support 
- [arg mapping](https://storybook.js.org/docs/react/writing-stories/args#mapping-to-complex-arg-values)
- [conditional controls](https://storybook.js.org/docs/react/essentials/controls#conditional-controls)
- decorators adding args (undocumented, probably we want to deprecate this).

Currently we treat the "input" args as the same type as the component's props, but this is incorrect. For conditional controls, it is not an issue, as if an arg is optional, then the component's prop must be optional too.

### Describe the solution you'd like

For arg mappings, we can use the type of the `mapping` object to transform `TArgs` taken from the component to `TInputArgs` used in story objects:

```tsx
export const MyComponent = ({ children }: { children: ReactNode }) => {};

const meta: Meta<typeof MyComponent> {
  render(args:TArgs) {
    // TArgs should = ComponentProps<typeof MyComponent>, so you can do:
    return <MyComponent {...args} />; // or similar
  },
  argTypes: {
    children: {
      mapping: {
        icon: <Icon />,
        button: <Button />
      }
    }
  },
  // However the type of args here should be TInputArgs,
  // where TInputArgs['children'] = 'icon' | 'button'
  args: {
    children: 'icon'
  }
}



### Describe alternatives you've considered

_No response_

### Are you able to assist to bring the feature to reality?

no

### Additional context

_No response_
Repository: excalidraw
Issue: Request: Chart type - Net
Labels: charts

Dear community,

**I would like to request a new chart-type: net.**
- Currently there are only two

I would like to use it for the wheel of life diagram.

Screenshot attached from my libreoffice calc/excel file
![Screenshot from 2023-04-24 13-23-26](https://user-images.githubusercontent.com/111446934/233982638-f47b2192-d6f4-496e-847c-b3d316edd2d5.png)

**Or is there a work-around for it?**
Repository: next.js
Issue: BUG: dynamic import generates Component twice. 
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
"next": "13.2.0",
 "next-translate": "2.0.2",
 "react": "18.2.0",
 "effector": "22.5.2",
 "effector-react": "22.5.0",
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue

there is no link

### To Reproduce

make dynamic import of component after inspect browser and see in elements that component is generated twice.

### Describe the Bug

After dynamic import  component is being generated twice.but dynamic import is working at version 13.1.6. after that version it doesn't work.and the version 13.1.6 doesn't work with next-translate version 2.0.2 and we are getting hydration error.

### Expected Behavior

i expect to generate component once after dynamic import.

### Which browser are you using? (if relevant)

Chrome

### How are you deploying your application? (if relevant)

_No response_
Repository: opencv
Issue: Some layers to not relay on CUDA implementation
Labels: bug,category: gpu/cuda (contrib),incomplete,category: dnn

### System Information

With the following setting of CUDA and cuDNN: 12.1, 8.x some layer do not use CUDA backend at all. Warning massage:



### Detailed description

`CUDA backend will fallback to the CPU implementation`

OpenCV version: 4.6.0
Operating System / Platform: Ubuntu 20.04
Compiler & compiler version: GCC 7.5.0
Python version: 3.8.10

### Steps to reproduce

```bash
cd build/bin/
./opencv_test_dnn
```
see logs

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: flutter
Issue: Add documentation to show how to embed HTML elements into a web application
Labels: d: api docs,platform-web,c: proposal,P2,team-web,triaged-web

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

The problem is absense of official documentation about how to embed HTML elements into flutter web app. We know this widget `[HtmlElementView](https://api.flutter.dev/flutter/widgets/HtmlElementView-class.html)` but it all. What means `viewType` and which values it keeps? What is _unique identifier_?

> A PlatformViewFactory for this type must have been registered.

Great! What is `PlatformViewFactory`?  Where and how it must be registered? `dart:ui` shims? What is this? And so on...

### Proposal

It would be good somewhere in Flutter [documentation](https://api.flutter.dev/flutter/widgets/HtmlElementView-class.html) the description with examples how to work (embed) and create HTML elements as Flutter widgets. Yes it is possible to find this information on `SO` but don't you think it should be a part of documentation?
Repository: pytorch
Issue: Dynamo config patching in our code is brittle
Labels: triaged,enhancement,needs design,oncall: pt2,module: dynamo

### 🐛 Describe the bug

Concretely, the other day, I was trying to change the default setting of `assume_static_by_default` for export only: https://github.com/pytorch/pytorch/pull/99554 The easiest way to do this was to modify _dynamo.export to patch this to False on entry.

However, this resulted in something very awkward: it's now *no longer possible* to override this setting via external configuration! Because the config setting always gets overwritten by the patch on the inside.

In general, it's awkward to have config settings that default one way for eager and another export. It would be nice to figure out some robust mechanism for doing this

### Versions

master

cc @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4 @aakhundov @wconstab @soumith @ngimel @Xia-Weiwen @desertfire
Repository: storybook
Issue: [Bug]: node_modules/@storybook/components/dist/index.d.ts type error
Labels: bug,help wanted,typescript,sev:S3

### Describe the bug

node_modules/@storybook/components/dist/index.d.ts type error

```
./node_modules/@storybook/components/dist/index.d.ts:283:8
Type error: Type '"async" | "start" | "hidden" | "color" | "content" | "size" | "style" | "default" | "wrap" | "open" | "height" | "translate" | "width" | "multiple" | "disabled" | "cite" | "data" | ... 345 more ... | "rev"' does not satisfy the constraint '"async" | "start" | "hidden" | "color" | "content" | "size" | "style" | "default" | "wrap" | "open" | "height" | "translate" | "width" | "multiple" | "disabled" | "cite" | "data" | ... 345 more ... | "valid"'.
  Type '"rev"' is not assignable to type '"async" | "start" | "hidden" | "color" | "content" | "size" | "style" | "default" | "wrap" | "open" | "height" | "translate" | "width" | "multiple" | "disabled" | "cite" | "data" | ... 345 more ... | "valid"'.

  281 |         valid?: ValidationStates;
  282 |         height?: number;
> 283 |     }, "download" | "href" | "hrefLang" | "media" | "target" | "type" | "form" | "list" | "cite" | "cellPadding" | "cellSpacing" | "summary" | "width" | "alt" | "crossOrigin" | "heigh
```

### To Reproduce

1. run ```git clone https://github.com/jeremytenjo/starter-website --branch storybookv7/type-error && cd starter-website && npm i && npm run build```

2. check terminal

![image](https://user-images.githubusercontent.com/25231946/234034019-6988f6f0-ac88-4a14-b9a4-6739860037d0.png)



### System

```shell
Environment Info:

  System:
    OS: macOS 13.3.1
    CPU: (8) arm64 Apple M1
  Binaries:
    Node: 16.15.0 - ~/.nvm/versions/node/v16.15.0/bin/node
    npm: 8.5.5 - ~/.nvm/versions/node/v16.15.0/bin/npm
  Browsers:
    Chrome: 112.0.5615.137
    Firefox: 95.0.2
    Safari: 16.4
  npmPackages:
    @storybook/addon-actions: 7.0.7 => 7.0.7 
    @storybook/addon-essentials: 7.0.7 => 7.0.7 
    @storybook/addon-interactions: 7.0.7 => 7.0.7 
    @storybook/addon-links: 7.0.7 => 7.0.7 
    @storybook/builder-webpack5: 7.0.7 => 7.0.7 
    @storybook/jest: 0.1.0 => 0.1.0 
    @storybook/nextjs: 7.0.7 => 7.0.7 
    @storybook/test-runner: 0.10.0 => 0.10.0 
    @storybook/testing-library: 0.1.0 => 0.1.0 
```
```


### Additional context

_No response_
Repository: storybook
Issue: [Bug]: Overwriting HTML class to dark is not possible anymore
Labels: bug,help wanted,vue3,builder-vite,sev:S3

### Describe the bug

I am currently trying to upgrade to Storybook 7 and noticed that my custom configuration for creating custom dark theme is not working anymore. My configuration below would swap between `light` and `dark` depending on the story params provided, by injecting the class into the html

### preview.js
```js
export const decorators = [(story, { parameters }) => {
    const theme = parameters.theme || 'light';
    const themeToAdd = theme === 'light' ? 'light' : 'dark';
    const themeToRemove = theme === 'light' ? 'dark' : 'light';
    const htmlElement = document.querySelector('html');

    htmlElement.classList.add(themeToAdd);
    htmlElement.classList.remove(themeToRemove);

    return story();
}]
```

### Story
```js
import { useUserStore } from '@/store/user';
import OfflineView from '@/views/Offline.vue';

export default {
  title: 'Views/Offline',
  parameters: {
    layout: 'centered',
  },
};

const Template = (args) => ({
  components: { OfflineView },
  setup() { return { args }; },
  template: '<offline-view />',
});

export const Default = Template.bind({});
export const DarkTheme = Template.bind({});

DarkTheme.parameters = { theme: 'dark' };
```

When this code was executed, I would get this kind of template:
<img width="577" alt="image" src="https://user-images.githubusercontent.com/4270980/234036906-0b3c780b-3c9f-447f-90c7-f4a6d151e2f2.png">

But with Storybook 7, this is not working anymore. I've tried adding other classes, including `light` and it does get added to HTML. But only `dark` doesn't work. As can be seen below, `class` gets set, but it seems to be removed at some point by Storybook itself, which seems like a bug to me

<img width="575" alt="image" src="https://user-images.githubusercontent.com/4270980/234037278-deaeee52-c5ef-426e-90d1-7154218c112a.png">


### To Reproduce

_No response_

### System

```shell
Environment Info:

  System:
    OS: macOS 12.5
    CPU: (8) arm64 Apple M2
  Binaries:
    Node: 19.9.0 - ~/.nvm/versions/node/v19.9.0/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 9.6.3 - ~/.nvm/versions/node/v19.9.0/bin/npm
  Browsers:
    Chrome: 112.0.5615.137
    Firefox: 104.0.2
    Safari: 15.6
  npmPackages:
    @storybook/addon-actions: 7.0.7 => 7.0.7
    @storybook/addon-essentials: 7.0.7 => 7.0.7
    @storybook/addon-interactions: ^7.0.7 => 7.0.7
    @storybook/addon-links: 7.0.7 => 7.0.7
    @storybook/testing-library: ^0.1.0 => 0.1.0
    @storybook/vue3: 7.0.7 => 7.0.7
    @storybook/vue3-vite: 7.0.7 => 7.0.7
```


### Additional context

_No response_
Repository: rust
Issue: Producing a &'a T does not entail T: 'a in the eye of the compiler
Labels: A-inference,C-bug,T-types

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code where rustc fails to recognize that  `deref<'a>(&'a Outer) -> &'a Inner` implies that `Inner: 'a`.

The goal of this code is to provide a newtype wrapper around nested smart pointers such as `Rc<bumpalo::boxed::Box<'a, T>>` that is able to `Deref<Target=T>`. In that context, `Rc` is the outer type and `bumpalo::boxed::Box` the inner type.

```rust
use core::ops::Deref;

pub struct Nested<Outer> {
    outer: Outer,
}

impl<T, Outer, Inner> Deref for Nested<Outer>
where
    Outer: Deref<Target = Inner>,
    Inner: Deref<Target = T> + ?Sized,
    T: ?Sized,
{
    type Target = T;

    #[inline]
    fn deref<'a>(&'a self) -> &'a T {
        let outer: &'a Outer = &self.outer;
        let inner: &'a Inner = Deref::deref(outer);
        let x: &'a T = Deref::deref(inner);
        x
    }
}
```

I expected to see this happen: AFAICT this code should compile.

Instead, this happened: rustc rejects the code with the following error:
```
Compiling playground v0.0.1 (/playground)
error[[E0309]](https://doc.rust-lang.org/stable/error_codes/E0309.html): the parameter type `Inner` may not live long enough
  --> src/lib.rs:18:20
   |
18 |         let inner: &'a Inner = Deref::deref(outer);
   |                    ^^^^^^^^^ ...so that the type `Inner` will meet its required lifetime bounds
   |
help: consider adding an explicit lifetime bound...
   |
10 |     Inner: Deref<Target = T> + ?Sized + 'a,
   |                                       ++++
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Also tried on rust playground v1.69 with the same error.

`rustc --version --verbose`:
```
rustc 1.68.2 (9eb3afe9e 2023-03-27)
binary: rustc
commit-hash: 9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0
commit-date: 2023-03-27
host: x86_64-unknown-linux-gnu
release: 1.68.2
LLVM version: 15.0.6

```
Repository: vscode
Issue: Setting for Merge Editor "Show Base Top"/"Show Base Center" in user/workspace settings.json
Labels: feature-request,merge-editor

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

There is missing option to enable Merge Editor "Show Base Top"/"Show Base Center" in user/workspace settings.json. Without this option I was unable to find that VSCode Merge Editor is indeed a 3-way merge editor! Also this way I could keep it in version-controlled settings.json



Some background story about this adventure;): When I saw Merge Editor in VSCode I checked VSCode settings to check if there is a way to make it a proper 3-way merge editor and could not find it, so I started looking if someone already reported feature request for that. I found #154877 which was closed at the spot by @hediet (not nice;)), then #155251, and finally #155277, where  issue was ultimately understood and implemented:). I still could not figure out how to enable it and finally I found [comment](https://github.com/microsoft/vscode/issues/155277#issuecomment-1283623303) by @HCanber that this option exists in three-dots menu. That was surprising as I used this menu to open the "Compare with base" option (which btw does not preserve focused line so it is useless) and it was not there. But in the end I found yet-another three-dots menu with what I wanted: showing base:) So there was one last thing to do, report this issue so no more people will struggle:)
Repository: node
Issue: deps: time zone updater workflow problems
Labels: i18n-api

See #47680  for example problem PR

- suggestion: move the script to `tools/icu` with other icu tools
- script should check the _current_ tz version and not proceed if it's already >= the proposed tz version. This would have prevented #47680 from running.
- The PR should indicate the current ICU version, this would distinguish #47302  (ICU v72.1 and a legitimate update) from #47680 (ICU v73.1).  It's visible from the `icudt*.bz2` file which is updated.

Ref: #47288 for the original tool work.