Update ar_archive_writer to 0.2.0
This adds a whole bunch of tests checking for any difference with llvm's archive writer. It also fixes two mistakes in the porting from C++ to Rust. The first one causes a divergence for Mach-O archives which may or may not be harmless. The second will definitively cause issues, but only applies to thin archives, which rustc currently doesn't create.
Correct usage note on OpenOptions::append()
This PR aims to correct the following usage note in `OpenOptions::append()`, which currently contains misleading information:
> One maybe obvious note when using append-mode: make sure that all data that belongs together is written to the file in one operation. This can be done by concatenating strings before passing them to [write()](https://doc.rust-lang.org/std/io/trait.Write.html#tymethod.write), or using a buffered writer (with a buffer of adequate size), and calling [flush()](https://doc.rust-lang.org/std/io/trait.Write.html#tymethod.flush) when the message is complete.
The above is misleading because, despite appearances, neither concatenating data before passing it to `write()`, nor delaying writes using `BufWriter`, ensures atomicity. `File::write()`, as well as the underlying `write(2)` system call, makes no guarantees that the data passed to it will be written out in full. It is allowed to write out only a part of the data, and has a return value that tells you how much it has written, at which point it has already returned and modified the file with partial data. Given this limitation, the only way to ensure atomicity of appends is through external locking.
Attempting to ensure atomicity by issuing data in a single `write()` is a footgun often stumbled upon by beginners, which shouldn't be advertised in the docs. The worst thing about the footgun is that it *appears* to work at first, only failing when the string becomes sufficiently large, or when some internal properties of the output file descriptor change (e.g. it is switched from regular file to a special file that talks to a socket or TTY), making it accept smaller writes. Additionally, the suggestion to use `BufWriter` skims over the issue of buffer sizes, as well as the fact that `BufWriter::flush()` contains a *loop* that can happily issue multiple writes. This loop is completely opaque to the caller, so you can't even assert atomicity after-the-fact.
The PR makes the following changes:
* removes the paragraph that suggests concatenating strings to pass them to `write()` for atomicity or using `BufWriter`
* adds a paragraph explaining why attempting to use `write()` to append atomically is not a good idea.
Disable two debuginfo tests failing under the future GDB 15 release
As seen in #123960, it seems two of our debuginfo tests started failing on gdb 15, which is also already in use in the `x86_64-gnu-llvm-18` builder: CI will randomly start to fail whenever this cached docker image expires.
This PR disables the following two tests under gdb 15+, to prevent future CI failures.
- `tests/debuginfo/include_string.rs`
- `tests/debuginfo/vec-slices.rs`
This seems very much related to https://sourceware.org/bugzilla/show_bug.cgi?id=30330 and https://sourceware.org/bugzilla/show_bug.cgi?id=31517 -- and I just now saw #122751 as well, where one of these bugzilla issues and one of the two test failures here was previously mentioned.
I don't know whether these are unexpected gdb changes, or if we need to change our tests as it seems some of the gdb changes are definitely intentional, so I'll just cc `@rust-lang/wg-debugging` and `@tromey.`
(In the same area, `tests/debuginfo/unsized.rs` was previously disabled due to https://sourceware.org/bugzilla/show_bug.cgi?id=30330. This issue has been fixed but I don't believe our test passes, so it's in the same boat as the 2 above regarding whether this test is expected to work or needs changes as well)
r? wg-debugging
I've confirmed this is enough to have CI pass on gdb 15 with the llvm 18 builder.
Trait predicates for types which have errors may still
evaluate to OK leading to downstream ICEs. Now we return
a selection error for such types in candidate assembly and
thereby prevent such issues
Rollup of 7 pull requests
Successful merges:
- #123016 (Remove `TypeVariableOriginKind` and `ConstVariableOriginKind`)
- #123462 (Cleanup: Rename `ModSep` to `PathSep`)
- #123603 (Don't even parse an intrinsic unless the feature gate is enabled)
- #123926 (Fix pretty HIR for anon consts in diagnostics)
- #123973 (crashes: readme: add reminder to add Fixes #abcde to prs to automatically close issues.)
- #123984 (sanitizers: Add rustc_sanitizers to triagebot.toml)
- #123989 (Just use `type_dependent_def_id` to figure out what the method is for an expr)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix pretty HIR for anon consts in diagnostics
This removes the `NoAnn` printer which skips over nested bodies altogether, which is confusing, and requires users of `{ty|qpath|pat}_to_string` to pass in `&tcx` which now impleemnts `hir_pretty::PpAnn`.
There's one case where this "regresses" by actually printing out the body of the anon const -- we could suppress that, but I don't expect people to actually get anon consts like that unless they're fuzzing, tbh.
r? estebank
Don't even parse an intrinsic unless the feature gate is enabled
Don't return true in `tcx.is_intrinsic` if the function is defined locally and `#![feature(intrinsics)]` is not enabled. This is a slightly more general fix than #123526, since #123587 shows that we have simplifying assumptions about intrinsics elsewhere in the compiler.
This will make the code ICE again if the user **enables** `#[feature(intrinsics)]`, but I kind of feel like if we want to fix that, we should make the `INTERNAL_FEATURES` lint `Deny` again. Perhaps we could do that on non-nightly compilers. Or we should just stop compilation altogether if they have `#![feature]` enabled on a non-nightly compiler.
As for the UX of *real* cases of hitting these ICEs, I believe pretty strongly that if a compiler/stdlib dev is modifying internal intrinsics (intentionally, like when making a change to rustc) we have no guarantee to make the ICE better looking for them. Honestly, *not* spitting out a stack trace is probably a disservice to the people who hit those ICEs in that case.
r? `@Nilstrieb` `@estebank`
Cleanup: Rename `ModSep` to `PathSep`
`::` is usually referred to as the *path separator* (citation needed).
The existing name `ModSep` for *module separator* is a bit misleading since it in fact separates the segments of arbitrary path segments, not only ones resolving to modules. Let me just give a shout-out to associated items (`T::Assoc`, `<Ty as Trait>::function`) and enum variants (`Option::None`).
Motivation: Reduce friction for new contributors, prevent potential confusion.
cc `@petrochenkov`
r? nnethercote or compiler
Remove `TypeVariableOriginKind` and `ConstVariableOriginKind`
It's annoying to have to import `TypeVariableOriginKind` just to fill it with `MiscVariable` for almost every use. Every other usage other than `TypeParameterDefinition` wasn't even used -- I can see how it may have been useful once for debugging, but I do quite a lot of typeck debugging and I've never really needed it.
So let's just remove it, and keep around the only useful thing which is the `DefId` of the param for `var_for_def`.
This is based on #123006, which removed the special use of `TypeVariableOriginKind::OpaqueInference`, which I'm pretty sure I was the one that added.
r? lcnr or re-roll to types
CI: add a script for dynamically computing CI job matrix
It would be great if was easier to run specific CI workflows locally, and also to allow us to spawn a specific CI workflow by bors, to enable running arbitrary try builds. See discussion [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/CI.20workflows.20refactoring).
This PR is a first step in that direction.
- Moves the definition of CI runners and (for now) PR jobs into a separate `jobs.yml` file.
- Adds a simple Python script that reads the file, decides which jobs should be active for the current CI workflow, and prints them as JSON to their output.
- The PR job then reads this output and generates its job matrix based on it.
By moving the job definitions from `ci.yml` into a separate file, we can handle it programmatically, which should make it easier to both do local execution of CI jobs and also to do arbitrary try builds.
Rollup of 4 pull requests
Successful merges:
- #123900 (Stop using `PolyTraitRef` for closure/coroutine predicates already instantiated w placeholders)
- #123924 (Fix various bugs in `ty_kind_suggestion`)
- #123943 (Use the rustc_private libc less in tests)
- #123970 (zkvm: fix references to `os_str` module)
r? `@ghost`
`@rustbot` modify labels: rollup
zkvm: fix references to `os_str` module
The `os_str` module has been moved to `sys`. This change fixes build issues by changing `use` to point to `crate::sys::os_str`.
Use the rustc_private libc less in tests
I started looking into our use of `rustc_private` + `extern crate libc;` in tests because of https://github.com/rust-lang/rust/pull/123938 and it looks like some fraction of the users of libc simply don't need the libc crate anymore.
Fix various bugs in `ty_kind_suggestion`
Consolidates two implementations of `ty_kind_suggestion`
Fixes some misuse of the empty param-env
Fixes a problem where we suggested `(42)` instead of `(42,)` for tuple suggestions
Suggest a value when `return;`, making it consistent with `break;`
Fixes#123906
Rollup of 12 pull requests
Successful merges:
- #123423 (Distribute LLVM bitcode linker as a preview component)
- #123548 (libtest: also measure time in Miri)
- #123666 (Fix some typos in doc)
- #123864 (Remove a HACK by instead inferring opaque types during expected/formal type checking)
- #123896 (Migrate some diagnostics in `rustc_resolve` to session diagnostic)
- #123919 (builtin-derive: tag → discriminant)
- #123922 (Remove magic constants when using `base_n`.)
- #123931 (Don't leak unnameable types in `-> _` recover)
- #123933 (move the LargeAssignments lint logic into its own file)
- #123934 (`rustc_data_structures::graph` mini refactor)
- #123941 (Fix UB in LLVM FFI when passing zero or >1 bundle)
- #123957 (disable create_dir_all_bare test on all(miri, windows))
r? `@ghost`
`@rustbot` modify labels: rollup
Fix UB in LLVM FFI when passing zero or >1 bundle
Rust passes a `*const &OperandBundleDef` to these APIs, usually from a `Vec<&OperandBundleDef>` or so. Previously we were dereferencing that pointer and passing it to the ArrayRef constructor with some length (N).
This meant that if the length was 0, we were dereferencing a pointer to nowhere (if the vector on the Rust side didn't actually get allocated or so), and if the length was >1 then loading the *second* element somewhere in LLVM would've been reading past the end.
Since Rust can't hold OperandBundleDef by-value we're forced to indirect through a vector that copies out the OperandBundleDefs from the by-reference list on the Rust side in order to match the LLVM expected API.
move the LargeAssignments lint logic into its own file
The collector is a file full of very subtle logic, so let's try to keep that separate from the logic that only serves to implement this lint.
Remove magic constants when using `base_n`.
Some use cases of `base_n` use number literals instead of the predefined constants. The latter are more descriptive so it might be better to use those instead.
builtin-derive: tag → discriminant
As far as I can tell, all of this operates on the discriminant, not the tag. After all, with something like `Option<&T>`, the "tag" of the `Some` variant is basically just the reference value, which is never what you want to compare when figuring out which variant the enum is in.
See [here](https://rustc-dev-guide.rust-lang.org/appendix/glossary.html) for an explanation of the difference between tag and discriminant.
Migrate some diagnostics in `rustc_resolve` to session diagnostic
Hello, I migrated some diagnostics in `rustc_resolve` to session diagnostic.
r? ``@davidtwco``
