Rollup merge of #57573 - Xanewok:querify-entry-fn, r=Zoxc
Querify `entry_fn`
Analogous to https://github.com/rust-lang/rust/pull/57570 but this will also require few fixups in Miri so I decided to separate that (and it seems [CI doesn't let us break tools anymore](https://github.com/rust-lang/rust/pull/57392#issuecomment-453801540)? Or was that because it was a rollup PR?)
Rollup merge of #57501 - petrochenkov:highvar, r=alexreg
High priority resolutions for associated variants
In https://github.com/rust-lang/rust/pull/56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.
This PR changes the rules to give variants highest priority instead.
Some motivation:
- If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits.
- Inherent associated items have higher priority during resolution than associated items from traits.
- The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority.
- It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.
Crater found some regressions from this change, but they are all in type positions, e.g.
```rust
fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`?
```
, so variants are not usable there right now, but they may become usable in the future if https://github.com/rust-lang/rfcs/pull/2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.
Rollup merge of #57476 - Xanewok:bye-crate-analysis, r=Zoxc
Move glob map use to query and get rid of CrateAnalysis
~Also includes commits from ~https://github.com/rust-lang/rust/pull/57392~ and ~https://github.com/rust-lang/rust/pull/57436~.~
With glob map calculated unconditionally in https://github.com/rust-lang/rust/pull/57392, this PR moves the calculated glob map to `GlobalCtxt` and exposes a relevant query (as we do with other queries which copy precomputed data over from the `Resolver`).
This allows us to get rid of the `CrateAnalysis` struct in an attempt to simplify the compiler interface.
cc @Zoxc
Rollup merge of #57268 - peterhj:peterhj-optmergefunc, r=nagisa
Add a target option "merge-functions", and a corresponding -Z flag (works around #57356)
This commit adds a target option "merge-functions", which takes values in ("disabled", "trampolines", or "aliases" (default is "aliases")), to allow targets to opt out of the MergeFunctions LLVM pass. Additionally, the latest commit also adds an optional -Z flag, "merge-functions", which takes the same values and has precedence over the target option when both are specified.
This works around https://github.com/rust-lang/rust/issues/57356.
cc @eddyb @japaric @oli-obk @nox @nagisa
Also thanks to @denzp and @gnzlbg for discussing this on rust-cuda!
### Motivation
Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3 [1], and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler `ptxas`). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does.
### Related work
The current behavior of rustc is to enable MergeFunctions at -O2 and -O3 [1], and also to enable the use of function aliases within MergeFunctions [2] [3]. MergeFunctions seems to have some benefits, such as reducing code size and fixing a crash [4], which is why it is enabled. However, MergeFunctions both with and without function aliases is incompatible with the NVPTX target; a more detailed example for both cases is given below.
clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default.
### Examples/more details
Consider an example Rust lib using `extern "ptx-kernel"` functions: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore.rs. If we try to compile this with nightly rustc, we get the following compiler error:
LLVM ERROR: Module has aliases, which NVPTX does not support.
This error happens because: (1) functions `foo` and `bar` have the same body, so are candidates to be merged by MergeFunctions; and (2) rustc configures MergeFunctions to generate function aliases using the "mergefunc-use-aliases" LLVM option [2] [3], but the NVPTX backend does not support those aliases.
Okay, so we can try omitting "mergefunc-use-aliases", and then rustc will happily emit PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-mergefunc-nousealiases-bad.ptx. However, this PTX is invalid! When we try to assemble it with `ptxas` (I'm on the CUDA 9.2 toolchain), we get an assembler error:
ptxas nocore-mergefunc-nousealiases-bad.ptx, line 38; error : Illegal call target, device function expected
ptxas fatal : Ptx assembly aborted due to errors
What's happening is that MergeFunctions rewrites the `bar` function to call `foo`. However, directly calling an `extern "ptx-kernel"` function from another `extern "ptx-kernel"` is wrong.
If we disable the MergeFunctions pass from running at all, rustc generates correct PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-nomergefunc-ok.ptx
bors [Sat, 19 Jan 2019 05:05:48 +0000 (05:05 +0000)]
Auto merge of #56722 - Aaron1011:fix/blanket-eval-overflow, r=nikomatsakis
Fix stack overflow when finding blanket impls
Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.
To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.
Fixes #56701
I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
bors [Fri, 18 Jan 2019 23:40:14 +0000 (23:40 +0000)]
Auto merge of #57747 - Centril:rollup, r=Centril
Rollup of 11 pull requests
Successful merges:
- #57107 (Add a regression test for mutating a non-mut #[thread_local])
- #57132 (Document that `-C opt-level=0` implies `-C debug-assertions`.)
- #57212 (docs(rustc): Link to the book's source in rustc)
- #57302 (Fix unused_assignments false positive)
- #57350 (Better error note on unimplemented Index trait for string)
- #57635 (use structured macro and path resolve suggestions)
- #57650 (librustc_metadata: Pass a default value when unwrapping a span)
- #57657 (Add regression test to close #53787)
- #57658 (Two HIR tweaks)
- #57720 (Fix suggestions given mulitple bad lifetimes)
- #57725 (Use structured suggestion to surround struct literal with parenthesis)
Rollup merge of #57650 - AB1908:master, r=petrochenkov
librustc_metadata: Pass a default value when unwrapping a span
Fixes #57323.
When compiling with `static-nobundle` a-la
`rustc -l static-nobundle=nonexistent main.rs`
we now get a neat output in the form of:
```
error[E0658]: kind="static-nobundle" is feature gated (see issue #37403)
|
= help: add #![feature(static_nobundle)] to the crate attributes to enable
error: aborting due to previous error
For more information about this error, try `rustc --explain E0658`.
```
The build and tests completed successfully on my machine. Should I be adding a new test?
Better error note on unimplemented Index trait for string
fixes #56740
I've tried to compile suggestion from comments in the issue #56740, but unsure of it. So I'm open to advice :)
Current output will be like this:
```rust
error[E0277]: the type `str` cannot be indexed by `{integer}`
--> $DIR/str-idx.rs:3:17
|
LL | let c: u8 = s[4]; //~ ERROR the type `str` cannot be indexed by `{integer}`
| ^^^^ `str` cannot be indexed by `{integer}`
|
= help: the trait `std::ops::Index<{integer}>` is not implemented for `str`
= note: you can use `.chars().nth()` or `.bytes().nth()`
see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
`x.py test src/test/ui` succeeded and I've also tested output manually by compiling the following code:
```rust
fn _f() {
let s = std::string::String::from("hello");
let _c = s[0];
let s = std::string::String::from("hello");
let mut _c = s[0];
let s = "hello";
let _c = s[0];
let s = "hello";
let mut _c = &s[0];
}
```
Not sure if some docs should be changed too. I will also fix error message in the [Book :: Indexing into Strings](https://github.com/rust-lang/book/blob/db53e2e3cdf77beac853df6f29db4b3b86ea598c/src/ch08-02-strings.md#indexing-into-strings) if that PR will get approved :)
Rollup merge of #57132 - daxpedda:master, r=steveklabnik
Document that `-C opt-level=0` implies `-C debug-assertions`.
I couldn't find it stated anywhere else (https://doc.rust-lang.org/nightly/rustc/codegen-options/index.html#opt-level).
It was a problem before here: https://github.com/rust-lang/rust/issues/39449, it got lost in the migration to the new documentation I assume.
On a sidenote: I think that `-C opt-level=0` having a sideeffect on another flag should be changed. Having compiler flags affecting others doesn't make much sense to me, they are used to fine tune anyway.
In any case, this plays no role in this PR.
bors [Fri, 18 Jan 2019 19:08:20 +0000 (19:08 +0000)]
Auto merge of #57737 - Centril:rollup, r=Centril
Rollup of 10 pull requests
Successful merges:
- #56594 (Remove confusing comment about ideally using `!` for `c_void`)
- #57340 (Use correct tracking issue for c_variadic)
- #57357 (Cleanup PartialEq docs.)
- #57551 (resolve: Add a test for issue #57539)
- #57636 (Fix sources sidebar not showing up)
- #57646 (Fixes text becoming invisible when element targetted)
- #57654 (Add some links in std::fs.)
- #57683 (Document Unpin in std::prelude documentation)
- #57685 (Enhance `Pin` impl applicability for `PartialEq` and `PartialOrd`.)
- #57710 (Fix non-clickable urls)
Rollup merge of #57685 - pthariensflame:enhancement/pin-impl-applicability, r=withoutboats
Enhance `Pin` impl applicability for `PartialEq` and `PartialOrd`.
This allows for comparing for equality or ordering a `Pin<P>` and a `Pin<Q>` as long as `P` and `Q` are correspondingly comparable themselves *even when `P` and `Q` are different types*.
An example might be comparing a `Pin<&mut OsString>` to a `Pin<&mut PathBuf>`, which might arise from pin projections from a pair of larger contexts that aren't `Unpin`.
Rollup merge of #57636 - GuillaumeGomez:fix-sources-sidebar, r=QuietMisdreavus
Fix sources sidebar not showing up
Fixes #57601.
The order of imports made it so that the sidebar creation was called before the sidebar sources were created. Like this, when the sources are loaded, they create the sidebar as expected.
Rollup merge of #57357 - frewsxcv:frewsxcv-partial-eq, r=QuietMisdreavus
Cleanup PartialEq docs.
- Cleanup the `impl PartialEq<BookFormat> for Book` implementation
- Implement `impl PartialEq<Book> for BookFormat` so it’s symmetric
- Fixes https://github.com/rust-lang/rust/issues/53844.
- Removes the last example since it appears to be redundant with the
previous two examples.
Rollup merge of #56594 - sdroege:c_void-is-not-never, r=TimNN
Remove confusing comment about ideally using `!` for `c_void`
Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.
In addition document that newtype wrappers around `c_void` can be used
safely in place of `extern type` until the latter is stabilized.
----
I'm not 100% sure about the usage for opaque types as the [nomicon](https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs) still recommends using `#[repr(C)] pub struct Foo { _private: [u8; 0] }` but it seems like these two should be equivalent in the end? Also the `#[repr(C)]` (in both cases) should be unneeded because such types never being passed by value, never being dereferenced but only passed around as pointer or reference, so the representation of (*values* of) the type itself should not matter at all?
Also in context of `c_void` and `!` the second unresolved question in the [`extern type`](https://github.com/rust-lang/rust/issues/43467) stabilization ticket seems relevant
> In [std's](https://github.com/rust-lang/rust/blob/164619a8cfe6d376d25bd3a6a9a5f2856c8de64d/src/libstd/os/raw.rs#L59-L64) source, it is mentioned that LLVM expects i8* for C's void*.
> We'd need to continue to hack this for the two c_voids in std and libc.
> But perhaps this should be done across-the-board for all extern types?
> Somebody should check what Clang does.
Please correct me if my understanding is wrong and everything's actually fine as is.
bors [Fri, 18 Jan 2019 16:18:11 +0000 (16:18 +0000)]
Auto merge of #56189 - rep-nop:keep_doc_test_executable, r=QuietMisdreavus
rustdoc: Add option to persist doc test executables
Fixes #37048.
This is the initial version of the code so the doctest executables can be used for stuff like code coverage (specifically https://github.com/xd009642/tarpaulin/issues/13) the folders it goes into were just a first idea, so any better ones are welcome.
Right now it creates a directory structure like:
```
given_path/
|_____ <filename>_rs_<linenum>/
|_____ ...
|_____ <filename>_rs_<linenum>/
|_____ rust_out
```
I couldn't figure out where it actually outputs the file w/ the name, I suspect its somewhere deeper in the compiler.
It also adds the unstable `--persist-doctests` flag to `rustdoc` that enables this behavior.
bors [Thu, 17 Jan 2019 05:00:14 +0000 (05:00 +0000)]
Auto merge of #57670 - rust-lang:beta-next, r=Mark-Simulacrum
Prepare beta 1.33.0
This PR includes the usual changes for a new beta, and suppresses a few lints on libcore: those lints are false positives caused by an internal attribute (`rustc_layout_scalar_valid_range_start`) and only happen on stage0.
bors [Wed, 16 Jan 2019 23:25:41 +0000 (23:25 +0000)]
Auto merge of #57392 - Xanewok:always-calc-glob-map, r=petrochenkov
Always calculate glob map but only for glob uses
Previously calculating glob map was *opt-in*, however it did record node id -> ident use for every use directive. This aims to see if we can unconditionally calculate the glob map and not regress performance.
Main motivation is to get rid of some of the moving pieces and simplify the compilation interface - this would allow us to entirely remove `CrateAnalysis`. Later, we could easily expose a relevant query, similar to the likes of `maybe_unused_trait_import` (so using precomputed data from the resolver, but which could be rewritten to be on-demand).
r? @nikomatsakis
Local perf run showed mostly noise (except `ctfe-stress-*`) but I'd appreciate if we could do a perf run run here and double-check that this won't regress performance.
bors [Wed, 16 Jan 2019 15:01:20 +0000 (15:01 +0000)]
Auto merge of #57321 - petrochenkov:atokens, r=nikomatsakis
Implement basic input validation for built-in attributes
Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax").
For some subset of attributes (found by crater run), errors are lowered to deprecation warnings.
NOTE: This PR previously included https://github.com/rust-lang/rust/pull/57367 as well.
bors [Wed, 16 Jan 2019 12:15:10 +0000 (12:15 +0000)]
Auto merge of #57416 - alexcrichton:remove-platform-intrinsics, r=nagisa
rustc: Remove platform intrinsics crate
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
Use `Lit` rather than `P<Lit>` in `hir::ExprKind`.
It's simpler and makes some benchmark run up to 1% faster. It also makes
`hir::ExprKind` more like `ast::ExprKind` (which underwent the
equivalent change in #55777).
Changes:
````
Really fix issue number in `map_clone` test
Fix issue number in `map_clone` test
Remove `map_clone` fixed known problem
Fix `map_clone` bad suggestion
Add run-rustfix to unnecessary_fold
Add run-rustfix to unit_arg test
Add run-rustfix for types test
Add run-rustfix to starts_ends_with
Add run-rustfix to replace_const test
Add run-rustfix to redundant_field_names
Missing docs: don't require documenting Global Asm items.
Add run-rustfix for precedence test
Add run-rustfix to mem_replace test
Add run-rustfix to map_clone test
Add run-rustfix to large_digit_groups
Add run-rustfix to into_iter_on_ref
Add run-rustfix to infallible_destructuring_match
Add rustfix to inconsistent_digit_grouping test
Add run-rustfix to explicit_write test
Add run-rustfix to excessive_precision test
Add run-rustfix to duration_subsec test
Disable deprecated_cfg_attr lint for inner attributes
Add run-rustfix to collapsible_if test
Update Readme
Update Readme for (arguably) better readability
rustup: the features if_while_or_patterns has been stabilized
Fix comments in clippy_lints/src/len_zero.rs
readme: update travis badge to reflect migration from travis-ci.org to travis-ci.com
Remove all copyright license headers
Move cast_ref_to_mut list to correctness group
Rustftmt
Don't import ty::Ref in cast_ref_to_mut lint
Move a hint to an error message in cast_ref_to_mut lint
Add a note to cast_ref_to_mut lint
Use ty::Ref instead of ty::TyKind::Ref
cast_ref_to_mut lint
Add missing ` in default lint
Improve tests and exclude nested impls
Update `unwrap_get` code review suggestions
Update known problems
Restrict use_self on nested items
Improve `get_unwrap` suggestion
````
Rollup merge of #57614 - GuillaumeGomez:fix-crate-filtering, r=QuietMisdreavus
[rustdoc] Fix crates filtering box not being filled
Currently, the filter crate box (at the left of the search input) is always empty. To get the number of keys of dictionary in JS, you need to call `Object.keys()` on it.
Rollup merge of #57608 - timvisee:master, r=frewsxcv
Simplify 'product' factorial example
This simplifies the [`factorial(n: 32)`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#examples-46) implementation as example for the `Iterator::product()` function.
It currently uses unnecessary additional complexity.
Although very minimal, I do not want to include it in some other irrelevant PR.
Rollup merge of #57579 - stjepang:once-with, r=SimonSapin
Add core::iter::once_with()
Functions `iter::once()` and `iter::repeat()` construct iterators from values. The latter has the lazy variant `iter::repeat_with()`, but the former doesn't. This PR therefore adds `iter::once_with()`.
Another way to think of `iter::once_with()` is that it's a function that converts `FnOnce() -> T` into `Iterator<Item = T>`.
If this seems like a reasonable addition, I'll open a tracking issue and update the `#[feature(...)]` attributes.
Rollup merge of #57352 - arielb1:no-manual-markers, r=nikomatsakis
forbid manually impl'ing one of an object type's marker traits
This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.
Prior to 1.12.0 we dropped both `_x` and `_y` before the rest of their
respective parameters, since then we dropped `_x` and `_y` after. The
original order appears to be the correct order, as the value created
later is dropped first, so we revert to that order and add a test for
it.
While this is technically a breaking change, I can't work out how
anyone could be relying on this without making their code very
brittle. If this is considered to be too likely to break real world code
then I can revert the change and change the test to check for the
current order.
Changes:
````
Really fix issue number in `map_clone` test
Fix issue number in `map_clone` test
Remove `map_clone` fixed known problem
Fix `map_clone` bad suggestion
Add run-rustfix to unnecessary_fold
Add run-rustfix to unit_arg test
Add run-rustfix for types test
Add run-rustfix to starts_ends_with
Add run-rustfix to replace_const test
Add run-rustfix to redundant_field_names
Missing docs: don't require documenting Global Asm items.
Add run-rustfix for precedence test
Add run-rustfix to mem_replace test
Add run-rustfix to map_clone test
Add run-rustfix to large_digit_groups
Add run-rustfix to into_iter_on_ref
Add run-rustfix to infallible_destructuring_match
Add rustfix to inconsistent_digit_grouping test
Add run-rustfix to explicit_write test
Add run-rustfix to excessive_precision test
Add run-rustfix to duration_subsec test
Disable deprecated_cfg_attr lint for inner attributes
Add run-rustfix to collapsible_if test
Update Readme
Update Readme for (arguably) better readability
rustup: the features if_while_or_patterns has been stabilized
Fix comments in clippy_lints/src/len_zero.rs
readme: update travis badge to reflect migration from travis-ci.org to travis-ci.com
Remove all copyright license headers
Move cast_ref_to_mut list to correctness group
Rustftmt
Don't import ty::Ref in cast_ref_to_mut lint
Move a hint to an error message in cast_ref_to_mut lint
Add a note to cast_ref_to_mut lint
Use ty::Ref instead of ty::TyKind::Ref
cast_ref_to_mut lint
Add missing ` in default lint
Improve tests and exclude nested impls
Update `unwrap_get` code review suggestions
Update known problems
Restrict use_self on nested items
Improve `get_unwrap` suggestion
````
projects / rust.git / log