stabilize core parts of MaybeUninit
and deprecate mem::uninitialized in the future (1.40.0). This is part of implementing https://github.com/rust-lang/rfcs/pull/1892.
Also expand the documentation a bit.
This type is currently primarily useful when dealing with partially initialized arrays. In libstd, it is used e.g. in `BTreeMap` (with some unstable APIs that however can all be replaced, less ergonomically, by stable ones). What we stabilize should also be enough for `SmallVec` (Cc @bluss).
Making this useful for structs requires https://github.com/rust-lang/rfcs/pull/2582 or a commitment that references to uninitialized data are not insta-UB.
Remove the unstable and deprecated mpsc_select
This removes macro `select!` and `std::sync::mpsc::{Handle, Select}`,
which were all unstable and have been deprecated since 1.32.
Closes#27800
r? @SimonSapin
Fix lints handling in rustdoc
Part of #60664: now lints are handled just like any other lints you would setup in rustc. Still remains to handle `missing code examples` and `missing_docs` as part of the same group.
r? @oli-obk
Perform constant propagation into terminators
Perform constant propagation into MIR `Assert` and `SwitchInt` `Terminator`s which in some cases allows them to be removed by the branch simplification pass.
r? @oli-obk
Test interaction of unions with non-zero/niche-filling optimization
Notably this nails down part of the behavior that MaybeUninit assumes, e.g. that a Option<MaybeUninit<&u8>> does not take advantage of non-zero optimization, and thus is a safe construct.
It also verifies the status quo: that even unions that could theoretically take advantage of niches don't. (relevant: https://github.com/rust-lang/rust/issues/36394)
rustdoc: set the default edition when pre-parsing a doctest
Fixes https://github.com/rust-lang/rust/issues/59313 (possibly more? i think we've had issues with parsing edition-specific syntax in doctests at some point)
When handling a doctest, rustdoc needs to parse it beforehand, so that it can see whether it declares a `fn main` or `extern crate my_crate` explicitly. However, while doing this, rustdoc doesn't set the "default edition" used by the parser like the regular compilation runs do. This caused a problem when parsing a doctest with an `async move` block in it, since it was expecting the `move` keyword to start a closure, not a block.
This PR changes the `rustdoc::test::make_test` function to set the parser's default edition while looking for a main function and `extern crate` statement. However, to do this, `make_test` needs to know what edition to set. Since this is also used during the HTML rendering process (to make playground URLs), now the HTML renderer needs to know about the default edition. Upshot: rendering standalone markdown files can now accept a "default edition" for their doctests with the `--edition` flag! (I'm pretty sure i waffled around how to set that a long time ago when we first added the `--edition` flag... `>_>`)
I'm posting this before i stop for the night so that i can write this description while it's still in my head, but before this merges i want to make sure that (1) the `rustdoc-ui/failed-doctest-output` test still works (i expect it doesn't), and (2) i add a test with the sample from the linked issue.
Mark core::alloc::Layout::from_size_align_unchecked const
Makes it possible (pending stabilization of #57563 (`const_fn`)) to rewrite code like
```rust
const BUFFER_SIZE: usize = 0x2000;
const BUFFER_ALIGN: usize = 0x1000;
fn foo() {
let layout = std::alloc::Layout::from_size_align(BUFFER_SIZE, BUFFER_ALIGN)
.unwrap();
let buffer = std::alloc::alloc(layout);
}
```
to
```rust
const BUFFER_LAYOUT: std::alloc::Layout = unsafe {
std::alloc::Layout::from_size_align_unchecked(0x2000, 0x1000)
};
fn foo() {
let buffer = std::alloc::alloc(BUFFER_LAYOUT);
}
```
which (although `unsafe` is used) looks somewhat cleaner and is easier to read.
Added ignore-sgx for appropriate tests in src/test
These are all the tests that make sense to ignore when targeting fortanix-unknonw-sgx, at least in test/runpass. Other suites not yet covered.
lint: convert incoherent_fundamental_impls into hard error
*Summary for affected authors:* If your crate depends on one of the following crates, please upgrade to a newer version:
- gtk-rs: upgrade to at least 0.4
- rusqlite: upgrade to at least 0.14
- nalgebra: upgrade to at least 0.15, or the last patch version of 0.14
- spade: upgrade or refresh the Cargo.lock file to use version 1.7
- imageproc: upgrade to at least 0.16 (newer versions no longer use nalgebra)
implement #46205
r? @nikomatsakis
Checking generic args after late bound region err.
Fixes#60622.
This PR fixes an ICE that occurs when a late bound region error is
emitted and that resulted in the rest of the generic arguments of a
function not being checked.
For example, you could specify a generic type parameter `T` in a function
call `foo<'_, T>()` to a function that doesn't have a generic type
parameter.
Since an error wasn't emitted from the function, compilation
continued to parts of typeck that didn't expect a generic type argument
in a call for a function that didn't have any generic type arguments.
This commit fixes an ICE that occurs when a late bound region error is
emitted and that resulted in the rest of the generic arguments of a
function not being checked.
For example, you could specify a generic type parameter `T` in a function
call `foo<'_, T>()` to a function that doesn't have a generic type
parameter.
Since an error wasn't emitted from the function, compilation
continued to parts of typeck that didn't expect a generic type argument
in a call for a function that didn't have any generic type arguments.
Include expression to wait for to the span of Await
Currently the span of `await!` only includes itself:
```rust
await!(3);
// ^^^^^
```
This PR changes it so that the span holds the whole `await!` expression:
```rust
await!(3);
// ^^^^^^^^^
Remove bitrig support from rust
Resolves#60743
using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?).
There's also this file 5b8e99bb61/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
default to $ARCH-apple-macosx10.7.0 LLVM triple for darwin targets
Over in #60378, we made `rustc` switch LLVM target triples dynamically
based on the `MACOSX_DEPLOYMENT_TARGET` environment variable. This
change was made to align with `clang`'s behavior, and therefore make
cross-language LTO feasible on OS X. Otherwise, `rustc` would produce
LLVM bitcode files with a target triple of `x86_64-apple-darwin`,
`clang` would produce LLVM bitcode files with a target triple of
`x86_64-apple-macosx$VERSION`, and the linker would complain.
This change worked fine, except for one corner case: if you didn't have
`MACOSX_DEPLOYMENT_TARGET` set, and you wanted to do LTO on just Rust
code, you'd get warning messages similar to:
```
warning: Linking two modules of different target triples: ' is 'x86_64-apple-macosx10.7.0' whereas 'main.7rcbfp3g-cgu.4' is 'x86_64-apple-darwin'
```
This message occurs because libstd is compiled with
`MACOSX_DEPLOYMENT_TARGET` set to 10.7. The LLVM bitcode distributed in
libstd's rlibs, then, is tagged with the target triple of
`x86_64-apple-macosx10.7.0`, while the bitcode `rustc` produces for
"user" code is tagged with the target triple of `x86_64-apple-darwin`.
It's not good to have LTO on just Rust code (probably much more common
than cross-language LTO) warn by default. These warnings also break
Cargo's testsuite.
This change defaults to acting as though `MACOSX_DEPLOYMENT_TARGET` was
set to 10.7. "user" code will then be given a target triple that is
equivalent to the target triple libstd bitcode is already using. The
above warning will therefore go away.
`rustc` already assumes that compiling without
`MACOSX_DEPLOYMENT_TARGET` means that we're compiling for a target
compatible with OS X 10.7 (e.g. that things like TLS work properly). So
this change is really just making things conform more closely to the
status quo.
(It's also worth noting that before and after this patch, compiling with
`MACOSX_DEPLOYMENT_TARGET` set to, say, 10.9, works just fine: target
triples with an "apple" version ignore OS versions when checking
compatibility, so bitcode with a `x86_64-apple-macosx10.7.0` triple works just
fine with bitcode with a `x86_64-apple-macosx10.9.0` triple.)
forego caching for all participants in cycles, apart from root node
This is a targeted fix for #60010, which uncovered a pretty bad failure of our caching strategy in the face of coinductive cycles. The problem is explained in the comment in the PR on the new field, `in_cycle`, but I'll reproduce it here:
> Starts out as false -- if, during evaluation, we encounter a
> cycle, then we will set this flag to true for all participants
> in the cycle (apart from the "head" node). These participants
> will then forego caching their results. This is not the most
> efficient solution, but it addresses #60010. The problem we
> are trying to prevent:
>
> - If you have `A: AutoTrait` requires `B: AutoTrait` and `C: NonAutoTrait`
> - `B: AutoTrait` requires `A: AutoTrait` (coinductive cycle, ok)
> - `C: NonAutoTrait` requires `A: AutoTrait` (non-coinductive cycle, not ok)
>
> you don't want to cache that `B: AutoTrait` or `A: AutoTrait`
> is `EvaluatedToOk`; this is because they were only considered
> ok on the premise that if `A: AutoTrait` held, but we indeed
> encountered a problem (later on) with `A: AutoTrait. So we
> currently set a flag on the stack node for `B: AutoTrait` (as
> well as the second instance of `A: AutoTrait`) to supress
> caching.
>
> This is a simple, targeted fix. The correct fix requires
> deeper changes, but would permit more caching: we could
> basically defer caching until we have fully evaluated the
> tree, and then cache the entire tree at once.
I'm not sure what the impact of this fix will be in terms of existing crates or performance: we were accepting incorrect code before, so there will perhaps be some regressions, and we are now caching less.
As the comment above notes, we could do a lot better than this fix, but that would involve more invasive rewrites. I thought it best to start with something simple.
r? @pnkfelix -- but let's do crater/perf run
cc @arielb1
