Auto merge of #69573 - pnkfelix:issue-53114-add-tests, r=Centril
tests encoding current behavior for various cases of "binding" to _.
The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed.
Cc #53114.
(This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)
Auto merge of #70986 - marmeladema:issue70853/librustc_middle-local-def-id, r=eddyb
rustc_middle: return `LocalDefId` where possible in hir::map module
This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`:
* opt_local_def_id_from_node_id
* opt_local_def_id
* body_owner_def_id
* local_def_id_from_node_id
* get_parent_id
This is another step in the right direction for #70853
This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive, we might want to wait for #70956 or #70961 (or some other form it) to land first.
Rollup merge of #70991 - longfangsong:master, r=jonas-schievink
fix rustc-dev-guide's url in src/librustc_codegen_ssa
Change the backend-agnostic chapter's url in rustc-dev-guide from [url](https://rustc-dev-guide.rust-lang.org/codegen/backend-agnostic.html), which is 404 now, to [the right one](https://rustc-dev-guide.rust-lang.org/backend/backend-agnostic.html).
Rollup merge of #70973 - ecstatic-morse:recursion-lint, r=jonas-schievink
Use forward traversal for unconditional recursion lint
While reviewing #70822, I noted that #54444 could be solved without requiring the predecessor graph and without allocating a `Vec<Span>` for every basic block. The unconditional recursion lint is not a performance bottleneck however, so I approved #70822 as it was.
Nevertheless, I wanted to try implementing my idea using `TriColorDepthFirstSearch`, which is a DFS that can differentiate between [forward/tree edges and backward ones](https://en.wikipedia.org/wiki/Depth-first_search#Output_of_a_depth-first_search). I found this approach more straightforward than the existing one, so I'm opening this PR to see if it is desirable.
The pass is now just a DFS across the control-flow graph. We ignore false edges and false unwinds, as well as the successors of recursive calls, just like existing pass does. If we see a back-edge (loop) or a terminator that would cause us to yield control-flow back to the caller (`Return`, `Resume`, etc.), we know that the function does not unconditionally recurse.
Auto merge of #66605 - GuillaumeGomez:drop-python2, r=Mark-Simulacrum
Stop explicitly depending on python 2
This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually, by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available).
The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such, though only on one builder. This is intended as a temporary, though likely long-lived, measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future, depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time.
Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).
tests encoding current behavior for various cases of "binding" to _.
The `_` binding form is special, in that it encodes a "no-op": nothing is
actually bound, and thus nothing is moved or borrowed in this scenario. Usually
we do the "right" thing in all such cases. The exceptions are explicitly pointed
out in this test case, so that we keep track of whether they are eventually
fixed.
Auto merge of #70983 - Centril:rollup-npabk7c, r=Centril
Rollup of 8 pull requests
Successful merges:
- #70784 (Consider methods on fundamental `impl` when method is not found on numeric type)
- #70843 (Remove the Ord bound that was plaguing drain_filter)
- #70913 (Replace "rc"/"arc" lang items with Rc/Arc diagnostic items.)
- #70932 (De-abuse TyKind::Error in pattern type checking)
- #70952 (Clean up E0511 explanation)
- #70964 (rustc_session CLI lint parsing: mark a temporary hack as such)
- #70969 (Fix JSON file_name documentation for macros.)
- #70975 (Fix internal doc comment nits.)
Rollup merge of #70964 - RalfJung:mark-cli-lint-hack, r=petrochenkov
rustc_session CLI lint parsing: mark a temporary hack as such
This code was added in https://github.com/rust-lang/rust/pull/70918, but it should not be necessary any more once `forbid` works as expected for in-code attributes.
Auto merge of #70619 - etherealist:musl_lld, r=Mark-Simulacrum
Enable rust-lld on dist-x86_64-musl
Add rust-lld to rustup llvm-tools-preview on nightly for musl
I am using a musl distro on my workstation, with `RUSTFLAGS="-C target-feature=-crt-static"` this works fine. I know that `x86_64-unknown-linux-musl` was originally only meant as a target and not as a host. But most problems have been fixed, and I have fewer problems with `unknown` (rustup) than when I am using `x86_64-alpine-linux-musl` (rust installed by the distro). The only thing I am missing is rust-lld in llvm-tools-preview on nightly.
I needed rust-lld for a wasm tutorial. I built rust-lld and tested it with that tutorial, and it worked well. I asked [here](https://users.rust-lang.org/t/enable-rust-lld-on-x86-64-unknown-linux-musl/39851) where to request to enable lld and ended up doing this PR.
I compared llvm-tools-preview `nightly-x86_64-unknown-linux-musl` and `nightly-x86_64-unknown-linux-gnu`: only rust-lld is missing in musl.
The only dataflow analysis that is incorrect in this case is `MaybeStorageLive`. `transform/generator.rs` implemented custom handling for this class of locals, but other consumers of this analysis (there's one in [clippy](https://github.com/rust-lang/rust-clippy/blob/513b46793e98ce5b412d388a91f6371d6a9b290b/clippy_lints/src/redundant_clone.rs#L402)) would be incorrect.
Auto merge of #70909 - marmeladema:issue70853/librustc_hir-local-def-id, r=eddyb
librustc_hir: return LocalDefId instead of DefId in local_def_id
Its a first try to remove a few calls to `expect_local` and use `LocalDefId` instead of `DefId` where possible for #70853
This adds some calls to `.to_def_id()` to get a `DefId` back when needed. I don't know if I should push `LocalDefId` even further and change, for example, `Res::Def` to accept a `LocalDefId` instead of a `DefId` as second argument.
Rollup merge of #70958 - Amanieu:android_try_reserve, r=Mark-Simulacrum
Disable try_reserve tests on Android
Calling `realloc` with large sizes seems to be broken on older Android versions that use dlmalloc as the default allocator. This is not an issue for modern Android versions that use jemalloc.
Rollup merge of #70900 - ehuss:update-cargo, r=ehuss
Update cargo
4 commits in 6e07d2dfb7fc87b1c9489de41da4dafa239daf03..390e8f245ef2cd7ac698b8a76abf029f9abcab0d
2020-03-31 03:22:39 +0000 to 2020-04-07 17:46:45 +0000
- Compatibility for rust-lang/rust#69926 (rust-lang/cargo#8080)
- Add note about converting triple case in environment variables (rust-lang/cargo#8079)
- Add support for `-Cembed-bitcode=no` (rust-lang/cargo#8066)
- Add triagebot configuration (rust-lang/cargo#8059)
Auto merge of #70943 - Centril:rollup-eowm2h3, r=Centril
Rollup of 7 pull requests
Successful merges:
- #67705 (Use unrolled loop for searching NULL in [u16] on Windows)
- #70367 (save/restore `pessimistic_yield` when entering bodies)
- #70822 (Don't lint for self-recursion when the function can diverge)
- #70868 (rustc_codegen_ssa: Refactor construction of linker arguments)
- #70896 (Implement Chain with Option fuses)
- #70916 (Support `#[track_caller]` on functions in `extern "Rust" { ... }`)
- #70918 (rustc_session: forbid lints override regardless of position)
Rollup merge of #70916 - Centril:track-caller-ffi, r=eddyb
Support `#[track_caller]` on functions in `extern "Rust" { ... }`
Fixes https://github.com/rust-lang/rust/issues/70830 which is the follow-up to @eddyb's suggestion in https://github.com/rust-lang/rust/pull/69251#discussion_r380791634 to allow `#[track_caller]` on `fn`s in FFI imports, that is, on functions in `extern "Rust" { ... }` blocks.
This requires that the other side, the FFI export, also have the `#[track_caller]` attribute. Otherwise, undefined behavior is triggered and the blame lies, as usual, with the `unsafe { ... }` block which called the FFI imported function.
After this PR, all forms of `fn` items with the right ABI (`"Rust"`) support `#[track_caller]`.
As a drive-by, the PR also hardens the check rejecting `#[naked] #[track_caller]` such that methods and other forms of `fn` items are also considered.
Rollup merge of #70896 - cuviper:optional-chain, r=scottmcm
Implement Chain with Option fuses
The iterators are now "fused" with `Option` so we don't need separate state to track which part is already exhausted, and we may also get niche layout for `None`. We don't use the real `Fuse` adapter because its specialization for `FusedIterator` unconditionally descends into the iterator, and that could be expensive to keep revisiting stuff like nested chains. It also hurts compiler performance to add more iterator layers to `Chain`.
This change was inspired by the [proposal](https://internals.rust-lang.org/t/proposal-implement-iter-chain-using-fuse/12006) on the internals forum. This is an alternate to #70332, directly employing some of the same `Fuse` optimizations as #70366 and #70750.
Rollup merge of #70868 - petrochenkov:linkorder, r=nagisa,mati865
rustc_codegen_ssa: Refactor construction of linker arguments
And add comments.
This PR doesn't reorder any linker arguments and therefore shouldn't contain any observable changes.
The next goal here is to
- Factor out order-independent linker arguments in the compiler code and in target specifications and pass them together. Such arguments generally apply to the whole linking session or the produced linking result rather to individual object files or libraries.
- Figure out where exactly among the remaining order-dependent arguments we should place customization points like `-C link-args` and `-Z pre-link-args`.
- Possibly provide command line opt-outs for options that are currently passed unconditionally (like CRT objects or arguments defined by the target spec).
- Document and stabilize the customization points that are not yet stable (https://github.com/rust-lang/rust/pull/70505).
Rollup merge of #70367 - nikomatsakis:issue-69307, r=Aaron1011
save/restore `pessimistic_yield` when entering bodies
This flag is used to make the execution order around `+=` operators
pessimistic. Failure to save/restore the flag was causing independent
async blocks to effect one another, leading to strange ICEs and failed
assumptions.
Auto merge of #70936 - Dylan-DPC:rollup-2ng3e5h, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #70134 (add basic support of OsStrExt for HermitCore)
- #70565 (Add inline attributes for functions used in the query system)
- #70828 (rustdoc: Don't try to load source files from external crates)
- #70870 (Fix abuses of tykind::err)
- #70906 (Suggest move for closures and async blocks in more cases.)
- #70912 (Do not suggest adding type param when `use` is already suggested)
- #70930 (add tracking issue to `VecDeque::make_contiguous`)
Rollup merge of #70915 - tsandstr:remove-nominal-flags, r=eddyb
Remove unnecessary TypeFlags::NOMINAL_FLAGS
This was a relic from when we had "nominal flags" and "cached
properties." The latter no longer exists, so nominal flags are no
longer necessary. In fact, every flag is considered a nominal flag. I
went ahead and removed all references to NOMINAL_FLAGS.
projects / rust.git / log