Fix various aspects around `let` bindings inside const functions
* forbid `let` bindings in const contexts that use short circuiting operators
* harden analysis code against derefs of mutable references
Initially this PR was about stabilizing `let` bindings, but too many flaws were exposed that need some more testing on nightly
add coherence future-compat warnings for marker-only trait objects
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
Note: this lint should be made to default-warn before we merge. It is deny only for the crater run.
r? @nikomatsakis / @scalexm . cc @Centril & @alexreg.
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
It should be possible to revert this commit when we're done with the
warnings.
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: 28ee12db81
Consider references and unions potentially inhabited during privacy-respecting inhabitedness checks
It isn't settled exactly how references to uninhabited types and unions of uninhabited types should act, but we should be more conservative here, as it's likely it will be permitted to soundly have values of such types.
This will also be more important in light of the changes at https://github.com/rust-lang/rust/pull/54125.
cc @RalfJung
Check arg/ret sizedness at ExprKind::Path
This PR solves three problems:
- #50940: ICE on casting unsized tuple struct constructors
- Unsized tuple struct constructors were callable in presence of `unsized_locals`.
- https://github.com/rust-lang/rust/issues/48055#issuecomment-437178966: we cannot relax `Sized` bounds on stable functions because of fn ptr casting
These are caused by lack of `Sized`ness checks for arguments/retvals at **reference sites of `FnDef` items** (not call sites of the functions). Therefore we can basically add more `Sized` obligations on typeck. However, adding `Sized` obligations arbitrarily breaks type inference; to prevent that I added a new method `require_type_is_sized_deferred` which doesn't interfere usual type inference.
Cleanup from lexical MIR borrowck removal
Lexical MIR borrowck was removed months ago now, and `EndRegion`s are no longer used for MIRI verification.
* Remove `rustc::mir::StatementKind::EndRegion` and the `-Zemit_end_regions` flag
* Use `RegionVid` instead of `Region` in BorrowSet
* Rewrite drop generation to create fewer goto terminators.
r? @nikomatsakis
Suggest correct syntax when writing type arg instead of assoc type
- When confusing an associated type with a type argument, suggest the appropriate syntax. Given `Iterator<isize>`, suggest `Iterator<Item = isize>`.
- When encountering multiple missing associated types, emit only one diagnostic.
- Point at associated type def span for context.
- Point at each extra type argument.
Follow up to #48288, fix#20977.
Rollup of 25 pull requests
Successful merges:
- #55562 (Add powerpc- and powerpc64-unknown-linux-musl targets)
- #55564 (test/linkage-visibility: Ignore on musl targets)
- #55827 (A few tweaks to iterations/collecting)
- #55834 (Forward the ABI of the non-zero sized fields of an union if they have the same ABI)
- #55857 (remove unused dependency)
- #55862 (in which the E0618 "expected function" diagnostic gets a makeover)
- #55867 (do not panic just because cargo failed)
- #55894 (miri enum discriminant handling: Fix treatment of pointers, better error when it is undef)
- #55916 (Make miri value visitor useful for mutation)
- #55919 (core/tests/num: Simplify `test_int_from_str_overflow()` test code)
- #55923 (reword #[test] attribute error on fn items)
- #55949 (ty: return impl Iterator from Predicate::walk_tys)
- #55952 (Update to Clang 7 on CI.)
- #55953 (#53488 Refactoring UpvarId)
- #55962 (rustdoc: properly calculate spans for intra-doc link resolution errors)
- #55963 (Stress test for MPSC)
- #55968 (Clean up some non-mod-rs stuff.)
- #55970 (Miri backtrace improvements)
- #56007 (CTFE: dynamically make sure we do not call non-const-fn)
- #56011 (Replace data.clone() by Arc::clone(&data) in mutex doc.)
- #56012 (avoid shared ref in UnsafeCell::get)
- #56016 (Add VecDeque::resize_with)
- #56027 (docs: Add missing backtick in object_safety.rs docs)
- #56043 (remove "approx env bounds" if we already know from trait)
- #56059 (Increase `Duration` approximate equal threshold to 1us)
CTFE: dynamically make sure we do not call non-const-fn
I'd love to have a test case for this, but I don't know how.
I am also really surprised by this test case that changed behavior: Why did it even start execution if it already determined that it shouldn't?!?
r? @oli-obk
