-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Rollup of 7 pull requests #148560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #148560
Conversation
document that the detect macros expand to `true` when the feature is statically enabled
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.
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.
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.
The link had a stray character that generated an invalid link.
…bel, r=Amanieu Make named asm_labels lint not trigger on hexagon register spans Fixes rust-lang#143021
…ochenkov 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.
…rue, r=Amanieu 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``
…ror-handling, r=lolbinarycat [rustdoc] Gracefully handle error in case we cannot run the compiler in doctests Fixes bug reported in [this comment](rust-lang#102981 (comment)). r? ``@lolbinarycat``
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.
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.
Fix broken qemu-cskyv2 link The link had a stray character that generated an invalid link.
|
Attempted rollup of everything except one iffy, but the included iffy failed merge. @bors r+ rollup=never p=5 |
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 401ae55427 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 401ae55 (parent) -> 642c19b (this PR) Test differencesShow 18 test diffsStage 0
Stage 1
Stage 2
Additionally, 10 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 642c19bfc3a5c1de985bf5d0cc8207ac9d22708a --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (642c19b): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary 3.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 474.482s -> 474.467s (-0.00%) |
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup