This is reducing the amount of test coverage for LLVM/debug assertions,
but we're just unfortunately running out of time on CI too many times.
Some test builds have shown that i686-gnu drops nearly an hour of CI
time by disabling these two assertions. Perhaps when we eventually get
4-core machines we can reenable these, but for now turn them off and
hook them up to the tracking issue at #59637 which will ideally be
repurposes to tracking all of these.
Auto merge of #64543 - pietroalbini:revert-miri-manifest, r=pietroalbini
Revert #64451
#64451 is making the release process panic, causing today's missing nightly (see https://github.com/rust-lang/rust/issues/64540). This reverts that PR, but I'm happy to review a fixed version of it.
Now that all indices have type `usize`, it makes sense to be more
consistent about their naming. This commit removes all uses of `i` in
favour of `index`.
The size of the indices doesn't matter much here, and having a
`newtype_index!` index type without also using `IndexVec` requires lots
of conversions. So this commit removes `NodeIndex` in favour of uniform
use of `usize` as the index type. As well as making the code slightly
more concise, it also slightly speeds things up.
`Node` has an optional parent and a list of other descendents. Most of
the time the parent is treated the same as the other descendents --
error-handling is the exception -- and chaining them together for
iteration has a non-trivial cost.
This commit changes the representation. There is now a single list of
descendants, and a boolean flag that indicates if there is a parent (in
which case it is first descendent). This representation encodes the same
information, in a way that is less idiomatic but cheaper to iterate over
for the common case where the parent doesn't need special treatment.
As a result, some benchmark workloads are up to 2% faster.
Rollup merge of #64416 - mark-i-m:region-naming-ctx, r=estebank
Various refactorings to clean up nll diagnostics
- Create ErrorReportingCtx and ErrorConstraintInfo, vasting reducing the
number of arguments passed around everywhere in the error reporting code
- Create RegionErrorNamingCtx, making a given lifetime have consistent
numbering thoughout all error messages for that MIR def.
- Make the error reporting code return the DiagnosticBuilder rather than
directly buffer the Diagnostic. This makes it easier to modify the
diagnostic later, e.g. to add suggestions.
r? @estebank
Split out from https://github.com/rust-lang/rust/pull/58281
Auto merge of #64526 - Centril:rollup-k4cz2xn, r=Centril
Rollup of 4 pull requests
Successful merges:
- #64357 (`AdtDef` is an algebraic data type, not abstract data type)
- #64485 (update Miri)
- #64509 (Make some adjustments to the documentation for `std::convert::identity`)
- #64518 (Use while let slice_pattern instead of carrying an index around)
r? @alexcrichton for the Cargo.toml changes: with byteorder 1.3, the `i128` feature is a NOP, so we can remove it everywhere and then get rid of this crate in the workspace-hack.
Niko Matsakis [Mon, 16 Sep 2019 20:15:20 +0000 (16:15 -0400)]
adjust desugaring for async fn to correct drop order
Old desugaring, given a user function body { $stmts; $expr }
```
{
let $param_pattern0 = $raw_param0;
...
let $param_patternN = $raw_paramN;
$stmts;
$expr
}
```
New desugaring:
```
{
let $param_pattern0 = $raw_param0;
...
let $param_patternN = $raw_paramN;
drop-temps {
$stmts;
$expr
}
}
```
The drop-temps is an internal bit of HIR that drops temporaries from
the resulting expression, but it should be equivalent to `return {
$stmts; $expr }`.
This is reducing the amount of test coverage for LLVM/debug assertions,
but we're just unfortunately running out of time on CI too many times.
Some test builds have shown that i686-gnu drops nearly an hour of CI
time by disabling these two assertions. Perhaps when we eventually get
4-core machines we can reenable these, but for now turn them off and
hook them up to the tracking issue at #59637 which will ideally be
repurposes to tracking all of these.
Auto merge of #64510 - Centril:rollup-m03zsq8, r=Centril
Rollup of 10 pull requests
Successful merges:
- #63955 (Make sure interned constants are immutable)
- #64028 (Stabilize `Vec::new` and `String::new` as `const fn`s)
- #64119 (ci: ensure all tool maintainers are assignable on issues)
- #64444 (fix building libstd without backtrace feature)
- #64446 (Fix build script sanitizer check.)
- #64451 (when Miri tests are not passing, do not add Miri component)
- #64467 (Hide diagnostics emitted during --cfg parsing)
- #64497 (Don't print the "total" `-Ztime-passes` output if `--prints=...` is also given)
- #64499 (Use `Symbol` in two more functions.)
- #64504 (use println!() instead of println!(""))
Rollup merge of #64451 - RalfJung:miri-manifest, r=pietroalbini
when Miri tests are not passing, do not add Miri component
This makes build-manifest query the toolstate repo at https://github.com/rust-lang-nursery/rust-toolstate to figure out if the tests of the Miri component are passing. If they are not, we remove the component from the manifest, to avoid shipping a broken Miri.
Rollup merge of #64446 - ehuss:fix-sanitizer-build, r=alexcrichton
Fix build script sanitizer check.
#64166 changed the way the sanitizer build scripts work. However, they were changed so that they switch between new-style to old-style cargo fingerprints. This trips up on https://github.com/rust-lang/cargo/issues/6779.
It also causes rustbuild to panic. If you build stage1 std (with sanitizers off), and then enable sanitizers, it panics. (This is because the build scripts don't declare that they need to re-run.)
This PR will trip https://github.com/rust-lang/cargo/issues/6779 again, unfortunately. I've been having way too many unexplained rebuilds in rust-lang/rust recently, but at least I'll know why this time.
This doesn't fix all problems with the build scripts, but arguably they should be fixed in cargo. For example, the build scripts change which rerun-if statements they declare between runs which triggers https://github.com/rust-lang/cargo/issues/7362.
The test for this is:
1. Turn off sanitizers (which is the default)
2. `./x.py build --stage=1 src/libstd`
3. `./x.py build --stage=1 src/libstd` again should be a null build.
4. Enable sanitizers.
5. `./x.py build --stage=1 src/libstd` should rebuild with sanitizers enabled.
6. `./x.py build --stage=1 src/libstd` again should be a null build. This actually rebuilds due to https://github.com/rust-lang/cargo/issues/7362 because the rerun-if directives changed between step 3 and 5. A 3rd attempt should be a null build.
Rollup merge of #64119 - pietroalbini:validate-toolstate-maintainers, r=kennytm
ci: ensure all tool maintainers are assignable on issues
GitHub only allows people explicitly listed as collaborators on the repository or who commented on the issue/PR to be assignees, failing to create the issue if non-assignable people are assigned.
This adds an extra check on CI to make sure all the people listed as tool maintainers can be assigned to toolstate issues. The check won't be executed on PR builds due to the lack of a valid token.
Rollup merge of #63955 - RalfJung:intern, r=oli-obk
Make sure interned constants are immutable
This makes sure that interning for constants (not statics) creates only immutable allocations.
Previously, the "main" allocation of `const FOO: Cell<i32> = Cell::new(0);` was marked as mutable, but I don't think we want that. It can be only copied, not written to.
Also, "leftover" allocations (behind raw pointers etc) were left mutable. I don't think we want to support that. I tried asserting that these are all already immutable (to double-check our static checks), but that failed in this one:
```rust
const NON_NULL_PTR2: NonNull<u8> = unsafe { mem::transmute(&0) };
```
Seems like maybe we want more precise mutability annotation inside Miri for locals (like `&0` here) so that this would actually become immutable to begin with?
I also factored `intern_shallow` out of the visitor so that we don't have to construct a visitor when we do not plan to visit anything. That confused me at first.
Pietro Albini [Tue, 3 Sep 2019 09:33:29 +0000 (11:33 +0200)]
ci: ensure all tool maintainers are assignable on issues
GitHub only allows people explicitly listed as collaborators on the
repository or who commented on the issue/PR to be assignees, failing to
create the issue if non-assignable people are assigned.
This adds an extra check on CI to make sure all the people listed as
tool maintainers can be assigned to toolstate issues. The check won't be
executed on PR builds due to the lack of a valid token.
Auto merge of #64383 - pcpthm:btreeset-size-hint, r=dtolnay
Improve BTreeSet::Intersection::size_hint
A comment on `IntersectionInner` mentions `small_iter` should be smaller than `other_iter` but this condition is broken while iterating because those two iterators can be consumed at a different rate. I added a test to demonstrate this situation.
<del>I made `small_iter.len() < other_iter.len()` always true by swapping two iterators when that condition became false. This change affects the return value of `size_hint`. The previous result was also correct but this new version always returns smaller upper bound than the previous version.</del>
I changed `size_hint` to taking minimum of both lengths of iterators and renamed fields to `a` and `b` to match `Union` iterator.
Improve BTreeSet::Intersection::size_hint
The commented invariant that an iterator is smaller than other iterator
was violated after next is called and two iterators are consumed at
different rates.
This makes the code a little faster, presumably because bounds checks
aren't needed on `nodes` accesses. It requires making `scratch` a
`RefCell`, which is not unreasonable.
This commit removes the custom index implementation of `NodeIndex`,
which probably predates `newtype_index!`.
As well as eliminating code, it improves the debugging experience,
because the custom implementation had the property of being incremented
by 1 (so it could use `NonZeroU32`), which was incredibly confusing if
you didn't expect it.
For some reason, I also had to remove an `unsafe` block marker from
`from_u32_unchecked()` that the compiler said was now unnecessary.
Auto merge of #64491 - Centril:rollup-21wkl69, r=Centril
Rollup of 3 pull requests
Successful merges:
- #63872 (Document platform-specific behavior of the iterator returned by std::fs::read_dir)
- #64250 (save-analysis: Nest typeck tables when processing functions/methods)
- #64472 (Don't mark expression with attributes as not needing parentheses)
Rollup merge of #64472 - Mark-Simulacrum:unused-parens-attr, r=varkor
Don't mark expression with attributes as not needing parentheses
This is not perfectly correct as `#[attr] (5)` will still not lint, but it does seem good enough, in particular as the parentheses in that case are not unambiguously incorrect; I might personally prefer to see them for clarity.
projects / rust.git / log