bors [Sun, 14 Jun 2020 10:37:36 +0000 (10:37 +0000)]
Auto merge of #73089 - tmiasko:musl-1.1.24, r=kennytm
Update musl to 1.1.24
Release notes since previous version 1.1.22:
## 1.1.23 release notes
### new features:
- riscv64 port
- configure now allows customizing AR and RANLIB vars
- header-level support for new linux features in 5.1
### major internal changes:
- removed extern __syscall; syscall header code is now fully self-contained
### performance:
- new math library implementation for log/exp/pow
- aarch64 dynamic tlsdesc function is streamlined
### compatibility & conformance:
- O_TTY_INIT is now defined
- sys/types.h no longer pollutes namespace with sys/sysmacros.h in any profile
- powerpc asm is now compatible with clang internal assembler
### changes for new POSIX interpretations:
- fgetwc now sets stream error indicator on encoding errors
- fmemopen no longer rejects 0 size
### bugs fixed:
- static TLS for shared libraries was allocated wrong on "Variant I" archs
- crash in dladdr reading through uninitialized pointer on non-match
- sigaltstack wrongly errored out on invalid ss_size when doing SS_DISABLE
- getdents function misbehaved with buffer length larger than INT_MAX
- set*id could deadlock after fork from multithreaded process
### arch-specfic bugs fixed:
- s390x SO_PEERSEC definition was wrong
- passing of 64-bit syscall arguments was broken on microblaze
- posix_fadvise was broken on mips due to missing 7-arg syscall support
- vrregset_t layout and member naming was wrong on powerpc64
## 1.1.24 release notes
### new features:
- GLOB_TILDE extension to glob
- non-stub catgets localization API, using netbsd binary catalog format
- posix_spawn file actions for [f]chdir (extension, pending future standard)
- secure_getenv function (extension)
- copy_file_range syscall wrapper (Linux extension)
- header-level support for new linux features in 5.2
### performance:
- new fast path for lrint (generic C version) on 32-bit archs
### major internal changes:
- functions involving time are overhauled to be time64-ready in 32-bit archs
- x32 uses the new time64 code paths to replace nasty hacks in syscall glue
### compatibility & conformance:
- support for powerpc[64] unaligned relocation types
- powerpc[64] and sh sys/user.h no longer clash with kernel asm/ptrace.h
- select no longer modifies timeout on failure (or at all)
- mips64 stat results are no longer limited to 32-bit time range
- optreset (BSD extension) now has a public declaration
- support for clang inconsistencies in wchar_t type vs some 32-bit archs
- mips r6 syscall asm no longer has invalid lo/hi register clobbers
- vestigial asm declarations of __tls_get_new are removed (broke some tooling)
- riscv64 mcontext_t mismatch glibc's member naming is corrected
### bugs fixed:
- glob failed to match broken symlinks consistently
- invalid use of interposed calloc to allocate initial TLS
- various dlsym symbol resolution logic errors
- semctl with SEM_STAT_ANY didn't work
- pthread_create with explicit scheduling was subject to priority inversion
- pthread_create failure path had data race for thread count
- timer_create with SIGEV_THREAD notification had data race getting timer id
- wide printf family failed to support l modifier for float formats
### arch-specific bugs fixed:
- x87 floating point stack imbalance in math asm (i386-only CVE-2019-14697)
- x32 clock_adjtime, getrusage, wait3, wait4 produced junk (struct mismatches)
- lseek broken on x32 and mipsn32 with large file offsets
- riscv64 atomics weren't compiler barriers
- riscv64 atomics had broken asm constraints (missing earlyclobber flag)
- arm clone() was broken when compiled as thumb if start function returned
- mipsr6 setjmp/longjmp did not preserve fpu register state correctly
Do I need to do anything to make sure Miri is still built by the tools CI builder? Are there other tools that should be off-by-default?
Also, unfortunately the `DEFAULT` associated const has no doc comment, so I have no idea what it does, or why there are semmingly two places where the default build of tools is controlled.
bors [Sat, 13 Jun 2020 15:50:56 +0000 (15:50 +0000)]
Auto merge of #73316 - Dylan-DPC:rollup-zgouwou, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #72932 (Clarify the behaviour of Pattern when used with methods like str::contains)
- #73066 (Querify whether a type has structural equality (Take 2))
- #73194 (Prefer the associated constants for pattern matching error)
- #73241 (Add/update comments about MinGW late_link_args)
- #73267 (Use the built cargo for cargotest.)
- #73290 (Fix links when pinging notification groups)
- #73302 (Adjusted some doctests in libcore to use `should_panic`.)
- #73308 (pretty/asm.rs should only be tested for x86_64 and not AArch64)
Dylan DPC [Sat, 13 Jun 2020 14:47:54 +0000 (16:47 +0200)]
Rollup merge of #73302 - JakobDegen:should-panic-documentation, r=Mark-Simulacrum
Adjusted some doctests in libcore to use `should_panic`.
Fixes #73196 .
I grepped libstd and libcore for all the instances of this pattern that I could find, but its possible that I missed some of course. If anyone knows of any more, please let me know and I will add them to the PR.
Dylan DPC [Sat, 13 Jun 2020 14:47:51 +0000 (16:47 +0200)]
Rollup merge of #73267 - ehuss:cargotest-this-cargo, r=Mark-Simulacrum
Use the built cargo for cargotest.
cargotest was using the beta (bootstrap) cargo. This changes it so that it will use the locally built cargo. This is intended to provide a sort of smoke test to ensure Cargo is functional. This *shouldn't* have any real impact on the CI build time. The cargotest job also happens to run cargo's testsuite, so it should already be building cargo.
Dylan DPC [Sat, 13 Jun 2020 14:47:45 +0000 (16:47 +0200)]
Rollup merge of #73066 - ecstatic-morse:query-structural-eq2, r=pnkfelix
Querify whether a type has structural equality (Take 2)
Alternative to #72177.
Unlike in #72177, this helper method works for all types, falling back to a query for `TyKind::Adt`s that determines whether the `{Partial,}StructuralEq` traits are implemented.
This is my preferred interface for this method. I think this is better than just documenting that the helper only works for ADTs. If others disagree, we can just merge #72177 with the fixes applied. This has already taken far too long.
Dylan DPC [Sat, 13 Jun 2020 14:47:40 +0000 (16:47 +0200)]
Rollup merge of #72932 - poliorcetics:pattern-contains-behaviour, r=hanna-kruppe
Clarify the behaviour of Pattern when used with methods like str::contains
Fixes #45507.
I used the previous work by @Emerentius (thanks !), added a paragraph and checked the links (they work for me but I'm not against someone else checking them too).
Jake Degen [Sat, 13 Jun 2020 04:06:09 +0000 (00:06 -0400)]
Adjusted some doctests in libcore to use `should_panic`.
Previously, some doctests were spawning new threads and joining them to
indicate that a particular call should panic; this hurt readability, so
the tests have been adjusted to simply call the method and use the
`should_panic` marker.
Dylan MacKenzie [Wed, 13 May 2020 20:40:22 +0000 (13:40 -0700)]
Helper method for whether type has structural equality
This helper method works for all types, falling back to a query for
`TyKind::Adt`s to determine whether the implement the
`{Partial,}StructuralEq` traits.
Dylan DPC [Fri, 12 Jun 2020 10:28:27 +0000 (12:28 +0200)]
Rollup merge of #73225 - tmandry:issue-73050, r=oli-obk
Allow inference regions when relating consts
As first noticed by @eddyb, `super_relate_consts` doesn't need to check for inference vars since `eval` does it already (and handles lifetimes correctly by erasing them).
Dylan DPC [Fri, 12 Jun 2020 10:28:25 +0000 (12:28 +0200)]
Rollup merge of #73178 - petrochenkov:explint, r=varkor
expand: More precise locations for expansion-time lints
First commit: a macro expansion doesn't have a `NodeId` associated with it, but it has a parent `DefId` which we can use for linting.
The observable effect is that lints associated with macro expansions can now be `allow`ed at finer-grained level than whole crate.
Second commit: each macro definition has a `NodeId` which we can use for linting, unless that macro definition was decoded from other crate.
Dylan DPC [Thu, 11 Jun 2020 22:05:34 +0000 (00:05 +0200)]
Rollup merge of #73247 - LeSeulArtichaut:patch-1, r=spastorino
Add various Zulip notifications for prioritization
Adapts `triagebot.toml` for rust-lang/triagebot#616 and adds various Zulip notifications for the Prioritization WG workflow.
We should also add indications about the procedure for handling those events, cc @rust-lang/wg-prioritization.
r? @spastorino
This should be merged as soon as possible after rust-lang/triagebot#616 is merged, cc @Mark-Simulacrum
Dylan DPC [Thu, 11 Jun 2020 22:05:27 +0000 (00:05 +0200)]
Rollup merge of #73036 - alexcrichton:update-wasm-fence, r=Mark-Simulacrum
std: Enable atomic.fence emission on wasm32
This commit removes the `#[cfg]` guards in `atomic::fence` on wasm
targets. Since these guards were originally added the upstream wasm
specification for threads gained an `atomic.fence` instruction, so LLVM
no longer panics on these intrinsics.
Although there aren't a ton of tests in-repo for this right now I've
tested locally and all of these fences generate `atomic.fence`
instructions in wasm.
Dylan DPC [Thu, 11 Jun 2020 22:05:19 +0000 (00:05 +0200)]
Rollup merge of #73033 - Amanieu:asm-tls, r=oli-obk
Fix #[thread_local] statics as asm! sym operands
The `asm!` RFC specifies that `#[thread_local]` statics may be used as `sym` operands for inline assembly.
This also fixes a regression in the handling of `#[thread_local]` during monomorphization which caused link-time errors with multiple codegen units, most likely introduced by #71192.
bors [Thu, 11 Jun 2020 18:11:07 +0000 (18:11 +0000)]
Auto merge of #73246 - Dylan-DPC:rollup-xnm531f, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #72180 (remove extra space from crate-level doctest names)
- #73012 (Show `SyntaxContext` in formatted `Span` debug output)
- #73097 (Try_run must only be used if toolstate is populated)
- #73169 (Handle assembler warnings properly)
- #73182 (Track span of function in method calls, and use this in #[track_caller])
- #73207 (Clean up E0648 explanation)
- #73230 (Suggest including unused asm arguments in a comment to avoid error)
Dylan DPC [Thu, 11 Jun 2020 17:04:20 +0000 (19:04 +0200)]
Rollup merge of #73230 - Amanieu:asm-unused2, r=petrochenkov
Suggest including unused asm arguments in a comment to avoid error
We require all arguments to an `asm!` to be used in the template string, just like format strings. However in some cases (e.g. `black_box`) it may be desirable to have `asm!` arguments that are not used in the template string.
Currently this is a hard error rather than a lint since `#[allow]` does not work on macros (#63221), so this PR suggests using the unused arguments in an asm comment as a workaround.
Dylan DPC [Thu, 11 Jun 2020 17:04:16 +0000 (19:04 +0200)]
Rollup merge of #73182 - Aaron1011:feature/call-fn-span, r=matthewjasper
Track span of function in method calls, and use this in #[track_caller]
Fixes #69977
When we parse a chain of method calls like `foo.a().b().c()`, each
`MethodCallExpr` gets assigned a span that starts at the beginning of
the call chain (`foo`). While this is useful for diagnostics, it means
that `Location::caller` will return the same location for every call
in a call chain.
This PR makes us separately record the span of the function name and
arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This
`Span` is passed through HIR lowering and MIR building to
`TerminatorKind::Call`, where it is used in preference to
`Terminator.source_info.span` when determining `Location::caller`.
This new span is also useful for diagnostics where we want to emphasize
a particular method call - for an example, see
https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
Dylan DPC [Thu, 11 Jun 2020 17:04:12 +0000 (19:04 +0200)]
Rollup merge of #73097 - Mark-Simulacrum:clippy-fail, r=oli-obk
Try_run must only be used if toolstate is populated
Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build.
The previous PR of this kind didn't catch this as I expected x.py failures to always lead to a non-successful build in CI, but that's not the case specifically for tool testing.
Dylan DPC [Thu, 11 Jun 2020 17:04:09 +0000 (19:04 +0200)]
Rollup merge of #73012 - Aaron1011:feature/span-debug-ctxt, r=matthewjasper
Show `SyntaxContext` in formatted `Span` debug output
This is only really useful in debug messages, so I've switched to
calling `span_to_string` in any place that causes a `Span` to end up in
user-visible output.
Dylan DPC [Thu, 11 Jun 2020 17:04:08 +0000 (19:04 +0200)]
Rollup merge of #72180 - euclio:rustdoc-test-extra-space, r=Dylan-DPC
remove extra space from crate-level doctest names
Before:
```
running 2 tests
test src/test/rustdoc-ui/doctest-output.rs - foo::bar (line 11) ... ok
test src/test/rustdoc-ui/doctest-output.rs - (line 5) ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
After:
```
running 2 tests
test src/test/rustdoc-ui/doctest-output.rs - foo::bar (line 11) ... ok
test src/test/rustdoc-ui/doctest-output.rs - (line 5) ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
Dylan DPC [Thu, 11 Jun 2020 11:15:53 +0000 (13:15 +0200)]
Rollup merge of #72380 - lcnr:const_context, r=estebank
Fix `is_const_context`, update `check_for_cast`
A better version of #71477
Adds `fn enclosing_body_owner` and uses it in `is_const_context`.
`is_const_context` now uses the same mechanism as `mir_const_qualif` as it was previously incorrect.
Renames `is_const_context` to `is_inside_const_context`.
I also updated `check_for_cast` in the second commit, so r? @estebank
(I removed one lvl of indentation, so it might be easier to review by hiding whitespace changes)
bors [Thu, 11 Jun 2020 04:58:48 +0000 (04:58 +0000)]
Auto merge of #71896 - spastorino:existential-assoc-types-variance, r=nikomatsakis
Relate existential associated types with variance Invariant
Fixes #71550 #72315
r? @nikomatsakis
The test case reported in that issue now errors with the following message ...
```
error[E0495]: cannot infer an appropriate lifetime for lifetime parameter 'a in function call due to conflicting requirements
--> /tmp/test.rs:25:5
|
25 | bad(&Bar(PhantomData), x)
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: first, the lifetime cannot outlive the lifetime `'a` as defined on the function body at 24:11...
--> /tmp/test.rs:24:11
|
24 | fn extend<'a, T>(x: &'a T) -> &'static T {
| ^^
note: ...so that reference does not outlive borrowed content
--> /tmp/test.rs:25:28
|
25 | bad(&Bar(PhantomData), x)
| ^
= note: but, the lifetime must be valid for the static lifetime...
note: ...so that the types are compatible
--> /tmp/test.rs:25:9
|
25 | bad(&Bar(PhantomData), x)
| ^^^^^^^^^^^^^^^^^
= note: expected `&'static T`
found `&T`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0495`.
```
I could also add that test case if we want to have a weaponized one too.
bors [Thu, 11 Jun 2020 01:27:03 +0000 (01:27 +0000)]
Auto merge of #73198 - ehuss:update-cargo, r=ehuss
Update cargo
15 commits in 40ebd52206e25c7a576ee42c137cc06a745a167a..1ec223effbbbf9fddd3453cdcae3a96a967608eb
2020-06-01 22:35:00 +0000 to 2020-06-09 20:03:14 +0000
- Default values for `readme` if not specified (rust-lang/cargo#8277)
- Fix tree completions. (rust-lang/cargo#8342)
- Support `{prefix}` and `{lowerprefix}` markers in `config.json` `dl` key (rust-lang/cargo#8267)
- Add environment variables to identify the binary and crate name (rust-lang/cargo#8270)
- Bump to 0.47.0, update changelog (rust-lang/cargo#8336)
- Nits: Remove unneeded mut and loop (rust-lang/cargo#8334)
- 1.45 beta backports (rust-lang/cargo#8331)
- Better error message when passing in relative path to Workspace::new (rust-lang/cargo#8321)
- Don't hash executable filenames on apple platforms. (rust-lang/cargo#8329)
- fix clippy warnings (rust-lang/cargo#8324)
- Require latest libgit2 to pull in bugfixes (rust-lang/cargo#8320)
- Fix an accidental raw access of field (rust-lang/cargo#8319)
- Use mem::take to replace with Default values (rust-lang/cargo#8314)
- Allow Windows dylibs without dll suffix. (rust-lang/cargo#8310)
- Show alias in help message (rust-lang/cargo#8307)
bors [Wed, 10 Jun 2020 22:01:37 +0000 (22:01 +0000)]
Auto merge of #73206 - Dylan-DPC:rollup-rha9g8q, r=Dylan-DPC
Rollup of 9 pull requests
Successful merges:
- #72706 (Add windows group to triagebot)
- #72789 (resolve: Do not suggest imports from the same module in which we are resolving)
- #72890 (improper ctypes: normalize return types and transparent structs)
- #72897 (normalize adt fields during structural match checking)
- #73005 (Don't create impl candidates when obligation contains errors)
- #73023 (Remove noisy suggestion of hash_map )
- #73070 (Add regression test for const generic ICE in #72819)
- #73157 (Don't lose empty `where` clause when pretty-printing)
- #73184 (Reoder order in which MinGW libs are linked to fix recent breakage)
Aaron Hill [Tue, 9 Jun 2020 19:34:23 +0000 (15:34 -0400)]
Track span of function in method calls, and use this in #[track_caller]
Fixes #69977
When we parse a chain of method calls like `foo.a().b().c()`, each
`MethodCallExpr` gets assigned a span that starts at the beginning of
the call chain (`foo`). While this is useful for diagnostics, it means
that `Location::caller` will return the same location for every call
in a call chain.
This PR makes us separately record the span of the function name and
arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This
`Span` is passed through HIR lowering and MIR building to
`TerminatorKind::Call`, where it is used in preference to
`Terminator.source_info.span` when determining `Location::caller`.
This new span is also useful for diagnostics where we want to emphasize
a particular method call - for an example, see
https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
bors [Wed, 10 Jun 2020 18:02:34 +0000 (18:02 +0000)]
Auto merge of #73213 - ehuss:fix-emsdk, r=Mark-Simulacrum
Fix emcc failure for wasm32.
The wasm32 job is currently failing on CI with the error `ERROR: llc executable not found at /usr/bin/llc`. The issue is that https://github.com/emscripten-core/emsdk/pull/472 has changed how emsdk discovers its configuration. We were relying on the global behavior that would use a configuration from the home directory. However, it looks like emsdk is moving away from that approach. This change adds the necessary env var for emcc to find the correct configuration.
There are a few alternate approaches this could take. The `--no-embedded` option could be passed to `emsdk activate` to use the old behavior, but it seems like they want to move away from that. Another option is to source `emsdk_env.sh`, which is how these env vars normally get set. I'm not entirely sure how to do that easily in a Dockerfile, though.
Dylan DPC [Wed, 10 Jun 2020 09:03:51 +0000 (11:03 +0200)]
Rollup merge of #73184 - mati865:fix-mingw-libs-order, r=petrochenkov
Reoder order in which MinGW libs are linked to fix recent breakage
Recent upstream mingw-w64 changes made libmsvcrt depend on libmingwex breaking compilation in some cases when using **external** MinGW.
Applying this change to the master fixes nightly and stage{1,2} build. For stage0 one has to export `RUSTFLAGS_BOOTSTRAP='-C link-arg=-lmsvcrt'` until this PR lands in bootstrap compiler.
Therefore I'm humbly asking to also backport it to the beta and update bootstrap compiler.
Dylan DPC [Wed, 10 Jun 2020 09:03:49 +0000 (11:03 +0200)]
Rollup merge of #73157 - Aaron1011:where-oh-where-has-my-little-span-gone, r=ecstatic-morse
Don't lose empty `where` clause when pretty-printing
Previously, we would parse `struct Foo where;` and `struct Foo;`
identically, leading to an 'empty' `where` clause being omitted during
pretty printing. This will cause us to lose spans when proc-macros
involved, since we will have a collected `where` token that does not
appear in the pretty-printed item.
We now explicitly track the presence of a `where` token during parsing,
so that we can distinguish between `struct Foo where;` and `struct Foo;`
during pretty-printing