Pietro Albini [Fri, 28 Aug 2020 08:23:53 +0000 (10:23 +0200)]
Rollup merge of #75330 - Nemo157:improve-doc-cfg-features, r=GuillaumeGomez
Improve rendering of crate features via doc(cfg)
The current rendering of crate features with `doc(cfg(feature = ".."))` is verbose and unwieldy for users, `doc(cfg(target_feature = ".."))` is special-cased to make it render nicely, and a similar rendering can be applied to `doc(cfg(feature))` to make it easier for users to read.
I also added special casing of `all`/`any` cfgs consisting of just `feature`/`target-feature` to remove the repetitive "target/crate feature" prefix.
The downside of this current rendering is that there is no distinction between `feature` and `target_feature` in the shorthand display. IMO this is ok, or if anything `target_feature` should have a more verbose shorthand, because `doc(cfg(feature = ".."))` usage is going to vastly outstrip `doc(cfg(target_feature = ".."))` usage in non-stdlib crates when it eventually stabilizes (or even before that given the number of crates using `cfg_attr(docsrs)` like constructs).
bors [Fri, 28 Aug 2020 01:20:17 +0000 (01:20 +0000)]
Auto merge of #70212 - Amanieu:catch_foreign, r=Mark-Simulacrum
Abort when foreign exceptions are caught by catch_unwind
Prior to this PR, foreign exceptions were not caught by catch_unwind, and instead passed through invisibly. This represented a painful soundness hole in some libraries ([take_mut](https://github.com/Sgeo/take_mut/blob/master/src/lib.rs#L37)), which relied on `catch_unwind` to handle all possible exit paths from a closure.
With this PR, foreign exceptions are now caught by `catch_unwind` and will trigger an abort since catching foreign exceptions is currently UB according to the latest proposals by the FFI unwind project group.
bors [Thu, 27 Aug 2020 23:22:34 +0000 (23:22 +0000)]
Auto merge of #75995 - pietroalbini:ci-let-fallible-finish, r=Mark-Simulacrum
Disable cancel-outdated-builds for auto-fallible
`cancel-outdated-builds` doesn't need to be enabled on fallible jobs, and it's actually making it harder for us to see if https://github.com/rust-lang/rust/issues/71988 is fixed. This adds some temporary code to avoid `auto-fallible` jobs from being cancelled by our tooling.
bors [Thu, 27 Aug 2020 21:30:32 +0000 (21:30 +0000)]
Auto merge of #75976 - GuillaumeGomez:help-popup, r=jyn514
Improve help popup
Fixes #75623.
The second commit is just a slight improvement: the help popup won't be created until someone presses "?" or ESC. Not a big improvement in itself but considering the low amount of code required, I think it was worth the shot.
bors [Thu, 27 Aug 2020 17:48:23 +0000 (17:48 +0000)]
Auto merge of #75933 - Aaron1011:feature/closure-move-err, r=oli-obk
Point to a move-related span when pointing to closure upvars
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.
bors [Thu, 27 Aug 2020 15:48:56 +0000 (15:48 +0000)]
Auto merge of #74941 - dylanmckay:replace-broken-avr-unknown-unknown-target, r=oli-obk
[AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target
The `avr-unknown-unknown` target has never worked correctly, always trying to invoke
the host linker and failing. It aimed to be a mirror of AVR-GCC's
default handling of the `avr-unknown-unknown' triple (assume bare
minimum chip features, silently skip linking runtime libraries, etc).
This behaviour is broken-by-default as it will cause a miscompiled executable
when flashed.
This patch improves the AVR builtin target specifications to instead
expose only a 'avr-unknown-gnu-atmega328' target. This target system is
`gnu`, as it uses the AVR-GCC frontend along with avr-binutils. The
target triple ABI is 'atmega328'.
In the future, it should be possible to replace the dependency on
AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support.
Perhaps at that point it would make sense to add an
'avr-unknown-unknown-atmega328' target as a better default when
implemented.
There is no current intention to add in-tree AVR target specifications for other
AVR microcontrollers - this one can serve as a reference implementation
for other devices via `rustc --print target-spec-json
avr-unknown-gnu-atmega328p`.
There should be no users of the existing 'avr-unknown-unknown' Rust
target as a custom target specification JSON has always been
recommended, and the avr-unknown-unknown target could never pass the
linking step anyway.
bors [Thu, 27 Aug 2020 07:26:32 +0000 (07:26 +0000)]
Auto merge of #72784 - csmoe:issue-61076, r=estebank
Await on mismatched future types
Closes #61076
This PR suggests to `await` on:
1. `async_fn().bar() => async_fn().await.bar()`
2. `async_fn().field => async_fn().await.field`
3. ` if let x = async() {} => if let x = async().await {}`
bors [Thu, 27 Aug 2020 00:25:52 +0000 (00:25 +0000)]
Auto merge of #75966 - Dylan-DPC:rollup-srfpces, r=Dylan-DPC
Rollup of 10 pull requests
Successful merges:
- #74730 (Hexagon libstd: update type defs)
- #75758 (Fixes for VxWorks)
- #75780 (Unconfuse Unpin docs a bit)
- #75806 (Prevent automatic page change when using history)
- #75818 (Update docs for SystemTime Windows implementation)
- #75837 (Fix font color for help button in ayu and dark themes)
- #75870 (Unify theme choices border color in ayu theme)
- #75875 (Shorten liballoc vec resize intra-doc link)
- #75953 (Fix swapped stability attributes for rustdoc lints)
- #75958 (Avoid function-scoping global variables)
Dylan DPC [Wed, 26 Aug 2020 23:14:20 +0000 (01:14 +0200)]
Rollup merge of #75958 - Mark-Simulacrum:fix-toolstate, r=kennytm
Avoid function-scoping global variables
In 2e6f2e885506ee4, we added a main function to the publish_toolstate.py script.
Unfortunately, we missed that the Python program implicitly declares global
variables in that code, which means that adding a function changes variable
scoping and breaks other code.
This commit avoids introducing that function and adds a warning to future
editors of the code.
Dylan DPC [Wed, 26 Aug 2020 23:14:18 +0000 (01:14 +0200)]
Rollup merge of #75953 - jyn514:missing-lints, r=Manishearth
Fix swapped stability attributes for rustdoc lints
This fixes a regression introduced in https://github.com/rust-lang/rust/pull/74855. Previously, `missing_doc_code_examples` would be run on stable and `private_doc_tests` would only be run on nightly. Now, it correctly does the reverse.
Closes https://github.com/rust-lang/rust/issues/75951.
r? @ehuss
For the ayu theme, the change is very "light", the font color was already close to white, so I unified the color with the pictures of the other buttons:
Dylan DPC [Wed, 26 Aug 2020 23:14:06 +0000 (01:14 +0200)]
Rollup merge of #75780 - matklad:unconfuseunpindocs, r=KodrAus
Unconfuse Unpin docs a bit
* Don't say that Unpin is used to prevent moves, because it is used
to *allow* moves
* Be more precise about kindedness of things, it is
`Pin<Pointer<Data>>`, rather than just `Pin<Pointer>`.
Mark Rousskov [Wed, 26 Aug 2020 21:22:13 +0000 (17:22 -0400)]
Avoid function-scoping global variables
In 2e6f2e885506ee4, we added a main function to the publish_toolstate.py script.
Unfortunately, we missed that the Python program implicitly declares global
variables in that code, which means that adding a function changes variable
scoping and breaks other code.
This commit avoids introducing that function and adds a warning to future
editors of the code.
bors [Wed, 26 Aug 2020 18:40:51 +0000 (18:40 +0000)]
Auto merge of #75912 - scottmcm:manuallydrop-vs-forget, r=Mark-Simulacrum
Suggest `mem::forget` if `mem::ManuallyDrop::new` isn't used
I think this communicates the intent more idiomatically, and is shorter anyway.
Inspired because [it came up on URLO](https://users.rust-lang.org/t/validity-of-memory-area-after-std-forget/47730/7?u=scottmcm), and it turns out that std had done it too in one spot:
bors [Wed, 26 Aug 2020 16:38:58 +0000 (16:38 +0000)]
Auto merge of #75903 - jyn514:lint-refactor, r=GuillaumeGomez
Warn about unknown or renamed lints in rustdoc
Fixes https://github.com/rust-lang/rust/issues/75884.
This is best reviewed one commit at a time.
r? @GuillaumeGomez
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:
(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.
bors [Wed, 26 Aug 2020 10:44:28 +0000 (10:44 +0000)]
Auto merge of #75687 - TimDiekmann:realloc-align, r=Amanieu
Allow reallocation to different alignment in `AllocRef`
The allocator-wg [has decided](https://github.com/rust-lang/wg-allocators/issues/5#issuecomment-672591112) to support reallocating to a different alignment in `AllocRef`. For more details please see the linked issue.
Aaron Hill [Wed, 26 Aug 2020 03:58:58 +0000 (23:58 -0400)]
Point to a move-related span when pointing to closure upvars
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.
bors [Wed, 26 Aug 2020 01:40:26 +0000 (01:40 +0000)]
Auto merge of #75811 - ecstatic-morse:better-dlerror, r=nagisa
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.
bors [Tue, 25 Aug 2020 20:54:59 +0000 (20:54 +0000)]
Auto merge of #75302 - Aaron1011:feature/partial-move-diag, r=estebank
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.
bors [Tue, 25 Aug 2020 18:52:11 +0000 (18:52 +0000)]
Auto merge of #74275 - wesleywiser:break_up_partitioning_rs, r=pnkfelix
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.
Joshua Nelson [Tue, 25 Aug 2020 14:02:16 +0000 (10:02 -0400)]
Warn about unknown or renamed lints
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:
(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.
bors [Tue, 25 Aug 2020 09:36:23 +0000 (09:36 +0000)]
Auto merge of #75773 - matklad:snapshot-tests, r=Mark-Simulacrum
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.
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:
* 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!
bors [Tue, 25 Aug 2020 07:36:52 +0000 (07:36 +0000)]
Auto merge of #75364 - rylev:libpanic-abort-failfast, r=alexcrichton
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](https://github.com/rust-lang/rust/blob/13290e83a6e20f3b408d177a9d64d8cf98fe4615/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.
bors [Tue, 25 Aug 2020 05:24:30 +0000 (05:24 +0000)]
Auto merge of #75132 - scottmcm:stabilize-range-is-empty, r=dtolnay
Stabilize Range[Inclusive]::is_empty
I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhausted isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with the stable `contains` method, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based `is_empty` plans, as these inherent ones are preferred in name resolution
bors [Tue, 25 Aug 2020 03:33:10 +0000 (03:33 +0000)]
Auto merge of #75764 - workingjubilee:tidy-up-cargo-metadata, r=Mark-Simulacrum
bump tidy to cargo_metadata 0.11
Updates cargo_metadata in tidy's Cargo.toml from 0.9.1 to 0.11
Real version change 0.9.11 -> 0.11.1
https://github.com/oli-obk/cargo_metadata/compare/v0.9.1...v0.11.1
bors [Tue, 25 Aug 2020 01:06:16 +0000 (01:06 +0000)]
Auto merge of #75666 - davidtwco:tidy-lang-items, r=varkor
hir: consistent use and naming of lang items
This PR adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or "LangItem". In addition, lang item variants are no longer exported from the `lang_items` module.
This is certainly subjective and while I think this is an improvement, if many in the team don't then we can just close this.
Scott McMurray [Tue, 4 Aug 2020 06:18:34 +0000 (23:18 -0700)]
Stabilize Range[Inclusive]::is_empty
I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhaused isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with now-stable `contains`, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based is_empty plans, as the inherent ones are preferred in name resolution
Aleksey Kladov [Fri, 21 Aug 2020 12:03:50 +0000 (14:03 +0200)]
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.
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:
* 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 https://github.com/rust-analyzer/rust-analyzer/pull/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!
The goal is to help me debug regressions like https://github.com/rust-lang/rust/pull/74518#issuecomment-661498214 (currently I have _no_ idea what could have gone wrong).
Aleksey Kladov [Fri, 21 Aug 2020 17:48:29 +0000 (19:48 +0200)]
Unconfuse Unpin docs a bit
* Don't say that Unpin is used to prevent moves, because it is used
to *allow* moves
* Be more precise about kindedness of things, it is
`Pin<Pointer<Data>>`, rather than just `Pin<Pointer>`.
David Wood [Tue, 18 Aug 2020 10:47:27 +0000 (11:47 +0100)]
hir: consistent use and naming of lang items
This commit adjusts the naming of various lang items so that they are
consistent and don't include prefixes containing the target or
"LangItem". In addition, lang item variants are no longer exported from
the `lang_items` module.
- Add a new `prim@` disambiguator, since both modules and primitives are in the same namespace
- Refactor `report_ambiguity` into a closure
Additionally, I noticed that rustdoc would previously allow `[struct@char]` if `char` resolved to a primitive (not if it had a DefId). I fixed that and added a test case.
I also need to update libstd to use `prim@char` instead of `type@char`. If possible I would also like to refactor `ambiguity_error` to use `Disambiguator` instead of its own hand-rolled match - that ran into issues with `prim@` (I updated one and not the other) and it would be better for them to be in sync.
[AVR] Merge the 'freestanding' base target spec into AVR base target spec
The 'freestanding' module was only ever used for AVR. It was an
unnecessary layer of abstraction. This commit merges the
'freestanding_base' module into 'avr_gnu_base'.
[AVR] Remove unnecessary arguments passed to the linker for GNU target
In general, linking with libc is not required, only libgcc is needed.
As suggested in the code review, a better option for libc support is by
building it into rust-lang/libc directly.
This also removes the '-Os' argument to the linker, which is a NOP.
[AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target
The `avr-unknown-unknown` target has never worked correctly, always trying to invoke
the host linker and failing. It aimed to be a mirror of AVR-GCC's
default handling of the `avr-unknown-unknown' triple (assume bare
minimum chip features, silently skip linking runtime libraries, etc).
This behaviour is broken-by-default as it will cause a miscompiled executable
when flashed.
This patch improves the AVR builtin target specifications to instead
expose only a 'avr-unknown-gnu-atmega328' target. This target system is
`gnu`, as it uses the AVR-GCC frontend along with avr-binutils. The
target triple ABI is 'atmega328'.
In the future, it should be possible to replace the dependency on
AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support.
Perhaps at that point it would make sense to add an
'avr-unknown-unknown-atmega328' target as a better default when
implemented.
There is no current intention to add in-tree AVR target specifications for other
AVR microcontrollers - this one can serve as a reference implementation
for other devices via `rustc --print target-spec-json
avr-unknown-gnu-atmega328p`.
There should be no users of the existing 'avr-unknown-unknown' Rust
target as a custom target specification JSON has always been
recommended, and the avr-unknown-unknown target could never pass the
linking step anyway.
bors [Mon, 24 Aug 2020 04:10:54 +0000 (04:10 +0000)]
Auto merge of #75865 - JohnTitor:rollup-yxia6d2, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #75819 (Use intra-doc-links in `core::{char, macros, fmt}`)
- #75821 (Switch to intra-doc links in `std::macros`)
- #75825 (Fix typo in documentation of i32 wrapping_abs())
- #75826 (Corrected Misleading documentation for derived Ord/PartialOrd implementation )
- #75831 (doc: Prefer https link for wikipedia URLs)
- #75844 (publish-toolstate: show more context on HTTP error)
- #75847 (Switch to intra-doc links in `std::collections`)
- #75851 (Switch to intra-doc links in `core::array`)
- #75856 (more tool clippy fixes)
- #75859 (doc: Fix typo in std::process::Child documentation)
projects / rust.git / log