Auto merge of #54247 - Munksgaard:better-error-message-in-no_lookup_host_duplicates, r=alexcrichton
Improve output if no_lookup_host_duplicates test fails
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
Auto merge of #53461 - petrochenkov:pmu, r=alexcrichton
resolve: Do not error on access to proc macros imported with `#[macro_use]`
This error is artificial, but previously, when `#[macro_use] extern crate x;` was stable, but non-derive proc macros were not, it worked like kind of a feature gate. Now both features are stable, so the error is no longer necessary.
This PR simplifies how `#[macro_use] extern crate x;` works - it takes all items from macro namespace of `x`'s root and puts them into macro prelude from which they all can now be accessed.
Auto merge of #53804 - RalfJung:ptr-invalid, r=nagisa
fix some uses of pointer intrinsics with invalid pointers
[Found by miri](https://github.com/solson/miri/pull/446):
* `Vec::into_iter` calls `ptr::read` (and the underlying `copy_nonoverlapping`) with an unaligned pointer to a ZST. [According to LLVM devs](https://bugs.llvm.org/show_bug.cgi?id=38583), this is UB because it contradicts the metadata we are attaching to that pointer.
* `HashMap` creation calls `ptr:.write_bytes` on a NULL pointer with a count of 0. This is likely not currently UB *currently*, but it violates the rules we are setting in https://github.com/rust-lang/rust/pull/53783, and we might want to exploit those rules later (e.g. with more `nonnull` attributes for LLVM).
Probably what `HashMap` really should do is use `NonNull::dangling()` instead of 0 for the empty case, but that would require a more careful analysis of the code.
It seems like ideally, we should do a review of usage of such intrinsics all over libstd to ensure that they use valid pointers even when the size is 0. Is it worth opening an issue for that?
Auto merge of #54157 - euclio:structured-suggestion, r=estebank
use structured suggestion for "missing mut" label
Fixes #54133 for both NLL and non-NLL.
r? @estebank
I'm not super happy with the existing wording here, since it's now a suggestion. I wonder if the message would work better as something like "help: make binding mutable: `mut foo`"?
Also, are the `HELP` and `SUGGESTION` comments necessary?
Auto merge of #53754 - RalfJung:slice_align_to, r=alexcrichton
stabilize slice_align_to
This is very hard to implement correctly, and leads to [serious bugs](https://github.com/llogiq/bytecount/pull/42) when done incorrectly. Moreover, this is needed to be able to run code that opportunistically exploits alignment on miri. So code using `align_to`/`align_to_mut` gets the benefit of a well-tested implementation *and* of being able to run in miri to test for (some kinds of) UB.
This PR also clarifies the guarantee wrt. the middle part being as long as possible. Should the docs say under which circumstances the middle part could be shorter? Currently, that can only happen when running in miri.
Auto merge of #54116 - eddyb:extern-prelude, r=petrochenkov
rustc_resolve: allow only core, std, meta and --extern in Rust 2018 paths.
As per https://github.com/rust-lang/rust/issues/53166#issuecomment-419265401:
* Rust 2018 imports can no longer refer to crates not in "extern prelude"
* `::foo` won't load a crate named `foo` unless `foo` is in the "extern prelude"
* `extern crate foo;`, however, remains unchanged (can load arbitrary crates)
* `--extern crate_name` is added (note the lack of `=path`) as an unstable option
* adds `crate_name` to the "extern prelude" (see above)
* crate is searched in sysroot & library paths, just like `extern crate crate_name`.
* `Cargo` support will be added later
* `core`, `std` and ~~`proc_macro`~~ `meta` are *always* available in the extern prelude
* warning for interaction with `no_std` / `no_core` will be added later
* **EDIT**: `proc_macro` was replaced by `meta`, see https://github.com/rust-lang/rust/issues/53166#issuecomment-421137230
* note that there is no crate named `meta` being added, so `use meta::...;` will fail, we're only whitelisting it so we can start producing `uniform_paths` compatibility errors
Fixes #54006 (as the example now requires `--extern alloc`, which is unstable).
Fixes #54253 (hit during fixing RLS).
r? @petrochenkov cc @aturon @alexcrichton @Centril @joshtriplett
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
Auto merge of #54151 - ljedrz:cleanup_hir, r=michaelwoerister
A few cleanups for hir
- prefer `if let` to `match` when only 1 branch matters
- `chain` iterable items that are looped over in sequence
- `sort_by_key` instead of `sort_by` when possible
- change cloning `map`s to `cloned()`
- use `unwrap_or_else` and `ok` when applicable
- a few other minor readability improvements
- whitespace fixes
Auto merge of #54069 - petrochenkov:subns, r=aturon
resolve: Introduce two sub-namespaces in macro namespace
Two sub-namespaces are introduced in the macro namespace - one for bang macros and one for attribute-like macros (attributes, derives).
"Sub-namespace" means this is not a newly introduced full namespace, the single macro namespace is still in place.
I.e. you still can't define/import two macros with the same name in a single module, `use` imports still import only one name in macro namespace (from any sub-namespace) and not possibly two.
However, when we are searching for a name used in a `!` macro call context (`my_macro!()`) we skip attribute names in scope, and when we are searching for a name used in attribute context (`#[my_macro]`/`#[derive(my_macro)]`) we are skipping bang macro names in scope.
In other words, bang macros cannot shadow attribute macros and vice versa.
For a non-macro analogy, we could e.g. skip non-traits when searching for `MyTrait` in `impl MyTrait for Type { ... }`.
However we do not do it in non-macro namespaces because we don't have practical issues with e.g. non-traits shadowing traits with the same name, but with macros we do, especially after macro modularization.
For `#[test]` and `#[bench]` we have a hack in the compiler right now preventing their shadowing by `macro_rules! test` and similar things. This hack was introduced after making `#[test]`/`#[bench]` built-in macros instead of built-in attributes (https://github.com/rust-lang/rust/pull/53410), something that needed to be done from the start since they are "active" attributes transforming their inputs.
Now they are passed through normal name resolution and can be shadowed, but that's a breaking change, so we have a special hack basically applying this PR for `#[test]` and `#[bench]` only.
Soon all potentially built-in attributes will be passed through normal name resolution (https://github.com/rust-lang/rust/pull/53913) and that uncovers even more cases where the strict "macro namespace is a single namespace" rule needs to be broken.
For example, with strict rules, built-in macro `cfg!(...)` would shadow built-in attribute `#[cfg]` (they are different things), standard library macro `thread_local!(...)` would shadow built-in attribute `#[thread_local]` - both of these cases are covered by special hacks in https://github.com/rust-lang/rust/pull/53913 as well.
Crater run uncovered more cases of attributes being shadowed by user-defined macros (`warn`, `doc`, `main`, even `deprecated`), we cannot add exceptions in the compiler for all of them.
Regressions with user-defined attributes like https://github.com/rust-lang/rust/issues/53583 and https://github.com/rust-lang/rust/issues/53898 also appeared after enabling macro modularization.
People are also usually confused (https://github.com/rust-lang/rust/issues/53205#issuecomment-411552763, https://github.com/rust-lang/rust/issues/53583#issuecomment-415447800) when they see conflicts between attributes and non-attribute macros for the first time.
So my proposed solution is to solve this issue by introducing two sub-namespaces and thus skipping resolutions of the wrong kind and preventing more error-causing cases of shadowing.
Auto merge of #54201 - eddyb:reflexive-disambiguation, r=petrochenkov
rustc_resolve: don't treat uniform_paths canaries as ambiguities unless they resolve to distinct Def's.
In particular, this allows this pattern that @cramertj mentioned in https://github.com/rust-lang/rust/issues/53130#issuecomment-420848814:
```rust
use log::{debug, log};
fn main() {
use log::{debug, log};
debug!(...);
}
```
The canaries for the inner `use log::...;`, *in the macro namespace*, see the `log` macro imported at the module scope, and the (same) `log` macro, imported in the block scope inside `main`.
Previously, these two possible (macro namspace) `log` resolutions would be considered ambiguous (from a forwards-compat standpoint, where we might make imports aware of block scopes).
With this PR, such a case is allowed *if and only if* all the possible resolutions refer to the same definition (more specifically, because the *same* `log` macro is being imported twice).
This condition subsumes previous (weaker) checks like #54005 and the second commit of #54011.
Only the last commit is the main change, the other two are cleanups.
Auto merge of #54088 - matthewjasper:use-reason-in-dlle-errors, r=pnkfelix
[NLL] Suggest let binding
Closes #49821
Also adds an alternative to `explain_why_borrow_contains_point` that allows changing error messages based on the reason that will be given. This will also be useful for #51026, #51169 and maybe further changes to does not live long enough messages.
- #53218 (Add a implementation of `From` for converting `&'a Option<T>` into `Option<&'a T>`)
- #54024 (Fix compiling some rustc crates to wasm)
- #54095 (Rename all mentions of `nil` to `unit`)
- #54173 (Suggest valid crate type if invalid crate type is found)
- #54194 (Remove println!() statement from HashMap unit test)
- #54203 (Fix the stable release of os_str_str_ref_eq)
- #54207 (re-mark the never docs as unstable)
- #54210 (Update Cargo)
This stability attribute was removed in https://github.com/rust-lang/rust/pull/47630, but not replaced with a `#[stable]` attribute, and when https://github.com/rust-lang/rust/pull/50121 reverted that stabilization, it didn't set the docs back to unstable. I'm concerned as to why it was allowed to not have the stability attribute at all, but at least this can put it back.
I'm nominating this for beta backport because it's a really small change, and right now our docs are in an awkward position where the `!` type is technically unstable to use, but the docs don't say so the same way any other library feature would. (And this is also the case *on stable* now, but i'm not suggesting a stable backport for a docs fix.)
Rollup merge of #54024 - alexcrichton:compile-to-wasm, r=petrochenkov
Fix compiling some rustc crates to wasm
I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:
* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
platforms.
In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!
- #53371 (Do not emit E0277 on incorrect tuple destructured binding)
- #53829 (Add rustc SHA to released DWARF debuginfo)
- #53950 (Allow for opting out of ThinLTO and clean up LTO related cli flag handling.)
- #53976 (Replace unwrap calls in example by expect)
- #54070 (Add Error::description soft-deprecation to RELEASES)
- #54076 (miri loop detector hashing)
- #54119 (Add some unit tests for find_best_match_for_name)
- #54147 (Add a test that tries to modify static memory at compile-time)
- #54150 (Updated 1.29 release notes with --document-private-items flag)
- #54163 (Update stage 0 to latest beta)
- #54170 (COMPILER_TESTS.md has been moved)
Rollup merge of #53950 - michaelwoerister:more-lto-cli, r=alexcrichton
Allow for opting out of ThinLTO and clean up LTO related cli flag handling.
It turns out that there currently is no way to explicitly disable ThinLTO (except for the nightly-only `-Zthinlto` flag). This PR extends `-C lto` to take `yes` and `no` in addition to `thin` and `fat`. It should be backwards compatible.
It also cleans up how LTO mode selection is handled.
Note that merging the PR in the current state would make the new values for `-C lto` available on the stable channel. I think that would be fine but maybe some team should vote on it.
Rollup merge of #53829 - alexcrichton:release-debuginfo, r=michaelwoerister
Add rustc SHA to released DWARF debuginfo
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
Rollup merge of #54119 - phansch:unit_test_find_best_match_for_name, r=nikomatsakis
Add some unit tests for find_best_match_for_name
There were only some UI tests that covered this function.
Since there's more diagnostic work going on, I think it makes
sense to have this unit tested.
Rollup merge of #54076 - RalfJung:miri-snapshot, r=oli-obk
miri loop detector hashing
* fix enum hashing to also consider discriminant
* do not hash extra machine state
* standalone miri is not interested in loop detection, so let it opt-out
In the future I think we want to move the hashing logic out of the miri engine, this is CTFE-only.
Auto merge of #53621 - jordanrh1:windows-arm, r=alexcrichton
Add target thumbv7a-pc-windows-msvc
This is an early draft of support for Windows/ARM. To test it,
1. Install Visual Studio 2017 and Windows SDK version 17134.
1. Obtain alexcrichton/xz2-rs#35, rust-lang-nursery/compiler-builtins#256, and the fix for [LLVM Bug 38620](https://bugs.llvm.org/show_bug.cgi?id=38620).
2. Open a command prompt and run
```
set CC_thumbv7a-pc-windows-msvc=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\CL.exe
set CFLAGS_thumbv7a-pc-windows-msvc=/D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /nologo
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc
```
It will build the stage 2 compiler, but fail building stage 2 test. To build an executable targeting windows/arm,
1. Copy `build\x86_64-pc-windows-msvc\stage0\bin\cargo.exe` to `build\x86_64-pc-windows-msvc\stage2\bin`
2. Open a command prompt and run
```
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
set PATH=build\x86_64-pc-windows-msvc\stage2\bin;%PATH%
cargo new hello
cd hello
cargo build --target thumbv7a-pc-windows-msvc –release
```
Copy target\thumbv7a-pc-windows-msvc\release\hello.exe to your platform and run.
There are a number of open issues that I'm hoping to get help with:
- Error when compiling the `test` crate: `error: cannot link together two panic runtimes: panic_abort and panic_unwind`
- Warnings when building the compiler_builtins crate: `warning: cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'`. It looks like the build system is passing GCC-style flags to MSVC.
- How to specify the LIBPATH entries for ARM. Right now they are hardcoded as absolute paths in the target spec.
This pull request depends on
- alexcrichton/xz2-rs#35 - update vcxproj to Visual Studio 2017
- rust-lang-nursery/compiler-builtins#256 - fix compile errors when building for windows/arm
- [Bug 38620 - ARM: Incorrect COFF relocation type for thumb bl instruction](https://bugs.llvm.org/show_bug.cgi?id=38620)
- It moves parts of bitslice.rs into bitvec.rs: `bitwise()`,
`BitwiseOperator`, `bits_to_string()`.
- It changes `IdxSet` to just be a wrapper around `BitArray`.
- It changes `BitArray` and `BitVec` to use `usize` words instead of
`u128` words. (`BitSlice` and `IdxSet` already use `usize`.) Local
profiling showed `usize` was better.
- It moves some operations from `IdxSet` into `BitArray`:
`new_filled()`, `clear()`, `set_up_to()`, `trim_to()` (renamed
`clear_above()`), `words()` and `words_mut()`, `encode()` and
`decode(). The `IdxSet` operations now just call the `BitArray`
operations.
- It replaces `BitArray`'s iterator implementation with `IdxSet`'s,
because the latter is more concise. It also removes the buggy
`size_hint` function from `BitArray`'s iterator, which counted the
number of *words* rather than the number of *bits*. `IdxSet`'s
iterator is now just a thin wrapper around `BitArray`'s iterator.
- It moves some unit tests from `indexed_set.rs` to `bitvec.rs`.
Auto merge of #54086 - petrochenkov:derhelp, r=alexcrichton
resolve: Future proof derive helper attributes
Derive helpers no longer require going through recovery mode (fixes https://github.com/rust-lang/rust/issues/53481).
They also report an error if they are ambiguous with any other macro in scope, so we can resolve the question about their exact priority sometime later (cc https://github.com/rust-lang/rust/issues/52226).
projects / rust.git / log