Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- from observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors
- Debuggers need to be able to handle a variety of versions withing the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
updates the test added in the previous commit to ensure no warning is
printed.
Arbitrary self types v2: recursion test
Add a test for infinite recursion of an arbitrary self type.
These diagnostics aren't perfect (especially the repetition of the statement that there's too much recursion) but for now at least let's add a test to confirm that such diagnostics are emitted.
As suggested by ```@oli-obk```
Relates to #44874
r? ```@wesleywiser```
Rename `slice::take...` methods to `split_off...`
This rename was discussed and recommended in a recent t-libs meeting.
cc https://github.com/rust-lang/rust/issues/62280
There's an additional commit here which modifies internals of unstable `OneSidedRange` APIs in order to implement `split_off` methods in a panic-free way (remove `unreachable!()`) as recommended in https://github.com/rust-lang/rust/pull/88502/files#r760177240. I can split this out into a separate PR if needed.
implement inherent str constructors
implement #131114
this implements
- str::from_utf8
- str::from_utf8_mut
- str::from_utf8_unchecked
- str::from_utf8_unchecked_mut
i left `std::str::from_raw_parts` and `std::str::from_raw_parts_mut` out of this as those are unstable and were not mentioned by the tracking issue or the original pull request, but i can add those here as well.
i was also unsure of what to do with the `rustc_const_(un)stable` attributes: i removed the `#[rustc_const_stable]` attribute from `str::from_utf8`, `str::from_utf8_unchecked` and `str::from_utf8_unchecked_mut`, and left the`#[rust_const_unstable]` in `str::from_utf8_mut` (btw why is that one not const stable yet with #57349 merged?).
is there a way to redirect users to the stable `std::str::from_utf8` instead of only saying "hey this is unstable"?
for now i just removed the check for `str::from_utf8` in the test in `tests/ui/suggestions/suggest-std-when-using-type.rs`.
std: move network code into `sys`
As per #117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support #135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.
I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
uefi: process: Add support for command environment variables
Set environment variables before launching the process and restore the prior variables after the program exists.
This is the same implementation as the one used by UEFI Shell Execute [0].
[0]: 2d2642f483/ShellPkg/Application/Shell/ShellProtocol.c (L1700)
Reject negative literals for unsigned or char types in pattern ranges and literals
It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic.
In https://github.com/rust-lang/rust/pull/134228 I caused
```rust
fn main() {
match 42_u8 {
-10..255 => {},
_ => {}
}
}
```
to just compile without even a lint.
I can't believe we didn't have tests for this
Amusingly https://github.com/rust-lang/rust/pull/136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.
tests: Port `split-debuginfo` to rmake.rs
Part of #121876.
This PR supersedes #128754 and is co-authored with `@Oneirical.`
## Known limitations
- In general, like the `Makefile` version, this test in its present form is also somewhat funny because for the most part it merely checks for existence/absence of output artifacts but makes no attempt to actually check if the debuginfo is at all usable.
## Changes
This PR ports `tests/run-make/split-debuginfo` to rmake.rs. This is an **initial** port, and certainly could be cleaned up and/or enhanced.
The original Makefile version had several functional problems. I fixed some of them, but also left some existing issues as-is.
1. The linux/non-linux final branch had a conditional interpolation of `UNSTABLE_OPTIONS := -Zunstable-options`. However, one of the use sites was `-C $(UNSTABLE_OPTIONS) split-debuginfo`. This indicates to me that this run-make test is not run in CI under a non-linux + non-windows + non-darwin environment, because that would've failed as this would expand to `-C -Zunstable-options split-debuginfo`. I fixed this in the rmake.rs version, but I'm not sure if this distinction is worth keeping at all if it's not tested in CI.
2. There are several comments that were discovered to be wrong. I tried to fix them in the rmake.rs version as well.
3. The check for path remapping / lack of path remapping through
```make
objdump -Wi $(TMPDIR)/foo | grep DW_AT_GNU_dwo_name | (! grep $(TMPDIR)) || exit 1
```
is incorrect, because that looks at the single line of that contains `DW_AT_GNU_dwo_name`. This is unfortunately wrong because empirical evidence shows that with `objdump`[^objdump], the check actually needs to look at the attribute value of `DW_AT_comp_dir` on the previous line not `DW_AT_GNU_dwo_name`[^gnu-ext]. Example output of `objdump`:
```text
<10> DW_AT_comp_dir : (indirect string, offset: 0xafb48): /home/joe/repos/rust
<14> DW_AT_GNU_dwo_name: (indirect string, offset: 0x5d1b0): foo.foo.fc848df41df7a00d-cgu.0.rcgu.dwo
```
In the rmake.rs version I used a 2-line sliding window to check for `DW_AT_comp_dir` and `DW_AT_GNU_dwo_name`, but to look at `DW_AT_comp_dir` specifically.
4. I included a bunch of FIXMEs and ENHANCEMENTs I noticed regarding the test because I didn't want to fix them in this initial port[^enhancement].
5. The Makefile version didn't test *anything* on Windows (both windows-msvc and windows-gnu). I added some *very* basic and *very* sparse checks for windows-msvc, but I am not willing to spend the effort to expand test coverage to windows-gnu in this initial port.
6. This run-make test is way too big. But I didn't want to expend the effort of breaking this up in this initial port.
[^objdump]: the output format differs between `objdump` and `llvm-objdump`, but the same is true for `llvm-objdump` that this is looking at the wrong line.
[^gnu-ext]: AFAICT that is a GNU DWARF attribute extension, since it isn't mentioned in DWARFv5 spec
[^enhancement]: For instance, the previous path remapping check could in theory be precisely inspected by inspecting `.debug_info` section to look for attribute value of `DW_AT_comp_dir`. But that involves resolving the value of the indirect string, which means you have to: (1) look for offset into string offset table and (2) use *that* offset to find the string itself in the string table. The split part of "split-debuginfo" makes this murky for me, so I wasn't able to replace `llvm-objdump` textual output substring matches with more precise `object` + `gimli` inspections.
## Review advice
- I'm sorry for how long the rmake.rs test ended up, but a lot of it is comments and just vertical space due to formatting. If there's any ways to make this test less long / convoluted, advice would be appreciated.
- This PR *intentionally* introduces several intermediate commits for the `Makefile`, mostly to illustrate the problems I discovered when looking at the original `Makefile` version. This is intended to highlight the existing problems in the `Makefile` version for the reviewer[^squash].
- There are several intentional non-functional commits:
1. Reindent the `Makefile` to make the platform conditional gating more obvious.
2. Collapse nested if-else branches into an else if construct, which is not supported by GNU Make 3.80.
3. Remove all redundant `-C debuginfo=2` when `-g` is already specified.
- This PR is best reviewed commit-by-commit.
[^squash]: I intend to squash these intermediate commits away after the reviewer concludes that the current form of the rmake.rs test is acceptable for merge. Before then, I'll keep them to help with review.
---
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: test-various
Upgrade elsa to the newest version.
This was locked to 1.7.1 because of an error in the elsa release process that has since been fixed. Upgrading has the advantage that the elsa code runs properly in miri, at least with tree borrows.
This was spawned from https://github.com/rust-lang/rust/issues/135870#issuecomment-2612470540
Add a test for infinite recursion of an arbitrary self type.
These diagnostics aren't perfect (especially the repetition of the
statement that there's too much recursion) but for now at least
let's add a test to confirm that such diagnostics are emitted.
Mark `std::fmt::from_fn` as `#[must_use]`
While working on #135494 I managed to shoot my own foot a few times by forgetting to actually use the result of `fmt::from_fn`, so I think a `#[must_use]` could be appropriate!
Didn't have a good message to put in the attr so left it blank, still unstable so we can come back to it I guess?
cc #117729 (and a huge +1 for getting it stabilized, it's very useful IMHO)
bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros
Follow-up to https://github.com/rust-lang/rust/pull/136091#discussion_r1930219425.
- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and `trace!`, which `cfg(feature = "tracing")`-gates the underlying `tracing` macros. They expand to nothing if `"tracing"` feature is not enabled.
- This is not done for `span!` or `event!` because they can return span guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute proc-macro unless you use another attribute proc-macro to wrap that.
It's not *great*, because `tracing::instrument` and `tracing::{span,event}` can't be wrapped this way.
Can test locally with:
```bash
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap/
```
r? ``@onur-ozkan`` (or reroll)
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1)
Part of #134001, follow-up to #136326, extracted from #134009.
This PR performs an arbitrary subset of the LLVM-C binding migrations from #134009, which should make it less tedious to review. The remaining migrations can occur in one or more subsequent PRs.
rustdoc: clean up a bunch of ts-expected-error declarations in main
This mostly consists of handling potentially-null input and adding more global functions to the list of globals.
Follow-up for #136161
#[contracts::requires(...)] + #[contracts::ensures(...)]
cc https://github.com/rust-lang/rust/issues/128044
Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition, building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).
Known issues:
* My original intent, as described in the MCP (https://github.com/rust-lang/compiler-team/issues/759) was to have a rustc-prefixed attribute namespace (like rustc_contracts::requires). But I could not get things working when I tried to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it is called `contracts::requires`.
* Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
* (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)
* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
librustdoc: create a helper for separating elements of an iterator instead of implementing it multiple times
This implements something similar to [`Itertools::format`](https://docs.rs/itertools/latest/itertools/trait.Itertools.html#method.format), but on `Fn`s returning iterators instead of directly on iterators, to allow implementing `Display` without the use of a `Cell` (to handle the possibility of `fmt` being called multiple times while receiving `&self`).
~This is WIP, I just want to get a perf run first to see if the regression I saw in #135494 is fixed~
This was originally part of #135494 , but originally caused a perf regression that was since fixed:
7d5ae1863a/src/librustdoc/html/format.rs (L507)
Shard AllocMap Lock
This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in https://github.com/rust-lang/rust/pull/136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too.
Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally.
r? `@RalfJung`
mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`
A combination of two loosely-related tweaks that would otherwise conflict with each other:
- `Cx` is a pretty unhelpful type name, especially when jumping between THIR-building and MIR-building while trying to make changes to THIR data structures.
- The `UserAnnotatedTyHelpers` trait doesn't appear to provide any benefit over a simple helper function, and its `tcx()` method is currently completely unnecessary.
No functional change.
Remove unnecessary layout assertions for object-safe receivers
The soundness of `DispatchFromDyn` relies on the fact that, like all other built-in marker-like layout traits (e.g. `Sized`, `CoerceUnsized`), the guarantees that they enforce in *generic* code via traits will result in assumptions that we can rely on in codegen.
Specifically, `DispatchFromDyn` ensures that we end up with a receiver that is a valid pointer type, and its implementation validity recursively ensures that the ABI of that pointer type upholds the `Scalar` or `ScalarPair` representation for sized and unsized pointees, respectively.
The check that this layout guarantee holds for arbitrary, possibly generic receiver types that also may exist in possibly impossible-to-instantiate where clauses is overkill IMO, and leads to several ICEs due to the fact that computing layouts before monomorphization is going to be fallible at best.
This PR removes the check altogether, since it just exists as a sanity check from very long ago, 6f2a161b1b.
Fixes#125810Fixes#90110
This PR is an alternative to #136195. cc `@adetaylor.` I didn't realize in that PR that the layout checks that were being modified were simply *sanity checks*, rather than being actually necessary for soundness.
Report generic mismatches when calling bodyless trait functions
Don't know if there's an open issue for this. Just happened to notice this when working in that area.
The awkward extra spans added to the diagnostics of some tests (e.g. `trait-with-missing-associated-type-restriction`) is consistent with what happens for normal functions. Should probably be removed since that span doesn't seem to note anything useful.
First and third commit are both cleanups removing some unnecessary work. Second commit has the actual fix.
fixes#135124
