bors [Sun, 23 Aug 2020 14:50:15 +0000 (14:50 +0000)]
Auto merge of #74238 - RalfJung:offset_from, r=oli-obk
stabilize ptr_offset_from
This stabilizes ptr::offset_from, and closes https://github.com/rust-lang/rust/issues/41079. It also removes the deprecated `wrapping_offset_from`. This function was deprecated 19 days ago and was never stable; given an FCP of 10 days and some waiting time until FCP starts, that leaves at least a month between deprecation and removal which I think is fine for a nightly-only API.
Regarding the open questions in https://github.com/rust-lang/rust/issues/41079:
* Should offset_from abort instead of panic on ZSTs? -- As far as I know, there is no precedent for such aborts. We could, however, declare this UB. Given that the size is always known statically and the check thus rather cheap, UB seems excessive.
* Should there be more methods like this with different restrictions (to allow nuw/nsw, perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)? -- No reason to block stabilization on that, we can always add such methods later.
Also nominating the lang team because this exposes an intrinsic.
The stabilized method is best described [by its doc-comment](https://github.com/RalfJung/rust/blob/56d4b2d69abb93e4f0ca79471deca7aaaaeca214/src/libcore/ptr/const_ptr.rs#L227). The documentation forgot to mention the requirement that both pointers must "have the same provenance", aka "be derived from pointers to the same allocation", which I am adding in this PR. This is a precondition that [Miri already implements](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a3b9d0a07a01321f5202cd99e9613480) and that, should LLVM ever obtain a `psub` operation to subtract pointers, will likely be required for that operation (following the semantics in [this paper](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf)).
bors [Sun, 23 Aug 2020 08:14:17 +0000 (08:14 +0000)]
Auto merge of #75465 - Aaron1011:feature/short-fn-def-span, r=estebank
Use smaller def span for functions
Currently, the def span of a function encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}
```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
bors [Sun, 23 Aug 2020 05:56:47 +0000 (05:56 +0000)]
Auto merge of #75813 - petrochenkov:feature/incr-def-path-table, r=Aaron1011
Lazy decoding of DefPathTable from crate metadata (non-incremental case)
The is the half of https://github.com/rust-lang/rust/pull/74967 that doesn't touch incremental-related structures.
We are still decoding def path hashes eagerly if we are in incremental mode.
The incremental part of https://github.com/rust-lang/rust/pull/74967 feels hacky, but I'm not qualified enough to suggest improvements. I'll reassign it so someone else once this PR lands.
@Aaron1011, I wasn't asking you to do this split because I wasn't sure that it's feasible (or simple to do).
bors [Sun, 23 Aug 2020 01:44:36 +0000 (01:44 +0000)]
Auto merge of #73084 - Aaron1011:feature/new-recursive-expand, r=petrochenkov
Re-land PR #72388: Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`
PR #72388 allowed us to preserve the original `TokenStream` in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See #72545 and #72622). These regressions fell into two categories
1. Missing handling for `Group`s with `Delimiter::None`, which are inserted during `macro_rules!` expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to `syn` and `proc-macro-hack`, but several crates needed changes to their own proc-macro code.
2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. [a compiliation error](https://github.com/paritytech/parity-scale-codec/pull/210) caused by misusing `quote_spanned!`). However, two crates had intentionally written unhygenic `macro_rules!` macros, which were able to access identifiers that were not passed as arguments (see https://github.com/rust-lang/rust/issues/72622#issuecomment-636402573).
All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at https://github.com/sammhicks/face-generator/pull/1) is not on `crates.io`, and is a Yew application that seems unlikely to have any reverse dependencies.
As @petrochenkov mentioned in https://github.com/rust-lang/rust/issues/72545#issuecomment-638632434, not re-landing PR #72388 allows more crates to write unhygenic `macro_rules!` macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic `macro_rules!` macros in the time it takes that PR to be merged.
Aaron Hill [Wed, 12 Aug 2020 21:02:14 +0000 (17:02 -0400)]
Use smaller def span for functions
Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
additional context for the recursive call.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
This is a re-attempt of PR #72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Josh Stone [Tue, 18 Aug 2020 22:11:02 +0000 (15:11 -0700)]
Match scalar-pair-bool more flexibly for LLVM 11
LLVM 11 started using `phi` and `select` for `fn pair_i32_bool`, which
is still valid, but harder to match than the simple instructions we were
getting before. We'll just check that the unpacked args are directly
referenced in any way, and call it good.
as suggested in https://github.com/rust-lang/rust/issues/63291#issuecomment-605511675 .
Also optimize `{Rc, Arc}::new_zeroed` to use `alloc_zeroed`, otherwise they are no more efficient than using `new_uninit` and zeroing the memory manually (which was the original implementation).
* [`handle_alloc_error`]: Link from `core` to `alloc` could not be resolved.
* [`slice`]: slice is a primitive type, but could not be resolved; had to use [`crate::slice`] instead.
bors [Sat, 22 Aug 2020 11:07:03 +0000 (11:07 +0000)]
Auto merge of #75795 - matthiaskrgr:cargotest_clippy, r=Dylan-DPC
cargotest: fix clippy warnings
Fixes clippy::redundant_static_lifetimes and clippy::toplevel_ref_arg
I also replaced some .expect("") calls with .unwrap()s since there was no message passed by the .expect() anyway.
bors [Sat, 22 Aug 2020 04:39:15 +0000 (04:39 +0000)]
Auto merge of #75772 - tmiasko:io-maybe-no, r=dtolnay
Remove unused `Maybe` wrapper around raw standard streams
* Remove result type from raw standard streams constructors
* Make raw standard stream constructors const
* Remove wrapper type handling absent raw standard streams
Dylan DPC [Sat, 22 Aug 2020 00:14:41 +0000 (02:14 +0200)]
Rollup merge of #75711 - CohenArthur:split-up-astconv, r=oli-obk
Split `astconv.rs` into its own submodule
Fixes #67418
This changed induced a few changes across the Type checker, but only there. Mostly, it was just renaming `Self::` into something else to call specific methods from a subtrait instead of having a 2500+ lines one.
I split up the `astconv.rs` file into its own module. This way, directives such as
```rust
use crate::astconv::AstConv;
```
are still valid, and doing
```rust
use crate::astconv::{AstConv, AstConvGeneric};
```
is possible
(instead of having two modules, one named `astconv_generic.rs` for example and `astconv.rs`)
I'm not entirely sure that the name `AstConvGeneric` is a good one. However, only methods related to lifetimes or generics have been moved over to this module. Sorry about the large diff.
I'd be very happy to make any correction you deem necessary.
I provided a separate commit that replaced links with anchors by intra-doc links.
Here the anchor location information gets lost, so its questionable whether to
actually replace those links.
Matthias Krüger [Fri, 21 Aug 2020 23:49:36 +0000 (01:49 +0200)]
cargotest: fix clippy warnings
Fixes clippy::redundant_static_lifetimes and clippy::toplevel_ref_arg
I also replaced some .expect("") calls with .unwrap()s since there was no message passed by the .expect() anyway.
bors [Fri, 21 Aug 2020 11:08:31 +0000 (11:08 +0000)]
Auto merge of #75697 - lzutao:mir-dumb-const-prefix, r=oli-obk
Suppress "const" prefix of FnDef constants in MIR dump
I [was asked][1] to suppress the `const` infront of `FnDef`.
I tried to suppress comments for other types, but turned out that `const ()` and `()` is different: https://github.com/rust-lang/rust/pull/75697#discussion_r473892806
CohenArthur [Wed, 19 Aug 2020 17:07:03 +0000 (19:07 +0200)]
astconv: Split astconv.rs into its own module with submodules
To separate the astconv.rs file, I split it into its own module with a
subtrait called GenericAstConv. This subtrait handles methods related to
generics, be it types or lifetimes.
typeck: Add bounds module and Bounds struct
bounds: Run fmt, add documentation
generic_astconv: Add subtrait GenericAstConv
Some methods of AstConv deal exclusively with Generics. Therefore, it
makes sense to have them in their own trait. Some other methods from
AstConv might be added to it later
generic_astconv: Add more methods from AstConv
Add check_generic_arg_count_for_call() and check_generic_arg_count()
astconv: Add module for clarity
generic: Rename GenericAstConv -> AstConvGeneric
generic: add more methods to AstConvGeneric
astconv: Remove AstConvGeneric trait, add impl dyn AstConv in other
module
astconv: Add errors module to handle AstConv complaints
fmt: format code in astconv/
astconv: Remove old file
astconv: Fix visibility on GenericArgPosition
astconv: Fix visibility on GenericArgPosition
astconv: Fix function visibility on other originally private functions
Yuki Okushi [Fri, 21 Aug 2020 08:55:10 +0000 (17:55 +0900)]
Rollup merge of #75532 - tmiasko:rfc-1014, r=nikomatsakis
Fix RFC-1014 test
Use two printlns when testing that writing to a closed stdout does not
panic. Otherwise the test is ineffective, since the current implementation
silently ignores the error during first println regardless.
Yuki Okushi [Fri, 21 Aug 2020 08:55:08 +0000 (17:55 +0900)]
Rollup merge of #75324 - ericseppanen:master, r=JohnTitor
clarify documentation of remove_dir errors
remove_dir will error if the path doesn't exist or isn't a directory.
It's useful to clarify that this is "remove dir or fail" not "remove dir
if it exists".
I don't think this belongs in the title. "Removes an existing, empty
directory" is strangely worded-- there's no such thing as a non-existing
directory. Better to just say explicitly it will return an error.
bors [Fri, 21 Aug 2020 06:05:39 +0000 (06:05 +0000)]
Auto merge of #75642 - matklad:lexer-comments, r=petrochenkov
Move doc comment parsing to rustc_lexer
Plain comments are trivia, while doc comments are not, so it feels
like this belongs to the rustc_lexer.
The specific reason to do this is the desire to use rustc_lexer in
rustdoc for syntax highlighting, without duplicating "is this a doc
comment?" logic there.
bors [Fri, 21 Aug 2020 02:16:35 +0000 (02:16 +0000)]
Auto merge of #74846 - Aaron1011:fix/pat-token-capture, r=petrochenkov
Capture tokens for Pat used in macro_rules! argument
This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.
bors [Thu, 20 Aug 2020 23:05:31 +0000 (23:05 +0000)]
Auto merge of #73565 - matthewjasper:core-min-spec, r=nagisa
Use min_specialization in libcore
Getting `TrustedRandomAccess` to work is the main interesting thing here.
- `get_unchecked` is now an unstable, hidden method on `Iterator`
- The contract for `TrustedRandomAccess` is made clearer in documentation
- Fixed a bug where `Debug` would create aliasing references when using the specialized zip impl
- Added tests for the side effects of `next_back` and `nth`.
bors [Thu, 20 Aug 2020 20:27:22 +0000 (20:27 +0000)]
Auto merge of #75494 - matthewjasper:defer-recursive-projection-error, r=nikomatsakis
Don't immediately error for cycles during normalization
#73452 meant some normalization cycles could be detected earlier, breaking some code.
This PR makes defers errors for normalization cycles to fulfillment, fixing said code.