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
in which the E0618 "expected function" diagnostic gets a makeover
A woman of wisdom once told me, "Better late than never." (Can't reopen the previously-closed pull request from six months ago [due to GitHub limitations](https://github.com/rust-lang/rust/pull/51098#issuecomment-437647157).)
Now the main span focuses on the erroneous not-a-function callee, while showing the entire call expression is relegated to a secondary span. In the case where the erroneous callee is itself a call, we
point out the definition, and, if the call expression spans multiple lines, tentatively suggest a semicolon (because we suspect that the "outer" call is actually supposed to be a tuple).
The new `bug!` assertion is, in fact, safe (`confirm_builtin_call` is only called by `check_call`, which is only called with a first arg of kind `ExprKind::Call` in `check_expr_kind`).
Resolves#51055.
r? @estebank
Now the main span focuses on the erroneous not-a-function callee,
while showing the entire call expression is relegated to a secondary
span. In the case where the erroneous callee is itself a call, we
point out the definition, and, if the call expression spans multiple
lines, tentatively suggest a semicolon (because we suspect that the
"outer" call is actually supposed to be a tuple).
The new `bug!` assertion is, in fact, safe (`confirm_builtin_call` is
only called by `check_call`, which is only called with a first arg of
kind `ExprKind::Call` in `check_expr_kind`).
Resolves#51055.
Take supertraits into account when calculating associated types
Fixes#24010 and #23856. Applies to trait aliases too.
As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See #50589 for more info.
I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+.
N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this.
CC @carllerche @theemathas @durka @mbrubeck
Bubble up an overflow error so that rustdoc can ignore it
fixes#54524
Idk how to write a test for this, other than trying to minimize the entire diesel crate. If desirable I will do that.
Note that there are many other such overflow errors hiding out there. Should we try to proactively eliminate them or do we just whack-a-mole them?
cc @GuillaumeGomez
r? @nikomatsakis
Update emscripten
This updates emscripten to 1.38.15, which is based on LLVM 6.0.1 and would allow us to drop code for handling LLVM 4.
The main issue I ran into is that exporting statics through `EXPORTED_FUNCTIONS` no longer works. As far as I understand exporting non-functions doesn't really make sense under emscripten anyway, so I've modified the symbol export code to not even try.
Closes#52323.
I also added `// skip-codegen` to each one, to address potential concerns
that this change would otherwise slow down our test suite spending time
generating code for files that are really just meant to be checks of
compiler diagnostics.
(However, I will say: My preference is to not use `// skip-codegen` if
one can avoid it. We can use all the testing of how we drive LLVM that
we can get...)
(Updated post rebase.)
