sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [docs-infra] Create a custom 404 page for the docs
Labels: new feature,scope: docs-infra

### Summary

We recently introduced a custom 404 page, closing #31349. 

As the project grow, it will increasingly make sense to have custom 404 pages per layout.

### Examples

- Stripe https://stripe.com/foo vs. https://stripe.com/docs/foo
- Vercel https://vercel.com/foo vs. https://vercel.com/docs/foo 

### Motivation

But it feels like you need a business of the scale of >200 people for the opportunity cost of this to start to make sense. See how the Vercel docs 404 page is broken, they couldn't pull it off correctly so far (500 people).

**Search keywords**: 404 pages
Repository: rust
Issue: Future compatibility lints are worded too strongly
Labels: A-diagnostics,T-compiler

### Code

```Rust
trait Trait {}
impl Trait for fn(&'static str) {}
impl Trait for fn(&str) {}
```


### Current output

```Shell
warning: conflicting implementations of trait `Trait` for type `fn(&'static str)`
 --> src/lib.rs:3:1
  |
2 | impl Trait for fn(&'static str) {}
  | ------------------------------- first implementation here
3 | impl Trait for fn(&str) {}
  | ^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `fn(&'static str)`
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #56105 <https://github.com/rust-lang/rust/issues/56105>
  = note: this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details
  = note: `#[warn(coherence_leak_check)]` on by default
```


### Desired output

```Shell
warning: conflicting implementations of trait `Trait` for type `fn(&'static str)`
 --> src/lib.rs:3:1
  |
2 | impl Trait for fn(&'static str) {}
  | ------------------------------- first implementation here
3 | impl Trait for fn(&str) {}
  | ^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `fn(&'static str)`
  |
  = warning: this was previously accepted by the compiler but is problematic; it may become a hard error in a future release!
  = note: for more information, see issue #56105 <https://github.com/rust-lang/rust/issues/56105>
  = note: this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details
  = note: `#[warn(coherence_leak_check)]` on by default
```


### Rationale and extra context

Future compatibility lints assert that the linted code will become a hard error in the future.  However, not all future compatibility lints become hard errors.  [The two-phase borrow compatibility lint](https://github.com/rust-lang/rust/issues/59159) is one example that never became a hard error.  As far as I know, [it is still the plan that the provided example remains supported as well.](https://github.com/rust-lang/rust/issues/56105#issuecomment-633038069)  And I've seen other cases as well.

The assertion that the code will definitely become a hard error can be problematic if people [rely on it for new compile/language development,](https://github.com/rust-lang/rust/issues/90629) or if they rely on it when reasoning about making their `unsafe` code sound.  It's also just plain annoying to find out the compiler is telling you and everyone else something which isn't true.

The specific future compatibility lint from my code example is just an example; all such lints share the "it will become a hard error" verbiage.

### Other cases

_No response_

### Rust Version

```Shell
Stable channel

Build using the Stable version: 1.76.0
Beta channel

Build using the Beta version: 1.77.0-beta.2

(2024-02-09 f2048098a1ca42a520e7)
Nightly channel

Build using the Nightly version: 1.78.0-nightly

(2024-02-09 d44e3b95cb9d410d89cb)
```


### Anything else?

_No response_
Repository: tauri
Issue: [bug] use of undeclared crate or module `tauri`  
Labels: type: bug,status: needs triage

### Describe the bug

build.rs

#[tauri::command]
fn my_custom_command() {
  println!("I was invoked from JS!");
}

// Also in main.rs
fn main() {
    tauri::Builder::default()
    // This is where you pass in your commands
    .invoke_handler(tauri::generate_handler![my_custom_command])
    .run(tauri::generate_context!())
    .expect("failed to run app");
}

this code given in the tauri documention but not working

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
error[E0433]: failed to resolve: use of undeclared crate or module `tauri`
  --> build.rs:22:10
   |
22 |     .run(tauri::generate_context!())
   |          ^^^^^ use of undeclared crate or module `tauri`

error[E0433]: failed to resolve: use of undeclared crate or module `tauri`
  --> build.rs:21:21
   |
21 |     .invoke_handler(tauri::generate_handler![my_custom_command])
   |                     ^^^^^ use of undeclared crate or module `tauri`

error[E0433]: failed to resolve: use of undeclared crate or module `tauri`
  --> build.rs:12:3
   |
12 | #[tauri::command]
   |   ^^^^^ use of undeclared crate or module `tauri`

error[E0433]: failed to resolve: use of undeclared crate or module `tauri`
  --> build.rs:19:5
   |
19 |     tauri::Builder::default()
   |     ^^^^^ use of undeclared crate or module `tauri`
   |
help: consider importing this struct
   |
12 + use std::thread::Builder;
   |
help: if you import `Builder`, refer to it directly
   |
19 -     tauri::Builder::default()
19 +     Builder::default()
   |

For more information about this error, try `rustc --explain E0433`.
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: godot
Issue: Played IKs work visually but don't apply transformations to bone in the editor.
Labels: discussion,topic:editor,topic:animation,topic:3d

### Tested versions

Godot_v4.3-dev3_mono_win64
Godot_v4.2.1-stable_mono_win64

### System information

Windows 11

### Issue description

I have a skeleton with bones, bone attachments to link the skeleton's bones to meshes, inverse kinematic nodes to move some bones around, and a target node linked for each IK nodes.

When I play the IKs, it works visually. However, when I go in the skeleton to check the bone's position and rotation, nothing has changed.

Similarly when I use the skeleton's features "insert keys for existing tracks" or "insert keys for all bones", the keys inserted also do not contain the modifications from the IKs.

Why I want to do that? So that I can animate things directly in godot.

Why don't I just move the targets around in the animation? Because I want the animation to be modifying bone's rotations, animations of that sort can easily work on different bone sizes.

### Steps to reproduce

* Setup a skeleton with bones
* Setup bone attachment and meshes to see where the bones are
* Setup inverse kinematics and targets to move the tip of a bone chain
* Play IKs
* Move targets
* Notice the meshes have moved along
* check the skeleton and the bones modified 
* observe no modification of their rotation or position.

### Minimal reproduction project (MRP)

[BugIKAndBones.zip](https://github.com/godotengine/godot/files/14230198/BugIKAndBones.zip)
Repository: flutter
Issue: Web: Scroll axis is not locked during trackpad/touchpad drags
Labels: framework,engine,f: scrolling,platform-web,has reproducible steps,P2,team-web,triaged-web,found in release: 3.16,found in release: 3.20

As a follow-up to: https://github.com/flutter/flutter/issues/125101

The issue still seems to be persistent (compare the Flutter Gallery app): https://flutter-gallery-archive.web.app/

https://github.com/flutter/flutter/assets/10195482/aa62ca92-6695-4b02-950c-c98c74ee65f4
Repository: rust
Issue: Assoc const equality bounds aren't taken into consideration when normalizing const projections
Labels: A-trait-system,T-compiler,C-bug,F-generic_const_exprs,T-types,F-associated_const_equality

For example, I expected the following code to succeed compilation:

```rs
#![feature(generic_const_exprs)]
#![feature(associated_const_equality)]

trait Trait {
    const C: usize;
}

fn f<T: Trait<C = 1>>()
where
    [(); T::C]:
{
    let _: [(); T::C] = [()];
}
```

Since (I'm pretty sure that) the ParamEnv contains the projection predicate `<T as Trait>::C == 1`, the const projection `<T as Trait>::C` inside the function body should be able to get normalized to `1`. That however doesn't seem to happen:

```
error[E0308]: mismatched types
  --> src/lib.rs:12:25
   |
12 |     let _: [(); T::C] = [()];
   |                         ^^^^ expected `T::C`, found `1`
   |
   = note: expected constant `T::C`
              found constant `1`
```
Repository: next.js
Issue: Throwing custom error object appears as [Object object]
Labels: bug

### Link to the code that reproduces this issue

https://github.com/carlos-dubon/nextjs-error-bug

### To Reproduce



```
// app/page.tsx

async function getData(): Promise<number> {
    throw {
        message: 'MY CUSTOM ERROR',
        name: 'My new error',
        cause: 'custom error',
    };
   return 3;
}

export default async function Home() {
    const pageData = await getData();

    return (
        <div>{pageData}</div>
    );
}

```

### Current vs. Expected behavior

Throwing a custom error object appears as `[Object object]` in my `app/error.ts` file. I get a digest but the error is still [Object object] so it isn't helpful at all. I need this because our apps use a common package for calling our apis, and i can't simply modify it to suit only our web app.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
Binaries:
  Node: 20.10.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

### Additional context

_No response_
Repository: three.js
Issue: XRButton defaults to `local-floor`
Labels: Addons

### Description

Recently switched from ARButton to XRButton and noticed all our content is initializing on the floor, despite setting `local` as a required option. 

### Reproduction steps

1. create a scene with XRButton
2. create an object and set it to 0, 0, 0
3. enter XR


### Code

```js
this.XRButton = XRButton.createButton(this.renderer, {
    requiredFeatures: ['local']
});
```

### Live example

* [XRButton issue](https://create.mrjs.io/view/xrbutton-issue-TEJZwOF//)


### Screenshots

<img width="1136" alt="Screenshot 2024-02-10 at 8 02 37 PM" src="https://github.com/mrdoob/three.js/assets/19628643/0249a571-ecd0-440c-8276-c41846aa85a5">


### Version

r161

### Device

Headset

### Browser

Chrome

### OS

Android
Repository: deno
Issue: WritableStream write() only accepts Uint8Array and not any ArrayBufferView
Labels: bug,ext/net

Version: Deno 1.40.4

Using `Deno.connect()` and writing to stream, `writer.write()` is supposed to take any `ArrayBufferView` but instead throws for anything other than `Uint8Array`

```js
const port = 3006;
const server = Deno.serve({ port }, r => new Response());
const tcp = await Deno.connect({ port });
const w = tcp.writable.getWriter();

await w.write(new Uint8Array(1));
await w.write(new Uint16Array(1)); // throws
await w.write(new Uint32Array(1)); // throws
await w.write(new BigUint64Array(1)); // throws
await w.write(new ArrayBuffer(1)); // throws
await w.write(new DataView(new ArrayBuffer(1))); // throws
```

If the stream only accepts writing with `Uint8Array`, the error message should say `Uint8Array` not `ArrayBufferView`

```
TypeError: expected typed ArrayBufferView
await w.write(new Uint16Array(1));
        ^
    at Object.write (ext:deno_web/06_streams.js:1155:20)
    at Module.invokeCallbackFunction (ext:deno_webidl/00_webidl.js:944:16)
    at WritableStreamDefaultController.writeAlgorithm (ext:deno_web/06_streams.js:3915:14)
    at writableStreamDefaultControllerProcessWrite (ext:deno_web/06_streams.js:4485:55)
    at writableStreamDefaultControllerAdvanceQueueIfNeeded (ext:deno_web/06_streams.js:4388:5)
    at writableStreamDefaultControllerWrite (ext:deno_web/06_streams.js:4532:3)
    at writableStreamDefaultWriterWrite (ext:deno_web/06_streams.js:4679:3)
    at WritableStreamDefaultWriter.write (ext:deno_web/06_streams.js:6602:12)
```
Repository: stable-diffusion-webui
Issue: [Feature Request]: Only explicit specification of embeddings is allowed, like <embedding:badhandv5>
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

I often come across amazing images shared by others on the internet. However, when attempting to replicate their results using the corresponding prompts they share with sd-webui, I often encounter failures. This is because they use embeddings, and I cannot determine exactly which embeddings they used. Despite their prompts containing many embeddings, they may only have a subset of embeddings locally, resulting in only a portion of the embeddings actually taking effect. What's more frustrating is that, for example, if the prompt includes both `badhandv5` and `baddream` embeddings, but the user only has `badhandv5.pt` locally, only `badhandv5` is effective, and `baddream` is treated as a regular prompt, split into `"bad"` and `"dream"` by the BPE algorithm. If I have both `badhandv5.pt` and `baddream.pt` locally, I must rename my `baddream.pt` to reproduce their results. The root cause of all this is the mixture of embeddings and regular prompts. If only explicit specification of embeddings is allowed, like `<embedding:badhandv5>`, it would solve this issue.

### Proposed workflow

1. Only explicit specification of embeddings is allowed, like `<embedding:badhandv5>`.


### Additional information

_No response_
Repository: rust
Issue: Crash of 1.76.0 compiler with generics
Labels: I-ICE,T-compiler,C-bug

### Code

Hey,I encountered a panic in the compiler version 1.76.0.
Using nightly 1.78.0 helps as it points the error in my code and do not crash the reason is that my first argument: 
fn serialize_price_matrix<T, S>(_: &**Vec<Vec<f64>>**, serializer: S should be

fn serialize_price_matrix<T, S>(_: &**T**, serializer: S

```
12 |     #[serde(serialize_with = "serialize_price_matrix")]
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `T` declared on the function `serialize_price_matrix`
```

```Rust
use serde::{Serialize, Serializer};

fn serialize_price_matrix<T, S>(_: &Vec<Vec<f64>>, serializer: S) -> Result<<S as Serializer>::Ok, <S as Serializer>::Error>
    where
        S: Serializer,
{
    serializer.serialize_f64(0.0)
}

#[derive(Serialize)]
pub(crate) struct Matrix {
    #[serde(serialize_with = "serialize_price_matrix")]
    matrix: Vec<Vec<f64>>,
}

fn main() {
}
```


### Meta
Using the stable version 1.76.0.

`rustc --version --verbose`:
```
rustc 1.76.0 (07dca489a 2024-02-04)
binary: rustc
commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
commit-date: 2024-02-04
host: x86_64-unknown-linux-gnu
release: 1.76.0
LLVM version: 17.0.6
```

### Error output

```
error: internal compiler error: compiler/rustc_middle/src/ty/typeck_results.rs:498:9: node HirId(DefId(0:14 ~ test_rust[7abd]::_::{impl#0}::serialize).40) (expr `Serialize`) cannot be placed in TypeckResults with hir_owner DefId(0:22 ~ test_rust[7abd]::_::{impl#0}::serialize::{impl#0}::serialize)
```

<details><summary><strong>Backtrace</strong></summary>
<p>

```
thread 'rustc' panicked at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/compiler/rustc_errors/src/lib.rs:1119:75:
Box<dyn Any>
stack backtrace:
   0: std::panicking::begin_panic::<rustc_errors::ExplicitBug>
   1: <rustc_errors::diagnostic_builder::Bug as rustc_errors::diagnostic_builder::EmissionGuarantee>::diagnostic_builder_emit_producing_guarantee
   2: <rustc_errors::DiagCtxt>::bug::<alloc::string::String>
   3: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>::{closure#0}
   4: rustc_middle::ty::context::tls::with_opt::<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}
   5: rustc_middle::ty::context::tls::with_context_opt::<rustc_middle::ty::context::tls::with_opt<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}, !>
   6: rustc_middle::util::bug::bug_fmt
   7: rustc_middle::ty::typeck_results::invalid_hir_id_for_typeck_results
   8: <rustc_middle::ty::typeck_results::TypeckResults>::expr_ty
   9: rustc_hir_typeck::typeck
      [... omitted 1 frame ...]
  10: rustc_hir_analysis::check_crate
  11: rustc_interface::passes::analysis
      [... omitted 1 frame ...]
  12: rustc_interface::interface::run_compiler::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#0}
```

</p>
</details>
Repository: transformers
Issue: Misleading ImportError when using JAX tensors without Flax installed
Labels: WIP,jax

### System Info

- `transformers` version: 4.37.2
- Platform: Linux-5.19.0-1027-gcp-x86_64-with-glibc2.35
- Python version: 3.11.4
- Huggingface_hub version: 0.20.1
- Safetensors version: 0.4.1
- Accelerate version: not installed
- Accelerate config: not found
- PyTorch version (GPU?): 2.3.0.dev20231228+cpu (False)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed  # But I have installed
- JaxLib version: not installed  # But I have installed
- Using GPU in script?: N/A
- Using distributed or parallel set-up in script?: N/A

### Who can help?

@sanchit-gandhi @ArthurZucker

### Information

- [ ] The official example scripts
- [ ] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

While attempting to convert tokenizer outputs to JAX tensors using the following code:
```python
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained('mistralai/Mistral-7B-v0.1')
sentences = ['hello world']
inputs = tokenizer(sentences, padding=True, return_tensors='jax')
```
I received the following ImportError:
```
ImportError: Unable to convert output to JAX tensors format, JAX is not installed.
```

However, JAX is indeed installed in my environment.

### Expected behavior

Upon further investigation, it seems the error arises because the library checks for Flax's availability (`is_flax_available()`) rather than JAX's direct presence. Here is the snippet from the [source code](https://github.com/huggingface/transformers/blob/58e3d23e97078f361a533b9ec4a6a2de674ea52a/src/transformers/tokenization_utils_base.py#L723-L724) that led to this conclusion:
```python
if not is_flax_available():
    raise ImportError("Unable to convert output to JAX tensors format, JAX is not installed.")
```
This can be somewhat misleading, as the error message suggests a lack of JAX installation, while the actual requirement is for Flax. Not all JAX users utilize Flax, and this might cause confusion.

Would it be possible to update the error message to more accurately reflect the requirement for Flax when attempting to use JAX tensor formats? Such a clarification would greatly assist users in diagnosing setup issues.
Repository: godot
Issue: Race condition in `RichTextLabel`
Labels: bug,crash,topic:gui

### Tested versions

4.2.1

### System information

Windows 10, Godot 4.2.1, Gles3 compatibility

### Issue description

There seems to be a race condition in `RichTextLabel` when using threaded updates. I got multiple crash dumps from users that crash in `RichTextLabel::_process_line_caches` on the line
```
Rect2 text_rect = _get_text_rect();
```
with an access fault on `theme_cache.normal_style->get_offset()` with `normal_style` seeming to be a `nullptr`.

My best guess is that the thread callback created here starts before `task` gets assigned
```
if (threaded) {
	updating.store(true);
	loaded.store(true);
	task = WorkerThreadPool::get_singleton()->add_template_task(this, &RichTextLabel::_thread_function, nullptr, true, vformat("RichTextLabelShape:%x", (int64_t)get_instance_id()));
	set_physics_process_internal(true);
	loading_started = OS::get_singleton()->get_ticks_msec();
	return false;
}
```

leading this check on `task` here to fail causing the destructor to not wait for the background task to complete.
```
void RichTextLabel::_stop_thread() {
	if (threaded) {
		stop_thread.store(true);
		if (task != WorkerThreadPool::INVALID_TASK_ID) {
			WorkerThreadPool::get_singleton()->wait_for_task_completion(task);
			task = WorkerThreadPool::INVALID_TASK_ID;
		}
	}
}
```

![grafik](https://github.com/godotengine/godot/assets/11277588/2c827bde-bf51-42ad-b237-54cd10ad7032)


### Steps to reproduce

Unload `RichTextLabels` with `threaded` set to true

### Minimal reproduction project (MRP)

-
Repository: rust
Issue: Cross-crate import chain misses docs from middle crate
Labels: T-rustdoc,C-bug,A-cross-crate-reexports

Given crates `a`:
```rust
/// (doc in a)
pub fn foo() {}
```
`b`:
```rust
/// (doc in b)
#[doc(inline)]
pub use a::foo;
```
and `c`:
```rust
/// (doc in master crate)
#[doc(inline)]
pub use b::foo;
```
The resulting rustdoc output for `c` omits documentation added in `b`:
![image](https://github.com/rust-lang/rust/assets/134893/6c64e7bc-ed40-40db-b99f-804b1a9d0b20)
I would expect the docs from all crates to be included.

# Source for reproduction
[inline-doc-reexport.zip](https://github.com/rust-lang/rust/files/14232061/inline-doc-reexport.zip)

# Related
#84619
#89020
@rustbot label +A-cross-crate-reexports +T-rustdoc
Repository: material-ui
Issue: [joy-ui][Modal] How to put it in the top of the screen (vertical positioning)?
Labels: component: modal,package: joy-ui,support: docs-feedback

### Related page

https://mui.com/joy-ui/react-modal/

### Kind of issue

Unclear explanations

### Issue description

One of the use cases for Modals is to put them not in the center of the screen, but on the top of the screen.

It is not possible now. 

**Example**:
`<ModalDialog sx={{top: "5px"}}>` puts the CENTER of the dialog 5px from the top, not its TOP RIGHT corner how I would expect for absolute positioning.

### Context

For mobile applications, when you want to fill something, the native mobile keyboard gets opened right away and if the modal is in the center of the srceen, it is covered partially by the native keyboard.

I want to put modal on the top of the screen so the user can start typing right away without scrolling first to see the modal (rest of the page)

**Search keywords**: modal, modaldialog