Rollup merge of #61263 - GuillaumeGomez:valid-html, r=Manishearth
Don't generate div inside header (h4/h3/h...) elements
Fixes #60865.
According to the HTML spec, we're not supposed to put `div` elements inside heading elements (h4/h3/h...). It doesn't change the display as far as I could tell.
bors [Fri, 31 May 2019 22:16:09 +0000 (22:16 +0000)]
Auto merge of #61300 - indygreg:upgrade-cross-make, r=sanxiyn
Update musl-cross-make to 0.9.8
This version uses musl 1.1.22 and GCC 6.4.0 by default. It also
contains support for newer binutils and GCC versions, should we
want to bump those as well. But I'm purposefully limiting this
patch in order to reduce the surface area for controversy.
bors [Fri, 31 May 2019 17:10:11 +0000 (17:10 +0000)]
Auto merge of #57967 - eddyb:rmangle, r=michaelwoerister
Introduce Rust symbol mangling scheme.
This is an implementation of a "feature-complete" Rust mangling scheme, in the vein of rust-lang/rfcs#2603 ~~- but with some differences, see https://github.com/rust-lang/rfcs/pull/2603#issuecomment-458410463 for details~~ (@michaelwoerister integrated my proposed changes into the RFC itself).
On nightly, you can now control the mangling scheme with `-Z symbol-mangling-version`, which can be:
* `legacy`: the older mangling version, still the default currently
* `v0`: the new RFC mangling version, as implemented by this PR
To test the new mangling, set `RUSTFLAGS=-Zsymbol-mangling-version=v0` (or change [`rustflags` in `.cargo/config.toml`](https://doc.rust-lang.org/cargo/reference/config.html#configuration-keys)). Please note that only symbols from crates built with that flag will use the new mangling, and that tool support (e.g. debuggers) will be limited initially, and it may take a while for everything to be upstreamed. However, `RUST_BACKTRACE` should work out of the box with either mangling version.
<hr/>
The demangling implementation PR is https://github.com/alexcrichton/rustc-demangle/pull/23
~~(this PR already uses it via a git dependency, to allow testing)~~.
Discussion of the *design* of the mangling scheme should still happen on the RFC, but this PR's specific implementation details can be reviewed in parallel.
*Notes for reviewers*:
* ~~only the last 6 commits are specific to this branch, if necessary I can open a separate PR for everything else (it was meant to be its own small refactoring, but it got a bit out of hand)~~
~~based on #58140~~
* the "harness" commit is only there because it does some extra validation (comparing the demangling from `rustc-demangle` to the compiler's pretty-printing, adjusted slightly to produce the same output), that I would like to try on crater
* ~~there is the question of whether we should turn on the new mangling now, wait for tools to support it (I'm working on that), and/or have it under a `-Z` flag for now~~ (we're gating this on `-Z symbol-mangling-version=v0`, see above)
r? @nikomatsakis / @michaelwoerister cc @rust-lang/compiler
Changes:
````
Rustup to https://github.com/rust-lang/rust/pull/61203
rustup https://github.com/rust-lang/rust/pull/60928
rustup https://github.com/rust-lang/rust/pull/61164 (which is included in https://github.com/rust-lang/rust/pull/61274)
````
Pietro Albini [Fri, 31 May 2019 11:33:55 +0000 (13:33 +0200)]
Rollup merge of #61319 - Centril:async-unsafe-fn-order, r=cramertj
Swap order of `unsafe async fn` to `async unsafe fn`
Change the order of `unsafe async fn` to `async unsafe fn`.
I had intended to do this a while back but didn't get around to it...
This should be done because:
- It is the order used by `const unsafe fn` so therefore it is consistent.
- This keeps all the "effect/restriction" modifiers to the left of `unsafe` (which according to some is not an effect) instead of mixing them such that we are more forward compatible with some sort of effect system.
Pietro Albini [Fri, 31 May 2019 11:33:54 +0000 (13:33 +0200)]
Rollup merge of #61304 - lzybkr:iwr_progress, r=alexcrichton
Speed up Azure CI installing Windows dependencies
There is known issue where PowerShell is unreasonably slow downloading
files due to an issue with rendering the progress bar, see this [issue](https://github.com/PowerShell/PowerShell/issues/2138)
That issue is fixed in PowerShell Core (available in Azure Pipelines as
pwsh.exe) but it can also be worked around by setting:
$ProgressPreference = 'SilentlyContinue'
I measured downloading LLVM and it took about 220s before, 5s after, so the improvement is significant.
Pietro Albini [Fri, 31 May 2019 11:33:51 +0000 (13:33 +0200)]
Rollup merge of #60897 - seanmonstar:patch-4, r=sfackler
error: remove StringError from Debug output
Seeing `StringError("something something")` in debug output can cause
someone to think there was an error dealing with `String`s, not that the
error type is just a string. So, remove that noise.
bors [Thu, 30 May 2019 19:52:11 +0000 (19:52 +0000)]
Auto merge of #61353 - alexcrichton:less-tools, r=pietroalbini
ci: Favor SCRIPT instead of RUST_CHECK_TARGET
Since #61212 we've been timing out on OSX, and this looks to be because
we're building tools like Cargo and the RLS twice instead of once. This
turns out to be a slight bug in our configuration. CI builders using the
`RUST_CHECK_TARGET` directive actually execute `make all` just before
their acual target. In `make all` we're building a stage2 cargo, and
then in `make dist` we're building a stage1 cargo.
Other builders use `SCRIPT` which provides explicit control over what
`x.py` script, for example, is used to execute the build. This moves
almost all targets to using `SCRIPT` to ensure that we're explicitly
specifying what's being built where. Additionally this updates the logic
of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the
pre-flight `make all`. The system LLVM builder (run on PRs) now
explicitly runs tidy first and then runs the rest of the test suite.
Alex Crichton [Thu, 30 May 2019 14:22:53 +0000 (07:22 -0700)]
ci: Favor SCRIPT instead of RUST_CHECK_TARGET
Since #61212 we've been timing out on OSX, and this looks to be because
we're building tools like Cargo and the RLS twice instead of once. This
turns out to be a slight bug in our configuration. CI builders using the
`RUST_CHECK_TARGET` directive actually execute `make all` just before
their acual target. In `make all` we're building a stage2 cargo, and
then in `make dist` we're building a stage1 cargo.
Other builders use `SCRIPT` which provides explicit control over what
`x.py` script, for example, is used to execute the build. This moves
almost all targets to using `SCRIPT` to ensure that we're explicitly
specifying what's being built where. Additionally this updates the logic
of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the
pre-flight `make all`. The system LLVM builder (run on PRs) now
explicitly runs tidy first and then runs the rest of the test suite.
bors [Thu, 30 May 2019 11:56:32 +0000 (11:56 +0000)]
Auto merge of #61343 - Centril:rollup-dzsuo01, r=Centril
Rollup of 11 pull requests
Successful merges:
- #60802 (upgrade rustdoc's `pulldown-cmark` to 0.5.2)
- #60839 (Fix ICE with struct ctors and const generics.)
- #60850 (Stabilize RefCell::try_borrow_unguarded)
- #61231 (Fix linkage diagnostic so it doesn't ICE for external crates)
- #61244 (Box::into_vec: use Box::into_raw instead of mem::forget)
- #61279 (implicit `Option`-returning doctests)
- #61280 (Revert "Disable solaris target since toolchain no longer builds")
- #61284 (Update all s3 URLs used on CI with subdomains)
- #61321 (libsyntax: introduce 'fn is_keyword_ahead(dist, keywords)'.)
- #61322 (ci: display more debug information in the init_repo script)
- #61333 (Fix ICE with APIT in a function with a const parameter)
Failed merges:
- #61304 (Speed up Azure CI installing Windows dependencies)
Changes:
````
Rustup to https://github.com/rust-lang/rust/pull/61203
rustup https://github.com/rust-lang/rust/pull/60928
rustup https://github.com/rust-lang/rust/pull/61164 (which is included in https://github.com/rust-lang/rust/pull/61274)
````
Rollup merge of #61322 - pietroalbini:debug-windows-submodule-cloning, r=alexcrichton
ci: display more debug information in the init_repo script
I'm *really* confused about the error message [while cloning submodules on Windows on Azure](https://dev.azure.com/rust-lang/e71b0ddf-dd27-435a-873c-e30f86eea377/_apis/build/builds/295/logs/506):
```
/usr/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options
Try '/usr/bin/tar --help' or '/usr/bin/tar --usage' for more information.
```
It doesn't make sense for it to execute a command without any of those flags since they're clearly added:
Introduces:
```rust
/// Returns whether any of the given keywords are `dist` tokens ahead of the current one.
fn is_keyword_ahead(&self, dist: usize, kws: &[Symbol]) -> bool {
self.look_ahead(dist, |t| kws.iter().any(|&kw| t.is_keyword(kw)))
}
```
Box::into_vec: use Box::into_raw instead of mem::forget
`Box::into_raw` does, in one step, turn the `Box` into a raw ptr and avoid deallocation. Seems cleaner than separating the two.
Also, `mem::forget` gets the `Box` with a `noalias` argument, but it is not actually correct that this is an exclusive pointer. So a stricter version of Stacked Borrows would complain here. (I can't actually make Stacked Borrows that strict yet though due to other issues.)
Rollup merge of #60850 - SimonSapin:unguarded, r=alexcrichton
Stabilize RefCell::try_borrow_unguarded
Servo has been using this since https://github.com/servo/servo/pull/23196 to add a runtime check to some unsafe code, as discussed in PR https://github.com/rust-lang/rust/pull/59211. Stabilizing would help do more of the same in libraries that also have users on Stable.
bors [Thu, 30 May 2019 03:37:37 +0000 (03:37 +0000)]
Auto merge of #61005 - michaelwoerister:error-pgo-windows-unwind, r=zackmdavis
Emit error when trying to use PGO in conjunction with unwinding on Windows.
This PR makes `rustc` emit an error when trying use PGO in conjunction with `-Cpanic=unwind` on Windows, isn't supported by LLVM yet. The error messages points to https://github.com/rust-lang/rust/issues/61002, which documents this known limitation.
bors [Thu, 30 May 2019 00:38:51 +0000 (00:38 +0000)]
Auto merge of #61212 - alexcrichton:skip-rustc, r=pietroalbini
ci: Attempt to skip a full rustc compile on dist*
Currently when we're preparing cross-compiled compilers it can take
quite some time because we have to build the compiler itself three
different times. The first is the normal bootstrap, the second is a
second build for the build platform, and the third is the actual target
architecture compiler. The second compiler was historically built
exclusively for procedural macros, and long ago we didn't actually need
it.
This commit tries out avoiding that second compiled compiler, meaning we
only compile rustc for the build platform only once. Some local testing
shows that this is promising, but bors is of course the ultimate test!
It's a hot function that returns a 2-tuple, but the hottest call site
(`hygienic_eq`) discards the second element.
This commit renames `adjust_ident` as `adjust_ident_and_get_scope`, and
then introduces a new `adjust_ident` that only computes the first
element. This change also avoids the need to pass in an unused
`DUMMY_HIR_ID` argument in a couple of places, which is nice.
Oliver Scherer [Wed, 29 May 2019 12:41:03 +0000 (14:41 +0200)]
Rollup merge of #60885 - euclio:strip-synstructure-consts, r=GuillaumeGomez
strip synstructure consts from compiler docs
Fixes #60150.
Unfortunately this PR depends on the use of the deprecated `--passes` flag in bootstrap to keep the `--strip-hidden` pass while still documenting private items. I've opened #60884 to track stabilization of a new flag that encapsulates this behavior.
Oliver Scherer [Wed, 29 May 2019 12:41:01 +0000 (14:41 +0200)]
Rollup merge of #60549 - euclio:doctest-panic-messages, r=GuillaumeGomez
do not print panic message on doctest failures
This PR cleans up rustdoc test output by silently unwinding on failure instead of using `panic!`. It also improves the clarity and consistency of the output on test failure, and adds test cases for failure modes that were previously untested.
David Wood [Tue, 14 May 2019 20:34:43 +0000 (21:34 +0100)]
Fix ICE with struct ctors and const generics.
This commit fixes a ICE where struct constructors were resulting in an
ICE with const generics. Previously, a `match` in `type_of` did not have
an arm for the `DefKind::Ctor` resolutions and therefore would assume
that the type did not have generics.
Rollup merge of #61297 - eddyb:forsaken-stats, r=nagisa
Remove LLVM instruction stats and other (obsolete) codegen stats.
Both `-Z count_llvm_insns` and `-Z codegen-stats` are removed, as (AFAIK) they have been of little use in the last few years, especially after the transition to MIR->LLVM codegen.
Other than for the LLVM instruction counts, `-Z codegen-stats` has long been obsoleted anyway.
Rollup merge of #61191 - phansch:annotate_snippet_refactorings1, r=estebank
librustc_errors: Move annotation collection to own impl
Extracted from work on #59346. This moves the annotation collection to
the `FileWithAnnotatedLines` impl to allow easier re-use in a separate
EmitterWriter. Even without that new EmitterWriter present, I think it makes
sense to have this as an associated function.
Rollup merge of #60766 - vorner:weak-into-raw, r=sfackler
Weak::into_raw
Hello
This is my first shot at #60728. I'd like to consult it a bit before moving further.
The biggest question I have is if this API makes sense. My motivation for it is to be able to store the `Weak` in `AtomicPtr`. For that I don't actually need for the pointer to point to the `T`, any pointer (maybe casted to `usize`) would be good enough, but this mirrors what `Arc` does and could be useful for other things too (like comparing if Arc and Weak point to the same thing without playing with the counts), while some opaque pointer wouldn't.
Some secondary questions, if this is deemed desirable are:
* The weak pointer may be dangling if it is created by `Weak::new()`. It would make sense to treat this as NULL, but that is incompatible with `T: ?Sized` ‒ both `new()` and `ptr::null()` are available only for sized types. The current implementation is therefore also available only for sized `T`s. It would be possible to allow `?Sized` if the API would be `fn into_raw(self) -> Option<NonNull<T>>` and `fn from_raw(NonNull<T>)`, but that's different API than `Arc` has. What would be preferred?
* There's a FIXME in my code about what I suspect could be UB. Is it really UB & how to get the pointer correctly? Is manual offsetting of the pointer the only way?
* Am I missing some other necessary thing around the feature gates and such?
* Is the documentation understandable? I know writing docs is not my strongest skill :-|.
Thinks I'd like to do as part of the PR, but are not yet done:
* Turn the referenced issue into tracking issue for the feature flag.
* Once the `sync::Weak` is considered reasonable, I'd do the equivalent for `rc::Weak`.
* This might call for few more tests than what is currently part of the documentation.
Rollup merge of #60555 - timvermeulen:rchunks_nth_back, r=scottmcm
Implement nth_back for RChunks(Exact)(Mut)
Part of #54054.
These implementations may not be optimal because of the use of `self.len()`, but it's quite cheap and simplifies the code a lot.
There's quite some duplication going on here, I wouldn't mind cleaning this up later. A good next step would probably be to add private `split_off_up_to`/`split_off_from` helper methods for slices since their behavior is commonly useful throughout the `Chunks` types.
Rollup merge of #58975 - jtdowney:iter_arith_traits_option, r=dtolnay
Implement `iter::Sum` and `iter::Product` for `Option`
This is similar to the existing implementation for `Result`. It will take each item into the accumulator unless a `None` is returned.
I based a lot of this on #38580. From that discussion it didn't seem like this addition would be too controversial or difficult. One thing I still don't understand is picking the values for the `stable` attribute. This is my first non-documentation PR for rust so I am open to any feedback on improvements.
projects / rust.git / log