bors [Mon, 8 Feb 2021 10:46:10 +0000 (10:46 +0000)]
Auto merge of #81313 - LeSeulArtichaut:revert-32558, r=jyn514
Restore linking to itself in implementors section of trait page
Reverts #32558 as proposed in [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Trait.20implementation.20self-links/near/223773273)
r? `@jyn514` cc `@camelid`
bors [Mon, 8 Feb 2021 07:56:04 +0000 (07:56 +0000)]
Auto merge of #79245 - ssomers:btree_curb_ord_bound, r=dtolnay
BTree: remove Ord bound where it is absent elsewhere
Some btree methods don't really need an Ord bound and don't have one, while some methods that more obviously don't need it, do have one.
An example of the former is `iter`, even though it explicitly exposes the work of the Ord implementation (["sorted by key"](https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.iter) - but I'm not suggesting it should have the Ord bound). An example of the latter is `new`, which doesn't involve any keys whatsoever.
These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations, and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below, it seems best practice is to stabilize the intrinsics. As such, `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable.
I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly, the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such, I believe these methods are ready to be stabilized as `const fn`.
This pull request represents the final methods mentioned in #53718. As such, this PR closes #53718.
bors [Mon, 8 Feb 2021 02:23:17 +0000 (02:23 +0000)]
Auto merge of #72603 - jsgf:extern-loc, r=nikomatsakis
Implement `--extern-location`
This PR implements `--extern-location` as a followup to #72342 as part of the implementation of #57274. The goal of this PR is to allow rustc, in coordination with the build system, to present a useful diagnostic about how to remove an unnecessary dependency from a dependency specification file (eg Cargo.toml).
EDIT: Updated to current PR state.
The location is specified for each named crate - that is, for a given `--extern foo[=path]` there can also be `--extern-location foo=<location>`. It supports ~~three~~ two styles of location:
~~1. `--extern-location foo=file:<path>:<line>` - a file path and line specification
1. `--extern-location foo=span:<path>:<start>:<end>` - a span specified as a file and start and end byte offsets~~
1. `--extern-location foo=raw:<anything>` - a raw string which is included in the output
1. `--extern-location foo=json:<anything>` - an arbitrary Json structure which is emitted via Json diagnostics in a `tool_metadata` field.
~~1 & 2 are turned into an internal `Span`, so long as the path exists and is readable, and the location is meaningful (within the file, etc). This is used as the `Span` for a fix suggestion which is reported like other fix suggestions.~~
`raw` and `json` are for the case where the location isn't best expressed as a file and location within that file. For example, it could be a rule name and the name of a dependency within that rule. `rustc` makes no attempt to parse the raw string, and simply includes it in the output diagnostic text. `json` is only included in json diagnostics. `raw` is emitted as text and also as a json string in `tool_metadata`.
If no `--extern-location` option is specified then it will emit a default json structure consisting of `{"name": name, "path": path}` corresponding to the name and path in `--extern name=path`.
This is a prototype/RFC to make some of the earlier conversations more concrete. It doesn't stand on its own - it's only useful if implemented by Cargo and other build systems. There's also a ton of implementation details which I'd appreciate a second eye on as well.
~~**NOTE** The first commit in this PR is #72342 and should be ignored for the purposes of review. The first commit is a very simplistic implementation which is basically raw-only, presented as a MVP. The second implements the full thing, and subsequent commits are incremental fixes.~~
...so we can skip serializing `tool_metadata` if it hasn't been set.
This makes the output a bit cleaner, and avoiding having to update a
bunch of unrelated tests.
Add `--extern-loc` to augment unused crate dependency diagnostics
This allows a build system to indicate a location in its own dependency
specification files (eg Cargo's `Cargo.toml`) which can be reported
along side any unused crate dependency.
This supports several types of location:
- 'json' - provide some json-structured data, which is included in the json diagnostics
in a `tool_metadata` field
- 'raw' - emit the provided string into the output. This also appears as a json string in
`tool_metadata`.
If no `--extern-location` is explicitly provided then a default json entry of the form
`"tool_metadata":{"name":<cratename>,"path":<cratepath>}` is emitted.
bors [Sun, 7 Feb 2021 22:25:14 +0000 (22:25 +0000)]
Auto merge of #80652 - calebzulawski:simd-lanes, r=nagisa
Improve SIMD type element count validation
Resolves rust-lang/stdsimd#53.
These changes are motivated by `stdsimd` moving in the direction of const generic vectors, e.g.:
```rust
#[repr(simd)]
struct SimdF32<const N: usize>([f32; N]);
```
This makes a few changes:
* Establishes a maximum SIMD lane count of 2^16 (65536). This value is arbitrary, but attempts to validate lane count before hitting potential errors in the backend. It's not clear what LLVM's maximum lane count is, but cranelift's appears to be much less than `usize::MAX`, at least.
* Expands some SIMD intrinsics to support arbitrary lane counts. This resolves the ICE in the linked issue.
* Attempts to catch invalid-sized vectors during typeck when possible.
Unresolved questions:
* Generic-length vectors can't be validated in typeck and are only validated after monomorphization while computing layout. This "works", but the errors simply bail out with no context beyond the name of the type. Should these errors instead return `LayoutError` or otherwise provide context in some way? As it stands, users of `stdsimd` could trivially produce monomorphization errors by making zero-length vectors.
bors [Sun, 7 Feb 2021 19:36:10 +0000 (19:36 +0000)]
Auto merge of #79078 - petrochenkov:derattr, r=Aaron1011
expand/resolve: Turn `#[derive]` into a regular macro attribute
This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros`, like it was previously done with other "active" attributes in https://github.com/rust-lang/rust/pull/62086, https://github.com/rust-lang/rust/pull/62735 and other PRs.
This PR is also a continuation of #65252, #69870 and other PRs linked from them, which layed the ground for converting `#[derive]` specifically.
`#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)`, and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later), but otherwise `#[derive]` is treated as any other macro attributes, which simplifies the resolution-expansion infra pretty significantly.
The change has several observable effects on language and library.
Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119).
#### Library
- `derive` is now available through standard library as `{core,std}::prelude::v1::derive`.
#### Language
- `derive` now goes through name resolution, so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`.
- `derive` now goes through name resolution, so this resolution can fail in corner cases. Crater found one such regression, where import `use foo as derive` goes into a cycle with `#[derive(Something)]`.
- **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change, non-macro attributes following `#[derive]` were treated in the same way previously).
- `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference, except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope, but previously both `Foo` and `Bar` were required to be resolved before expanding any of them.
- **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input, eagerly evaluating `cfg` everywhere in its target, for example on fields.
Expansion infra doesn't do that for other attributes, but now when macro attributes attributes are allowed to be written after `#[derive]`, it means that derive can *fully configure* items for them.
```rust
#[derive()]
#[my_attr]
struct S {
#[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]`
field: u8
}
```
- `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past, but was warned about since early 2018 (#50092), despite that crater found a few such cases in unmaintained crates.
- Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization, https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033), but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202.
```rust
#[trait_helper] // warning: derive helper attribute is used before it is introduced
#[derive(Trait)]
struct S {}
```
bors [Sun, 7 Feb 2021 16:48:57 +0000 (16:48 +0000)]
Auto merge of #80632 - Nadrieril:fix-80501, r=varkor
Identify unreachable subpatterns more reliably
In https://github.com/rust-lang/rust/pull/80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In https://github.com/rust-lang/rust/issues/80501 it was revealed that `Span`s are complicated and that this was not a good idea.
Instead, this PR identifies subpatterns logically: as a path in the tree of subpatterns of a given pattern. I made a struct that captures a set of such subpatterns. This is a bit complex, but thankfully self-contained; the rest of the code does not need to know anything about it.
Fixes https://github.com/rust-lang/rust/issues/80501. I think I managed to keep the perf neutral.
bors [Sun, 7 Feb 2021 13:57:24 +0000 (13:57 +0000)]
Auto merge of #81853 - GuillaumeGomez:rollup-xzh1z4v, r=GuillaumeGomez
Rollup of 5 pull requests
Successful merges:
- #81526 (btree: use Option's unwrap_unchecked())
- #81742 (Add a note about the correctness and the effect on unsafe code to the `ExactSizeIterator` docs)
- #81830 (Add long error explanation for E0542)
- #81835 (Improve long explanation for E0546)
- #81843 (Add regression test for #29821)
bors [Sun, 7 Feb 2021 02:36:08 +0000 (02:36 +0000)]
Auto merge of #81821 - nikic:update-wasm32, r=sanxiyn
Upgrade wasm32 image to Ubuntu 20.04
This switches the wasm32 image, which is used to test
wasm32-unknown-emscripten, to Ubuntu 20.04. While at it, enable
most of the excluded tests, as they seem to work fine with some
minor fixes.
bors [Sat, 6 Feb 2021 20:55:36 +0000 (20:55 +0000)]
Auto merge of #80883 - GuillaumeGomez:remove-some-function-fields, r=ollie27
Remove some function fields
Same kind as #80845.
This PR removes the `all_types` and `ret_types` from the `clean::Function` type.
Another change that I had to do was implementing the `From` trait to be able to convert `hir::def::DefKind` into `clean::TypeKind` without requiring `DocContext` (and so I updated the `clean` method so that it's taken into account).
The last two commits improve a bit the `get_real_types` function and the `Type::generics` method.
Jonas Schievink [Sat, 6 Feb 2021 16:01:52 +0000 (17:01 +0100)]
Rollup merge of #81812 - nagisa:nagisa/escape-the-escape-hatch, r=Amanieu
Add a test for escaping LLVMisms in inline asm
We escape certain LLVM-specific features when passing the inline
assembly string to the LLVM. Until now, however, there was no test
making sure this behaviour stays intact. This commit adds such a test!
Jonas Schievink [Sat, 6 Feb 2021 16:01:45 +0000 (17:01 +0100)]
Rollup merge of #81680 - camsteffen:primty, r=oli-obk
Refactor `PrimitiveTypeTable` for Clippy
I removed `PrimitiveTypeTable` and added `PrimTy::ALL` and `PrimTy::from_name` in its place. This allows Clippy to use `PrimTy::from_name` for the `builtin_type_shadow` lint, and a `const` list of primitive types is deleted from Clippy code (the goal). All changes should be a little faster, if anything.
Jonas Schievink [Sat, 6 Feb 2021 16:01:42 +0000 (17:01 +0100)]
Rollup merge of #81402 - ehuss:md-tidy, r=jyn514
tidy: Run tidy style against markdown files.
This adds tidy checks for markdown files. I think it is useful to have some style enforcement (for the same reasons the style is enforced on other files). I think it is worthwhile to avoid `ignore` on rust examples since having broken code in documentation is frustrating. Avoiding trailing whitespace is good because it has semantic meaning in markdown, which I think should be avoided.
We escape certain LLVM-specific features when passing the inline
assembly string to the LLVM. Until now, however, there was no test
making sure this behaviour stays intact. This commit adds such a test!
Nikita Popov [Fri, 5 Feb 2021 14:52:49 +0000 (15:52 +0100)]
Upgrade wasm32 image to Ubuntu 20.04
This switches the wasm32 image, which is used to test
wasm32-unknown-emscripten to Ubuntu 20.04. While at it, enable
most of the excluded tests, as they seem to work fine with some
minor fixes.
bors [Sat, 6 Feb 2021 04:55:09 +0000 (04:55 +0000)]
Auto merge of #81810 - m-ou-se:rollup-q3nborp, r=m-ou-se
Rollup of 7 pull requests
Successful merges:
- #80011 (Stabilize `peekable_next_if`)
- #81580 (Document how `MaybeUninit<Struct>` can be initialized.)
- #81610 (BTreeMap: make Ord bound explicit, compile-test its absence)
- #81664 (Avoid a hir access inside get_static)
- #81675 (Make rustdoc respect `--error-format short` in doctests)
- #81753 (Never MIR inline functions with a different instruction set)
- #81795 (Small refactor with Iterator::reduce)
Mara Bos [Fri, 5 Feb 2021 23:14:11 +0000 (00:14 +0100)]
Rollup merge of #81610 - ssomers:btree_emphasize_ord_bound, r=dtolnay
BTreeMap: make Ord bound explicit, compile-test its absence
Most `BTreeMap` and `BTreeSet` members are subject to an `Ord` bound but a fair number of methods are not. To better convey and perhaps later tune the `Ord` bound, make it stand out in individual `where` clauses, instead of once far away at the beginning of an `impl` block. This PR does not introduce or remove any bounds.
Also adds compilation test cases checking that the bound doesn't creep in unintended on the historically unbounded methods.
bors [Fri, 5 Feb 2021 22:58:13 +0000 (22:58 +0000)]
Auto merge of #79253 - rcvalle:fix-rustc-sysroot-cas, r=nagisa
Fix rustc sysroot in systems using CAS
Change filesearch::get_or_default_sysroot() to check if sysroot is found using env::args().next() if rustc in argv[0] is a symlink; otherwise, or if it is not found, use env::current_exe() to imply sysroot. This makes the rustc binary able to locate Rust libraries in systems using content-addressable storage (CAS).
bors [Fri, 5 Feb 2021 12:11:05 +0000 (12:11 +0000)]
Auto merge of #81784 - m-ou-se:rollup-s23fow7, r=m-ou-se
Rollup of 15 pull requests
Successful merges:
- #79554 (Generic associated types in trait paths)
- #80726 (relax adt unsizing requirements)
- #81307 (Handle `Span`s for byte and raw strings and add more detail )
- #81318 (rustdoc-json: Fix has_body)
- #81456 (Make remote-test-server easier to use with new targets)
- #81497 (rustdoc: Move `display_fn` struct inside `display_fn`)
- #81500 (Remove struct_type from union output)
- #81542 (Expose correct symlink API on WASI)
- #81676 (Add more information to the error code for 'crate not found')
- #81682 (Add additional bitset benchmarks)
- #81730 (Make `Allocator` object-safe)
- #81763 (Cleanup rustdoc pass descriptions a bit)
- #81767 (Update LayoutError/LayoutErr stability attributes)
- #81771 (Indicate change in RSS from start to end of pass in time-passes output)
- #81781 (Fix `install-awscli.sh` error in CI)
Mara Bos [Fri, 5 Feb 2021 11:26:06 +0000 (12:26 +0100)]
Rollup merge of #81763 - camelid:rustdoc-passes-desc-up, r=GuillaumeGomez
Cleanup rustdoc pass descriptions a bit
Also changed a couple of comments from "intra-doc-links" to
"intra-doc links" (my understanding is that "intra-doc links" is the
standard way to refer to them).
Mara Bos [Fri, 5 Feb 2021 11:26:03 +0000 (12:26 +0100)]
Rollup merge of #81682 - JulianKnodt:bit_set_iter_benchmarks, r=oli-obk
Add additional bitset benchmarks
Add additional benchmarks for operations in bitset, I realize that it was a bit lacking when I intended to optimize it earlier, so I was hoping to put some in so I can verify my work later.
Mara Bos [Fri, 5 Feb 2021 11:26:00 +0000 (12:26 +0100)]
Rollup merge of #81542 - RReverser:wasi-symlink, r=alexcrichton
Expose correct symlink API on WASI
As described in https://github.com/rust-lang/rust/issues/68574, the currently exposed API for symlinks is, in fact, a thin wrapper around the corresponding syscall, and not suitable for public usage.
The reason is that the 2nd param in the call is expected to be a handle of a "preopened directory" (a WASI concept for exposing dirs), and the only way to retrieve such handle right now is by tinkering with a private `__wasilibc_find_relpath` API, which is an implementation detail and definitely not something we want users to call directly.
Making matters worse, the semantics of this param aren't obvious from its name (`fd`), and easy to misinterpret, resulting in people trying to pass a handle of the target file itself (as in https://github.com/vitiral/path_abs/pull/50), which doesn't work as expected.
I did a [codesearch among open-source repos](https://sourcegraph.com/search?q=std%3A%3Aos%3A%3Awasi%3A%3Afs%3A%3Asymlink&patternType=literal), and the usage above is so far the only usage of this API at all, but we should fix it before more people start using it incorrectly.
While this is technically a breaking API change, I believe it's a justified one, as 1) it's OS-specific and 2) there was strictly no way to correctly use the previous form of the API, and if someone does use it, they're likely doing it wrong like in the example above.
The new API does not lead to the same confusion, as it mirrors `std::os::unix::fs::symlink` and `std::os::windows::fs::symlink_{file,dir}` variants by accepting source/target paths.
Mara Bos [Fri, 5 Feb 2021 11:25:59 +0000 (12:25 +0100)]
Rollup merge of #81500 - CraftSpider:union-kind, r=jyn514
Remove struct_type from union output
Also bumps the format number and adds a test
Rationale: It's illegal to have unions of the form `union Union(i32, f32);`, or `union Union;`. The struct_type field was recently removed from the rustdoc Union AST, at which time this field was changed to always just read "union". It makes sense to completely remove it, as it provides no information.
This makes it clear that it's an implementation detail of `display_fn`
and shouldn't be used elsewhere, and it enforces in the compiler that no
one else can use it.
Mara Bos [Fri, 5 Feb 2021 11:25:56 +0000 (12:25 +0100)]
Rollup merge of #81456 - Amanieu:remote-test-server, r=Amanieu
Make remote-test-server easier to use with new targets
While testing #81455 I encountered 2 issues with `remote-test-server`:
- It is built with the stage 0 toolchain, which does not support a newly added target.
- It overwrites `LD_LIBRARY_PATH` instead of appending to it, which prevents the use of a custom sysroot for target libraries.
Mara Bos [Fri, 5 Feb 2021 11:25:52 +0000 (12:25 +0100)]
Rollup merge of #80726 - lcnr:unsize-query, r=oli-obk
relax adt unsizing requirements
Changes unsizing of structs in case the last struct field shares generic params with other adt fields which do not change.
This change is currently insta stable and changes the language, so it at least requires a lang fcp. I feel like the current state is fairly unintuitive.
An example for what's now allowed would be https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6dd331d23f5c9ffc8c978175aae2e967
```rust
struct A<T, U: ?Sized>(T, B<T, U>); // previously ERR
// struct A<T, U: ?Sized>(T, B<[u32; 1], U>); // ok
struct B<T, U: ?Sized>(T, U);
fn main() {
let x = A([0; 1], B([0; 1], [0; 1]));
let y: &A<[u32; 1], [u32]> = &x;
assert_eq!(y.1.1.len(), 1);
}
```
bors [Fri, 5 Feb 2021 09:20:51 +0000 (09:20 +0000)]
Auto merge of #81736 - tgnottingham:tune-cgu-scheduling-for-memory, r=nagisa
rustc_codegen_ssa: tune codegen scheduling to reduce memory usage
For better throughput during parallel processing by LLVM, we used to sort
CGUs largest to smallest. This would lead to better thread utilization
by, for example, preventing a large CGU from being processed last and
having only one LLVM thread working while the rest remained idle.
However, this strategy would lead to high memory usage, as it meant the
LLVM-IR for all of the largest CGUs would be resident in memory at once.
Instead, we can compromise by ordering CGUs such that the largest and
smallest are first, second largest and smallest are next, etc. If there
are large size variations, this can reduce memory usage significantly.
projects / rust.git / log