Rollup of 11 pull requests #144058
Merged
Rollup of 11 pull requests #144058
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
…tive Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Key changes include: - Removal of the word "syntax" from the lint message. More accurately, it could have been something like "syntax group" or "syntax category", but avoiding it completely is easier. - The primary lint message now reflects exactly which mismatch is occurring, instead of trying to be general. A new `help` line is general across the mismatch kinds. - Suggestions have been reduced to be more minimal, no longer also changing non-idiomatic but unrelated aspects. - Suggestion text no longer mentions changes when those changes don't occur in that specific suggestion.
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
This was done by making the tracing_chrome tracing layer check if "tracing_separate_line" was in the arguments of a span, and act accordingly.
Remove deprecated `Error::description` impl from `c_str::FromBytesWithNulError`
Use relative visibility when noting sealed trait to reduce false positive Fixes rust-lang#143392 I used relative visibility instead of just determining if it's public or not. r? compiler
resolve: Use interior mutability for extern module map Module map for extern modules is a lazily populated cache, it's not *significantly* mutable. If some logic in name resolver is parallelized, then this cache can be populated from any thread, and without affecting results of any speculative resolution. Unblocks rust-lang#143884. This is a part of [#gsoc > Project: Parallel Macro Expansion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/with/527348747). cc `@LorrensP-2158466`
…-errors update to literal-escaper-0.0.5 Quoting from the changelog, this version brings: - Use `NonZero<char/u8>` in `unescape_c_str` and `check_raw_c_str` to statically exclude nuls - Add `#[inline]` to small functions for improved performance
Opaque type collection: Guard against endlessly recursing free alias types See test description for technical details. Fixes rust-lang#131994. r? oli-obk (sry, your queue is large, so no rush & feel free to reassign)
…-lines-debuginfo, r=wesleywiser tests: Test line debuginfo for linebreaked function parameters Closes rust-lang#45010 which just [E-needs-test](rust-lang#45010 (comment)). To verify that this is actually a regression test, do this, which is a simplified and adapted version of what compiletest does for 1.39 and then 1.88: ```sh for toolchain in 1.39 1.88; do echo -e "\nWith $toolchain:" rustc +$toolchain "tests/codegen/fn-parameters-on-different-lines-debuginfo.rs" "--emit" "llvm-ir" "-o" "/tmp/fn-parameters-on-different-lines-debuginfo.ll" "-g" "-Copt-level=0" "build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" "--input-file" "/tmp/fn-parameters-on-different-lines-debuginfo.ll" "tests/codegen/fn-parameters-on-different-lines-debuginfo.rs" "--check-prefix=CHECK" "--dump-input-context" "100" && echo OK || echo FAIL done ``` which gives ``` With 1.39: FAIL With 1.88: OK ``` <details> <summary>Click to expand full output</summary> ``` $ for toolchain in 1.39 1.88; do echo -e "\nWith $toolchain:" rustc +$toolchain "tests/codegen/fn-parameters-on-different-lines-debuginfo.rs" "--emit" "llvm-ir" "-o" "/tmp/fn-parameters-on-different-lines-debuginfo.ll" "-g" "-Copt-level=0" "build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" "--input-file" "/tmp/fn-parameters-on-different-lines-debuginfo.ll" "tests/codegen/fn-parameters-on-different-lines-debuginfo.rs" "--check-prefix=CHECK" "--dump-input-context" "100" && echo OK || echo FAIL done With 1.39: tests/codegen/fn-parameters-on-different-lines-debuginfo.rs:16:16: error: CHECK-SAME: expected string not found in input // CHECK-SAME: line: 10 ^ /tmp/fn-parameters-on-different-lines-debuginfo.ll:69:42: note: scanning from here !10 = !DILocalVariable(name: "x", arg: 1, scope: !5, file: !3, line: 1, type: !9) ^ /tmp/fn-parameters-on-different-lines-debuginfo.ll:69:64: note: possible intended match here !10 = !DILocalVariable(name: "x", arg: 1, scope: !5, file: !3, line: 1, type: !9) ^ Input file: /tmp/fn-parameters-on-different-lines-debuginfo.ll Check file: tests/codegen/fn-parameters-on-different-lines-debuginfo.rs -dump-input=help explains the following input dump. Input was: <<<<<< 1: ; ModuleID = 'fn_parameters_on_different_lines_debuginfo.3a1fbbbh-cgu.0' 2: source_filename = "fn_parameters_on_different_lines_debuginfo.3a1fbbbh-cgu.0" 3: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" 4: target triple = "x86_64-unknown-linux-gnu" 5: 6: ``@str.0`` = internal constant [59 x i8] c"tests/codegen/fn-parameters-on-different-lines-debuginfo.rs" 7: ``@str.1`` = internal constant [28 x i8] c"attempt to add with overflow" 8: ``@panic_loc.2`` = private unnamed_addr constant { { [0 x i8]*, i64 }, { [0 x i8]*, i64 }, i32, i32 } { { [0 x i8]*, i64 } { [0 x i8]* bitcast ([28 x i8]* ``@str.1`` to [0 x i8]*), i64 28 }, { [0 x i8]*, i64 } { [0 x i8]* bitcast ([59 x i8]* ``@str.0`` to [0 x i8]*), i64 59 }, i32 13, i32 3 }, align 8 9: ``@__rustc_debug_gdb_scripts_section__`` = linkonce_odr unnamed_addr constant [34 x i8] c"\01gdb_load_rust_pretty_printers.py\00", section ".debug_gdb_scripts", align 1 10: 11: ; fn_parameters_on_different_lines_debuginfo::foo 12: ; Function Attrs: nonlazybind uwtable 13: define i32 ``@_ZN42fn_parameters_on_different_lines_debuginfo3foo17ha98e7c29f4ed8d60E(i32,`` i32) unnamed_addr #0 !dbg !5 { 14: start: 15: %y = alloca i32, align 4 16: %x = alloca i32, align 4 17: store i32 %0, i32* %x, align 4 18: call void ``@llvm.dbg.declare(metadata`` i32* %x, metadata !10, metadata !DIExpression()), !dbg !11 19: store i32 %1, i32* %y, align 4 20: call void ``@llvm.dbg.declare(metadata`` i32* %y, metadata !12, metadata !DIExpression()), !dbg !11 21: %2 = load i32, i32* %x, align 4, !dbg !13 22: %3 = load i32, i32* %y, align 4, !dbg !14 23: %4 = call { i32, i1 } ``@llvm.sadd.with.overflow.i32(i32`` %2, i32 %3), !dbg !13 24: %5 = extractvalue { i32, i1 } %4, 0, !dbg !13 25: %6 = extractvalue { i32, i1 } %4, 1, !dbg !13 26: %7 = call i1 ``@llvm.expect.i1(i1`` %6, i1 false), !dbg !13 27: br i1 %7, label %panic, label %bb1, !dbg !13 28: 29: bb1: ; preds = %start 30: ret i32 %5, !dbg !15 31: 32: panic: ; preds = %start 33: ; call core::panicking::panic 34: call void ``@_ZN4core9panicking5panic17h2f49f09cf859b728E({`` [0 x i64], { [0 x i8]*, i64 }, [0 x i64], { [0 x i8]*, i64 }, [0 x i32], i32, [0 x i32], i32, [0 x i32] }* noalias readonly align 8 dereferenceable(40) bitcast ({ { [0 x i8]*, i64 }, { [0 x i8]*, i64 }, i32, i32 }* ``@panic_loc.2`` to { [0 x i64], { [0 x i8]*, i64 }, [0 x i64], { [0 x i8]*, i64 }, [0 x i32], i32, [0 x i32], i32, [0 x i32] }*)), !dbg !13 35: unreachable, !dbg !13 36: } 37: 38: ; Function Attrs: nounwind readnone speculatable 39: declare void ``@llvm.dbg.declare(metadata,`` metadata, metadata) #1 40: 41: ; Function Attrs: nounwind readnone speculatable 42: declare { i32, i1 } ``@llvm.sadd.with.overflow.i32(i32,`` i32) #1 43: 44: ; Function Attrs: nounwind readnone 45: declare i1 ``@llvm.expect.i1(i1,`` i1) rust-lang#2 46: 47: ; core::panicking::panic 48: ; Function Attrs: cold noinline noreturn nonlazybind uwtable 49: declare void ``@_ZN4core9panicking5panic17h2f49f09cf859b728E({`` [0 x i64], { [0 x i8]*, i64 }, [0 x i64], { [0 x i8]*, i64 }, [0 x i32], i32, [0 x i32], i32, [0 x i32] }* noalias readonly align 8 dereferenceable(40)) unnamed_addr rust-lang#3 50: 51: attributes #0 = { nonlazybind uwtable "probe-stack"="__rust_probestack" "target-cpu"="x86-64" } 52: attributes #1 = { nounwind readnone speculatable } 53: attributes rust-lang#2 = { nounwind readnone } 54: attributes rust-lang#3 = { cold noinline noreturn nonlazybind uwtable "probe-stack"="__rust_probestack" "target-cpu"="x86-64" } 55: 56: !llvm.module.flags = !{!0, !1} 57: !llvm.dbg.cu = !{!2} 58: 59: !0 = !{i32 2, !"RtLibUseGOT", i32 1} 60: !1 = !{i32 2, !"Debug Info Version", i32 3} 61: !2 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !3, producer: "clang LLVM (rustc version 1.39.0 (4560ea7 2019-11-04))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4) 62: !3 = !DIFile(filename: "tests/codegen/fn-parameters-on-different-lines-debuginfo.rs", directory: "/home/martin/src/rust") 63: !4 = !{} 64: !5 = distinct !DISubprogram(name: "foo", linkageName: "_ZN42fn_parameters_on_different_lines_debuginfo3foo17ha98e7c29f4ed8d60E", scope: !6, file: !3, line: 9, type: !7, scopeLine: 9, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, templateParams: !4, retainedNodes: !4) 65: !6 = !DINamespace(name: "fn_parameters_on_different_lines_debuginfo", scope: null) 66: !7 = !DISubroutineType(types: !8) 67: !8 = !{!9, !9, !9} 68: !9 = !DIBasicType(name: "i32", size: 32, encoding: DW_ATE_signed) 69: !10 = !DILocalVariable(name: "x", arg: 1, scope: !5, file: !3, line: 1, type: !9) same:16'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found same:16'1 ? possible intended match 70: !11 = !DILocation(line: 1, scope: !5) same:16'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 71: !12 = !DILocalVariable(name: "y", arg: 2, scope: !5, file: !3, line: 1, type: !9) same:16'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 72: !13 = !DILocation(line: 13, column: 2, scope: !5) same:16'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 73: !14 = !DILocation(line: 13, column: 6, scope: !5) same:16'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 74: !15 = !DILocation(line: 13, column: 9, scope: !5) same:16'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> FAIL With 1.88: OK ``` <details>
…taxes-rewording, r=traviscross,jieyouxu Reword mismatched-lifetime-syntaxes text based on feedback Key changes include: - Removal of the word "syntax" from the lint message. More accurately, it could have been something like "syntax group" or "syntax category", but avoiding it completely is easier. - The primary lint message now reflects exactly which mismatch is occurring, instead of trying to be general. A new `help` line is general across the mismatch kinds. - Suggestions have been reduced to be more minimal, no longer also changing non-idiomatic but unrelated aspects. - Suggestion text no longer mentions changes when those changes don't occur in that specific suggestion. r? ``@jieyouxu``
…cated-fields, r=jieyouxu Remove deprecated fields in bootstrap This PR removes deprecated fields: 1. `description` - part of rust toml 2. `ccache` - part of llvm toml
…fJung Make frame spans appear on a separate trace line This PR changes tracing_chrome's `tracing::Layer` so that if a span has the "tracing_separate_line" field as one of the span arguments, that span is put on a separate trace line. See rust-lang/miri#4451 for an earlier attempt and for screenshots explaining better what I mean by "separate trace line". This PR also makes the "frame" span use this feature (so it appears on a separate trace line, see rust-lang/miri#4451 for motivation), but passes `tracing::field::Empty` as the span parameter value so it is ignored by other tracing layers (e.g. the logger): ```rust info_span!("frame", tracing_separate_line = Empty, "{}", instance); ``` <details><summary>Also see the following discussion I had with ``@RalfJung</summary>`` > Is there no way to attach metadata we could use instead? [These](https://docs.rs/tracing-core/0.1.34/src/tracing_core/metadata.rs.html#57) are the **static** metadata items we can control about a span. We can't add more metadata outside of them. The most relevant are: - `name` (for the frame span it's currently "frame") - `target` which acts as the category (for the frame span it's currently "rustc_const_eval::interpret::stack" by default) - `fields` which contains a list of the *names* of each of the arguments passed to the `span!` macro (for the frame span it's currently ["message"], where "message" is the default identifier for data passed in the `format!` syntax) When the tracing code is called at runtime, the **dynamic** values of the arguments are collected into a [`ValueSet`](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#166). Each argument value stored there corresponds with one of the static names stored in `fields` (see above). --- We have already determined that filtering out spans by `name` is not a good idea, and I would say the same goes for `target`. Both the `name` and the `target` fields are printed to stderr when `MIRI_LOG=` is enabled, so changing them to contain an identifier (e.g. "frame:tracing_separate_root" instead of "frame" as the name) would uselessly clutter the text logs (unless we add one more filter [there](https://github.com/rust-lang/rust/blob/master/compiler/rustc_log/src/lib.rs#L137), but then it gets even more complicated). ```rust // examples of how the above (problematic) solutions would look like info_span!("frame:tracing_separate_root", "{}", instance); info_span!(target: "tracing_separate_root", "frame", "{}", instance); ``` --- So that leaves us with `fields` and their runtime values. Now, my initial thought (inspired by [this comment](rust-lang/miri#4451 (comment))) was to use a field with the static name "tracing_separate_root" and with a dynamic boolean value of "true". In `tracing_chrome.rs` we can easily check if this field is true and act accordingly. This would work but then again this field would also be picked up by the logger when `MIRI_LOG=` is enabled, and would uselessly clutter the text logs. ```rust // example of how the above (problematic) solution would look like info_span!("frame", tracing_separate_root = true, "{}", instance); ``` --- To avoid cluttering the text logs, we can instead set "tracing_separate_root" to the dynamic value of `tracing::field::Empty`. Citing from [here](https://docs.rs/tracing/0.1.41/tracing/field/struct.Empty.html), "when a field’s value is `Empty`, it will not be recorded". "not being recorded" means that the field and its value won't be printed to stderr text logs, nor will it be printed by any other tracing layers that might be attached in the future. In `tracing_chrome.rs` we would still be able to check if "tracing_separate_root" is in the list of static `fields`, and act accordingly. So I believe this solution would effectively allow us to attach metadata to a span in a way that does not clutter logs and still allows being read in `tracing_chrome.rs`. If we ever wanted to pass arbitrary metadata (i.e. not just a present/not present flag), it would be possible with a custom `Empty` that also holds data and implement `Value` without doing anything ([like `Empty` does](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#775)). ```rust // example of how the above solution would look like info_span!("frame", tracing_separate_root = tracing::field::Empty, "{}", instance); ``` </details>
type_id_eq: check that the hash fully matches the type The previous logic wouldn't always detect when the hash mismatches the provenance. Fix that by adding a new helper, `read_type_id`, that reads a single type ID while fully checking it for validity and consistency. r? ``@oli-obk``
…ce, r=Urgau Fix ice for feature-gated `cfg` attributes applied to the crate This PR fixes two fixes: 1. When a feature gated option of the `cfg` attribute is applied to the crate, an ICE would occur because features are not yet available at that stage. This is fixed by ignoring the feature gate at that point, the attribute will later be re-checked (this was already done) when the feature gate is available. Fixes rust-lang#143977 2. Errors and lints on the `cfg` attribute applied to the crate would be produced twice, because of the re-checking. This is fixed by not producing any errors and lints during the first run. The added regression test checks both problems. r? ``@jdonszelmann``
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
This was referenced Jul 17, 2025
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 8c12d76304 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 8c12d76 (parent) -> bf5e6cc (this PR) Test differencesShow 55 test diffsStage 1
Stage 2
Additionally, 47 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 bf5e6cc7a7a7eb03e3ed9b875d76530eddd47d5f --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 (bf5e6cc): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@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)Results (primary 2.1%, secondary -1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 463.461s -> 464.659s (0.26%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Error::descriptionimpl fromc_str::FromBytesWithNulError#143326 (Remove deprecatedError::descriptionimpl fromc_str::FromBytesWithNulError)cfgattributes applied to the crate #143984 (Fix ice for feature-gatedcfgattributes applied to the crate)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup