Fixes#75904
When emitting move/borrow errors, we may point into a closure to
indicate why an upvar is used in the closure. However, we use the
'upvar span', which is just an arbitrary usage of the upvar. If the
upvar is used in multiple places (e.g. a borrow and a move), we may end
up pointing to the borrow. If the overall error is a move error, this
can be confusing.
This PR tracks the span that caused an upvar to become captured by-value
instead of by-ref (assuming that it's not a `move` closure). We use this
span instead of the 'upvar' span when we need to point to an upvar usage
during borrow checking.
Refactor dynamic library error checking on *nix
The old code was checking `dlerror` more often than necessary, since (unlike `dlsym`) checking the return value of [`dlopen`](https://www.man7.org/linux/man-pages/man3/dlopen.3.html) is enough to indicate whether an error occurred. In the first commit, I've refactored the code to minimize the number of system calls needed. It should be strictly better than the old version.
The second commit is an optional addendum which fixes the issue observed on illumos in #74469, a PR I reviewed that was ultimately closed due to inactivity. I'm not sure how hard we try to work around platform-specific bugs like this, and I believe that, due to the way that `dlerror` is specified in the POSIX standard, libc implementations that want to run on conforming systems cannot call `dlsym` in multi-threaded programs.
Fix incorrect suggestion when `clone_on_ref_ptr` is triggered in macros
In the lint `clone_on_ref_ptr`, if the `span` is in a macro, don't expand it for suggestion.
Fixes: #2076
changelog: none
r? @ebroto
Be consistent when describing a move as a 'partial' in diagnostics
When an error occurs due to a partial move, we would use the world
"partial" in some parts of the error message, but not in others. This
commit ensures that we use the word 'partial' in either all or none of
the diagnostic messages.
Additionally, we no longer describe a move out of a `Box` via `*` as
a 'partial move'. This was a pre-existing issue, but became more
noticable when the word 'partial' is used in more places.
- Give a suggestion even if there is no span available
- Give a more accurate description of the change than 'use the
disambiguator'
- Write much less code
Re-enable len_zero for ranges now that `is_empty` is stable on them
Fixes#5956
Completed stabilization PR: https://github.com/rust-lang/rust/pull/75132
changelog: len_zero: re-enable linting ranges now that range_is_empty is stable
Refactor the partitioning module to make it easier to introduce new algorithms
I've split the `librustc_mir::monomorphize::partitioning` module into a few files and introduced a `Partitioner` trait which allows us to decouple the partitioning algorithm from the code which integrates it into the query system. This should allow us to introduce new partitioning algorithms much more easily. I've also gone ahead and added a `-Z` flag to control which algorithm is used (currently there is only the `default`).
I left a few comments in places where things might be improved further.
r? @pnkfelix cc @rust-lang/wg-incr-comp
Bump LLVM on CI to 10.0.0
This PR bumps the LLVM version we use on our macOS and Windows CI to 10.0.0, fixing a breakage we noticed today:
```
2020-08-25T14:24:28.5939568Z FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.obj
2020-08-25T14:24:28.5940317Z D:\a\rust\rust\build\bootstrap\debug\sccache-plus-cl.exe /nologo -TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib\Support -ID:\a\rust\rust\src\llvm-project\llvm\lib\Support -Iinclude -ID:\a\rust\rust\src\llvm-project\llvm\include -nologo -MT -Brepro --target=x86_64-pc-windows-msvc /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /Brepro /W4 -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wno-noexcept-type -Wno-comment /Gw /MT /O2 /Ob2 -UNDEBUG -std:c++14 /EHs-c- /GR- /showIncludes /Folib\Support\CMakeFiles\LLVMSupport.dir\AMDGPUMetadata.cpp.obj /Fdlib\Support\CMakeFiles\LLVMSupport.dir\LLVMSupport.pdb -c D:\a\rust\rust\src\llvm-project\llvm\lib\Support\AMDGPUMetadata.cpp
2020-08-25T14:24:28.5940861Z clang-cl: warning: argument unused during compilation: '-Brepro' [-Wunused-command-line-argument]
2020-08-25T14:24:28.5941076Z clang-cl: warning: argument unused during compilation: '-Brepro' [-Wunused-command-line-argument]
2020-08-25T14:24:28.5941321Z In file included from D:\a\rust\rust\src\llvm-project\llvm\lib\Support\AMDGPUMetadata.cpp:15:
2020-08-25T14:24:28.5941545Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/Twine.h:12:
2020-08-25T14:24:28.5941774Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/SmallVector.h:16:
2020-08-25T14:24:28.5942016Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/iterator_range.h:21:
2020-08-25T14:24:28.5942257Z In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\iterator:9:
2020-08-25T14:24:28.5942542Z C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\yvals_core.h(494,2): error: STL1000: Unexpected compiler version, expected Clang 10.0.0 or newer.
```
I uploaded both the new tarballs to our mirrors bucket.
Originally I tried to do a much broader refactoring that got rid of `init_lints` altogether. My reasoning is that now the lints aren't being run anymore (after https://github.com/rust-lang/rust/pull/73566), there's no need to ignore them explicitly. But it seems there are still some lints that aren't affected by setting `lint_mod` to a no-op:
```
deny(pub_use_of_private_extern_crate)
deny(const_err)
warn(unused_imports)
```
(there are possibly more, these are just the ones that failed in the rustdoc test suite).
Some of these seem like we really should be warning about, but that's a much larger change and I don't propose to make it here. So for the time being, this just adds the `unknown_lints` and `renamed_or_removed_lints` passes to the list of lints rustdoc warns about.
Introduce expect snapshot testing library into rustc
Snapshot testing is a technique for writing maintainable unit tests.
Unlike usual `assert_eq!` tests, snapshot tests allow
to *automatically* upgrade expected values on test failure.
In a sense, snapshot tests are inline-version of our beloved
UI-tests.
Example:
A particular library we use, `expect_test` provides an `expect!`
macro, which creates a sort of self-updating string literal (by using
`file!` macro). Self-update is triggered by setting `UPDATE_EXPECT`
environmental variable (this info is printed during the test failure).
This library was extracted from rust-analyzer, where we use it for
most of our tests.
There are some other, more popular snapshot testing libraries:
* https://github.com/mitsuhiko/insta
* https://github.com/aaronabramov/k9
The main differences of `expect` are:
* first-class snapshot objects (so, tests can be written as functions,
rather than as macros)
* focus on inline-snapshots (but file snapshots are also supported)
* restricted feature set (only `assert_eq` and `assert_debug_eq`)
* no extra runtime (ie, no `cargo insta`)
See rust-analyzer/rust-analyzer#5101 for a
an extended comparison.
It is unclear if this testing style will stick with rustc in the long
run. At the moment, rustc is mainly tested via integrated UI tests.
But in the library-ified world, unit-tests will become somewhat more
important (that's why use use `rustc_lexer` library-ified library as
an example in this PR). Given that the cost of removal shouldn't be
too high, it probably makes sense to just see if this flies!
Call into fastfail on abort in libpanic_abort on Windows x86(_64)
This partially resolves#73215 though this is only for x86 targets. This code is directly lifted from [libstd](13290e83a6/library/std/src/sys/windows/mod.rs (L315)). `__fastfail` is the preferred way to abort a process on Windows as it will hook into debugger toolchains.
Other platforms expose a `_rust_abort` symbol which wraps `std::sys::abort_internal`. This would also work on Windows, but is a slightly largely change as we'd need to make sure that the symbol is properly exposed to the linker. I'm inlining the call to the `__fastfail`, but the indirection through `rust_abort` might be a cleaner approach.
A different instruction must be used on ARM architectures. I'd like to verify this works first before tackling ARM.
