ernie-research/MEnvBench huggingface dataset:
Repository: lightningdevkit/rust-lightning (Rust)

Issue:
LSPS2: Order opening fee params by increasing fee rates
Currently we don't enforce any ordering and just return whatever the LSP provides.  The spec says these need to be ordered by fee rates. Perhaps this means implementing Ord/PartialOrd and then using some built-in sorting alg?

From the spec:

> The LSP, when ordering the opening_fee_params_menu array, MUST order by the following rules:
> 
> The 0th item MAY have any parameters.
> 
> Each succeeding item MUST, compared to the previous item, obey any one of the following:
> 
> - Have a larger min_fee_msat, and equal proportional.
> - Have a larger proportional, and equal min_fee_msat.
> - Have a larger min_fee_msat, AND larger proportional.
> 
> 
> Rationale This simplifies how the client expresses the expected opening fee to the user, as it assures the client that the order of the fee rates is strictly increasing.



Fix (patch):
diff --git a/lightning-liquidity/src/lsps2/service.rs b/lightning-liquidity/src/lsps2/service.rs
index abab51366ff..6d69925fa2d 100644
--- a/lightning-liquidity/src/lsps2/service.rs
+++ b/lightning-liquidity/src/lsps2/service.rs
@@ -12,6 +12,7 @@
 use alloc::string::{String, ToString};
 use alloc::vec::Vec;
 
+use core::cmp::Ordering as CmpOrdering;
 use core::ops::Deref;
 use core::sync::atomic::{AtomicUsize, Ordering};
 
@@ -645,13 +646,21 @@ where
 
 					match self.remove_pending_request(&mut peer_state_lock, &request_id) {
 						Some(LSPS2Request::GetInfo(_)) => {
-							let response = LSPS2Response::GetInfo(LSPS2GetInfoResponse {
-								opening_fee_params_menu: opening_fee_params_menu
+							let mut opening_fee_params_menu: Vec<LSPS2OpeningFeeParams> =
+								opening_fee_params_menu
 									.into_iter()
 									.map(|param| {
 										param.into_opening_fee_params(&self.config.promise_secret)
 									})
-									.collect(),
+									.collect();
+							opening_fee_params_menu.sort_by(|a, b| {
+								match a.min_fee_msat.cmp(&b.min_fee_msat) {
+									CmpOrdering::Equal => a.proportional.cmp(&b.proportional),
+									other => other,
+								}
+							});
+							let response = LSPS2Response::GetInfo(LSPS2GetInfoResponse {
+								opening_fee_params_menu,
 							});
 							(Ok(()), Some(response))
 						},
Repository: juhaku/utoipa (Rust)

Issue:
Trouble creating schema for structs with Arc
Hi,
I'm trying to use utoipa with my project, and I stumbled with an issue when trying to use ToSchema with a struct that uses `Arc`. A way to reproduce the issue would be:
```
use std::sync::Arc;
use serde_json;
use utoipa::ToSchema;

#[derive(ToSchema)]
struct B {
    a: u32,
    b: String,
}

#[derive(ToSchema)]
pub struct A {
    z: Arc<B>,
    zz: Arc<String>,
}

fn main() {
    let z = &A::schema().1;
    println!("{}", serde_json::to_string(z).unwrap());
}
```
which produces:
`{"type":"object","required":["z","zz"],"properties":{"z":{"$ref":"#/components/schemas/Arc"},"zz":{"$ref":"#/components/schemas/Arc"}}}`

I'm assuming that's not by design? I took the liberty of proposing a change to treat Arc's as Box or RefCell:
https://github.com/juhaku/utoipa/pull/690
maybe it could get included in the next release? :)



Fix (patch):
diff --git a/utoipa-gen/src/component.rs b/utoipa-gen/src/component.rs
index d1d80268..fe257886 100644
--- a/utoipa-gen/src/component.rs
+++ b/utoipa-gen/src/component.rs
@@ -280,6 +280,7 @@ impl<'t> TypeTree<'t> {
             "Option" => Some(GenericType::Option),
             "Cow" => Some(GenericType::Cow),
             "Box" => Some(GenericType::Box),
+            "Arc" => Some(GenericType::Arc),
             "RefCell" => Some(GenericType::RefCell),
             _ => None,
         }
@@ -392,6 +393,7 @@ pub enum GenericType {
     Cow,
     Box,
     RefCell,
+    Arc,
 }
 
 trait Rename {
@@ -507,15 +509,18 @@ impl<'c> ComponentSchema {
                 })
                 .to_tokens(&mut tokens);
             }
-            Some(GenericType::Cow) | Some(GenericType::Box) | Some(GenericType::RefCell) => {
+            Some(GenericType::Cow)
+            | Some(GenericType::Box)
+            | Some(GenericType::RefCell)
+            | Some(GenericType::Arc) => {
                 ComponentSchema::new(ComponentSchemaProps {
                     type_tree: type_tree
                         .children
                         .as_ref()
-                        .expect("CompnentSchema generic container type should have children")
+                        .expect("ComponentSchema generic container type should have children")
                         .iter()
                         .next()
-                        .expect("CompnentSchema generic container type should have 1 child"),
+                        .expect("ComponentSchema generic container type should have 1 child"),
                     features: Some(features),
                     description,
                     deprecated,
Repository: paradigmxyz/reth (Rust)

Issue:
Rename "Tree Task" thread name to something else
### Describe the feature

Right now we call the thread that runs execution, and handles engine messages, the "tree task":
https://github.com/paradigmxyz/reth/blob/a3298ecfdd2f604e6fc288bf803aa2980637e82d/crates/engine/tree/src/tree/mod.rs#L392

This was useful when we were calling this part of the code the blockchain tree, but it might be more useful if we call this thread something like the "engine task" or "block validation task". We should rename it 

### Additional context

_No response_



Fix (patch):
diff --git a/crates/engine/tree/src/tree/mod.rs b/crates/engine/tree/src/tree/mod.rs
index 929d5493df1..c7fe61de90d 100644
--- a/crates/engine/tree/src/tree/mod.rs
+++ b/crates/engine/tree/src/tree/mod.rs
@@ -389,7 +389,7 @@ where
             evm_config,
         );
         let incoming = task.incoming_tx.clone();
-        std::thread::Builder::new().name("Tree Task".to_string()).spawn(|| task.run()).unwrap();
+        std::thread::Builder::new().name("Engine Task".to_string()).spawn(|| task.run()).unwrap();
         (incoming, outgoing)
     }
Repository: wasm-bindgen/wasm-bindgen (Rust)

Issue:
Missing "options" parameter from Date.to_locale_time_string
According to the [MDN docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleTimeString#options), toLocalTimeString takes an options parameter but it's missing from js-sys 
[js-sys::Date.to_locale_time_string](https://docs.rs/js-sys/latest/js_sys/struct.Date.html#method.to_locale_time_string)

### Workaround
You can use [Reflect](https://docs.rs/js-sys/latest/js_sys/Reflect/index.html) to call it directly. Here's a wrapper I made to do this.
```rust
use js_sys::{Date, Reflect};
use wasm_bindgen::JsValue;

pub fn to_local_time_string(date: &Date, locale: &str, options: &JsValue) -> Result<String, JsValue> {
    let method = Reflect::get(&date.into(), &JsValue::from("toLocaleTimeString"))?;
    let result = js_sys::Function::from(method).call2(
        &date.clone().into(),
        &JsValue::from(locale),
        options,
    )?;

    // Convert the result to a string and return
    result
        .as_string()
        .ok_or_else(|| JsValue::from("Failed to convert to string"))
}
```



Fix (patch):
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 16bd83de8e0..f144ab366c6 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -17,6 +17,9 @@
 * Add `--list`, `--ignored`, `--exact` and `--nocapture` to `wasm-bindgen-test-runner`, analogous to `cargo test`.
   [#4356](https://github.com/rustwasm/wasm-bindgen/pull/4356)
 
+* Add bindings to `Date.to_locale_time_string_with_options`.
+  [#4384](https://github.com/rustwasm/wasm-bindgen/pull/4384)
+
 ### Changed
 
 * Optional parameters are now typed as `T | undefined | null` to reflect the actual JS behavior.
diff --git a/crates/js-sys/src/lib.rs b/crates/js-sys/src/lib.rs
index 459e4d93953..ac1d51bfadd 100644
--- a/crates/js-sys/src/lib.rs
+++ b/crates/js-sys/src/lib.rs
@@ -3392,6 +3392,13 @@ extern "C" {
     #[wasm_bindgen(method, js_name = toLocaleTimeString)]
     pub fn to_locale_time_string(this: &Date, locale: &str) -> JsString;
 
+    #[wasm_bindgen(method, js_name = toLocaleTimeString)]
+    pub fn to_locale_time_string_with_options(
+        this: &Date,
+        locale: &str,
+        options: &JsValue,
+    ) -> JsString;
+
     /// The `toString()` method returns a string representing
     /// the specified Date object.
     ///
Repository: GreptimeTeam/greptimedb (Rust)

Issue:
bug: enabling `cache_path` results in json decode err
### What type of bug is this?

Unexpected error

### What subsystems are affected?

Datanode

### What happened?

#### what happened
Setup
1. [datanode]use S3 as backend storage
2. [datanode]set `cache_path` option
3. start datanode in distribute mode
4. datanode failed to start

After modifying `DecodeJsonSnafu` to print error json string, it seemed the json was cut in the middle. Error log is attached below.

[err.log](https://github.com/GreptimeTeam/greptimedb/files/11320607/err.log)

#### expected
datanode starts as normal and caches S3 content to local path


### What operating system did you use?

Linux Docker pod

### Relevant log output and stack trace

_No response_

### How can we reproduce the bug?

see **What happened?**




Fix (patch):
diff --git a/src/object-store/src/cache_policy.rs b/src/object-store/src/cache_policy.rs
index cb08a26d99da..81275d7d15f6 100644
--- a/src/object-store/src/cache_policy.rs
+++ b/src/object-store/src/cache_policy.rs
@@ -93,7 +93,7 @@ impl<I: Accessor, C: Accessor> LayeredAccessor for LruCacheAccessor<I, C> {
         let cache_path = self.cache_path(&path, &args);
         let lru_cache = self.lru_cache.clone();
 
-        match self.cache.read(&cache_path, OpRead::default()).await {
+        match self.cache.read(&cache_path, args.clone()).await {
             Ok((rp, r)) => {
                 increment_counter!(OBJECT_STORE_LRU_CACHE_HIT);
 
@@ -116,7 +116,7 @@ impl<I: Accessor, C: Accessor> LayeredAccessor for LruCacheAccessor<I, C> {
                 writer.write(Bytes::from(buf)).await?;
                 writer.close().await?;
 
-                match self.cache.read(&cache_path, OpRead::default()).await {
+                match self.cache.read(&cache_path, args.clone()).await {
                     Ok((rp, reader)) => {
                         let r = {
                             // push new cache file name to lru
Repository: zephyrproject-rtos/zephyr (C)

Issue:
tests: posix: common: rework testsuite to de-duplicate code, narrow test scope, etc
**Is your enhancement proposal related to a problem? Please describe.**
It's become very evident there there is significant bitrot in `tests/posix/common`
* State is spread throughout not only `pthread.c` but most other places

**Describe the solution you'd like**

* Each component should be in it's own `ZTEST_SUITE()` instead of using a single `posix_apis` testsuite
  * They can all still be a part of the `common` app (unless it really makes sense to move them out - e.g. sleep APIs?)
  * barrier, clock, cond, fnmatch, mqueue, mutex, pthread, pthread_attr, rwlock, semaphore, signal, sleep, spinlock, timer, uname
* for `pthread.c`, rather than testing many things in only a couple of `ZTEST()` cases, it's probably better to narrow the of each `ZTEST()` and test many things in many `ZTEST()` cases
* potentially utilize `setup()`, `before()`, `after()`, and `teardown()` callbacks for `ZTEST_SUITE()`
* potentially use `ZTEST_F()` for testcases and fixtures to separately track state for each suite
* make tests more concise
  * avoid use of temporary variables, branches, and printks
  * instead of `ret = pthread_..(); zassert_.. (ret, ...)`, just use `zassert_...(pthread_...())`
  * preserve existing zassert error messages, if it makes sense

**Describe alternatives you've considered**
Not refactoring the testsuite code and having to continue dealing with state being spread everywhere.

**Additional context**
Decided after wrestling with #67085 for days (months?).

Actually, I wanted to put a `struct posix_thread_attr` inside of `struct posix_thread` 6 months ago, and the testsuite / techdebt was the major limiting factor. It only took 6 months of working on this in my "spare time" to make it happen 😅 

- [x] https://github.com/zephyrproject-rtos/zephyr/pull/67094
- [ ] https://github.com/zephyrproject-rtos/zephyr/pull/67575
- [ ] Possibly more?



Fix (patch):
diff --git a/lib/posix/clock.c b/lib/posix/clock.c
index 1a59aa741f906..a8835a4424847 100644
--- a/lib/posix/clock.c
+++ b/lib/posix/clock.c
@@ -235,3 +235,23 @@ int clock_getcpuclockid(pid_t pid, clockid_t *clock_id)
 
 	return 0;
 }
+
+#ifdef CONFIG_ZTEST
+#include <zephyr/ztest.h>
+static void reset_clock_base(void)
+{
+	K_SPINLOCK(&rt_clock_base_lock) {
+		rt_clock_base = (struct timespec){0};
+	}
+}
+
+static void clock_base_reset_rule_after(const struct ztest_unit_test *test, void *data)
+{
+	ARG_UNUSED(test);
+	ARG_UNUSED(data);
+
+	reset_clock_base();
+}
+
+ZTEST_RULE(clock_base_reset_rule, NULL, clock_base_reset_rule_after);
+#endif /* CONFIG_ZTEST */
Repository: capstone-engine/capstone (C)

Issue:
[x86] pseudo opcode adjustment for vcmpnlesd is wrong to vcompresspd
When disassemble asm code `vcmpnlesd %xmm2,%xmm0,%xmm3`, whose machine codes are `\xc5\xfb\xc2\xda\x06`, capstone got a wrong opcode 804(X86_INS_VCOMPRESSPD in x86.h `enum x86_insn`).

The origin opcode is 797(X86_INS_VCMP in x86.h `enum x86_insn`), while is adjusted to 804 in cs_disasm function. The displacement(7) is from printSSEAVXCC.

We can reproduce the problem by disassemble `\xc5\xfb\xc2\xda\x06` machine codes alonely by capstone. Such as code snippets below:
```c
#include <stdio.h>
#include <stdint.h>
#include "capstone.h"

int main() {
    csh handle;
    cs_insn *insn;
    cs_err err = cs_open(CS_ARCH_X86, CS_MODE_64, &handle);
    const uint8_t code[] = {0xc5, 0xfb, 0xc2, 0xda, 0x06};
    int count = cs_disasm(handle, code, 16, 0, 1, &insn);

    printf("opcode: %d, mnemonic: %s\n", insn[0].id, insn[0].mnemonic);

    cs_free(insn, count);
    cs_close(&handle);

    return 0;
}
```
Compiling with `gcc test.c -I include/capstone/ -L. -lcapstone` and run with `./a.out`, the output is `opcode: 804, mnemonic: vcmpnlesd`.



Fix (patch):
diff --git a/cs.c b/cs.c
index 65f89b8e5b..fc74d7ccfd 100644
--- a/cs.c
+++ b/cs.c
@@ -1209,7 +1209,7 @@ size_t CAPSTONE_API cs_disasm(csh ud, const uint8_t *buffer, size_t size, uint64
 			fill_insn(handle, insn_cache, ss.buffer, &mci, handle->post_printer, buffer);
 
 			// adjust for pseudo opcode (X86)
-			if (handle->arch == CS_ARCH_X86)
+			if (handle->arch == CS_ARCH_X86 && insn_cache->id != X86_INS_VCMP)
 				insn_cache->id += mci.popcode_adjust;
 
 			next_offset = insn_size;
Repository: avahi/avahi (C)

Issue:
Reachable assertion in avahi_dns_packet_append_record
It can be triggered by unprivileged local users (unless `disable-user-service-publishing` is set to `yes` explicitly):
```sh
avahi-publish -s T _qotd._tcp 22 $(perl -le 'print "A " x 100000')
```
```sh
dns.c:806: avahi_dns_packet_append_record: Assertion `size <= AVAHI_DNS_RDATA_MAX' failed.
```
```sh
#0  0x00007f848f08ec0c in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007f848f03e986 in raise () from /lib64/libc.so.6
#2  0x00007f848f0287f4 in abort () from /lib64/libc.so.6
#3  0x00007f848f02871b in __assert_fail_base.cold () from /lib64/libc.so.6
#4  0x00007f848f037536 in __assert_fail () from /lib64/libc.so.6
#5  0x00007f848fdd6524 in avahi_dns_packet_append_record (p=0x7f848e44b800, r=0x604000007ad0, cache_flush=0, max_ttl=0) at dns.c:806
#6  0x00007f848fda0055 in elapse_callback (e=0x60600002f6c0, data=0x60600002f660) at probe-sched.c:265
#7  0x00007f848fd3d5d7 in expiration_event (timeout=0x606000000aa0, userdata=0x6030000008e0) at timeeventq.c:94
#8  0x00007f849080a115 in timeout_callback (t=0x606000000aa0) at simple-watch.c:447
#9  0x00007f849080b6d2 in avahi_simple_poll_dispatch (s=0x60e000000040) at simple-watch.c:570
#10 0x00007f849080c03f in avahi_simple_poll_iterate (s=0x60e000000040, timeout=-1) at simple-watch.c:605
#11 0x0000000000413103 in run_server (c=0x51d4e0 <config>) at main.c:1268
#12 0x0000000000415069 in main (argc=5, argv=0x7fffeaf698a8) at main.c:1686
```


Discussion: This issue has CVE-2023-38469 assigned.



Fix (patch):
diff --git a/avahi-core/rr.c b/avahi-core/rr.c
index 2bb892445..9c04ebbdb 100644
--- a/avahi-core/rr.c
+++ b/avahi-core/rr.c
@@ -32,6 +32,7 @@
 #include <avahi-common/malloc.h>
 #include <avahi-common/defs.h>
 
+#include "dns.h"
 #include "rr.h"
 #include "log.h"
 #include "util.h"
@@ -689,11 +690,17 @@ int avahi_record_is_valid(AvahiRecord *r) {
         case AVAHI_DNS_TYPE_TXT: {
 
             AvahiStringList *strlst;
+            size_t used = 0;
 
-            for (strlst = r->data.txt.string_list; strlst; strlst = strlst->next)
+            for (strlst = r->data.txt.string_list; strlst; strlst = strlst->next) {
                 if (strlst->size > 255 || strlst->size <= 0)
                     return 0;
 
+                used += 1+strlst->size;
+                if (used > AVAHI_DNS_RDATA_MAX)
+                    return 0;
+            }
+
             return 1;
         }
     }
Repository: cc65/cc65 (C)

Issue:
cc65: Compiler accepts structs with flexible members as struct fields
cc65 allows struct fields that are structs with flexible array members:

```c      
typedef struct x {
    int a;
    int b[];    /* Ok: Flexible array member can be last */
} x;
    
struct y {
    x   x;      /* Not ok but accepted: Contains flexible array member */
    int a;
};
```


cc65: Compiler allows arrays of structs with flexible array members
The following is illegal according to the standard but accepted by cc65:

```c
struct x {
    int a;
    int c;
    int b[];
};

struct x y[3];          /* Should be an error */
````
 


Discussion: #2017 is closely related
Could there be any value supporting this as an extension like gcc's/clang's? Or should an error be raised?
I don't see a real use for it and it complicates things a lot. How, for example, would `struct y` be statically initialized? Not supporting it is cleaner and easier to implement.

#2016 is closely related
Could there be any value supporting this as an extension like gcc's/clang's? Or should an error be raised?



Fix (patch):
diff --git a/src/cc65/declare.c b/src/cc65/declare.c
index 59eb555c42..80be9ceb7f 100644
--- a/src/cc65/declare.c
+++ b/src/cc65/declare.c
@@ -515,6 +515,13 @@ static void CheckArrayElementType (Type* DataType)
                 if (!IsTypeVoid (T) || IS_Get (&Standard) != STD_CC65) {
                     Error ("Array of 0-size element type '%s'", GetFullTypeName (T));
                 }
+            } else {
+                if (IsTypeStruct (T)) {
+                    SymEntry* TagEntry = GetESUTagSym (T);
+                    if (TagEntry && SymHasFlexibleArrayMember (TagEntry)) {
+                        Error ("Invalid use of struct with flexible array member");
+                    }
+                }
             }
         } else {
             ++T;
@@ -1193,6 +1200,9 @@ static SymEntry* ParseStructSpec (const char* Name, unsigned* DSFlags)
                     if (TagEntry && SymHasFlexibleArrayMember (TagEntry)) {
                         Field->Flags |= SC_HAVEFAM;
                         Flags        |= SC_HAVEFAM;
+                        if (IsTypeStruct (Decl.Type)) {
+                            Error ("Invalid use of struct with flexible array member");
+                        }
                     }
                 }
Repository: cc65/cc65 (C)

Issue:
Evaluation of constant expression in preprocessing directives may produce incorrect results
Compiling this code in C99 mode:
```
#if (0u - 1) < 0
#error
#endif

#if !1u - 1 > 0
#error
#endif

#if (1 & 1u) - 2 < 0
#error
#endif

#if (1 | 1u) - 2 < 0
#error
#endif

#if (1 ^ 1u) - 2 < 0
#error
#endif

#if (1u >> 1) - 2 < 0
#error
#endif

#if (0u << 1) - 1 < 0
#error
#endif
```
produces:
```
<source>:2: Error: #error
<source>:6: Error: #error
<source>:10: Error: #error
<source>:14: Error: #error
<source>:18: Error: #error
<source>:22: Error: #error
<source>:26: Error: #error
```
while in C99 all expressions evaluate to false (zero).



Fix (patch):
diff --git a/src/cc65/ppexpr.c b/src/cc65/ppexpr.c
index 8d8c0b65d7..bedb015074 100644
--- a/src/cc65/ppexpr.c
+++ b/src/cc65/ppexpr.c
@@ -55,7 +55,6 @@ static int PPEvaluationFailed  = 0;
 
 
 
-static void PPhie0 (PPExpr* Expr);
 static void PPhie1 (PPExpr* Expr);
 
 
@@ -138,7 +137,7 @@ static void PPhiePrimary (PPExpr* Expr)
             ** recursively.
             */
             NextToken ();
-            PPhie0 (Expr);
+            PPhie1 (Expr);
             ConsumeRParen ();
             break;
 
@@ -263,6 +262,7 @@ void PPhie10 (PPExpr* Expr)
             NextToken ();
             PPhie10 (Expr);
             Expr->IVal = !Expr->IVal;
+            Expr->Flags &= ~PPEXPR_UNSIGNED;    /* Result is signed */
             break;
 
         case TOK_CEOF:
@@ -424,10 +424,10 @@ static void PPhie_compare (const token_t* Ops,    /* List of generators */
                 }
             }
         }
-    }
 
-    /* The result is signed */
-    Expr->Flags &= ~PPEXPR_UNSIGNED;
+        /* The result is signed */
+        Expr->Flags &= ~PPEXPR_UNSIGNED;
+    }
 }
 
 
@@ -711,7 +711,7 @@ static void PPhieQuest (PPExpr* Expr)
 
         /* Parse second expression */
         PPExprInit (&Expr2);
-        PPhie0 (&Expr2);
+        PPhie1 (&Expr2);
 
         /* Skip the colon */
         ConsumeColon ();
@@ -809,23 +809,6 @@ static void PPhie1 (PPExpr* Expr)
 
 
 
-static void PPhie0 (PPExpr* Expr)
-/* Handle the comma "," operator */
-{
-    PPhie1 (Expr);
-
-    while (CurTok.Tok == TOK_COMMA) {
-        /* Skip the comma */
-        NextToken ();
-        /* Reset the expression */
-        PPExprInit (Expr);
-        /* Use the next operand as the value instead */
-        PPhie1 (Expr);
-    }
-}
-
-
-
 void ParsePPExprInLine (PPExpr* Expr)
 /* Parse a line for PP expression */
 {
@@ -836,7 +819,7 @@ void ParsePPExprInLine (PPExpr* Expr)
 
     /* Parse */
     PPExprInit (Expr);
-    PPhie0 (Expr);
+    PPhie1 (Expr);
 
     /* If the evaluation fails, the result is always zero */
     if (PPEvaluationFailed) {
Repository: lvgl/lvgl (C)

Issue:
Label does not clip vertically
### LVGL version

v9.3.0

### Platform

STM32U5

### What happened?

I created a label with fixed size, border visible, and long mode set to wrap. The text is drawn beyond the bottom border.

Current

![Image](https://github.com/user-attachments/assets/8db4f007-af9d-4d68-9054-53a3d9c35927)

Expected

![Image](https://github.com/user-attachments/assets/7497b055-cbf7-4ea8-9e08-4a67f2b56941)

### How to reproduce?

    lv_obj_t* label1 = lv_label_create(lv_screen_active());
    lv_label_set_long_mode(label1, LV_LABEL_LONG_MODE_WRAP);
    lv_label_set_text(label1, "This is a long text that should be clipped vertically");
    lv_obj_set_size(label1, 150, 25);
    lv_obj_set_pos(label1, 10, 10);
    lv_obj_set_style_border_width(label1, 1, LV_PART_MAIN);
    lv_obj_set_style_border_color(label1, lv_palette_main(LV_PALETTE_RED), LV_PART_MAIN);



Fix (patch):
diff --git a/src/widgets/label/lv_label.c b/src/widgets/label/lv_label.c
index 8fa790ab5691..186c9b25c0c9 100644
--- a/src/widgets/label/lv_label.c
+++ b/src/widgets/label/lv_label.c
@@ -884,7 +884,13 @@ static void draw_main(lv_event_t * e)
         layer->_clip_area = clip_area_ori;
     }
     else {
+        /*Labels have some extra draw area by default to not clip characters with
+         *italic, handwritten and other less standard fonts.
+         *However, with most of the fonts typically it's safe to clip at least to bottom side*/
+        const lv_area_t clip_area_ori = layer->_clip_area;
+        layer->_clip_area.y2 = txt_clip.y2;
         lv_draw_label(layer, &label_draw_dsc, &txt_coords);
+        layer->_clip_area = clip_area_ori;
     }
 
     lv_area_t clip_area_ori = layer->_clip_area;