Load include_bytes! directly into an Lrc
This PR deletes an innocent-looking `.into()` that was converting from a `Vec<u8>` to `Lrc<[u8]>`. This has significant runtime and memory overhead when using `include_bytes!` to pull in a large binary file.
Add a specialization for encoding byte arrays in rmeta
This specialization already exists for FileEncoder, but since EncodeContext is implemented by forwarding down to FileEncoder, using EncodeContext used to bypass the specialization.
wasi: round up the size for `aligned_alloc`
C11 `aligned_alloc` requires that the size be a multiple of the
alignment. This is enforced in the wasi-libc emmalloc implementation,
which always returns NULL if the size is not a multiple.
(The default `MALLOC_IMPL=dlmalloc` does not currently check this.)
Unify CSS color formats a bit more
When `rgb` format doesn't have an `rgba` equivalent, I turned it into hex format. I also "decapitalized" hex formats.
r? `@notriddle`
Add an (perma-)unstable option to disable vtable vptr
This flag is intended for evaluation of trait upcasting space cost for embedded use cases.
Compared to the approach in #112355, this option provides a way to evaluate end-to-end cost of trait upcasting. Rationale: https://github.com/rust-lang/rust/issues/112355#issuecomment-1658207769
## How this flag should be used (after merge)
Build your project with and without `-Zno-trait-vptr` flag. If you are using cargo, set `RUSTFLAGS="-Zno-trait-vptr"` in the environment variable. You probably also want to use `-Zbuild-std` or the binary built may be broken. Save both binaries somewhere.
### Evaluate the space cost
The option has a direct and indirect impact on vtable space usage. Directly, it gets rid of the trait vptr entry needed to store a pointer to a vtable of a supertrait. (IMO) this is a small saving usually. The larger saving usually comes with the indirect saving by eliminating the vtable of the supertrait (and its parent).
Both impacts only affects vtables (notably the number of functions monomorphized should , however where vtable reside can depend on your relocation model. If the relocation model is static, then vtable is rodata (usually stored in Flash/ROM together with text in embedded scenario). If the binary is relocatable, however, the vtable will live in `.data` (more specifically, `.data.rel.ro`), and this will need to reside in RAM (which may be a more scarce resource in some cases), together with dynamic relocation info living in readonly segment.
For evaluation, you should run `size` on both binaries, with and without the flag. `size` would output three columns, `text`, `data`, `bss` and the sum `dec` (and it's hex version). As explained above, both `text` and `data` may change. `bss` shouldn't usually change. It'll be useful to see:
* Percentage change in text + data (indicating required flash/ROM size)
* Percentage change in data + bss (indicating required RAM size)
Remove some wasm/emscripten ignores
I'm planning on landing a few PRs like this that remove ignores that aren't required. This just covers mir-opt and codegen tests.
Move a local to the `#if` block where it is used
For other cases (LLVM < 17), this was complaining under `-Wall`:
```
warning: llvm-wrapper/PassWrapper.cpp: In function ‘void LLVMRustPrintTargetCPUs(LLVMTargetMachineRef, const char*)’:
warning: llvm-wrapper/PassWrapper.cpp:311:26: warning: unused variable ‘MCInfo’ [-Wunused-variable]
warning: 311 | const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
warning: | ^~~~~~
```
This reverts commit 441086879821d554ecdfde391e767d1a954fd5e2, reversing
changes made to 249595b7523fc07a99c1adee90b1947739ca0e5b.
This causes linker failures with the binutils version used by
cross (#115239), as well as miscompilations when using the mold
linker.
compile rust-anaylzer with `x check` if it's enabled
By default, `x check` doesn't compile the rust-analyzer. But when it's enabled in the config's tools section, there's no reason not to do it. This change allows `x check` to compile rust-analyzer if it's enabled in config's tools section.
Helps to #115031
Correct and expand documentation of `handle_alloc_error` and `set_alloc_error_hook`.
The primary goal of this change is to remove the false claim that `handle_alloc_error` always aborts; instead, code should be prepared for `handle_alloc_error` to possibly unwind, and be sound under that condition.
I saw other opportunities for improvement, so I have added all the following information:
* `handle_alloc_error` may panic instead of aborting. (Fixes#114898)
* What happens if a hook returns rather than diverging.
* A hook may panic. (This was already demonstrated in an example, but not stated in prose.)
* A hook must be sound to call — it cannot assume that it is only called by the runtime, since its function pointer can be retrieved by safe code.
I've checked these statements against the source code of `alloc` and `std`, but there may be nuances I haven't caught, so a careful review is welcome.
coverage: Tidy up `run-coverage` tests in several small ways
Prior to #114875 (anonymized line numbers), these tests were very sensitive to lines being added/removed, since doing so would change the line numbers in every subsequent line of output. Therefore they ended up with a few small style issues that weren't worth the hassle of fixing.
Now that we can freely rearrange lines without needing to re-bless the entire output, we can tidy up the tests in various trivial ways.
Go into more detail about panicking in drop.
This patch was sitting around in my drafts. I don't recall the motivation, but I think it was someone expressing confusion over “will likely abort” (since, in fact, a panicking drop _not_ caused by dropping while panicking will predictably _not_ abort).
I hope that the new text will leave people well-informed about why not to panic and when it is reasonable to panic.
Point at type parameter that introduced unmet bound instead of full HIR node
```
error[E0277]: the size for values of type `[i32]` cannot be known at compilation time
--> $DIR/issue-87199.rs:18:15
|
LL | ref_arg::<[i32]>(&[5]);
| ^^^^^ doesn't have a size known at compile-time
```
instead of
```
error[E0277]: the size for values of type `[i32]` cannot be known at compilation time
--> $DIR/issue-87199.rs:18:22
|
LL | ref_arg::<[i32]>(&[5]);
| ---------------- ^^^^ doesn't have a size known at compile-time
| |
| required by a bound introduced by this call
```
------
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/own-bound-span.rs:14:24
|
LL | let _: <S as D>::P<String>;
| ^^^^^^ the trait `Copy` is not implemented for `String`
|
note: required by a bound in `D::P`
--> $DIR/own-bound-span.rs:4:15
|
LL | type P<T: Copy>;
| ^^^^ required by this bound in `D::P`
```
instead of
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/own-bound-span.rs:14:12
|
LL | let _: <S as D>::P<String>;
| ^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String`
|
note: required by a bound in `D::P`
--> $DIR/own-bound-span.rs:4:15
|
LL | type P<T: Copy>;
| ^^^^ required by this bound in `D::P`
```
Fix#105306.
Remove lub_empty from lexical region resolve
As of my understanding this method made sense when we had `ReEmpty`.
Removed `lub_empty` and made the calling site code equivalent.
r? `@lcnr` `@compiler-errors`
C11 `aligned_alloc` requires that the size be a multiple of the
alignment. This is enforced in the wasi-libc emmalloc implementation,
which always returns NULL if the size is not a multiple.
(The default `MALLOC_IMPL=dlmalloc` does not currently check this.)
Fix waiting on a query that panicked
This fixes waiting on a query that panicked. The code now looks for `QueryResult::Poisoned` in the query state in addition to the query cache. This fixes https://github.com/rust-lang/rust/issues/111528.
r? `@cjgillot`
Rollup of 4 pull requests
Successful merges:
- #115197 (Remove special cases that are no longer needed due to #112606)
- #115210 (Make `rustc_on_unimplemented` std-agnostic for `alloc::rc`)
- #115237 (Fixup sparc-unknown-none-elf table spacing)
- #115244 (Migrate GUI colors test to original CSS color format)
r? `@ghost`
`@rustbot` modify labels: rollup
Make `rustc_on_unimplemented` std-agnostic for `alloc::rc`
See https://github.com/rust-lang/rust/issues/112923
Just a few lines related to `alloc:rc` for `Send` and `Sync`.
That seems to be all of the `... = "std::..."` issues found, but there a few notes with `std::` inside them still.
r? `@WaffleLapkin`
Revert "Use the same DISubprogram for each instance of the same inline function within the caller"
This reverts commit 687bffa49375aa00bacc51f5d9adfb84a9453e17.
Reverting to resolve ICEs reported on nightly.
cc `@dpaoliello`
Fixes#115156
Stop emitting non-power-of-two vectors in (non-portable-SIMD) codegen
Fixes#115212
It's unclear what makes this not work sometimes, since it often *does* work, so for now just disable the unusual cases. A future PR can consider doing something smarter, but this is an easy and safe tweak that we can do to resolve the regressions for now.
