| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
lldb-formatters: Use StdSliceSyntheticProvider for &str
&str has associated summary provider which correctly displays string values in debugger, but while working on https://github.com/rust-lang/rust/pull/124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging
However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value
I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
44 let plain_str = "Hello";
45 let str_in_struct = Foo { inner: "Hello" };
46 let str_in_tuple = ("Hello", "World");
-> 47 zzz(); // #break
48 }
49
50 fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
vec = size=5 {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
(&str) plain_str = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
(strings_and_strs::Foo) str_in_struct = {
inner = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
}
((&str, &str)) str_in_tuple = {
0 = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
1 = "World" {
data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
}
```
After this PR it would look the following way:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
44 let plain_str = "Hello";
45 let str_in_struct = Foo { inner: "Hello" };
46 let str_in_tuple = ("Hello", "World");
-> 47 zzz(); // #break
48 }
49
50 fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
vec = size=5 {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
(&str) plain_str = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
(strings_and_strs::Foo) str_in_struct = {
inner = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
((&str, &str)) str_in_tuple = {
0 = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
1 = "World" {
[0] = 'W'
[1] = 'o'
[2] = 'r'
[3] = 'l'
[4] = 'd'
}
}
```
|
|
Rollup of 3 pull requests
Successful merges:
- #125214 (Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability)
- #125236 (Add tests for `-Zunpretty=expanded` ported from stringify's tests)
- #125251 (Clarify how String::leak and into_boxed_str differ )
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add tests for `-Zunpretty=expanded` ported from stringify's tests
This PR adds a new set of tests for the AST pretty-printer.
Previously, pretty-printer edge cases were tested by way of `stringify!` in [tests/ui/macros/stringify.rs](https://github.com/rust-lang/rust/blob/1.78.0/tests/ui/macros/stringify.rs), such as the tests added by https://github.com/rust-lang/rust/commit/419b26931b73209bfafdb9938c09e12b9d650613 and https://github.com/rust-lang/rust/commit/527e2eac17c5d3709e4e30e8b72ae33a6e8990b1.
Those tests will no longer provide effective coverage of the AST pretty-printer after #124141. `Nonterminal` and `TokenKind::Interpolated` are being removed, and a consequence is that `stringify!` will perform token stream pretty printing, instead of AST pretty printing, in all of the `stringify!` cases including $:expr and all other interpolations.
This PR adds 2 new ui tests with `compile-flags: -Zunpretty=expanded`:
- **tests/ui/unpretty/expanded-exhaustive.rs** — this test aims for exhaustive coverage of all the variants of `ExprKind`, `ItemKind`, `PatKind`, `StmtKind`, `TyKind`, and `VisibilityKind`. Some parts could use being fleshed out further, but the current state is roughly on par with what exists in the old stringify-based tests.
- **tests/ui/unpretty/expanded-interpolation.rs** — this test covers tricky macro metavariable edge cases that require the AST pretty printer to synthesize parentheses in order for the printed code to be valid Rust syntax.
r? `@nnethercote`
|
|
Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
|
|
|
|
GuillaumeGomez:migrate-rustdoc-scrape-examples-invalid-expr, r=jieyouxu
Migrate `run-make/rustdoc-scrape-examples-invalid-expr` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
Improve parser
Fixes #124935.
- Add a few more help diagnostics to incorrect semicolons
- Overall improved that function
- Addded a few comments
- Renamed diff_marker fns to git_diff_marker
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Add `-` (stdin) support in rustdoc
This PR adds support for the special `-` input which threats the input as coming from *stdin* instead of being a filepath.
Doing this also makes `rustdoc` consistent with `rustc` and ~~every~~ other tools. Full [motivation](https://github.com/rust-lang/rust/pull/124611#issuecomment-2094234876).
Fixes https://github.com/rust-lang/rust/issues/123671
r? `@fmease`
|
|
|
|
|
|
|
|
|
|
|
|
Migrate `run-make/issue-28766` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
|
|
Migrate `run-make/issue64319` to `rmake` and rename
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
~~I noticed that the Makefile was not listed in `allowed-run-makefiles` in Tidy. Does this mean the test was being ignored?~~ EDIT: No, it was there, just not in its expected alphabetical order.
EDIT2: Perhaps it could be interesting to clean this test visually by looping over the `rustc` calls, like in #125227.
|
|
Migrate `run-make/static-unwinding` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
An easy one after the last one, though the explanatory comment could use some clarification.
|
|
|
|
|
|
|
|
|
|
|
|
Give `FileDescription::{read, write}` access to the `MiriInterpCx `
fixes #3572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Migrate `run-make/rustdoc-with-out-dir-option` to new `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
Adjust Allocation Bytes used by Miri to custom MiriAllocBytes
Previously, the `MiriMachine` used `type Bytes = Box<[u8]>` for its allocations.
This PR swaps this out for a custom `MiriAllocBytes` type implemented in `alloc_bytes.rs`.
This is in anticipation of an extension to Miri's FFI, which will require its allocations to take care of alignment (the methods in `impl AllocBytes for Box<[u8]>` ignore this `_align: Align` argument).
Needs https://github.com/rust-lang/rust/pull/124492
|
|
set `rust.channel` properly in source tarballs
This change sets the appropriate channel by default when using nightly, beta or stable source tarballs.
Fixes #124618
|
|
Enable `rust-lld` on nightly `x86_64-unknown-linux-gnu`
We believe we have done virtually all the internal work and tests we could to prepare for using `lld` as the default linker (at least on Linux). We're IMHO at a point where we'd need to expand testing and coverage in order to make progress on this effort.
Therefore, for further testing and gathering real-world feedback, unexpected issues and use-cases, this PR enables `rust-lld` as the default linker:
- on nightly only (and dev channel)
- on `x86_64-unknown-linux-gnu` only
- when not using an external LLVM (except `download-ci-llvm`), so that distros are not impacted
as described in more detail in this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Enabling.20.60rust-lld.60.20on.20nightly.20.60x86_64-unknown-linux-gnu.60/near/433709343).
In case any issues happen to users, as e.g. lld is not bug-for-bug compatible with GNU ld, it's easy to disable with `-Zlinker-features=-lld` to revert to using the system's default linker.
---
I don't know who should review this kind of things, as it's somewhat of a crosscutting effort. Compiler contributor, compiler performance WG and infra member sounds perfect, so r? `@Mark-Simulacrum.`
The last crater run encountered a low number (44) of mainly avoidable issues, like small incompatibilities, user errors, and a difference between the two linkers about which default to use with `--gc-sections`. [Here's the triage report](https://hackmd.io/OAJxlxc6Te6YUot9ftYSKQ?view), categorizing the issues, with some analyses and workarounds. I'd appreciate another set of eyes looking at these results.
The changes in this PR have been test-driven for CI changes, try builds with tests enabled, rustc-perf with bootstrapping, in PR #113382.
For infra, about the CI change: this PR forces `rust.lld` to false on vanilla LLVM builders, just to make sure we have coverage without `rust-lld`. Though to be clear, just using an external LLVM is already enough to keep `rust.lld` to false, in turn reverting everything to using the system's default linker.
cc `@rust-lang/bootstrap` for the bootstrap and config change
cc `@petrochenkov` for the small compiler change
cc `@rust-lang/wg-compiler-performance`
The blog post announcing the change, that we expect to merge around the same time as we merge this PR, is open [on the blog repo](https://github.com/rust-lang/blog.rust-lang.org/pull/1319).
Bootstrap change history: this PR changes the default of a config option on `x86_64-unknown-linux-gnu`. It's, however, not expected to cause issues, or require any changes to existing configurations. It's a big enough change that people should at least know about it, in case it causes unexpected problems. If that happens, set `rust.lld = false` in your `config.toml` (and open an issue).
|
|
|
|
|
|
|
|
|
|
|
|
the default value changes on `x86_64-unknown-linux-gnu`, and semantics kinda
as it will impact the target's default linker
|
|
`x86_64-unknown-linux-gnu` has switched to using the self-contained linker
by default (unless asked not to), so we have to build rust-lld:
- when we build our own llvm
- when we use download-ci-llvm
- otherwise, when using an external llvm we can't enable it
|
