Guillaume Gomez [Sun, 22 Nov 2020 15:15:10 +0000 (16:15 +0100)]
Rollup merge of #78670 - sasurau4:test/check-pass-incremental, r=jyn514
Remove FIXME comment in some incremental test suite
Helps with #62277
I removed FIXME comment in some incremental tests with [rustc_partition_codegened](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_incremental/assert_module_sources/index.html). This seems using codegen process. So it uses intentionally `build-pass`
bors [Sun, 22 Nov 2020 08:30:23 +0000 (08:30 +0000)]
Auto merge of #79275 - integer32llc:doc-style, r=jonas-schievink
More consistently use spaces after commas in lists in docs
This PR changes instances of lists that didn't use spaces after commas, like `vec![1,2,3]`, to `vec![1, 2, 3]` to be more consistent with idiomatic Rust style (the way these were looks strange to me, especially because there are often lists that *do* use spaces after the commas later in the same code block 😬).
I noticed one of these in an example in the stdlib docs and went looking for more, but as far as I can see, I'm only changing those spots in user-facing documentation or rustc output, and the changes make no semantic difference.
- Should this be opt-in instead of on by default?
+ No
- Should this call through to `delta`? That's not a very common program to have installed, but I'm not sure how to do diffs after the fact. Maybe `compiletest` can take a `--syntax-highlighter` parameter or something?
+ I decided to use `delta` if available and `diff --color` otherwise. It prints a warning if delta isn't installed so you know you can get nicer diffs
## Open questions.
- What version of rustdoc would this compare against? Ideally it would compare against `$(git merge-base HEAD origin/master)` - maybe that's feasible if we install those artifacts from CI?
- Does it always make sense to compare the tests? Especially for new tests, I'm not sure how useful it would be ... but then again, one of the questions I want to know most as a reviewer is 'did it break before?'.
bors [Sat, 21 Nov 2020 20:18:11 +0000 (20:18 +0000)]
Auto merge of #79273 - Dylan-DPC:rollup-zd10xlt, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #77844 (clarify rules for ZST Boxes)
- #79067 (Refactor the abi handling code a bit)
- #79182 (Fix links to extern types in rustdoc (fixes #78777))
- #79231 (Exhaustively match in variant count instrinsic)
- #79238 (Direct RUSTC_LOG (tracing/log) output to stderr instead of stdout.)
- #79256 (Fix typos)
- #79264 (Get rid of some doctree items)
- #79272 (Support building clone shims for arrays with generic size)
Dylan DPC [Sat, 21 Nov 2020 18:44:15 +0000 (19:44 +0100)]
Rollup merge of #79238 - eddyb:rustc-log-stderr, r=jyn514
Direct RUSTC_LOG (tracing/log) output to stderr instead of stdout.
Looks like this got missed in the initial implementation, AFAIK the old behavior was to output on stderr.
(Hit this while trying to debug `rustc` running inside a build script which was only letting stderr through)
Dylan DPC [Sat, 21 Nov 2020 18:44:11 +0000 (19:44 +0100)]
Rollup merge of #79182 - lochsh:78777-fix-extern-types-ref, r=jyn514
Fix links to extern types in rustdoc (fixes #78777)
r? `@jyn514`
Fixes #78777.
The initial fix we tried was:
```diff
diff --git a/src/librustdoc/passes/collect_intra_doc_links.rs b/src/librustdoc/passes/collect_intra_doc_links.rs
index 8be9482acff..c4b7086fdb1 100644
--- a/src/librustdoc/passes/collect_intra_doc_links.rs
+++ b/src/librustdoc/passes/collect_intra_doc_links.rs
`@@` -433,8 +433,9 `@@` impl<'a, 'tcx> LinkCollector<'a, 'tcx> {
Res::PrimTy(prim) => Some(
self.resolve_primitive_associated_item(prim, ns, module_id, item_name, item_str),
),
- Res::Def(DefKind::Struct | DefKind::Union | DefKind::Enum | DefKind::TyAlias, did) => {
+ Res::Def(kind, did) if kind.ns() == Some(Namespace::TypeNS) => {
debug!("looking for associated item named {} for item {:?}", item_name, did);
+
// Checks if item_name belongs to `impl SomeItem`
let assoc_item = cx
.tcx
```
However, this caused traits to be matched, resulting in a panic when `resolve_associated_trait_item` is called further down in this function.
This PR also adds an error message for that panic. Currently it will look something like:
```rust
thread 'rustc' panicked at 'Not a type: DefIndex(8624)', compiler/rustc_metadata/src/rmeta/decoder.rs:951:32
```
I wasn't sure how to get a better debug output than `DefIndex(...)`, and am open to suggestions.
Dylan DPC [Sat, 21 Nov 2020 18:44:07 +0000 (19:44 +0100)]
Rollup merge of #77844 - RalfJung:zst-box, r=nikomatsakis
clarify rules for ZST Boxes
LLVM's rules around `getelementptr inbounds` with offset 0 are a bit annoying, and as a consequence we have no choice but say that a `Box<()>` pointing to previously allocated memory that has since been freed is UB. Clarify the docs to reflect this.
This is based on conversations on the LLVM mailing list.
* Here's my initial mail: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130452.html
* The first email of the March part of that thread: https://lists.llvm.org/pipermail/llvm-dev/2019-March/130831.html
* First email of the April part: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131693.html
The conclusion for me at least was that `getelementptr inbounds` with offset 0 is *not* the identity function, but can sometimes return `poison` even when the input is a regular pointer -- specifically, it returns `poison` when this pointer points into something that LLVM "knows has been deallocated", i.e., a former LLVM-managed allocation. It is however the identity function on pointers obtained by casting integers.
Note that there [are formal proposals](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf) for LLVM semantics where `getelementptr inbounds` with offset 0 isn't quite the identity function but never returns `poison` (it affects the provenance of the pointer but in a way that doesn't matter if this pointer is never used for memory accesses), and indeed this is likely necessary to consistently describe LLVM semantics. But with the informal LLVM LangRef that we have right now, and with LLVM devs insisting otherwise, it seems unwise to rely on this.
bjorn3 [Sat, 14 Nov 2020 18:16:43 +0000 (19:16 +0100)]
Remove StructRet arg attr
It is applied exactly when the return value has an indirect pass mode.
Except for InReg on x86 fastcall, arg attrs are now only used for
optimization purposes and thus are fine to ignore.
bors [Sat, 21 Nov 2020 18:05:07 +0000 (18:05 +0000)]
Auto merge of #79237 - alexcrichton:update-backtrace, r=Mark-Simulacrum
std: Update the bactrace crate submodule
This commit updates the `library/backtrace` submodule which primarily
pulls in support for split-debuginfo on macOS, avoiding the need for
`dsymutil` to get run to get line numbers and filenames in backtraces.
bors [Sat, 21 Nov 2020 15:43:09 +0000 (15:43 +0000)]
Auto merge of #79115 - cuviper:rust-description, r=Mark-Simulacrum
x.py: allow a custom string appended to the version
This adds `rust.description` to the config as a descriptive string to be
appended to `rustc --version` output, which is also used in places like
debuginfo `DW_AT_producer`. This may be useful for supplementary build
information, like distro-specific package versions.
For example, in Fedora 33, `gcc --version` outputs:
As suggested by `@m-ou-se` in https://github.com/rust-lang/rust/issues/70758#issuecomment-726838099 this implements `slice::fill_with` as a counterpart to `slice::fill`. This mirrors `Vec::resize` and `Vec::resize_with`. Thanks!
bors [Sat, 21 Nov 2020 05:52:16 +0000 (05:52 +0000)]
Auto merge of #79003 - petrochenkov:innertest, r=estebank
rustc_expand: Mark inner `#![test]` attributes as soft-unstable
Custom inner attributes are feature gated (https://github.com/rust-lang/rust/issues/54726) except for attributes having name `test` literally, which are not gated for historical reasons.
`#![test]` is an inner proc macro attribute, so it has all the issues described in https://github.com/rust-lang/rust/issues/54726 too.
This PR gates it with the `soft_unstable` lint.
bors [Sat, 21 Nov 2020 01:30:26 +0000 (01:30 +0000)]
Auto merge of #78588 - HeroicKatora:sccc, r=nikomatsakis
Reworks Sccc computation to iteration instead of recursion
Linear graphs, producing as many scc's as nodes, would recurse once for every node when entered from the start of the list. This adds a test that exhausted the stack at least on my machine with error:
```
thread 'graph::scc::tests::test_deep_linear' has overflowed its stack
fatal runtime error: stack overflow
```
This may or may not be connected to #78567. I was only reminded that I started this rework some time ago. It might be plausible as borrow checking a long function with many borrow regions around each other—((((((…))))))— may produce the linear list setup to trigger this stack overflow ? I don't know enough about borrow check to say for sure.
This is best read in two separate commits. The first addresses only `find_state` internally. This is classical union phase from union-find. There's also a common solution of using the parent pointers in the (virtual) linked list to track the backreferences while traversing upwards and then following them backwards in a second path compression phase.
The second is more involved as it rewrites the mutually recursive `walk_node` and `walk_unvisited_node`. Firstly, the caller is required to handle the unvisited case of `walk_node` so a new `start_walk_from` method is added to handle that by walking the unvisited node if necessary. Then `walk_unvisited_node`, where we would previously recurse into in the missing case, is rewritten to construct a manual stack of its frames. The state fields consist of the previous stack slots.
bors [Fri, 20 Nov 2020 23:21:34 +0000 (23:21 +0000)]
Auto merge of #78569 - bugadani:arena-spec, r=Mark-Simulacrum
Arena: use specialization to avoid copying data
In several cases, a `Vec` or `SmallVec` is passed to `Arena::alloc_from_iter` directly. This PR makes sure those cases don't copy their data unnecessarily, by specializing the `alloc_from_iter` implementation.
Alex Crichton [Fri, 20 Nov 2020 17:12:14 +0000 (09:12 -0800)]
std: Update the backtrace crate submodule
This commit updates the `library/backtrace` submodule which primarily
pulls in support for split-debuginfo on macOS, avoiding the need for
`dsymutil` to get run to get line numbers and filenames in backtraces.
bors [Fri, 20 Nov 2020 16:12:35 +0000 (16:12 +0000)]
Auto merge of #78104 - ssomers:btree_root_redux, r=Mark-Simulacrum
BTreeMap: replace Root with NodeRef<Owned, ...>
`NodeRef<marker::Owned, …>` already exists as a representation of root nodes, and it makes more sense to alias `Root` to that than to reuse the space-efficient `BoxedNode` that is oblivious to height, where height is required.
bors [Fri, 20 Nov 2020 06:01:49 +0000 (06:01 +0000)]
Auto merge of #79192 - tmiasko:naked-noinline, r=oli-obk
Never inline naked functions
The `#[naked]` attribute disabled prologue / epilogue emission for the
function and it is responsibility of a developer to provide them. The
compiler is no position to inline such functions correctly.
Disable inlining of naked functions at LLVM and MIR level.
bors [Fri, 20 Nov 2020 03:40:20 +0000 (03:40 +0000)]
Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint, r=estebank
Add lint for panic!("{}")
This adds a lint that warns about `panic!("{}")`.
`panic!(msg)` invocations with a single argument use their argument as panic payload literally, without using it as a format string. The same holds for `assert!(expr, msg)`.
This lints checks if `msg` is a string literal (after expansion), and warns in case it contained braces. It suggests to insert `"{}", ` to use the message literally, or to add arguments to use it as a format string.
This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later, once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.
bors [Fri, 20 Nov 2020 00:51:54 +0000 (00:51 +0000)]
Auto merge of #79220 - Dylan-DPC:rollup-5bpbygd, r=Dylan-DPC
Rollup of 11 pull requests
Successful merges:
- #79119 (Clarify availability of atomic operations)
- #79123 (Add u128 and i128 integer tests)
- #79177 (Test drop order for (destructuring) assignments)
- #79181 (rustdoc: add [src] links to methods on a trait's page)
- #79183 (Make compiletest testing use the local sysroot)
- #79185 (expand/resolve: Pre-requisites to "Turn `#[derive]` into a regular macro attribute")
- #79193 (Revert #78969 "Normalize function type during validation")
- #79194 (Make as{_mut,}_slice on array::IntoIter public)
- #79204 (Add jyn514 email alias to mailmap)
- #79212 (Move `rustc_ty` -> `rustc_ty_utils`)
- #79217 (Add the "memcpy" doc alias to slice::copy_from_slice)
Tomasz MiÄ…sko [Fri, 20 Nov 2020 00:00:00 +0000 (00:00 +0000)]
Never inline naked functions
The `#[naked]` attribute disabled prologue / epilogue emission for the
function and it is responsibility of a developer to provide them. The
compiler is no position to inline such functions correctly.
Disable inlining of naked functions at LLVM and MIR level.
Dylan DPC [Thu, 19 Nov 2020 22:58:50 +0000 (23:58 +0100)]
Rollup merge of #79217 - yoshuawuyts:copy_from_slice-alias, r=Mark-Simulacrum
Add the "memcpy" doc alias to slice::copy_from_slice
[RFC1419](https://github.com/rust-lang/rfcs/pull/1419) describes `slice::copy_from_slice` as a "safe memcpy". This enables people searching for `memcpy` to find the `slice::copy_from_slice` method. Thanks!
## Screenshots
This is currently the output when searching for "memcpy" -- `copy_from_slice` is safe, and should be part of this list.
Dylan DPC [Thu, 19 Nov 2020 22:58:45 +0000 (23:58 +0100)]
Rollup merge of #79194 - est31:array_into_iter_slice, r=scottmcm
Make as{_mut,}_slice on array::IntoIter public
The functions are useful in cases where you want to move data out of the IntoIter in bulk, by transmute_copy'ing the slice and then forgetting the IntoIter.
In the compiler, this is useful for providing a sped up IntoIter implementation. One can alternatively provide a separate allocate_array function but one can avoid duplicating some logic by passing everything through the generic iterator using interface.
As per suggestion in https://github.com/rust-lang/rust/pull/78569/files#r526506964
- The way I've implemented it, links are also provided for required methods, that just link to the signature in the code. I'm not sure if this is the desired behaviour.
- I'm not sure if the css changes are correct. I inspected them visualy on firefox on desktop, and they seem to be fine.
- I can't tell how `src/librustdoc/html/render/mod.rs` is structured, so I probably
Dylan DPC [Thu, 19 Nov 2020 22:58:37 +0000 (23:58 +0100)]
Rollup merge of #79177 - fanzier:drop-order-test, r=RalfJung
Test drop order for (destructuring) assignments
Add a test that checks whether the drop order of `let` bindings is consistent with the drop order of the corresponding destructuring assignments.
Thanks to ```@RalfJung``` for the suggesting this test ([here](https://github.com/rust-lang/rust/pull/79016#issuecomment-727608732)) and an implementation!
bors [Thu, 19 Nov 2020 17:27:24 +0000 (17:27 +0000)]
Auto merge of #79200 - Dylan-DPC:rollup-su689pq, r=Dylan-DPC
Rollup of 14 pull requests
Successful merges:
- #78961 (Make bad "rust-call" arguments no longer ICE)
- #79082 (Improve the diagnostic for when an `fn` contains qualifiers inside an `extern` block.)
- #79090 (libary: Forward compiler-builtins "asm" and "mangled-names" feature)
- #79094 (Add //ignore-macos to pretty-std-collections.rs)
- #79101 (Don't special case constant operands when lowering intrinsics)
- #79102 (Add two regression tests)
- #79110 (Remove redundant notes in E0275)
- #79116 (compiletest: Fix a warning in debuginfo tests on windows-gnu)
- #79117 (add optimization fuel checks to some mir passes)
- #79147 (Highlight MIR as Rust on GitHub)
- #79149 (Move capture lowering from THIR to MIR)
- #79155 (fix handling the default config for profiler and sanitizers)
- #79156 (Allow using `download-ci-llvm` from directories other than the root)
- #79164 (Permit standalone generic parameters as const generic arguments in macros)
Dylan DPC [Thu, 19 Nov 2020 15:26:42 +0000 (16:26 +0100)]
Rollup merge of #79156 - jyn514:relative-llvm, r=Mark-Simulacrum
Allow using `download-ci-llvm` from directories other than the root
Previously, bootstrap.py would attempt to find the LLVM commit from
`src/llvm-project`. However, it assumed it was always being run from the
top-level directory, which isn't always the case.
Dylan DPC [Thu, 19 Nov 2020 15:26:40 +0000 (16:26 +0100)]
Rollup merge of #79155 - 12101111:fix-profiler-config, r=Mark-Simulacrum
fix handling the default config for profiler and sanitizers
#78354 don't handle the case that user don't add any target-specific config in `[target.*]` of `config.toml`:
```toml
changelog-seen = 2
[llvm]
link-shared = true
[build]
sanitizers = true
profiler = true
[install]
[rust]
[dist]
```
The previes code handle the default config in `Config::prase()`:
In this case, `toml.target` don't contain any target, so the above code won't execute. Instead, a default `Target` is insert in https://github.com/rust-lang/rust/blob/c919f490bbcd2b29b74016101f7ec71aaa24bdbb/src/bootstrap/sanity.rs#L162-L166
The default value for `bool` is false, hence the issue in #79124
This fix change the type of `sanitizers` and `profiler` to `Option<bool>`, so the default value is `None`, and fallback config is handled in `Config::sanitizers_enabled` and `Config::profiler_enabled`
Dylan DPC [Thu, 19 Nov 2020 15:26:39 +0000 (16:26 +0100)]
Rollup merge of #79149 - sexxi-goose:upvar_ref, r=nikomatsakis
Move capture lowering from THIR to MIR
This allows us to:
- Handle precise Places captured by a closure directly in MIR. Handling
captures in MIR is easier since we can rely on/ tweak PlaceBuilder to
generate `mir::Place`s that resemble how we store captures (`hir::Place`).
- Handle `let _ = x` case when feature `capture_disjoint_fields`
is enabled directly in MIR. This is required to be done in MIR since
patterns are desugared in MIR.
Dylan DPC [Thu, 19 Nov 2020 15:26:35 +0000 (16:26 +0100)]
Rollup merge of #79117 - cjkenn:mir-fuel, r=oli-obk
add optimization fuel checks to some mir passes
Fixes #77402
Inserts a bunch of calls to `consider_optimizing`. Note that `consider_optimizing` is the method that actually decrements the fuel count, so the point at which it's called is when the optimization takes place, from a fuel perspective. This means that where we call it has some thought behind it:
1. We probably don't want to decrement the fuel count before other simple checks, otherwise we count an optimization as being performed even if nothing was mutated (ie. it returned early).
2. In cases like `InstCombine`, where we gather optimizations in a pass and then mutate values, we probably would rather skip the gathering pass for performance reasons rather than skip the mutations afterwards.
Dylan DPC [Thu, 19 Nov 2020 15:26:33 +0000 (16:26 +0100)]
Rollup merge of #79116 - petrochenkov:gdbwarn, r=Mark-Simulacrum
compiletest: Fix a warning in debuginfo tests on windows-gnu
The warning looked like this for me:
```
Warning: C:msys64homewerust./src/etc: No such file or directory.
```
It didn't affect actual testing because we don't currently emit gdb pretty-printer information into executables on windows-gnu.
projects / rust.git / log