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.
Rollup merge of #62528 - SimonSapin:concat, r=alexcrichton
Add joining slices of slices with a slice separator, not just a single item
https://github.com/rust-lang/rust/issues/27747#issuecomment-294525391
> It's kinda annoying to be able to join strings with a str (which can have multiple chars), but joining a slice of slices, you can only join with a single element.
This turns out to be fixable, with some possible inference regressions.
# TL;DR
Related trait(s) are unstable and tracked at https://github.com/rust-lang/rust/issues/27747, but the `[T]::join` method that is being extended here is already stable.
Example use of the new insta-stable functionality:
```rust
let nested: Vec<Vec<Foo>> = /* … */;
let separator: &[Foo] = /* … */; // Previously: could only be a single &Foo
nested.join(separator)
```
Complete API affected by this PR, after changes:
```rust
impl<T> [T] {
pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output
where Self: Concat<Item>
{
Concat::concat(self)
}
pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output
where Self: Join<Separator>
{
Join::join(self, sep)
}
}
// The `Item` parameter is only useful for the the slice-of-slices impl.
pub trait Concat<Item: ?Sized> {
type Output;
fn concat(slice: &Self) -> Self::Output;
}
impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V {
type Output = Vec<T>;
}
impl<S: Borrow<str>> SliceConcat<str> for S {
type Output = String;
}
```
By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value.
In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great.
The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous.
Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore:
```rust
error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates
--> src/liballoc/slice.rs:608:6
|
608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] {
| ^ unconstrained type parameter
```
This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`.
This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it.
The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls.
In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes.
# Joining strings with `char`
For symmetry I also tried adding this impl (because why not):
```rust
impl<S: Borrow<str>> Join<char> for [S] {
type Output = String;
}
```
This immediately caused an inference regression in a dependency of rustc:
```rust
error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied
--> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37
|
595 | row.push_str(&desc_rows.join(&desc_sep));
| ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String`
|
= help: the following implementations were found:
<std::string::String as std::borrow::Borrow<str>>
= note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]`
```
In the context of this code, two facts are known:
* `desc_rows` is a `Vec<String>`
* `desc_sep` is a `String`
Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`.
With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution.
I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))`
The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.
Rollup merge of #61890 - golddranks:fix_sanity_check_llvm, r=Dylan-DPC
Fix some sanity checks
Update: Changes that made it not to work dropped.
* Fix `building_llvm` in sanity check
* This was subtly broken: we build LLVM if any of the hosts builds LLVM, and not setting the config meant that LLVM is built for that target. Because of filtering away the targets not configured and the semantics of `Iterator::any`, it currently didn't set the `building_llvm` flag even if we indeed build it.
* Add `swig` sanity check
* This checks whether there is a `swig` executable needed for LLDB.
Rollup merge of #60938 - jonas-schievink:doc-include-paths, r=petrochenkov
rustdoc: make #[doc(include)] relative to the containing file
This matches the behavior of other in-source paths like `#[path]` and the `include_X!` macros.
Fixes https://github.com/rust-lang/rust/pull/58373#issuecomment-462349380
Also addresses https://github.com/rust-lang/rust/issues/44732#issuecomment-467660239
cc #44732
This is still missing a stdsimd change (https://github.com/jonas-schievink/stdsimd/commit/42ed30e0b5fb5e2d11765b5d1e1f36234af85984), so CI will currently fail. I'll land that change once I get initial feedback for this PR.
Attempt to create sockets with the WSA_FLAG_NO_HANDLE_INHERIT flag, and
handle the potential error gracefully (as the flag isn't support on
Windows 7 before SP1)
rustc: codegen: Build import library for all windows targets
So far it is assumed that using a DLL as a -l parameter argument is ok,
but the assumption doesn't hold when compiling the native code with
llvm.
In which case, an import library is required, so let's build one
This also requires the cargo counterpart to add the import library in
the stamp files, at least when compiling libstd. Otherwise, the files
don't get uplifted
Auto merge of #60340 - mgeier:cap-vs-capacity, r=alexcrichton
Rename .cap() methods to .capacity()
As mentioned in #60316, there are a few `.cap()` methods, which seem out-of-place because such methods are called `.capacity()` in the rest of the code.
This PR renames them to `.capacity()` but leaves `RawVec::cap()` in there for backwards compatibility.
I didn't try to mark the old version as "deprecated", because I guess this would cause too much noise.
Remove `cfg(bootstrap)` code for array implementations
In PR #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.
Pietro Albini [Thu, 25 Jul 2019 09:51:08 +0000 (11:51 +0200)]
ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar
Unfortunately due to an Azure quirk the TOOLSTATE_REPO_ACCESS_TOKEN is
not suitable to gate whether to push new commits to the repo, as if it's
not defined on the Azure side it will actually be set to the literal
`$(TOOLSTATE_REPO_ACCESS_TOKEN)`, which screws everything up.
This instead adds another, non-secret environment variable to gate
publishing: TOOLSTATE_PUBLISH. As non-secret environment variables
behave correctly this fixes the issue.
Auto merge of #62961 - Centril:rollup-kydeswa, r=Centril
Rollup of 9 pull requests
Successful merges:
- #61727 (Add binary dependencies to dep-info files)
- #62736 (Polonius: fix some cases of `killed` fact generation, and most of the `ui` test suite)
- #62758 (ci: Install clang on Windows through tarballs)
- #62784 (Add riscv32i-unknown-none-elf target)
- #62814 (add support for hexagon-unknown-linux-musl)
- #62827 (Don't link mcjit/interpreter LLVM components)
- #62901 (cleanup: Remove `extern crate serialize as rustc_serialize`s)
- #62903 (Support SDKROOT env var on iOS)
- #62906 (Require a value for configure --debuginfo-level)
Failed merges:
- #62910 (cleanup: Remove lint annotations in specific crates that are already enforced by rustbuild)
Rollup merge of #62906 - cuviper:debuginfo-level, r=Mark-Simulacrum
Require a value for configure --debuginfo-level
In `configure.py`, using the `o` function creates an enable/disable
boolean setting, and writes `true` or `false` in `config.toml`. However,
rustbuild is expecting to parse a `u32` debuginfo level. We can change
to the `v` function to have the options require a value.
Rollup merge of #62903 - swolchok:ios-sdkroot, r=alexcrichton
Support SDKROOT env var on iOS
Following what clang does (https://github.com/llvm/llvm-project/blob/296a80102a9b72c3eda80558fb78a3ed8849b341/clang/lib/Driver/ToolChains/Darwin.cpp#L1661-L1678), allow allow SDKROOT to tell us where the Apple SDK lives so we don't have to invoke xcrun.
Rollup merge of #62758 - alexcrichton:llvm-tarball-windows, r=pietroalbini
ci: Install clang on Windows through tarballs
Previously we used the executables built the LLVM project but these
executables are difficult to run in a CI environment, they can
accidentally pollute global state, etc. In testing some of the possible
4-core machine environments for Azure this step would frequently cause
issues.
To assuage these future issues and hopefully make builds slightly more
self-contained, this commit changes to install from a tarball instead.
The tarball isn't provided by LLVM itself, but we use the offical LLVM
installer to extract itself and then we pack up the LLVM installation
directory into the tarball.
Rollup merge of #62736 - lqd:polonius_tests3, r=matthewjasper
Polonius: fix some cases of `killed` fact generation, and most of the `ui` test suite
Since basic Polonius functionality was re-enabled by @matthewjasper in #54468, some tests were still failing in the polonius compare-mode.
This PR fixes all but one test in the `ui` suite by:
- fixing some bugs in the fact generation code, related to the `killed` relation: Polonius would incorrectly reject some NLL-accepted code, because of these missing `killed` facts.
- ignoring some tests in the polonius compare-mode: a lot of those manually test the NLL or migrate mode, and the failures were mostly artifacts of the test revisions, e.g. that `-Z polonius` requires full NLLs. Some others were also both failing with NLL and succeeding with Polonius, which we can't encode in tests at the moment.
- blessing the output of some tests: whenever Polonius and NLL have basically the same errors, except for diagnostics differences, the Polonius output is blessed. Whenever we've advanced into a less experimental phase, we'll want to revisit these cases (much like we did on the NLL test suite last year) to specifically work on diagnostics.
Fact generation changes:
- we now kill loans on the destination place of `Call` terminators
- we now kill loans on the locals destroyed by `StorageDead`
- we now also handle assignments to projections: killing the loans on a either a deref-ed local, or the ones whose `borrowed_place` conflicts with the current place.
One failing test remains: an overflow during fact generation, on a case of polymorphic recursion (and which I'll continue investigating later).
This adds some tests for the fact generation changes, with some simple Polonius cases similar to the existing smoke tests, but also for some cases encountered in the wild (in the `rand` crate for example).
A more detailed write-up is available [here](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?view) with an explanation for each test failure, the steps taken to resolve it (as a commit in the current PR), NLL and Polonius outputs (and diff), etc.
Since they've worked on this before, and we've discussed some of these failures together:
Rollup merge of #61727 - Mark-Simulacrum:crate-deps-in-deps, r=alexcrichton
Add binary dependencies to dep-info files
I'm not sure about the lack of incremental-tracking here, but since I'm pretty sure this runs on every compile anyway it might not matter? If there's a better place/way to get at the information I want, I'm happy to refactor the code to match.
Auto merge of #62935 - Centril:rollup-hzj9att, r=Centril
Rollup of 10 pull requests
Successful merges:
- #62641 (Regenerate character tables for Unicode 12.1)
- #62716 (state also in the intro that UnsafeCell has no effect on &mut)
- #62738 (Remove uses of mem::uninitialized from std::sys::cloudabi)
- #62772 (Suggest trait bound on type parameter when it is unconstrained)
- #62890 (Normalize use of backticks in compiler messages for libsyntax/*)
- #62905 (Normalize use of backticks in compiler messages for doc)
- #62916 (Add test `self-in-enum-definition`)
- #62917 (Always emit trailing slash error)
- #62926 (Fix typo in mem::uninitialized doc)
- #62927 (use PanicMessage in MIR, kill InterpError::description)
projects / rust.git / log