Auto merge of #63057 - Centril:rollup-z3a3c6v, r=Centril
Rollup of 8 pull requests
Successful merges:
- #61207 (Allow lifetime elision in `Pin<&(mut) Self>`)
- #62074 (squash of all commits for nth_back on ChunksMut)
- #62771 (Break dependencies between `syntax_ext` and other crates)
- #62883 (Refactoring use common code between option, result and accum)
- #62949 (Re-enable assertions in PPC dist builder)
- #62996 (tidy: Add a check for inline unit tests)
- #63038 (Make more informative error on outer attribute after inner)
- #63050 (ci: download awscli from our mirror)
Rollup merge of #63050 - pietroalbini:vendor-awscli, r=Mark-Simulacrum
ci: download awscli from our mirror
This fixes multiple network issues we had when downloading awscli from PyPI on Azure Pipelines by vendoring awscli itself and its dependencies in our S3 bucket. Instructions on how to update the cache are present at the top of `src/ci/install-awscli.sh`.
Rollup merge of #62996 - petrochenkov:outest, r=Mark-Simulacrum
tidy: Add a check for inline unit tests
As described in https://github.com/rust-lang/rust/issues/61097.
There's a large whitelist right now, because in many crates the tests are not outlined yet.
~This PR only outlines tests in one crate (`rustc_lexer`) as an example.~
Rollup merge of #62883 - Stargateur:refactoring-adapters, r=scottmcm
Refactoring use common code between option, result and accum
`Option` and `Result` have almost exactly the same code that in `accum.rs` that implement `Sum` and `Product`. This PR just move some code to use the same code for all of them. I believe is better to not implement this `Iterator` feature twice.
I'm not very familiar with pub visibility hope I didn't make then public. However, maybe these adapters could be useful and we could think to make then pub.
Pietro Albini [Sat, 27 Jul 2019 20:18:40 +0000 (22:18 +0200)]
ci: download awscli from our mirror
This fixes multiple network issues we had when downloading awscli from
PyPI on Azure Pipelines by vendoring awscli itself and its dependencies
in our S3 bucket. Instructions on how to update the cache are present at
the top of src/ci/install-awscli.sh
Auto merge of #63029 - petrochenkov:rpass, r=Centril
Move run-pass tests to ui
This is the second attempt at doing https://github.com/rust-lang/rust/pull/53994 (which was previously reverted in https://github.com/rust-lang/rust/pull/54530).
The issue with inability to run the test suite in a faster way (https://github.com/rust-lang/rust/issues/54047) that motivated the revert was recently addressed by https://github.com/rust-lang/rust/pull/61755.
Auto merge of #63043 - Centril:rollup-f4baee4, r=Centril
Rollup of 6 pull requests
Successful merges:
- #62423 (Fix cycle error with existential types)
- #62979 (Cleanup save-analysis JsonDumper)
- #62982 (Don't access a static just for its size and alignment)
- #63013 (add `repr(transparent)` to `IoSliceMut` where missing)
- #63014 (Stop bare trait lint applying to macro call sites)
- #63036 (Add lib section to rustc_lexer's Cargo.toml)
Rollup merge of #63036 - topecongiro:add-lib-section, r=matklad
Add lib section to rustc_lexer's Cargo.toml
This is required to fix the rustc-ap-syntax build error in the recent version. The error could also be fixed on the [rustc-auto-publish](https://github.com/alexcrichton/rustc-auto-publish) side by manually adding `[lib]` section if one does not exist. The latter approach, however, may have a surprising side effect, so I am opting for a simpler solution for now.
Rollup merge of #63014 - davidtwco:rustfix-incorrect-dyn-suggestion, r=estebank
Stop bare trait lint applying to macro call sites
Fixes #61963. Apologies for the delay with in fixing this. If anyone has a better idea how to detect this macro call site case, I'd be happy to fix this in a more robust, less hacky way.
Rollup merge of #63013 - nivkner:ffi-safe-slice, r=sfackler
add `repr(transparent)` to `IoSliceMut` where missing
tried using `IoSliceMut` in FFI, got `improper_ctypes` warning.
according to the docs: `IoSliceMut` is "guaranteed to be ABI compatible with the `iovec` type" so it should be usable in FFI.
`IoSlice` is also `repr(transparent)` for every platform where these types contain `iovec`-like types.
vxworks also has `IoSliceMut` as transparent so its not even consistently one or the other.
no comment about this next to the types or in the PR that introduced the types, so assuming this was just missed.
Rollup merge of #62423 - Aaron1011:fix/existential-cycle, r=oli-obk
Fix cycle error with existential types
Fixes #61863
We now allow uses of `existential type`'s that aren't defining uses - that is, uses which don't constrain the underlying concrete type.
To make this work correctly, we also modify `eq_opaque_type_and_type` to not try to apply additional constraints to an opaque type. If we have code like this:
then `foo2` doesn't end up constraining `Foo`, which means that `foo2` will end up using the type `Foo` internally - that is, an actual `TyKind::Opaque`. We don't want to equate this to the underlying concrete type - we just need to enforce the basic equality constraint between the two types (here, the return type of `foo1` and the return type of `foo2`)
Auto merge of #62086 - petrochenkov:builtout, r=eddyb
Define built-in macros through libcore
This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`).
All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler.
The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope.
As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change.
Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`).
Now when built-in macros have canonical definitions they can be imported or reexported without issues (https://github.com/rust-lang/rust/issues/61687).
Other changes:
- You can now define a derive macro with a name matching one of the built-in derives (https://github.com/rust-lang/rust/issues/52269). This was an artificial restriction that could be worked around with import renaming anyway.
Known regressions:
- Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type.
Auto merge of #63015 - Centril:rollup-ydhpcas, r=Centril
Rollup of 22 pull requests
Successful merges:
- #62084 (allow clippy::unreadable_literal in unicode tables)
- #62120 (Add missing type links in documentation)
- #62310 (Add missing doc links in boxed module)
- #62421 (Introduce `as_deref` to Option)
- #62583 (Implement Unpin for all raw pointers)
- #62692 (rustc: precompute the largest Niche and store it in LayoutDetails.)
- #62801 (Remove support for -Zlower-128bit-ops)
- #62828 (Remove vector fadd/fmul reduction workarounds)
- #62862 (code cleanup)
- #62904 (Disable d32 on armv6 hf targets)
- #62907 (Initialize the MSP430 AsmParser)
- #62956 (Implement slow-path for FirstSets::first)
- #62963 (Allow lexer to recover from some homoglyphs)
- #62964 (clarify and unify some type test names)
- #62970 (ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar)
- #62980 (std: Add more accessors for `Metadata` on Windows)
- #62983 (Remove needless indirection through Rc)
- #62985 (librustc_errors: Support ui-testing flag in annotate-snippet emitter)
- #63002 (error_index_generator should output stdout/stderr when it panics.)
- #63004 (Add test for issue-54062)
- #63007 (ci: debug network failures while downloading awscli from PyPI)
- #63009 (Remove redundant `mut` from variable declaration.)
Rollup merge of #63002 - gilescope:better-build-diagnostics, r=Mark-Simulacrum
error_index_generator should output stdout/stderr when it panics.
**bootstrap change**
Call error_index_generator tool using run_quiet which will additionally print std out and std err of the command when it returns an error.
(was `run` uses `run_silent` under the covers.)
Why: PR #62871 is hitting a build error but the panic isn't getting shown so its unclear what the problem is.
Rollup merge of #62980 - alexcrichton:windows-metadata, r=sfackler
std: Add more accessors for `Metadata` on Windows
This commit adds accessors for more fields in `fs::Metadata` on Windows
which weren't previously exposed. There's two sources of `fs::Metadata`
on Windows currently, one from `DirEntry` and one from a file itself.
These two sources of information don't actually have the same set of
fields exposed in their stat information, however. To handle this the
platform-specific accessors of Windows-specific information all return
`Option` to return `None` in the case a metadata comes from a
`DirEntry`, but they're guaranteed to return `Some` if it comes from a
file itself.
This is motivated by some changes in CraneStation/wasi-common#42, and
I'm curious how others feel about this platform-specific functionality!
Rollup merge of #62970 - pietroalbini:fix-tools-builder, r=alexcrichton
ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar
This PR fixes toolstate failing to push on the LinuxTools PR builder by gating the pushes on the new `TOOLSTATE_PUBLISH` environment variable, which is set on prod credentials but not on the PR ones. The old code checked whether the access token was set, but that doesn't work due to an Azure quirk.
For a bit of background, secret environment variables are not available by default, but each step needs to explicitly declare which secret vars to load:
This works fine when the variable is present but when it's missing, instead of setting `SECRET_VAR` to an empty string or just not setting it at all, Azure Pipelines puts the literal `$(SECRET_VAR)` as the content, which completly breaks the old check we had. I tried almost every thing to make this work in a sensible way, and the only conclusion I reached is to set the variable at the top level with the runtime expression evaluation syntax, which sets the variable to an empty string if missing:
```yaml
# At the top:
variables:
- name: MAYBE_SECRET_VAR
value: $[ variables.MAYBE_SECRET_VAR ]
# In the step:
- bash: echo foo
env:
SECRET_VAR: $(MAYBE_SECRET_VAR)
```
While that *could've worked* it was ugly and messy, so I just opted to add yet another non-secret variable.
Rollup merge of #62964 - RalfJung:ty-tests, r=Centril
clarify and unify some type test names
* `is_mutable_pointer`: use `ptr` suffix for consistency with `is_region_ptr`, `is_fn_ptr`, `is_unsafe_ptr`.
* `is_pointer_sized`: the name is misleading as this only tests for pointer-sized *integers*, so rename to `is_ptr_sized_integral`.
Rollup merge of #62692 - eddyb:precompute-niches, r=oli-obk
rustc: precompute the largest Niche and store it in LayoutDetails.
Since we only ever can use at most one niche, it makes sense to just store that in the layout, for the simplest caching (especially as it's almost trivial to compute).
There might be a speedup from this, but even if it's marginal now, the caching would be a more significant benefit for future optimization attempts.
Alex Crichton [Thu, 25 Jul 2019 16:44:04 +0000 (09:44 -0700)]
std: Add more accessors for `Metadata` on Windows
This commit adds accessors for more fields in `fs::Metadata` on Windows
which weren't previously exposed. There's two sources of `fs::Metadata`
on Windows currently, one from `DirEntry` and one from a file itself.
These two sources of information don't actually have the same set of
fields exposed in their stat information, however. To handle this the
platform-specific accessors of Windows-specific information all return
`Option` to return `None` in the case a metadata comes from a
`DirEntry`, but they're guaranteed to return `Some` if it comes from a
file itself.
This is motivated by some changes in CraneStation/wasi-common#42, and
I'm curious how others feel about this platform-specific functionality!
Auto merge of #62914 - ehuss:update-cargo, r=alexcrichton
Update cargo
11 commits in e3563dbdcd2e370bc4f11d080f739d82d25773fd..d0f828419d6ce6be21a90866964f58eb2c07cd56
2019-07-16 19:22:44 +0000 to 2019-07-23 21:58:59 +0000
- Remove include/exclude glob warning. (rust-lang/cargo#7170)
- Optimize lock file format for git merge conflicts (rust-lang/cargo#7070)
- Set up CI with Azure Pipelines (rust-lang/cargo#7139)
- Force clippy to run. (rust-lang/cargo#7157)
- Work around rust-lang/rust#61440 (rust-lang/cargo#7158)
- initial working version of cargo fix --clippy (rust-lang/cargo#7069)
- Optimize runtime of `#[cargo_test_macro]` (rust-lang/cargo#7146)
- Don't fail if we can't acquire readonly lock (rust-lang/cargo#7149)
- Add support for multiple --features options (rust-lang/cargo#7084)
- Fix a typo in an env var name (rust-lang/cargo#7145)
- Add a way to disable all nightly tests (rust-lang/cargo#7142)
Auto merge of #60260 - videolabs:rust_uwp2, r=alexcrichton
Add support for UWP targets
Hi,
This pull request aims at adding support for UWP (Universal Windows Apps) platform.
A few notes:
- This requires a very recent mingw-w64 version (containing this commit and the previous related ones: https://github.com/mirror/mingw-w64/commit/e8c433c871687a78408ae9b40ab7776577db908d#diff-eefdfbfe9cec5f4ebab88c9a64d423a9)
- This was tested using LLVM/clang rather than gcc, and so far it assumes that LLVM/clang will be the native compiler. This is mostly due to the fact that the support for exceptions/stack unwinding for UWP got much more attention in libunwind
- The "uwp" part of the target needs support for it in the `cc-rs` & `backtrace-rs` crates. I'll create the MR there right after I submit this one and will link everything together, but I'm not sure what's the correct way of dealing with external dependencies in the context of rust
- Enabling import libraries and copying them across stages requires a change in cargo, for which I'll open a MR right after I submit this one as well
- The i686 stack unwinding is unsupported for now, because LLVM assumes SjLj, while rust seems to assume SEH will be used. I'm unsure how to fix this
Also, this is my first encounter with rust, so please bear with my code, it might not feel so idiomatic or even correct :)
I'm pretty sure there's a way of doing things in a cleaner way when it comes to win/c.rs, maybe having a UWP & desktop specific modules, and import those conditionally? It doesn't feel right to sprinkle `#[cfg(...)]` all over the place
Off course, I'll gladly update anything you see fit (to the extent of my abilities/knowledge :) )!
Auto merge of #62990 - Centril:rollup-k9n0hvs, r=Centril
Rollup of 15 pull requests
Successful merges:
- #60066 (Stabilize the type_name intrinsic in core::any)
- #60938 (rustdoc: make #[doc(include)] relative to the containing file)
- #61884 (Stablize Euclidean Modulo (feature euclidean_division))
- #61890 (Fix some sanity checks)
- #62528 (Add joining slices of slices with a slice separator, not just a single item)
- #62707 (Add tests for overlapping explicitly dropped locals in generators)
- #62735 (Turn `#[global_allocator]` into a regular attribute macro)
- #62822 (Improve some pointer-related documentation)
- #62887 (Make the parser TokenStream more resilient after mismatched delimiter recovery)
- #62921 (Add method disambiguation help for trait implementation)
- #62930 (Add test for #51559)
- #62942 (Use match ergonomics in Condvar documentation)
- #62977 (Fix inconsistent highlight blocks.)
- #62978 (Remove `cfg(bootstrap)` code for array implementations)
- #62981 (Add note suggesting to borrow a String argument to find)
Rollup merge of #62978 - LukasKalbertodt:remove-array-impl-bootstrap-cfg, r=Mark-Simulacrum
Remove `cfg(bootstrap)` code for array implementations
In https://github.com/rust-lang/rust/pull/62435 ("Use const generics for array impls [part 1]") the old macro-based implementations were not removed but still used with `cfg(bootstrap)` since the bootstrap compiler had some problems with const generics at the time. This does not seem to be the case anymore, so there is no reason to keep the old code.
Unfortunately, the diff is pretty ugly because much of the code was indented by one level before. The change is pretty trivial, though.
PS: I did not run the full test suite locally. There are 40°C outside and 31°C inside my room. I don't want my notebook to melt. I hope that CI is green.
projects / rust.git / log