Allow Weak::as_ptr and friends for unsized T
Relaxes `impl<T> Weak<T>` to `impl<T: ?Sized> Weak<T>` for the methods `rc::Weak::as_ptr`, `into_raw`, and `from_raw`.
Follow-up to #73845, which did most of the impl work to make these functions work for `T: ?Sized`.
We still have to adjust the implementation of `Weak::from_raw` here, however, because I missed a use of `ptr.is_null()` previously. This check was necessary when `into`/`from_raw` were first implemented, as `into_raw` returned `ptr::null()` for dangling weak. However, we now just (wrapping) offset dangling weaks' pointers the same as nondangling weak, so the null check is no longer necessary (or even hit). (I can submit just 17a928f as a separate PR if desired.)
As a nice side effect, moves the `fn is_dangling` definition closer to `Weak::new`, which creates the dangling weak.
This technically stabilizes that "something like `align_of_val_raw`" is possible to do. However, I believe the part of the functionality required by these methods here -- specifically, getting the alignment of a pointee from a pointer where it may be dangling iff the pointee is `Sized` -- is uncontroversial enough to stabilize these methods without a way to implement them on stable Rust.
r? `@RalfJung,` who reviewed #73845.
ATTN: This changes (relaxes) the (input) generic bounds on stable fn!
This matches Cargo behavior and avoids the (somewhat expensive) double checking,
as well as the unfortunate duplicate error messages (#76822,
rust-lang/cargo#5128).
Remove --cfg dox from rustdoc.rs
This was added in https://github.com/rust-lang/rust/pull/53076 because
several dependencies were using `cfg(dox)` instead of `cfg(rustdoc)` (now `cfg(doc)`).
I ran `rg 'cfg\(dox\)'` on the source tree with no matches, so I think
this is now safe to remove.
r? `@Mark-Simulacrum`
cc `@QuietMisdreavus` :)
Rollup of 8 pull requests
Successful merges:
- #75377 (Fix Debug implementations of some of the HashMap and BTreeMap iterator types)
- #76107 (Write manifest for MAJOR.MINOR channel to enable rustup convenience)
- #76745 (Move Wrapping<T> ui tests into library)
- #77182 (Add missing examples for Fd traits)
- #77251 (Bypass const_item_mutation if const's type has Drop impl)
- #77264 (Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used. )
- #77421 (Revert "resolve: Avoid "self-confirming" import resolutions in one more case")
- #77452 (Permit ty::Bool in const generics for v0 mangling)
Failed merges:
r? `@ghost`
Permit ty::Bool in const generics for v0 mangling
This should unbreak using new-symbol-mangling = true in config.toml (once it lands in beta anyway).
Fixes#76365 (well, it will, but seems fine to close as soon as we have support)
r? @eddyb (for mangling) but I'm okay with some other reviewer too :)
Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used.
The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However, every program will check these variables on every print, even outside of testing.
This involves allocating a thread local key, and registering a thread local destructor. This can be somewhat expensive.
This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So, effectively only in test and benchmark runs.) When this flag is off, these thread locals are not even looked at and therefore will not be initialized on the first output on every thread, which also means no thread local destructors will be registered.
---
Together with https://github.com/rust-lang/rust/pull/77154, this should make output a little bit more efficient.
Bypass const_item_mutation if const's type has Drop impl
Follow-up to #75573. This PR disables the const_item_mutation lint in cases that the const has a Drop impl which observes the mutation.
```rust
struct Log { msg: &'static str }
const LOG: Log = Log { msg: "" };
impl Drop for Log {
fn drop(&mut self) { println!("{}", self.msg); }
}
LOG.msg = "wow"; // prints "wow"
```
r? @Aaron1011
Write manifest for MAJOR.MINOR channel to enable rustup convenience
This connects to https://github.com/rust-lang/rustup/issues/794.
It's hard to remember if there have been patch releases for old versions
when you'd like to install the latest in a MAJOR.MINOR series.
When we're doing a stable release, we write duplicate manifests to
`stable`. With this change, only when we're doing a stable release, also
write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup
(and any other tooling that builds Rust release URLs) to request, say,
`1.45` and get `1.45.2` (assuming `1.45.2` is the latest available
`1.45` and assuming that we never publish patch releases out of order).
I tested the best I could; it's a bit hard to get everything set up right
to be able to run the build-manifest tool. But I was able to run it with
a release of "1.45.2" and in addition to the files like `channel-rust-1.45.2.toml`
and `channel-rust-stable.toml` (and other manifests) that I got before this
change, I now get `channel-rust-1.45.toml`.
I believe this change to be safe to deploy as it does not change or remove
anything about manifests, just adds more. The actions in rust-central-station
that interact with manifests appear to use wildcards in such a way that it will
pick up these files without any problems.
There will need to be changes to `rustup` before `rustup install 1.45` will work,
but we can wait for a stable release and stable patch releases to happen with this
change before making the `rustup` changes, so that we're not committing to anything
before we know it works.
Fix Debug implementations of some of the HashMap and BTreeMap iterator types
HashMap's `ValuesMut`, BTreeMaps `ValuesMut`, IntoValues and `IntoKeys` structs were printing both keys and values on their Debug implementations. But they are iterators over either keys or values. Irrelevant values should not be visible. With this PR, they only show relevant fields.
This fixes#75297.
[Here's an example code.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0c79356ed860e347a0c1a205616f93b7) This prints this on nightly:
```
ValuesMut { inner: IterMut { range: [(1, "hello"), (2, "goodbye")], length: 2 } }
IntoKeys { inner: [(1, "hello"), (2, "goodbye")] }
IntoValues { inner: [(1, "hello"), (2, "goodbye")] }
[(2, "goodbye"), (1, "hello")]
```
After the patch this example prints these instead:
```
["hello", "goodbye"]
["hello", "goodbye"]
[1, 2]
["hello", "goodbye"]
```
I didn't add test cases for them, since I couldn't see any tests for Debug implementations anywhere. But please let me know if I should add it to a specific place.
r? @dtolnay
The previous error was confusing since it made it sound like you can't
link to items that are defined outside the current module.
Also suggested importing the item.
Stop running macOS builds on Azure Pipelines
The Infrastructure Team agreed to migrate macOS builds to GitHub Actions, so this commit stops running those builders on Azure Pipelines. The GitHub Actions runners are already configured to upload to the production bucket.
We can't still fully remove the Azure Pipelines configuration, as we still need to have that available until no stable releases run any of their builds on Azure Pipelines anymore. I'll open an issue to track fully removing our Azure Pipelines setup once the PR is merged.
r? @Mark-Simulacrum
Fix AVR stack corruption bug
Updates the Rust LLVM fork to pull in a fix for a stack corruption bug in AVR platform interrupt code lowering.
Fixes#75504
----
It looks like this is also pulling in a register selection fix by @Amanieu and @tambry that hasn't merged yet; I don't see an open PR for that update.
Use posix_spawn on musl targets
The posix_spawn had been available in a form suitable for use in a
Command implementation since musl 0.9.12. Use it in a preference to a
fork when possible, to benefit from CLONE_VM|CLONE_VFORK used there.
Add `-Zprecise-enum-drop-elaboration`
Its purpose is to assist in debugging #77382 and #74551. Passing `-Zprecise-enum-drop-elaboration=no` will turn off the added precision that seems to be causing issues on some platforms. This assumes that we can reproduce #77382 on the latest master. I should have done this earlier. Oh well.
cc @cuviper
r? @pnkfelix
resolve: prohibit anon const non-static lifetimes
Fixes#75323, fixes#74447 and fixes#73375.
This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so, `to_region_vid`'s `bug!` had to be changed into a delayed bug, which unfortunately required providing it a `TyCtxt`.~~
---
~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const`, emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked, but it didn't silence the ICE either. To silence the ICE, I changed it to a delayed bug which worked but was more invasive that I would have liked, and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary, but I wasn't sure where that would be and wanted to get some feedback first.~~
The approach taken by this PR has been changed to implement the error in name resolution, which ended up being much simpler.
cc @rust-lang/wg-const-eval
r? @lcnr
