typeck: don't suggest inaccessible private fields
Fixes#76077.
This PR adjusts the missing field diagnostic logic in typeck so that when none of the missing fields in a struct expr are accessible then the error is less confusing.
r? @estebank
Add revisions to const generic issue UI tests.
Fixes#75279.
I have gotten into the flow, so I can do more of these if requested. I'm looking for feedback as to whether my work is on the right track so far.
Syntactically permit unsafety on mods
Similar to https://github.com/rust-lang/rust/pull/66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust.
```rust
#[mymacro]
unsafe mod m {
...
}
#[mymacro]
unsafe extern "C++" {
...
}
```
The intention is that this might be used as a kind of "item-level unsafe" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx.
In the absence of a procedural macro rewriting them to something else, they'll continue to be rejected at compile time though with a better error message than before.
### Before:
```console
error: expected item, found keyword `unsafe`
--> src/main.rs:1:1
|
1 | unsafe mod m {
| ^^^^^^ expected item
```
### After:
```console
error: module cannot be declared unsafe
--> src/main.rs:1:1
|
1 | unsafe mod m {
| ^^^^^^
error: extern block cannot be declared unsafe
--> src/main.rs:4:1
|
4 | unsafe extern "C++" {
| ^^^^^^
```
Closes#68048.
This commit adjusts the missing field diagnostic logic for struct
patterns in typeck to improve the diagnostic when the missing fields are
inaccessible.
Signed-off-by: David Wood <david@davidtw.co>
This commit adjusts the missing field diagnostic logic for struct
expressions in typeck to improve the diagnostic when the missing
fields are inaccessible.
Signed-off-by: David Wood <david@davidtw.co>
ci: avoid moving the build directory on GHA
While waiting for a PR job to start testing my code, I noticed the symlink-build-dir step took 10 minutes to complete, so I investigated what caused that.
It seems like something changed in the build environment between version 20200901.1 (where the step took 45 seconds) and version 20200908.1 (where the step took 10 minutes). At the time of writing this commit, the rust-lang organization is on vertsion 20200908.1, while the rust-lang-ci organization is at version 20200901.1 (and is not affected by this yet).
There is no need for this step anymore on GHA, as our XL builders got an increase in the root paritition size, so this commit removes the code that moved stuff around on GHA (while keeping it on Azure).
For the record, at the time of writing this, the disk situation is:
```
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 667G 60G 607G 9% /
/dev/sdb1 110G 4.1G 101G 4% /mnt
```
r? `@Mark-Simulacrum`
While waiting for a PR job to start testing my code, I noticed the
symlink-build-dir step took 10 minutes to complete, so I investigated
what caused that.
It seems like something changed in the build environment between version
20200901.1 (where the step took 45 seconds) and version 20200908.1
(where the step took 10 minutes). At the time of writing this commit,
the rust-lang organization is on vertsion 20200908.1, while the
rust-lang-ci organization is at version 20200901.1 (and is not affected
by this yet).
There is no need for this step anymore on GHA, as our XL builders got an
increase in the root paritition size, so this commit removes the code
that moved stuff around on GHA (while keeping it on Azure).
For the record, at the time of writing this, the disk situation is:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 667G 60G 607G 9% /
/dev/sdb1 110G 4.1G 101G 4% /mnt
rustbuild: Build tests with LLD if `use-lld = true` was passed
Addresses https://github.com/rust-lang/rust/pull/76127#discussion_r479932392.
Our test suite is generally ready to run with an explicitly specified linker (https://github.com/rust-lang/rust/pull/45191),
so LLD specified with `use-lld = true` works as well.
Only 4 tests fail (on `x86_64-pc-windows-msvc`):
```
ui/panic-runtime/lto-unwind.rs
run-make-fulldeps/debug-assertions
run-make-fulldeps/foreign-exceptions
run-make-fulldeps/test-harness
```
All of them are legitimate issues with LLD (or at least with combination Rust+LLD) and manifest in segfaults on access to TLS (https://github.com/rust-lang/rust/pull/76127#issuecomment-683473325). UPD: These issues are caused by https://github.com/rust-lang/rust/issues/72145 and appear because I had `-Ctarget-cpu=native` set.
UPD: Further commits build tests with LLD for non-MSVC targets and propagate LLD to more places when `use-lld` is enabled.
Add CONST_ITEM_MUTATION lint
Fixes#74053Fixes#55721
This PR adds a new lint `CONST_ITEM_MUTATION`.
Given an item `const FOO: SomeType = ..`, this lint fires on:
* Attempting to write directly to a field (`FOO.field = some_val`) or
array entry (`FOO.array_field[0] = val`)
* Taking a mutable reference to the `const` item (`&mut FOO`), including
through an autoderef `FOO.some_mut_self_method()`
The lint message explains that since each use of a constant creates a
new temporary, the original `const` item will not be modified.
rustbuild: don't set PYTHON_EXECUTABLE and WITH_POLLY cmake vars since they are no longer supported by llvm
This resolves
CMake Warning:
Manually-specified variables were not used by the project:
PYTHON_EXECUTABLE
WITH_POLLY
Add drain_filter method to HashMap and HashSet
Add `HashMap::drain_filter` and `HashSet::drain_filter`, implementing part of rust-lang/rfcs#2140. These new methods are unstable. The tracking issue is #59618.
The added iterators behave the same as `BTreeMap::drain_filter` and `BTreeSet::drain_filter`, except their iteration order is arbitrary. The unit tests are adapted from `alloc::collections::btree`.
This branch rewrites `HashSet` to be a wrapper around `hashbrown::HashSet` rather than `std::collections::HashMap`.
(Both are themselves wrappers around `hashbrown::HashMap`, so the in-memory representation is the same either way.) This lets `std` re-use more iterator code from `hashbrown`. Without this change, we would need to duplicate much more code to implement `HashSet::drain_filter`.
This branch also updates the `hashbrown` crate to version 0.9.0. Aside from changes related to the `DrainFilter` iterators, this version only changes features that are not used in libstd or rustc. And it updates `indexmap` to version 1.6.0, whose only change is compatibility with `hashbrown` 0.9.0.
Move `rustllvm` into `compiler/rustc_llvm`
The `rustllvm` directory is not self-contained, it contains C++ code built by a build script of the `rustc_llvm` crate which is then linked into that crate.
So it makes sense to make `rustllvm` a part of `rustc_llvm` and move it into its directory.
I replaced `rustllvm` with more obvious `llvm-wrapper` as the subdirectory name, but something like `llvm-adapter` would work as well, other suggestions are welcome.
To make things more confusing, the Rust side of FFI functions defined in `rustllvm` can be found in `rustc_codegen_llvm` rather than in `rustc_llvm`. Perhaps they need to be moved as well, but this PR doesn't do that.
The presence of multiple LLVM-related directories in `src` (`llvm-project`, `rustllvm`, `librustc_llvm`, `librustc_codegen_llvm` and their predecessors) historically confused me and made me wonder about their purpose.
With this PR we will have LLVM itself (`llvm-project`), a FFI crate (`rustc_llvm`, kind of `llvm-sys`) and a codegen backend crate using LLVM through the FFI crate (`rustc_codegen_llvm`).
Improve unresolved use error message
"use of undeclared type or module `foo`" doesn't mention that it could be a crate.
This error can happen when users forget to add a dependency to `Cargo.toml`, so I think it's important to mention that it could be a missing crate.
I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter, and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.
VS code graphviz extensions use d3-graphviz, which supports `Courier`
fontname but does not support `monospace`. This caused graphs to render
poorly because the text sizes were wrong.
make `ConstEvaluatable` more strict
relevant zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/.60ConstEvaluatable.60.20generic.20functions/near/204125452
Let's see how much this impacts. Depending on how this goes this should probably be a future compat warning.
Short explanation: we currently forbid anonymous constants which depend on generic types, e.g. `[0; std::mem::size_of::<T>]` currently errors.
We previously checked this by evaluating the constant and returned an error if that failed. This however allows things like
```rust
const fn foo<T>() -> usize {
if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
std::mem::size_of::<T>()
} else {
8
}
}
fn test<T>() {
let _ = [0; foo::<T>()];
}
```
which is a backwards compatibility hazard. This also has worrying interactions with mir optimizations (https://github.com/rust-lang/rust/pull/74491#issuecomment-661890421) and intrinsics (#74538).
r? `@oli-obk` `@eddyb`
Make rustdoc output deterministic for UI tests
Closes https://github.com/rust-lang/rust/issues/76442 (hopefully, since it's non-deterministic I don't have a way to test).
r? `@Mark-Simulacrum`
cc `@GuillaumeGomez`
rustdoc: Fix font CSS for crate lists
I had put it in the wrong file in #76126. This should fix it now. Thank
you to `@ollie27` for pointing this out!
---
`@rustbot` modify labels: T-rustdoc C-bug
Update cargo
8 commits in 126907a7cfccbe93778530e6a6bbaa3adb6c515c..875e0123259b0b6299903fe4aea0a12ecde9324f
2020-08-31 20:42:11 +0000 to 2020-09-08 20:17:21 +0000
- Lowercase and remove periods in error messages for consistency (rust-lang/cargo#8655)
- Allow running build-man.sh from any directory (rust-lang/cargo#8682)
- docs: add details for cargo check pass where cargo build fail (rust-lang/cargo#8677)
- Fix nightly exported_priv_warning test. (rust-lang/cargo#8678)
- fix mdbook test with ```ignore/text/sh/console (rust-lang/cargo#8674)
- End CACHEDIR.TAG with newline (rust-lang/cargo#8672)
- Fixed the fossil repo initialization actually run commands (rust-lang/cargo#8671)
- Remove asciidoc attribute in cargo-metadata man page. (rust-lang/cargo#8670)
Add help note to unconstrained const parameter
Resolves#68366, since it is currently intended behaviour.
If demonstrating `T -> U` is injective, there should be an additional word that it is not **yet** supported.
r? @lcnr
Fix HashMap visualizers in Visual Studio (Code)
CDB (as used in unit tests) doesn't care that we're using static_cast between unrelated types (`u8*` to `tuple<$T1, $T2>*`).
Visual Studio & Visual Studio Code care. These should've been reinterpret_cast or C casts.
Credit to @petrochenkov per https://github.com/rust-lang/rust/issues/76352 for helping catch this.
### Testing
```cmd
x.py test --stage 1 src/tools/tidy
x.py test --stage 1 --build x86_64-pc-windows-msvc src\test\debuginfo
```
We no longer lint assignments to const item fields in the
`temporary_assignment` lint, since this is now covered by the
`CONST_ITEM_MUTATION` lint.
Additionally, we `#![allow(const_item_mutation)]` in the
`borrow_interior_mutable_const.rs` test. Clippy UI tests are run with
`-D warnings`, which seems to cause builtin lints to prevent Clippy
lints from running.
Add rust-dev component to support rustc development
This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM, CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date, and carries all necessary patches.
This is a separate PR from #76349 because it needs to land before that one, since we want a master build with the full CI LLVM to be available for easier testing.
