Add num_children method to some gdb pretty-printers
gdb doesn't have a way to know when an object hasn't yet been initialized, and in this case, if a pretty-printer returns an absurd number of children, this can result in apparent hangs in some modes. This came up specifically with DAP, see this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=33594
This patch (mostly) addresses this potential issue in the Rust pretty-printers, by adding 'num_children' methods. In particular a method like this is added when the number of children is variable and also relatively easy to compute. (I.e., I didn't attempt the btree printers.)
Supplying num_children is good for DAP regardless of the initialization problem, because DAP requires a count of child objects and this is more efficient than enumerating the children, which is gdb's fallback approach.
Minor fixes to StdNonZeroNumberProvider for gdb
While looking at the pretty-printers, I found a few minor oddities in StdNonZeroNumberProvider.
First, gdb.Type.fields() already returns a sequence, so there's no need to call list().
Second, it's more idiomatic for the (somewhat misnamed) to_string method to simply return the underlying gdb.Value. This also lets gdb apply whatever formats were passed to `print`, as the new test shows.
Third, there's no need to use the field's name when looking up a field in a value, the gdb.Field itself can be used.
std-detect: improve detect macro docs
Specifically, document that the detect macros expand to `true` when the feature is statically enabled.
Now that we have a bunch of these macros, perhaps we should streamline further how they are documented?
r? ``@Amanieu``
Add default sanitizers to TargetOptions
Some sanitizers are part of a system's ABI, like the shadow call stack on Aarch64 and RISC-V Fuchsia. Typically ABI options have other spellings, but LLVM has, for historical reasons, marked this as a sanitizer instead of an alternate ABI option. As a result, Fuchsia targets may not be compiled against the correct ABI unless this option is set. This hasn't caused correctness problems, since the backend reserves the SCS register, and thus preserves its value. But this is an issue for unwinding, as the SCS will not be an array of PCs describing the call complete call chain, and will have gaps from callers that don't use the correct ABI.
In the long term, I'd like to see all the sanitizer configs that all frontends copy from clang moved into llvm's libFrontend, and exposed so that frontend consumers can use a small set of simple APIs to use sanitizers in a consistent way across the LLVM ecosystem, but that work is not yet ready today.
Fix ICE from lit_to_mir_constant caused by type error
Fixesrust-lang/rust#148515
we still need to mark that there were errors to prevent later phases (like MIR building) from proceeding.
Unify the configuration of the compiler docs
Previously it was rather inconsistent which crates got the rust logo and which didn't and setting html_root_url was forgotten in many cases.
[rustdoc search] Simplify itemTypes and filter "dependencies"
We currently have a list of type filters, some constants to be able to index the list of type filters and finally a `switch` to include some types in a given filter (for example when we filter on `constant`, we also include `associatedconstant` items).
r? ``@notriddle``
Deduplicate deprecation warning when using unit or tuple structs
First commit adds a test that's broken currently, 2nd commit fixes it.
Created with `@WaffleLapkin`
gdb doesn't have a way to know when an object hasn't yet been
initialized, and in this case, if a pretty-printer returns an absurd
number of children, this can result in apparent hangs in some modes.
This came up specifically with DAP, see this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=33594
This patch (mostly) addresses this potential issue in the Rust
pretty-printers, by adding 'num_children' methods. In particular a
method like this is added when the number of children is variable and
also relatively easy to compute. (I.e., I didn't attempt the btree
printers.)
Supplying num_children is good for DAP regardless of the
initialization problem, because DAP requires a count of child objects
and this is more efficient than enumerating the children, which is
gdb's fallback approach.
While looking at the pretty-printers, I found a few minor oddities in
StdNonZeroNumberProvider.
First, gdb.Type.fields() already returns a sequence, so there's no
need to call list().
Second, it's more idiomatic for the (somewhat misnamed) to_string
method to simply return the underlying gdb.Value. This also lets gdb
apply whatever formats were passed to `print`, as the new test shows.
Third, there's no need to use the field's name when looking up a field
in a value, the gdb.Field itself can be used.
error on non-rustic ABIs using unsized parameters
tracking issue: https://github.com/rust-lang/rust/issues/48055
This came up in https://github.com/rust-lang/rust/pull/144529#discussion_r2470214068.
The idea is that the layout of an unsized type is unstable (following the rust layout rules), and hence stable ABIs should not use unsized types. On stable, unsized types (or generics with a `?Sized` bound) are not accepted as parameters, so the errors introduced by this PR can only be observed when the unstable `unsized_fn_params` feature is enabled.
r? `@bjorn3`
cc `@RalfJung`
Relax r29 inline asm restriction on PowerPC64 targets
LLVM uses r29 to hold a base pointer for some PowerPC target configurations. It is usable on all 64 bit targets as a callee save register.
r? `@Amanieu`
Ralf Jung