about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2023-09-13Bring back `verbose_generic_activity_with_arg`John Kåre Alsaker-0/+19
2023-09-13Generate MIR pass names for profiling on the fly and pass the body DefId as ↵John Kåre Alsaker-4/+47
argument
2023-09-10Remove `verbose_generic_activity_with_arg`John Kåre Alsaker-49/+21
2023-09-10Auto merge of #115725 - PhilVoel:patch-1, r=notriddlebors-1/+1
Fixed typo in re-exports.md own't -> won't
2023-09-10Auto merge of #115713 - chenyukang:yukang-fix-115680-rustdoc-arg-check, ↵bors-5/+13
r=compiler-errors Abort if check nightly options failed on stable Fixes #115680 Also, if there are multiple unstable options passing on stable compiler, printing multiple same `note` and `help` seems noisy.
2023-09-10Auto merge of #115668 - Zoxc:deadlock-msg, r=jackh726bors-1/+3
Make the deadlock panic clearly refer to a deadlock
2023-09-10Abort if check nightly options failed on stableyukang-5/+13
2023-09-10Auto merge of #115712 - RalfJung:wf, r=compiler-errorsbors-185/+222
rustc_layout, rustc_abi: make sure the types are well-formed Fixes https://github.com/rust-lang/rust/issues/115676
2023-09-10Fixed typo in re-exports.mdPhilVoel-1/+1
own't -> won't
2023-09-09Auto merge of #115703 - ouz-a:smir_span, r=oli-obkbors-0/+11
Add function that returns span of an item in smir Addressees https://github.com/rust-lang/project-stable-mir/issues/31 Maybe we should change `Span = Opaque` into something else, and then return `String` with newly added function, I don't think it matters that much though, since we are not storing `Span` anywhere. r? `@oli-obk`
2023-09-09Auto merge of #114590 - ijackson:stdio-stdio-2, r=dtolnaybors-11/+134
Allow redirecting subprocess stdout to our stderr etc. (redux) This is the code from #88561, tidied up, including review suggestions, and with the for-testing-only CI commit removed. FCP for the API completed in #88561. I have made a new MR to facilitate review. The discussion there is very cluttered and the branch is full of changes (in many cases as a result of changes to other Rust stdlib APIs since then). Assuming this MR is approvedl we should close that one. ### Reviewer doing a de novo review Just code review these four commits.. FCP discussion starts here: https://github.com/rust-lang/rust/pull/88561#issuecomment-1640527595 Portability tests: you can see that this branch works on Windows too by looking at the CI results in #88561, which has the same code changes as this branch but with an additional "DO NOT MERGE" commit to make the Windows tests run. ### Reviewer doing an incremental review from some version of #88561 Review the new commits since your last review. I haven't force pushed the branch there. git diff the two branches (eg `git diff 176886197d6..0842b69c219`). You'll see that the only difference is in gitlab CI files. You can also see that *this* MR doesn't touch those files.
2023-09-09Auto merge of #115698 - gurry:115143-ice-normalization-error, r=compiler-errorsbors-11/+27
Fix ICE in improper_ctypes_definitions lint Fix #115143
2023-09-09Auto merge of #115700 - GuillaumeGomez:migrate-gui-test-color-39, r=notriddlebors-9/+9
Migrate GUI colors test to original CSS color format Follow-up of https://github.com/rust-lang/rust/pull/111459. r? `@notriddle`
2023-09-09better spans for WF errorsRalf Jung-19/+28
2023-09-09use hir_crate_items(()).definitions() instead of hir().items()Ralf Jung-141/+118
2023-09-09rustc_layout, rustc_abi: make sure the types are well-formedRalf Jung-36/+87
2023-09-09Auto merge of #115707 - weihanglo:update-cargo, r=weihanglobors-0/+0
Update cargo 14 commits in d14c85f4e6e7671673b1a1bc87231ff7164761e1..2fc85d15a542bfb610aff7682073412cf635352f 2023-09-05 22:28:10 +0000 to 2023-09-09 01:49:46 +0000 - feat: Stabilize lints (rust-lang/cargo#12648) - Ues strip_prefix for cleaner code (rust-lang/cargo#12631) - fix: don't print _TOKEN suggestion when not applicable (rust-lang/cargo#12644) - Bump cargo-credential-1password to v0.4.0 (rust-lang/cargo#12641) - refactor: put `Source` trait under `cargo::sources` (rust-lang/cargo#12527) - Error out if `cargo clean --doc` is mixed with `-p`. (rust-lang/cargo#12637) - Add wrappers around std::fs::metadata (rust-lang/cargo#12636) - Add with_stdout_unordered. (rust-lang/cargo#12635) - Fix example for creating a git project test. (rust-lang/cargo#12632) - Read/write the encoded `cargo update --precise` in the same place (rust-lang/cargo#12629) - docs(guide): Apply feedback on CI (rust-lang/cargo#12630) - fix: improve warning for both token & credential-provider (rust-lang/cargo#12626) - Skip clean up `profile.release.package."*"` (rust-lang/cargo#12624) - Add MSRV validation GitHub Action for cargo-credential (rust-lang/cargo#12623)
2023-09-09Update cargoWeihang Lo-0/+0
2023-09-09add function that returns span of an itemouz-a-0/+11
2023-09-09Auto merge of #115594 - nnethercote:span-tweaks, r=cjgillotbors-121/+146
Span tweaks Some minor improvements to code clarity. r? `@cjgillot`
2023-09-09std::process (unsupported): Implement From<io::Stdout> etc. for imp::StdioIan Jackson-0/+20
This implementation is wrong. Like the impl for From<File>, it is forced to panic because process::Stdio in unsupported/process.rs doesn't have a suitable variant. The root cause of the problem is that process::Stdio in unsupported/process.rs has any information in it at all. I'm pretty sure that it should just be a unit struct. However, making that build on all platforms is going to be a lot of work, iterating through CI and/or wrestling Docker. I don't think this extra panic is making things significantly worse. For now I have added some TODOs.
2023-09-09Migrate GUI colors test to original CSS color formatGuillaume Gomez-9/+9
2023-09-09Auto merge of #115657 - Zoxc:source-span-avoid-query, r=cjgillotbors-13/+15
Avoid a `source_span` query when encoding Spans into query results This avoids a `source_span` query when encoding `Span`s into query results. It's not sound to execute queries here as the query caches can be locked and the dep graph is no longer writable. r? `@cjgillot`
2023-09-09Fix ICE in improper_ctypes_definitions lintGurinder Singh-11/+27
The lint panicked for an input like 'extern "C" fn(Option<&<T as FooTrait>::FooType>)' because the type T therein cannot be normalized. The normalization failure caused SizeSkeleton::compute() to return an error and trigger a panic in the unwrap().
2023-09-09Auto merge of #115669 - GuillaumeGomez:js-anonymous-functions, r=notriddlebors-18/+18
rustdoc: Change syntax for anonymous functions set in JS This function is not very useful in itself but it slightly reduces the JS size so it's always that I suppose... No changes in behaviour. r? `@notriddle`
2023-09-08Auto merge of #115685 - matthiaskrgr:rollup-t31gowy, r=matthiaskrgrbors-29/+248
Rollup of 5 pull requests Successful merges: - #113807 (Tests crash from inappropriate use of common linkage) - #115358 (debuginfo: add compiler option to allow compressed debuginfo sections) - #115630 (Dont suggest use between `use` and cfg attr) - #115662 (Improve "associated type not found" diagnostics) - #115673 (Fix sanitize/cfg.rs test) r? `@ghost` `@rustbot` modify labels: rollup
2023-09-09Rollup merge of #115673 - tmiasko:sanitizer-cfg, r=compiler-errorsMatthias Krüger-8/+8
Fix sanitize/cfg.rs test * Move needs-sanitizer conditions to specific revisions that require them (otherwise the conditions are mutually exclusive with needs-sanitizer-kcfi and test is always ignored). * Add missing revisions
2023-09-09Rollup merge of #115662 - ShE3py:E0220-note, r=compiler-errorsMatthias Krüger-14/+39
Improve "associated type not found" diagnostics ```rs use core::ops::Deref; fn foo<T>() where T: Deref<Output = u32> {} ``` Before: ``` error[E0220]: associated type `Output` not found for `Deref` --> E0220.rs:5:28 | 5 | fn foo<T>() where T: Deref<Output = u32> {} | ^^^^^^ associated type `Output` not found ``` After: ``` error[E0220]: associated type `Output` not found for `Deref` --> E0220.rs:5:28 | 5 | fn foo<T>() where T: Deref<Output = u32> {} | ^^^^^^ help: `Deref` has the following associated type: `Target` ``` --- `@rustbot` label +A-diagnostics +D-papercut
2023-09-09Rollup merge of #115630 - compiler-errors:dont-suggest-use-btw-use-and-attr, ↵Matthias Krüger-1/+52
r=wesleywiser Dont suggest use between `use` and cfg attr Fixes #115618
2023-09-09Rollup merge of #115358 - durin42:compress-debuginfo, r=oli-obkMatthias Krüger-6/+132
debuginfo: add compiler option to allow compressed debuginfo sections LLVM already supports emitting compressed debuginfo. In debuginfo=full builds, the debug section is often a large amount of data, and it typically compresses very well (3x is not unreasonable.) We add a new knob to allow debuginfo to be compressed when the matching LLVM functionality is present. Like clang, if a known-but-disabled compression mechanism is requested, we disable compression and emit uncompressed debuginfo sections. The API is different enough on older LLVMs we just pretend the support is missing on LLVM older than 16.
2023-09-09Rollup merge of #113807 - mojingran:master, r=WaffleLapkinMatthias Krüger-0/+17
Tests crash from inappropriate use of common linkage Follows up my proposal under the [tracking issue for the linkage feature](https://github.com/rust-lang/rust/issues/29603#issuecomment-1597662999). Adds test for [issue 109681](https://github.com/rust-lang/rust/issues/109681).
2023-09-08Auto merge of #115417 - dpaoliello:fixdi, r=wesleywiserbors-22/+61
Use the same DISubprogram for each instance of the same inlined function within a caller # Issue Details: The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this are inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together. When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location. As an example of this, consider the following program: ```rust #[no_mangle] fn add_numbers(x: &Option<i32>, y: &Option<i32>) -> i32 { let x1 = x.unwrap(); let y1 = y.unwrap(); x1 + y1 } ``` When building for x86_64 Windows using 1.72 it generates (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction): ```llvm .cv_loc 0 1 3 0 # src\lib.rs:3:0 addq $40, %rsp retq leaq .Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx leaq .Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17h12e60b9063f6dee8E int3 ``` # Fix Details: Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again. Ideally, we would also deduplicate child scopes and variables, however my attempt to do that with #114643 resulted in asserts when building for Linux (#115156) which would require some deep changes to Rust to fix (#115455). Instead, when using an inlined function as a debug scope, we will also create a new child scope such that subsequent child scopes and variables do not collide (from LLVM's perspective). After this change the above assembly now (with <https://reviews.llvm.org/D159226> as well) shows the `panic!` was inlined from `unwrap` in `option.rs` at line 935 into the current function in `lib.rs` at line 0 (line 0 is emitted since it is ambiguous which line to use as there were two inline sites that lead to this same code): ```llvm .cv_loc 0 1 3 0 # src\lib.rs:3:0 addq $40, %rsp retq .cv_inline_site_id 6 within 0 inlined_at 1 0 0 .cv_loc 6 2 935 0 # library\core\src\option.rs:935:0 leaq .Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx leaq .Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17hde1558f32d5b1c04E int3 ```
2023-09-08Auto merge of #115641 - durin42:llvm-18-fatlto-take-2, r=nikicbors-16/+89
lto: load bitcode sections by name Upstream change llvm/llvm-project@6b539f5eb8ef1d3a3c87873caa2dbd5147e1adbd changed `isSectionBitcode` works and it now only respects `.llvm.lto` sections instead of also `.llvmbc`, which it says was never intended to be used for LTO. We instead load sections by name, and sniff for raw bitcode by hand. This is an alternative approach to #115136, where we tried the same thing using the `object` crate, but it got too fraught to continue. r? `@nikic` `@rustbot` label: +llvm-main
2023-09-08Auto merge of #115418 - Zoxc:freeze-source, r=oli-obkbors-229/+298
Use `Freeze` for `SourceFile` This uses the `Freeze` type in `SourceFile` to let accessing `external_src` and `lines` be lock-free. Behavior of `add_external_src` is changed to set `ExternalSourceKind::AbsentErr` on a hash mismatch which matches the documentation. `ExternalSourceKind::Unneeded` was removed as it's unused. Based on https://github.com/rust-lang/rust/pull/115401.
2023-09-08Auto merge of #115612 - cjgillot:const-prop-int, r=oli-obkbors-188/+1979
Improvements to dataflow const-prop Partially cherry-picked from https://github.com/rust-lang/rust/pull/110719 r? `@oli-obk` cc `@jachris`
2023-09-08tests: use warning output from rustc to catch missing compressionAugie Fackler-4/+2
Using `ld.lld` may have been clever, but that was getting the /system/ ld.lld, not one we may have built as part of building llvm. By using the warning message coming directly from rustc we now correctly skip the zlib and zstd tests when the support is missing.
2023-09-08sortAugie Fackler-2/+2
2023-09-08options: fix indentationAugie Fackler-3/+3
rustfmt didn't save me here, sigh
2023-09-08debuginfo: add compiler option to allow compressed debuginfo sectionsAugie Fackler-7/+135
LLVM already supports emitting compressed debuginfo. In debuginfo=full builds, the debug section is often a large amount of data, and it typically compresses very well (3x is not unreasonable.) We add a new knob to allow debuginfo to be compressed when the matching LLVM functionality is present. Like clang, if a known-but-disabled compression mechanism is requested, we disable compression and emit uncompressed debuginfo sections. The API is different enough on older LLVMs we just pretend the support is missing on LLVM older than 16.
2023-09-08lto: handle Apple platforms correctly by eliding __LLVM, from section nameAugie Fackler-1/+4
2023-09-08lto: load bitcode sections by nameAugie Fackler-16/+86
Upstream change llvm/llvm-project@6b539f5eb8ef1d3a3c87873caa2dbd5147e1adbd changed `isSectionBitcode` works and it now only respects `.llvm.lto` sections instead of also `.llvmbc`, which it says was never intended to be used for LTO. We instead load sections by name, and sniff for raw bitcode by hand. r? @nikic @rustbot label: +llvm-main
2023-09-08Auto merge of #115672 - GuillaumeGomez:rollup-mjiy56f, r=GuillaumeGomezbors-22/+173
Rollup of 6 pull requests Successful merges: - #104299 (Clarify stability guarantee for lifetimes in enum discriminants) - #115088 (Fix Step Skipping Caused by Using the `--exclude` Option) - #115201 (rustdoc: list matching impls on type aliases) - #115633 (Lint node for `PRIVATE_BOUNDS`/`PRIVATE_INTERFACES` is the item which names the private type) - #115638 (`-Cllvm-args` usability improvement) - #115643 (fix: return early when has tainted in mir-lint) r? `@ghost` `@rustbot` modify labels: rollup
2023-09-08Fix sanitize/cfg.rs testTomasz Miąsko-8/+8
* Move needs-sanitizer conditions to specific revisions that require them (otherwise the conditions are mutually exclusive with needs-sanitizer-kcfi and test is always ignored). * Add missing revisions
2023-09-08Add Freeze::cloneJohn Kåre Alsaker-8/+12
2023-09-08Rollup merge of #115643 - bvanjoi:fix-115203, r=RalfJung,oli-obkGuillaume Gomez-0/+34
fix: return early when has tainted in mir-lint Fixes #115203 `a[..]` is of indeterminate size, it had been reported error during borrow check, therefore we skip the mir lint process.
2023-09-08Rollup merge of #115638 - ldm0:ldm/llvm-args-fix, r=nikicGuillaume Gomez-1/+4
`-Cllvm-args` usability improvement fixes: #26338 fixes: #115564 Two problems were found during playing with `-Cllvm-args` 1. When `llvm.link-shared` is set to `false` in `config.toml`, output of `rustc -C llvm-args='--help-list-hidden'` doesn't contain `--emit-dwarf-unwind` and `--emulated-tls`. When it is set to `true`, `rustc -C llvm-args='--help-list-hidden'` emits `--emit-dwarf-unwind`, but `--emulated-tls` is still missing. 2. Setting `-Cllvm-args=--emit-dwarf-unwind=always` doesn't take any effect, but `-Cllvm-args=-machine-outliner-reruns=3` does work. ### 1 Adding `RegisterCodeGenFlags` to register codegen flags fixed the first problem. `rustc -C llvm-args='--help-list-hidden'` emits full codegen flags including `--emit-dwarf-unwind` and `--emulated-tls`. ### 2 Constructing `TargetOptions` from `InitTargetOptionsFromCodeGenFlags` in `LLVMRustCreateTargetMachine` fixed the second problem. The `LLVMRustSetLLVMOptions` calls `ParseCommandLineOptions` which parses given `llvm-args`. For options like `machine-outliner-reruns`, it just works, since the codegen logic directly consumes the parsing result: [machine-outliner-reruns register](https://github.com/rust-lang/llvm-project/blob/0537f6354cffe546cbf47f6dc9c7f82e49e86cfb/llvm/lib/CodeGen/MachineOutliner.cpp#L114) [machine-outliner-reruns consumption](https://github.com/rust-lang/llvm-project/blob/0537f6354cffe546cbf47f6dc9c7f82e49e86cfb/llvm/lib/CodeGen/MachineOutliner.cpp#L1138) But for flags defined in `TargetOptions` and `MCTargetOptions` to take effect, constructing them with `InitTargetOptionsFromCodeGenFlags` is essential, or the parsing result is just not consumed. Similar patterns can be observed in [lli](https://github.com/rust-lang/llvm-project/blob/0537f6354cffe546cbf47f6dc9c7f82e49e86cfb/llvm/tools/llc/llc.cpp#L494), [llc](https://github.com/rust-lang/llvm-project/blob/0537f6354cffe546cbf47f6dc9c7f82e49e86cfb/llvm/tools/lli/lli.cpp#L517), etc.
2023-09-08Rollup merge of #115633 - compiler-errors:PRIVATE_BOUNDS-lint-node, ↵Guillaume Gomez-3/+11
r=petrochenkov Lint node for `PRIVATE_BOUNDS`/`PRIVATE_INTERFACES` is the item which names the private type The HIR that the `PRIVATE_BOUNDS` lint should be attached to is the item that has the *bounds*, not the private type. This PR also aligns this behavior with the `EXPORTED_PRIVATE_DEPENDENCIES` lint, which also requires putting the `allow` on the item that names the private type. Fixes #115475 r? petrochenkov
2023-09-08Rollup merge of #115201 - notriddle:notriddle/type-alias-impl-list, ↵Guillaume Gomez-13/+111
r=GuillaumeGomez rustdoc: list matching impls on type aliases Fixes https://github.com/rust-lang/rust/issues/32077 Fixes #99952 Remake of https://github.com/rust-lang/rust/pull/112429 Partially reverts https://github.com/rust-lang/rust/pull/112543, but keeps the test case. This version of the PR avoids the infinite loop by structurally matching types instead of using full unification. This version does not support type alias trait bounds, but the compiler does not enforce those anyway (https://github.com/rust-lang/rust/issues/21903). r? `@GuillaumeGomez` CC `@lcnr`
2023-09-08Rollup merge of #115088 - LuuuXXX:issue-112009, r=albertlarsan68Guillaume Gomez-5/+8
Fix Step Skipping Caused by Using the `--exclude` Option The original code was overreacting to the `--exclude` option, https://github.com/rust-lang/rust/blob/eadf69a6c6edfe220fc5b1b659e46e271d75a3a1/src/bootstrap/builder.rs#L257-L260 For example: When `x test --exclude alloc` or `x test --exclude library/alloc` is passed, the entire libraray test is skipped. Related issues: https://github.com/rust-lang/rust/issues/112009
2023-09-08Rollup merge of #104299 - mkrasnitski:discriminant-transmute-docs, r=oli-obkGuillaume Gomez-0/+5
Clarify stability guarantee for lifetimes in enum discriminants Since `std::mem::Discriminant` erases lifetimes, it should be clarified that changing the concrete value of a lifetime parameter does not change the value of an enum discriminant for a given variant. This is useful as it guarantees that it is safe to transmute `Discriminant<Foo<'a>>` to `Discriminant<Foo<'b>>` for any combination of `'a` and `'b`. This also holds for type-generics as long as the type parameters do not change, e.g. `Discriminant<Foo<T, 'a>>` can be transmuted to `Discriminant<Foo<T, 'b>>`. Side note: Is what I've written actually enough to imply soundness (or rather codify it), or should it specifically be spelled out that it's OK to transmute in the above way?
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 14:30:22 +0000