Supercedes: https://github.com/rust-lang/rust/pull/65082
Depends on: https://github.com/rust-lang/rust/pull/65037
Tracking issue: https://github.com/rust-lang/rust/issues/47809
[RFC text](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md)
steps taken:
* [x] add a `ReifyShim` that is similar to `VirtualShim` in behavior (see #54183)
* [x] add `ty::Instance::resolve_for_fn_ptr` (leave `ty::Instance::resolve_vtable` alone), migrate appropriate callers
* [x] `resolve_for_fn_ptr` returns the shim if calling a `#[track_caller]` function
bors [Sat, 12 Oct 2019 23:47:27 +0000 (23:47 +0000)]
Auto merge of #64873 - popzxc:prettify-test-time, r=wesleywiser
Enhance report-time option
## Short overview
This PR is a follow-up to a previously closed #64714 PR.
## Changes introduced by this PR
* `libtest` now retrieves the type of the test within `TestDesc` (available types are: `UnitTest`, `IntegrationTest`, `DocTest`, `Unknown`).
* `--report-time` subcommand of the `libtest` now supports colored output (disabled by default).
* Colorized output depends on the threshold values. Default values (proposed by @wesleywiser):
- For unit-tests: 50ms warn/100ms critical,
- For integration-tests: 500ms warn/1000ms critical,
- For doctests: same as for integration tests,
- For unknown tests: `TEST_WARN_TIMEOUT_S` warn/ `TEST_WARN_TIMEOUT_S * 2` critical (it will only applied single-threaded mode, because otherwise test will be interrupted after reaching `TEST_WARN_TIMEOUT_S`).
- These values can be overrided by setting environment variables (since those thresholds are somewhat constant for every project, it's more flexible to use environment variables than command line arguments).
* New optional flag `--ensure-test-time` for `libtest`. With this flag applied, exectuion time limit excesss will cause test failure.
## What have not been done
There was a comment that it would be nice to have an entry in the Cargo book about it.
However, changes introduced by this PR (and #64663 in which `report-time` flag was added) aren't related directly to `cargo`, it's more about `libtest` itself.
I'm considering that [The Unstable Book](https://doc.rust-lang.org/unstable-book/) is more appropriate place, but not sure if I'm right (and if so, how exactly it should be described).
As one possible option, this PR may be merged without denoting it in the documentation, and in the next PR adding support of this feature to the `cargo` itself, I'll add a note in the Cargo book.
## Scope of this PR
Logical scope of this PR is `libtest` only. However, to get test types, I had to modify also `libsyntax_ext` and `librustdoc` for them to provide information about test type.
## Rationale
Rationale for colored output was submitted in #64714
Providing the information about kind of test was also proposed in #64714, and as an additional benefit this information may be useful for the tools using `libtest` (e.g. `cargo`).
Adding flag to treat time limits excess seems logical to me, so projects that do care about test execution time won't have to invent a wheel.
## Backward compatibility
All the changes are completely backward compatible.
bors [Sat, 12 Oct 2019 06:25:03 +0000 (06:25 +0000)]
Auto merge of #65322 - tmandry:rollup-frr651r, r=tmandry
Rollup of 15 pull requests
Successful merges:
- #64337 (libstd: Fix typos in doc)
- #64986 (Function pointers as const generic arguments)
- #65048 (Added doc about behavior of extend on HashMap)
- #65191 (Add some regression tests)
- #65200 (Add ?Sized bound to a supertrait listing in E0038 error documentation)
- #65205 (Add long error explanation for E0568)
- #65220 (Update LLVM for Emscripten exception handling support)
- #65263 (Deduplicate is_{freeze,copy,sized}_raw)
- #65266 (Mark Path::join as must_use)
- #65276 (Don't cc rust-lang/compiler for toolstate changes)
- #65277 (Query generator kind for error reporting)
- #65283 (stability: Do not use `buffer_lint` after lowering to HIR)
- #65289 (Fix suggested bound addition diagnostic)
- #65310 (deriving: avoid dummy Span on an artificial `type_ident` path)
- #65321 (Remove painful test that is not pulling its weight)
bors [Sat, 12 Oct 2019 02:31:03 +0000 (02:31 +0000)]
Auto merge of #65020 - pnkfelix:targetted-fix-for-always-marking-rust-abi-unwind-issue-64655, r=alexcrichton
Always mark rust and rust-call abi's as unwind
PR #63909 identified a bug that had been injected by PR #55982. As discussed on https://github.com/rust-lang/rust/issues/64655#issuecomment-537517428 , we started marking extern items as nounwind, *even* extern items that said they were using "Rust" or "rust-call" ABI.
This is a more targeted variant of PR #63909 that fixes the above bug.
Fix #64655
----
I personally suspect we will want PR #63909 to land in the long-term
But:
* it is not certain that PR #63909 *will* land,
* more importantly, PR #63909 almost certainly will not be backported to beta/stable.
The identified bug was more severe than I think anyone realized (apart from perhaps @gnzlbg, as noted [here](https://github.com/rust-lang/rust/pull/63909#issuecomment-524818838)).
Thus, I was motivated to write this PR, which fixes *just* the issue with extern rust/rust-call functions, and deliberately avoids injecting further deviation from current behavior (you can see further notes on this in the comments of the code added here).
Tyler Mandry [Fri, 11 Oct 2019 22:10:01 +0000 (15:10 -0700)]
Rollup merge of #65321 - Mark-Simulacrum:remove-linker-no-utf8-test, r=nikomatsakis
Remove painful test that is not pulling its weight
Research suggests that we are not properly testing this case anyway, and
even if we were, it is unlikely that we will regress here -- or, perhaps
more accurately, if we do, I am uncertain that we care too much. It
definitely seems like an edge case, and one that is particularly
unlikely to occur as time goes on.
Tyler Mandry [Fri, 11 Oct 2019 22:10:00 +0000 (15:10 -0700)]
Rollup merge of #65310 - da-x:issue-56195, r=petrochenkov
deriving: avoid dummy Span on an artificial `type_ident` path
The dummy Span pointed to the beginning of the source file instead to where the `#[derive]` is located. Later, it tripped the `in_derive_expansion(span)` check at `src/librustc/middle/stability.rs`, causing a span-less deprecation warning to be emitted.
Tyler Mandry [Fri, 11 Oct 2019 22:09:50 +0000 (15:09 -0700)]
Rollup merge of #65220 - tlively:update-llvm-for-emscripten-exceptions, r=nikic
Update LLVM for Emscripten exception handling support
Updates LLVM to pick up the cherry-picked support for correctly
handling exception handling with aggregates passed by value. This will
be necessary to continue to support Emscripten's exception handling
once we switch using Emscripten's LLVM backend. See #63649.
Mark Rousskov [Fri, 11 Oct 2019 21:41:55 +0000 (17:41 -0400)]
Remove painful test that is not pulling its weight
Research suggests that we are not properly testing this case anyway, and
even if we were, it is unlikely that we will regress here -- or, perhaps
more accurately, if we do, I am uncertain that we care too much. It
definitely seems like an edge case, and one that is particularly
unlikely to occur as time goes on.
Dan Aloni [Fri, 11 Oct 2019 12:14:23 +0000 (15:14 +0300)]
deriving: avoid dummy Span on an artificial `type_ident` path
The dummy Span pointed to the beginning of the source file instead to
where the `#[derive]` is located. Later, it tripped the
`in_derive_expansion(span)` check at `src/librustc/middle/stability.rs`,
causing a span-less deprecation warning to be emitted.
bors [Thu, 10 Oct 2019 23:43:55 +0000 (23:43 +0000)]
Auto merge of #64823 - cuviper:min-std, r=Mark-Simulacrum
minimize the rust-std component
This changes the `rust-std` dist component to only include the artifacts of compiling the `libstd` step, as listed in `.libstd.stamp`. This does include `test` and `proc-macro` as well. The remaining _unstable_ libraries that are built as part of `rustc` are packaged into a new `rustc-dev` component, intended for use in the development of closely related tools (clippy, miri, rls).
Here are the component sizes from the [try build](https://dev-static.rust-lang.org/dist/2019-10-07/index.html):
bors [Thu, 10 Oct 2019 19:40:48 +0000 (19:40 +0000)]
Auto merge of #65153 - da-x:issue-58017, r=petrochenkov
Improve message when attempting to instantiate tuple structs with private fields
Fixes #58017, fixes #39703.
```
error[E0603]: tuple struct `Error` is private
--> main.rs:22:16
|
2 | pub struct Error(usize, pub usize, usize);
| ----- ----- field is private
| |
| field is private
...
22 | let x = a::Error(3, 1, 2);
| ^^^^^
|
= note: a tuple struct constructor is private if any of its fields is private
```
bors [Thu, 10 Oct 2019 15:40:39 +0000 (15:40 +0000)]
Auto merge of #59546 - sfanxiang:interminable-ub, r=nagisa
Add llvm.sideeffect to potential infinite loops and recursions
LLVM assumes that a thread will eventually cause side effect. This is
not true in Rust if a loop or recursion does nothing in its body,
causing undefined behavior even in common cases like `loop {}`.
Inserting llvm.sideeffect fixes the undefined behavior.
As a micro-optimization, only insert llvm.sideeffect when jumping back
in blocks or calling a function.
A patch for LLVM is expected to allow empty non-terminate code by
default and fix this issue from LLVM side.
https://github.com/rust-lang/rust/issues/28728
**UPDATE:** [Mentoring instructions here](https://github.com/rust-lang/rust/pull/59546#issuecomment-515072429) to unstall this PR
Adam Perry [Wed, 9 Oct 2019 13:20:23 +0000 (06:20 -0700)]
Return ReifyShim from Instance::resolve_for_fn_ptr when track_caller present.
This ICEs in MIR currently, which I think is to be expected since none of the MIR plumbing is set up. I added a test which confirms that the shim is being used for reifying a track_caller function.
bors [Wed, 9 Oct 2019 03:32:21 +0000 (03:32 +0000)]
Auto merge of #65229 - Centril:rollup-wnr46vg, r=Centril
Rollup of 4 pull requests
Successful merges:
- #64656 (Implement (HashMap) Entry::insert as per #60142)
- #65037 (`#[track_caller]` feature gate (RFC 2091 1/N))
- #65166 (Suggest to add `move` keyword for generator capture)
- #65175 (add more info in debug traces for gcu merging)
Rollup merge of #64656 - passcod:map-entry-insert, r=Amanieu
Implement (HashMap) Entry::insert as per #60142
Implementation of `Entry::insert` as per @SimonSapin's comment on #60142. This requires a patch to hashbrown:
```diff
diff --git a/src/rustc_entry.rs b/src/rustc_entry.rs
index fefa5c3..7de8300 100644
--- a/src/rustc_entry.rs
+++ b/src/rustc_entry.rs
@@ -546,6 +546,32 @@ impl<'a, K, V> RustcVacantEntry<'a, K, V> {
let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
unsafe { &mut bucket.as_mut().1 }
}
+
+ /// Sets the value of the entry with the RustcVacantEntry's key,
+ /// and returns a RustcOccupiedEntry.
+ ///
+ /// # Examples
+ ///
+ /// ```
+ /// use hashbrown::HashMap;
+ /// use hashbrown::hash_map::RustcEntry;
+ ///
+ /// let mut map: HashMap<&str, u32> = HashMap::new();
+ ///
+ /// if let RustcEntry::Vacant(v) = map.rustc_entry("poneyland") {
+ /// let o = v.insert_and_return(37);
+ /// assert_eq!(o.get(), &37);
+ /// }
+ /// ```
+ #[inline]
+ pub fn insert_and_return(self, value: V) -> RustcOccupiedEntry<'a, K, V> {
+ let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
+ RustcOccupiedEntry {
+ key: None,
+ elem: bucket,
+ table: self.table
+ }
+ }
}
impl<K, V> IterMut<'_, K, V> {
```
This is also only an implementation for HashMap. I tried implementing for BTreeMap, but I don't really understand BTreeMap's internals and require more guidance on implementing the equivalent `VacantEntry::insert_and_return` such that it returns an `OccupiedEntry`. Notably, following the original PR's modifications I end up needing a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::LeafOrInternal>, _>` while I only have a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::Internal>, _>` and don't know how to proceed.
(To be clear, I'm not asking for guidance right now; I'd be happy getting only the HashMap implementation — the subject of this PR — reviewed and ready, and leave the BTreeMap implementation for a latter PR.)
bors [Tue, 8 Oct 2019 21:32:07 +0000 (21:32 +0000)]
Auto merge of #65223 - Centril:rollup-5sdvdni, r=Centril
Rollup of 7 pull requests
Successful merges:
- #64284 (Warn if include macro fails to include entire file)
- #65081 (Remove -Zprofile-queries)
- #65133 (typeck: prohibit foreign statics w/ generics)
- #65135 (Add check for missing tests for error codes)
- #65141 (Replace code of conduct with link)
- #65194 (Use structured suggestion for removal of `as_str()` call)
- #65213 (Ignore `ExprKind::DropTemps` for some ref suggestions)
Rollup merge of #65141 - BO41:code-of-conduct, r=Mark-Simulacrum
Replace code of conduct with link
This will replace the code of conduct and link to a single version at https://www.rust-lang.org/conduct.html
Fixes https://github.com/rust-lang/rust/pull/61531#issuecomment-501473787
Rollup merge of #65133 - davidtwco:issue-65035-static-with-generic-in-foreign-mod, r=petrochenkov
typeck: prohibit foreign statics w/ generics
Fixes #65035 and fixes #65025.
This PR modifies resolve to disallow foreign statics that have
generics.
`improper_ctypes` is not written to support type parameters, as these
are normally disallowed before the lint is run. Thus, type parameters in
foreign statics must be prohibited before the lint.
The only other case where this *could* have occured is in functions,
but typeck prohibits this with a "foreign items may not have type
parameters" error - a similar error did not exist for statics, because
statics cannot have type parameters, but they can use any
type parameters that are in scope (which isn't the case for functions).