Rollup merge of #63867 - petrochenkov:dhelpers, r=matthewjasper
resolve: Block expansion of a derive container until all its derives are resolved
So, it turns out there's one more reason to block expansion of a `#[derive]` container until all the derives inside it are resolved, beside `Copy` (https://github.com/rust-lang/rust/pull/63248).
The set of derive helper attributes registered by derives in the container also has to be known before the derives themselves are expanded, otherwise it may be too late (see https://github.com/rust-lang/rust/pull/63468#issuecomment-524550872 and the `#[stable_hasher]`-related test failures in https://github.com/rust-lang/rust/pull/63468).
So, we stop our attempts to unblock the container earlier, as soon as the `Copy` status is known, and just block until all its derives are resolved.
After all the derives are resolved we immediately go and process their helper attributes in the item, without delaying it until expansion of the individual derives.
Unblocks https://github.com/rust-lang/rust/pull/63468
r? @matthewjasper (as a reviewer of https://github.com/rust-lang/rust/pull/63248)
cc @c410-f3r
bors [Thu, 29 Aug 2019 05:05:17 +0000 (05:05 +0000)]
Auto merge of #63990 - Centril:rollup-q1nt0b0, r=Centril
Rollup of 11 pull requests
Successful merges:
- #63811 (Correctly suggest adding bounds to `impl Trait` argument)
- #63933 (Resolve some small issues related to #63580)
- #63938 (or-pattern: fix typo in error message)
- #63945 (Recover `mut $pat` and other improvements)
- #63958 (const_prop: only call error_to_const_error if we are actually showing something)
- #63961 (Add Option<Span> to `require_lang_item`)
- #63963 (remove the reference to __cxa_thread_atexit_impl)
- #63965 (Prevent syntax error in LD linker version script)
- #63968 (rustc_apfloat: make the crate #![no_std] explicitly.)
- #63970 (Notify me (flip1995) when Clippy toolstate changes)
- #63980 (add missing `#[repr(C)]` on the Slices union)
Failed merges:
- #63989 (Add Yaah to clippy toolstain notification list)
Rollup merge of #63980 - DutchGhost:master, r=cramertj
add missing `#[repr(C)]` on the Slices union
Adds the `#[repr(C)]` attribute to the `Slices` union used to convert an `&str` into a `&[u8]`.
Without the attribute, the union has an unspecified layout: https://doc.rust-lang.org/reference/types/union.html, so performing the 'transmute' is unsound without the attribute (as far as I understand).
The `Repr` union, used for converting a raw ptr + len to a slice has this attribute as well:
https://github.com/rust-lang/rust/blob/master/src/libcore/ptr/mod.rs#L211-#L216
Rollup merge of #63970 - flip1995:notify_clippy, r=oli-obk
Notify me (flip1995) when Clippy toolstate changes
I want in on the fun :tada:
Also friendly ping @llogiq @mcarton: Since you two aren't _that_ active on the Clippy repo anymore, do you still want to get pinged on Clippy toolstate changes?
Rollup merge of #63965 - loganwendholt:linker-script-fix, r=michaelwoerister
Prevent syntax error in LD linker version script
As discussed in #63925, there is an edge case in which an invalid LD version script is generated when building a `cdylib` with no exported symbols. This PR makes a slight modification to the LD version script generation by first checking to see if any symbols need to be exported. If not, the `global` section of the linker script is simply omitted, and the syntax error is averted.
Rollup merge of #63945 - Centril:recover-mut-pat, r=estebank
Recover `mut $pat` and other improvements
- Recover on e.g. `mut Foo(x, y)` and suggest `Foo(mut x, mut y)`. Fixes https://github.com/rust-lang/rust/issues/63764.
- Recover on e.g. `let mut mut x;`
- Recover on e.g. `let keyword` and `let keyword(...)`.
- Cleanups in `token.rs` with `fn is_non_raw_ident_where` and friends.
This commit removes the special rustdoc handling for proc macros, as we can now
retrieve their span and attributes just like any other item.
A new command-line option is added to rustdoc: `--crate-type`. This takes the same options as rustc's `--crate-type` option. However, all values other than `proc-macro` are treated the same. This allows Rustdoc to enable 'proc macro mode' when handling a proc macro crate.
In compiletest, a new 'rustdoc-flags' option is added. This allows us to
pass in the '--proc-macro-crate' flag in the absence of Cargo.
I've opened [an additional PR to Cargo](https://github.com/rust-lang/cargo/pull/7159) to support passing in this flag.
These two PRS can be merged in any order - the Cargo changes will not
take effect until the 'cargo' submodule is updated in this repository.
bors [Wed, 28 Aug 2019 21:42:52 +0000 (21:42 +0000)]
Auto merge of #62941 - GuillaumeGomez:save-crate-filter, r=Mark-Simulacrum
Save crate filtering on rustdoc
Fixes #62929.
I added a hashmap and a hash encoding for the current crate list in case you have multiple crates handling on a same website (who talked about docs.rs?!). Like that, for each context, you have the filter crate selected.
bors [Wed, 28 Aug 2019 17:49:37 +0000 (17:49 +0000)]
Auto merge of #63875 - philipc:issue-57822, r=michaelwoerister
debuginfo: give unique names to closure and generator types
Closure types have been moved to the namespace where they
are defined, and both closure and generator type names now
include the disambiguator.
This fixes an exception when lldb prints nested closures.
Fixes #57822
I haven't included the `DW_AT_artificial` changes discussed in #57822 because they make the output worse IMO, but I can easily add these if still required. For example, for the new test case the output is now:
```
(lldb) p g
(issue_57822::main::closure-1) $1 = closure-1(closure(1))
```
but adding `DW_AT_artificial` changes this to:
```
(lldb) p g
(issue_57822::main::closure-1) $0 = closure-1 {
}
```
Note that nested generators didn't cause the exception. I haven't determined why, but I think it makes sense to add the disambiguator for them too. It feels like we still don't really understand why closures were causing an error though.
bors [Tue, 27 Aug 2019 23:57:05 +0000 (23:57 +0000)]
Auto merge of #63960 - ehuss:update-cargo, r=alexcrichton
Update cargo
Update cargo
10 commits in 3f700ec43ce72305eb5315cfc710681f3469d4b4..22f7dd0495cd72ce2082d318d5a9b4dccb9c5b8c
2019-08-19 22:43:12 +0000 to 2019-08-27 16:10:51 +0000
- Update and improve zsh completion (rust-lang/cargo#7296)
- Document that `package` can be used in `[patch]` (rust-lang/cargo#7263)
- Fix `error:`/`warning:` coloring inconsistency with rustc (rust-lang/cargo#7294)
- Tests: Import rustc_plugin from its new location (rust-lang/cargo#7287)
- Update README azure badge. (rust-lang/cargo#7293)
- Update home dependencies to v0.5 (rust-lang/cargo#7277)
- Fix typo (rust-lang/cargo#7279)
- Update libgit2 dependencies (rust-lang/cargo#7275)
- Fix old lockfile encoding wrt newlines (rust-lang/cargo#7262)
- Fix dSYM uplifting when symlink is broken (rust-lang/cargo#7268)
bors [Tue, 27 Aug 2019 06:18:24 +0000 (06:18 +0000)]
Auto merge of #63940 - Centril:rollup-47qe9gn, r=Centril
Rollup of 4 pull requests
Successful merges:
- #62600 (libtest: add --show-output flag to print stdout of successful tests)
- #63698 (Fixed floating point issue with asinh function)
- #63761 (Propagate spans and attributes from proc macro definitions)
- #63917 (Error when generator trait is not found)
Rollup merge of #63761 - petrochenkov:procattrs, r=eddyb
Propagate spans and attributes from proc macro definitions
Thanks to https://github.com/rust-lang/rust/pull/63269 we now have spans and attributes from proc macro definitions available in metadata.
However, that PR didn't actually put them into use! This PR finishes that work.
Attributes `rustc_macro_transparency`, `allow_internal_unstable`, `allow_internal_unsafe`, `local_inner_macros`, `rustc_builtin_macro`, `stable`, `unstable`, `rustc_deprecated`, `deprecated` now have effect when applied to proc macro definition functions.
From those attributes only `deprecated` is both stable and supposed to be used in new code.
(`#![staged_api]` still cannot be used in proc macro crates for unrelated reasons though.)
`Span::def_site` from the proc macro API now returns the correct location of the proc macro definition.
Also, I made a mistake in https://github.com/rust-lang/rust/pull/63269#discussion_r312702919, loaded proc macros didn't actually use the resolver cache.
This PR fixes the caching issue, now proc macros go through the `Resolver::macro_map` cache as well.
(Also, the first commit turns `proc_macro::quote` into a regular built-in macro to reduce the number of places where `SyntaxExtension`s need to be manually created.)
Rollup merge of #63698 - Phosphorus15:master, r=nagisa
Fixed floating point issue with asinh function
This should fixes #63271 , in which `asinh(-0.0)` returns `0.0` instead of `-0.0`.
according to @nagisa
>
>
> IEEE-754 (2008), section 9.2.1:
>
> > For the functions expm1, exp2m1, exp10m1, logp1, log2p1, log10p1, sin, tan, sinPi, atanPi, asin, atan, sinh, tanh, asinh, and atanh, f(+0) is +0 and f(−0) is −0 with no exception.
>
> and
>
> > sinh(±∞) and asinh(±∞) are ±∞ with no exception.
After ensuring that the function `asinh` is the only function affected (functions like `sin`, `sinh` are all based on `cmath` library or `llvm` intrinsics), and that `atanh` always gives the correct result. The only function to modify is `asinh`.
Rollup merge of #62600 - emmericp:libtest-add-show-output, r=gnzlbg
libtest: add --show-output flag to print stdout of successful tests
This pull request adds a new flag `--show-output` for tests to show the output of successful tests. For most formatters this was already supported just not exposed via the CLI (apparently only used by `librustdoc`). I've also added support for this option in the JSON formatter.
This kind of fixes https://github.com/rust-lang/rust/issues/54669 which wants `--format json` to work with `--nocapture`, which is... well, impossible. What this issue really calls for is `--show-output` as implemented here.
Mark Rousskov [Mon, 12 Aug 2019 18:36:09 +0000 (14:36 -0400)]
Transition a few fmt::Display impls to functions
This introduces a WithFormatter abstraction that permits one-time
fmt::Display on an arbitrary closure, created via `display_fn`. This
allows us to prevent allocation while still using functions instead of
structs, which are a bit unwieldy to thread arguments through as they
can't easily call each other (and are generally a bit opaque).
The eventual goal here is likely to move us off of the formatting
infrastructure entirely in favor of something more structured, but this
is a good step to move us in that direction as it makes, for example,
passing a context describing current state to the formatting impl much
easier.
bors [Tue, 27 Aug 2019 00:07:38 +0000 (00:07 +0000)]
Auto merge of #63926 - Centril:rollup-6kckn9n, r=Centril
Rollup of 6 pull requests
Successful merges:
- #63317 (Do not complain about unused code when used in `impl` `Self` type)
- #63693 (Fully implement or-pattern parsing)
- #63836 (VxWorks does not provide a way to set the task name except at creation time)
- #63845 (Removed a confusing FnOnce example)
- #63855 (Refactor feature gates)
- #63921 (add link to FileCheck docs)
Mark Rousskov [Mon, 12 Aug 2019 11:10:55 +0000 (07:10 -0400)]
Move top-level Clean impl to function
This allows us to pass it a `&mut DocContext` which will allow removal
of RefCells, etc. in the following commits. It's also somewhat a unique
Clean impl in that it previously ignored `self` (re-retriveing
hir::Crate), which it no longer needs to do.
Rollup merge of #63855 - killercup:refactor/feature-gates, r=Centril
Refactor feature gates
After #63824, this goes a few steps further by
- parsing doc comments in the macros to extract descriptions for feature gates, and
- introducing a common `Feature` type to replace the tuples used previously to improve readability.
The descriptions are not yet used, but I felt like this PR is a useful enough refactoring on its own.
Rollup merge of #63693 - Centril:polish-parse-or-pats, r=estebank
Fully implement or-pattern parsing
Builds upon the initial parsing in https://github.com/rust-lang/rust/pull/61708 to fully implement or-pattern (`p | q`) parsing as specified in [the grammar section of RFC 2535](https://github.com/rust-lang/rfcs/blob/master/text/2535-or-patterns.md#grammar).
Noteworthy:
- We allow or-patterns in `[p | q, ...]`.
- We allow or-patterns in `let` statements and `for` expressions including with leading `|`.
- We improve recovery for `p || q` (+ tests for that in `multiple-pattern-typo.rs`).
- We improve recovery for `| p | q` in inner patterns (tests in `or-patterns-syntactic-fail.rs`).
- We rigorously test or-pattern parsing (in `or-patterns-syntactic-{pass,fail}.rs`).
- We harden the feature gating tests.
- We do **_not_** change `ast.rs`. That is, `ExprKind::Let.0` and `Arm.pats` still accept `Vec<P<Pat>>`.
I was starting work on that but it would be cleaner to do this in a separate PR so this one has a narrower scope.
cc @dlrobertson
cc the tracking issue https://github.com/rust-lang/rust/issues/54883.
resolve: Block expansion of a derive container until all its derives are resolved
Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.
bors [Mon, 26 Aug 2019 17:33:50 +0000 (17:33 +0000)]
Auto merge of #63901 - estebank:unknown-receiver-type, r=zackmdavis
Point at method call on missing annotation error
Make it clearer where the type name that couldn't be inferred comes from.
Before:
```
error[E0282]: type annotations needed
--> src/test/ui/span/type-annotations-needed-expr.rs:2:13
|
2 | let _ = (vec![1,2,3]).into_iter().sum() as f64; //~ ERROR E0282
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for `S`
|
= note: type must be known at this point
```
after
```
error[E0282]: type annotations needed
--> src/test/ui/span/type-annotations-needed-expr.rs:2:39
|
2 | let _ = (vec![1,2,3]).into_iter().sum() as f64; //~ ERROR E0282
| ^^^ cannot infer type for `S`
|
= note: type must be known at this point
```
bors [Mon, 26 Aug 2019 04:10:54 +0000 (04:10 +0000)]
Auto merge of #62891 - vext01:improve-black-box-docs, r=RalfJung,Centril,gnzlbg
Improve the documentation for std::hint::black_box.
The other day a colleague was reviewing some of my code which was using `black_box` to block constant propogation. There was a little confusion because the documentation kind of implies that `black_box` is only useful for dead code elimination, and only in benchmarking scenarios.
The docs currently say:
> A function that is opaque to the optimizer, to allow benchmarks to pretend to use outputs to assist in avoiding dead-code elimination.
Here is our discussion, in which I show (using godbolt) that a black box can also block constant propagation:
https://github.com/softdevteam/yk/pull/21#discussion_r302985038
This change makes the docstring for `black_box` a little more general, and while we are here, I've added an example (the same one from our discussion).
bors [Mon, 26 Aug 2019 00:27:17 +0000 (00:27 +0000)]
Auto merge of #62603 - cuviper:no-unwind-abort, r=joshtriplett
Permit unwinding through FFI by default
This repeats #62505 for master (Rust 1.38+), as #58794 is not yet resolved. This is a stopgap until a stable alternative is available, like [RFC 2699](https://github.com/rust-lang/rfcs/pull/2699), as long as progress is being made to that end.
bors [Sun, 25 Aug 2019 19:20:20 +0000 (19:20 +0000)]
Auto merge of #61613 - sinkuu:impl_trait_inline, r=ollie27
Support `impl Trait` in inlined documentation
`impl Trait` in argument position was not properly rendered when inlined from other crates. ([a live example on docs.rs](https://docs.rs/libp2p/0.8.1/libp2p/floodsub/struct.Floodsub.html#method.unsubscribe))
projects / rust.git / log