Dylan DPC [Thu, 6 Feb 2020 21:38:34 +0000 (22:38 +0100)]
Rollup merge of #68791 - mark-i-m:proper-linkcheck, r=ehuss,JohnTitor
implement proper linkchecker hardening
r? @JohnTitor
This implements proper linkcheck filtering... we might need to fiddle with a bit to adjust what is or isn't filtered, but this seems to work reasonable locally.
Dylan DPC [Thu, 6 Feb 2020 21:38:33 +0000 (22:38 +0100)]
Rollup merge of #68524 - jonas-schievink:generator-resume-arguments, r=Zoxc
Generator Resume Arguments
cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974
Blockers:
* [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069)
* [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162)
* [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901)
* [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137)
Follow-up work:
* Change async/await desugaring to make use of this feature
* Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
Dylan DPC [Thu, 6 Feb 2020 21:38:31 +0000 (22:38 +0100)]
Rollup merge of #67359 - eddyb:macro-backtrace-all-the-same, r=petrochenkov
Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation.
This is my attempt at dealing with https://github.com/rust-lang/rust/pull/66364#issuecomment-565517232, although I'm not sure it's the least disruptive one.
The behavior of `-Zexternal-macro-backtrace` was already to enable full macro backtraces for *all* macros, the only part of it that was specific to cross-crate macros was showing this when *not used*:
```
note: this error originates in a macro outside of the current crate
(in Nightly builds, run with -Z external-macro-backtrace for more info)
```
After this PR:
* the flag is renamed to `-Zmacro-backtrace`
* do we need to have a deprecation period? cc @rust-lang/compiler
* the message informing you about the flag is always shown when an expansion of a bang macro/attribute/derive is involved, not just cross-crate ones
* this accounts for most of the changes in tests
* we could perhaps only show it for the bang macro case? feels odd for derives
* `fix_multispans_in_std_macros` is split into `fix_multispans_in_extern_macros` and `render_multispans_macro_backtrace`
* this roughly reverts the non-behavioral parts of #46605, which combined the two functionalities
* not sure where the old `std_macros` name came from, perhaps the `<std macros>` synthetic "file"? even then, odd that `std` specifically was mentioned
* `render_multispan_macro_backtrace`, by default (i.e. without `-Zmacro-backtrace`), hides the `in this macro invocation` label specifically to avoid redundancy in the diagnostic
* that is, showing the macro use site is only useful when the diagnostic is inside the macro definition and the user can't otherwise tell which use site it applies to, not when the diagnostic is at/inside the use site already (which would make the label redundant)
* before, it was only checking for the situation in which a cross-crate macro *definition* span would be replaced with the invocation span, which both made the connection to redundancy unobvious, and didn't help with other redundancy (e.g. when the diagnostic was pointing to an argument inside the macro invocation)
* this accounts for the remaining test changes, which I've first noticed in https://github.com/rust-lang/rust/pull/66364#discussion_r356135967 but only later understood as part of this PR (hence the "redundancy" descriptions)
This PR is not needed for #66364, but it would help, as after this PR there's only one `.span_to_filename(...).is_macros()` check (i.e. for `<... macros>` synthetic "files") left in `rustc_errors`, and it's much more self-contained.
Dylan DPC [Thu, 6 Feb 2020 14:37:47 +0000 (15:37 +0100)]
Rollup merge of #68845 - dwrensha:fix-68783, r=estebank
stop using BytePos for computing spans in librustc_parse/parser/mod.rs
Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like #68730 when non-ascii characters are given as input.
#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`.
This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters.
Dylan DPC [Thu, 6 Feb 2020 14:37:43 +0000 (15:37 +0100)]
Rollup merge of #68837 - jonas-schievink:assoc-item-lookup-2, r=estebank
Make associated item collection a query
Before this change, every time associated items were iterated over (which rustc does *a lot* – this can probably be further optimized), there would be N+1 queries to fetch all assoc. items. Now there's just one after they've been computed once.
Dylan DPC [Thu, 6 Feb 2020 14:37:41 +0000 (15:37 +0100)]
Rollup merge of #68788 - Centril:unified-fn-bodies, r=petrochenkov
Towards unified `fn` grammar
Part of https://github.com/rust-lang/rust/pull/68728.
- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.
- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.
- We move towards unifying the `fn` front matter; this is fully realized in https://github.com/rust-lang/rust/pull/68728.
bors [Thu, 6 Feb 2020 08:48:01 +0000 (08:48 +0000)]
Auto merge of #68664 - tspiteri:no_run-complete-build, r=nikomatsakis
rustdoc: attempt full build for compile_fail test
Some code fails when doing a full build but does not fail when only emitting metadata. This commit makes sure compile_fail tests for such code behave as expected, that is, the test succeeds because the compilation fails.
bors [Thu, 6 Feb 2020 05:19:52 +0000 (05:19 +0000)]
Auto merge of #68583 - estebank:hrlt, r=oli-obk
Account for HR lifetimes when suggesting introduction of named lifetime
```
error[E0106]: missing lifetime specifier
--> src/test/ui/suggestions/fn-missing-lifetime-in-item.rs:2:32
|
2 | struct S2<F: Fn(&i32, &i32) -> &i32>(F);
| ---- ---- ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from argument 1 or argument 2
= note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html
help: consider making the bound lifetime-generic with a new `'a` lifetime
|
2 | struct S2<F: for<'a> Fn(&'a i32, &'a i32) -> &'a i32>(F);
| ^^^^^^^ ^^^^^^^ ^^^^^^^ ^^^
help: consider introducing a named lifetime parameter
|
2 | struct S2<'a, F: Fn(&'a i32, &'a i32) -> &'a i32>(F);=
| ^^^ ^^^^^^^ ^^^^^^^ ^^^
```
Follow up to #68267. Addresses the diagnostics part of #49287.
bors [Wed, 5 Feb 2020 22:41:54 +0000 (22:41 +0000)]
Auto merge of #68461 - cjgillot:split_infer_prelude, r=matthewjasper
Move datatypes definitions in specific modules inside rustc::{traits, infer}
Prelude to #67953
Some data types inside `rustc::traits` and `rustc::infer` are used in other parts of `librustc`. These cannot go to a separate crate `librustc_infer`.
This PR moves those data types to `traits::types` and `infer::types` modules, from where everything is reexported.
Note for review: some imports feature the `crate -> rustc` substitution. This is cruft from the splitting out of #67953. This can be reverted, but are bound to be put back by #67953.
bors [Wed, 5 Feb 2020 19:11:04 +0000 (19:11 +0000)]
Auto merge of #67429 - mati865:mingw-ultimate-fix, r=alexcrichton
windows-gnu: prefer system crt libraries if they are available
The origin of the issue is the fact Rust ships mingw-w64 libraries but no headers and prefers own libraries over the system ones.
This leads to situation when headers aren't compatible with libraries (mingw-w64 doesn't provide any forward compatibility and AFAIK backwards compatibility is guaranteed only within major release series).
It's easier to understand how this PR works when looking at the linker invocation before and with this PR: https://www.diffchecker.com/GEuYFmzo
It adds system libraries path before Rust libraries so the linker will prefer them.
It has potential issue when system has files with the same names as Rust but that could be avoided by moving Rust shipped mingw-w64 libraries from `lib/rustlib/x86_64-pc-windows-gnu/lib` to say `lib/rustlib/x86_64-pc-windows-gnu/lib/mingw`. Then adding linker paths in this order: Rust libraries, system libraries, Rust shipped mingw-w64 libraries.
Dylan DPC [Wed, 5 Feb 2020 12:14:37 +0000 (13:14 +0100)]
Rollup merge of #68858 - ljedrz:collapse_stable_hash_foos, r=michaelwoerister
Merge item id stable hashing functions
Supersedes https://github.com/rust-lang/rust/pull/67999 splitting out the pure cleanup bits, i.e. merging `hash_item_id`, `hash_impl_item_id` and `hash_trait_item_id` into a common `hash_reference_to_item`.
Dylan DPC [Wed, 5 Feb 2020 12:14:28 +0000 (13:14 +0100)]
Rollup merge of #68809 - ecstatic-morse:const-int-functions, r=oli-obk
Make more arithmetic functions unstably const
This is a smaller version of #66884 (thanks @9999years) that constifies many of the arithmetic functions on integer primitives from #53718 that were blocked on #49146.
bors [Tue, 4 Feb 2020 23:56:49 +0000 (23:56 +0000)]
Auto merge of #68544 - Aaron1011:remove-overlapping-traits, r=estebank
Remove the `overlapping_marker_traits` feature
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
Dylan DPC [Tue, 4 Feb 2020 20:51:56 +0000 (21:51 +0100)]
Rollup merge of #68818 - matthiaskrgr:misc_perf, r=Mark-Simulacrum
fix couple of perf related clippy warnings
librustc: don't clone a type that is copy
librustc_incremental: use faster vector initialization
librustc_typeck: don't clone a type that is copy
librustdoc: don't create a vector where a slice will do
Dylan DPC [Tue, 4 Feb 2020 20:51:50 +0000 (21:51 +0100)]
Rollup merge of #68758 - daboross:fix-59191, r=petrochenkov
Fix 59191 - ICE when macro replaces crate root with non-module item
Hi,
This should fix #59191! My friend and I are working on learning the rustc codebase through contributions, so please feel free to mention anything amiss or that could be done better.
The code adds an explicit case for when a macro applied to the crate root (via an inner attribute) replaces it with something nonsensical, like a function. The crate root must be a module, and the error message reflects this.
---
I should note that there are a few other weird edge cases here, like if they do output a module, it succeeds but uses that module's name as a prefix for all names in the crate. I'm assuming that's an issue for stabilizing #54726, though.
bors [Tue, 4 Feb 2020 20:30:53 +0000 (20:30 +0000)]
Auto merge of #68558 - HeroicKatora:buf-writer-capacity, r=alexcrichton
Add a method to query the capacity of a BufWriter and BufReader
Besides the obvious of retrieving the parameter used to construct the writer, this method allows consumers to control the number of `flush` calls during write operations. For `BufReader` it gives an upper bound on the returned buffer in `fill_buf` which might influence the allocation behaviour of a consumer.
projects / rust.git / log