bootstrap: Don't panic on `x install --set build.extended=true`
This was a regression from rust-lang/rust#155732.
The Cargo submodule wasn't checked out, so reading from Cargo.toml didn't work. Return a fake version during dry-runs to avoid unnecessarily checking out submodules.
Fixes https://github.com/rust-lang/rust/issues/156408.
Improve doc comments for f32::ceil() and f32::floor()
Previously ::floor() included an example showing behaviour for negative values, but ::ceil() did not. Ensure both have examples of the negative case, for both f32 and f64.
Whilst we're here, tweak the wording slightly so it reads better.
Remove some dead code for dumping MIR for a single DefId
The functions that call `dump_mir_def_ids` are themselves never called with a specific DefId; they always dump MIR for the entire crate.
remove allows_weak_linkage target spec flag
The flag doesn't actually do anything. I have no idea what it's original purpose was.
It got introduced in https://github.com/rust-lang/rust/commit/59cfe904dcfbe2c3ad5396131b3d3ba6b7179fdd, but already a few months later in https://github.com/rust-lang/rust/commit/57950982b27c6ab45509c1f2db4a01fa1d2cfebb both of its uses were removed when the entire file `src/librustc_trans/closure.rs` got deleted.
It seems like back in the day we used weak linkage for closures by default and MinGW wasn't happy about that? But not much later the way we compile closures got changed, making the work-around unnecessary. The flag has then persisted unused for 10 years. A couple of Windows/UEFI targets are setting `allows_weak_linkage: false` but I assume that was just cargo-culted.
But to be sure, let's ping the folks listed for the affected targets and other Windows folks:
@dvdhrm @nicholasbishop @Berrysoft @mati865 @thomcc @tbu- @ChrisDenton
Refuse to push changes with a dirty git client
I've run into the issue more than once where I've fixed an issue in my client but forgotten to commit it one way or another. The verification succeeds because the files on disk are correct even though the files in the commit being pushed are incorrect.
This change checks to see if there are any uncommitted changes in tracked files in the client before running the tidy checks.
resolve: Module-related refactorings
Extracted parts of https://github.com/rust-lang/rust/pull/156362 that don't require splitting `(Local,Extern)ModuleData` into separate data structures.
- Some `expect_local` assertions are added
- Methods that need to exist on all of `Module` and `(Local,Extern)Module` are implemented for `ModuleData`
- Methods that need to exist on `ModuleKind` are moved to `ModuleKind`
- Some unnecessary complicated logic using `graph_root` is simplified
- `glob_importers` are filled and used only for local modules.
- Some unnecessary logic is skipped for extern modules in `resolve_ident_in_module_non_globs_unadjusted`
- Module construction functions are cleaned up
- `module_to_string` is simplified
r? @nnethercote
kernel_copy tests: properly join background threads
This helps Miri because when there are threads just hanging in the background, we cannot check for memory leaks.
I think even without Miri this currently leads to 100% CPU load on one core for each of these threads: once the test function returns and `sink` gets dropped, the `read` in the thread will always immediately return `0`, and then we just loop with that forever until the process exits.
tests: ip*_properties: avoid parsing the IP over and over again
This test somehow takes 12s to execute in Miri (on CI, i.e. on a slow machine), despite not having any loop. I suspect it's caused by us for some reason re-parsing the same string again and again. Let's just not do that.
remove forever-deprecated and hidden `f64` methods
The methods `f64::is_positive` and `f64::is_negative` were deprecated since 1.0 and marked as `#[doc(hidden)]` in favor of `f64::is_sign_positive` and `f64::is_sign_negative`. They also only exist on `f64`, not on `f32`. But for some unknown reason, they have been marked as stable.
This PR proposes to remove both methods as they were never a part of the documented API, assuming that a crater run finds no significant breakage.
This was a regression from 155732.
The Cargo submodule wasn't checked out, so reading from Cargo.toml
didn't work. Return a fake version during dry-runs to avoid
unnecessarily checking out submodules.
stream_send_recv_stress tests: wait for threads to finish
These tests currently fail in Miri (when run with nextest) because all they do is spawn a lot of threads that will do stuff, but they don't wait for the threads to actually finish. Miri by default errors when there are background threads lingering when `main` is done (since that can indicate a leak, and since it makes it impossible to check for memory leaks). Miri gives background threads a bit of time to finish when `main` is done, but for these tests that's nowhere near enough since basically the entire test runs after `main` is done.
Outside Miri, this could also still mean that the test doesn't actually run to completion, it might get abort when `main` finishes.
So let's use `thread::scope` to ensure all threads are done before the test is considered done.
compiletest: Migrate from `PassMode`/`FailMode` to `PassFailMode`
Every UI test has an explicit or implicit “pass/fail mode” (e.g. `check-fail` or `build-pass`) that was historically stored in two separate optional fields (`pass_mode` and `fail_mode`). That split made it very hard to determine how the respective values were actually produced and consumed, especially in the presence of `--pass=check` on the command-line, or when building auxiliary crates.
This PR replaces the separate fields and enums for pass-mode and fail-mode with a single `PassFailMode` enum and a single `pass_fail_mode` field.
With this new representation, it should hopefully be easier to understand and modify the pass/fail-mode logic.
---
In order to focus on the main migration, I have mostly refrained from subsequent cleanups.
r? jieyouxu
rustdoc: Reify emission types
Implements https://github.com/rust-lang/rust/pull/155374#discussion_r3124208232:
Instead of maintaining the hidden assumption or invariant that `opts.emit.is_empty()` actually means "emit default artifacts" (i.e., `[HtmlStaticFiles, HtmlNonStaticFiles]` under output format `html`; "`[???]`" under output format `json`), actually *reify* the list of emission types so the rest of the code doesn't need to keep this in mind.
I'm not sure if you like this. It's a tinge overengineered, maybe, but it's more robust I claim.
This PR also rejects `--emit` when `--output-format doctest -Zunstable-options` is passed since the latter doesn't honor emission types at all (yet).
Add `Drop::pin_drop` for pinned drops
This PR is part of the `pin_ergonomics` experiment (the tracking issue is rust-lang/rust#130494). It allows implementing `Drop` with a pinned `self` receiver, which is required for safe pin-projection.
Implementations:
- [x] At least and at most one of `drop` and `pin_drop` should be implemented.
- [x] No direct call of `drop` or `pin_drop`. They should only be called by the drop glue.
- [x] `pin_drop` must and must only be used with types that support pin-projection (i.e. types with `#[pin_v2]`).
- [ ] Allows writing `fn drop(&pin mut self)` and desugars to `fn pin_drop(&pin mut self)`. (Will be in the next PRs)
Previously ::floor() included an example showing behaviour for
negative values, but ::ceil() did not. Ensure both have examples of
the negative case, for both f32 and f64.
Whilst we're here, tweak the wording slightly so it reads better.
yukang