Remove `masked_crates` from `clean::Crate`
Previously, `masked_crates` existed both on `Cache` and on
`clean::Crate`. During cache population, the `clean::Crate` version was
`take`n and moved to `Cache`.
This change removes the version on `clean::Crate` and instead directly
mutates `Cache.masked_crates` to initialize it. This has the advantage
of avoiding duplication and avoiding unnecessary allocation, as well as
making the flow of information through rustdoc less confusing.
The one downside I see is that `clean::utils::krate()` now uses the side
effect of mutating `DocContext.cache` instead of returning the data
directly, but it already mutated the `Cache` for other things (e.g.,
`deref_trait_did`) so it's not really new behavior. Also,
`clean::utils::krate()` is only called once (and is meant to only be
called once since it performs expensive and potentially destructive
operations) so the mutation shouldn't be an issue.
Follow-up to https://github.com/rust-lang/rust/pull/82018#discussion_r584197747.
cc `@jyn514`
Rollup of 9 pull requests
Successful merges:
- #81309 (always eagerly eval consts in Relate)
- #82217 (Edition-specific preludes)
- #82807 (rustdoc: Remove redundant enableSearchInput function)
- #82924 (WASI: Switch to crt1-command.o to enable support for new-style commands)
- #82949 (Do not attempt to unlock envlock in child process after a fork.)
- #82955 (fix: wrong word)
- #82962 (Treat header as first paragraph for shortened markdown descriptions)
- #82976 (fix error message for copy(_nonoverlapping) overflow)
- #82977 (Rename `Option::get_or_default` to `get_or_insert_default`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Treat header as first paragraph for shortened markdown descriptions
"The Rust Standard LibraryThe Rust Standard Library is the …" is an awful description.
Do not attempt to unlock envlock in child process after a fork.
This implements the first two points from https://github.com/rust-lang/rust/issues/64718#issuecomment-793030479
This is a breaking change for cases where the environment is accessed in a Command::pre_exec closure. Except for single-threaded programs these uses were not correct anyway since they aren't async-signal safe.
Note that we had a ui test that explicitly tried `env::set_var` in `pre_exec`. As expected it failed with these changes when I tested locally.
WASI: Switch to crt1-command.o to enable support for new-style commands
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.
See here for more information on new-style commands:
- https://github.com/WebAssembly/wasi-libc/pull/203
- https://reviews.llvm.org/D81689
r? ```@alexcrichton```
rustdoc: Remove redundant enableSearchInput function
enableSearchInput was called from two places:
- setupSearchLoader
- addSearchOptions, which is itself called from setupSearchLoader only
This commit can safely get rid of the addSearchOptions calls entirely, and since the setupSearchLoader call is immediately preceded by other method calls on search_input, there's no need to check if it's set.
Edition-specific preludes
This changes `{std,core}::prelude` to export edition-specific preludes under `rust_2015`, `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*`, but this allows us to add things to the 2021edition prelude soon.
This also changes the compiler to make the automatically injected prelude import dependent on the selected edition.
cc `@rust-lang/libs` `@djc`
Implement RFC 2945: "C-unwind" ABI
## Implement RFC 2945: "C-unwind" ABI
This branch implements [RFC 2945]. The tracking issue for this RFC is #74990.
The feature gate for the issue is `#![feature(c_unwind)]`.
This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.
### Changes
Further details will be provided in commit messages, but a high-level overview
of the changes follows:
* A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI boundaries is
acceptable. The cases where each of these variants' `unwind` member is true
correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and
`thiscall-unwind` ABI strings introduced in RFC 2945 [3].
* This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`, which
ensure that this feature gate works correctly for each of the new ABIs.
A new language features entry in the unstable book is added as well.
* We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a function that
should be able to unwind when `panic=unwind` is in use.
* Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the function ABI is
used to determind whether it should abort, assuming that the `panic=unwind`
strategy is being used, and no explicit unwind attribute was provided.
[RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
Remove the -Zinsert-sideeffect
This removes all of the code we had in place to work-around LLVM's
handling of forward progress. From this removal excluded is a workaround
where we'd insert a `sideeffect` into clearly infinite loops such as
`loop {}`. This code remains conditionally effective when the LLVM
version is earlier than 12.0, which fixed the forward progress related
miscompilations at their root.
This removes all of the code we had in place to work-around LLVM's
handling of forward progress. From this removal excluded is a workaround
where we'd insert a `sideeffect` into clearly infinite loops such as
`loop {}`. This code remains conditionally effective when the LLVM
version is earlier than 12.0, which fixed the forward progress related
miscompilations at their root.
Store HIR attributes in a side table
Same idea as #72015 but for attributes.
The objective is to reduce incr-comp invalidations due to modified attributes.
Notably, those due to modified doc comments.
Implementation:
- collect attributes during AST->HIR lowering, in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables;
- access the attributes through a `hir_owner_attrs` query;
- local refactorings to use this access;
- remove `attrs` from HIR data structures one-by-one.
Change in behaviour:
- the HIR visitor traverses all attributes at once instead of parent-by-parent;
- attribute arrays are sometimes duplicated: for statements and variant constructors;
- as a consequence, attributes are marked as used after unused-attribute lint emission to avoid duplicate lints.
~~Current bug: the lint level is not correctly applied in `std::backtrace_rs`, triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~
Previously, `masked_crates` existed both on `Cache` and on
`clean::Crate`. During cache population, the `clean::Crate` version was
`take`n and moved to `Cache`.
This change removes the version on `clean::Crate` and instead directly
mutates `Cache.masked_crates` to initialize it. This has the advantage
of avoiding duplication and avoiding unnecessary allocation, as well as
making the flow of information through rustdoc less confusing.
The one downside I see is that `clean::utils::krate()` now uses the side
effect of mutating `DocContext.cache` instead of returning the data
directly, but it already mutated the `Cache` for other things (e.g.,
`deref_trait_did`) so it's not really new behavior. Also,
`clean::utils::krate()` is only called once (and is meant to only be
called once since it performs expensive and potentially destructive
operations) so the mutation shouldn't be an issue.
RFC 1240 states that it is unsafe to capture references into a
packed-struct. This PR ensures that when a closure captures a precise
path, we aren't violating this safety constraint.
To acheive so we restrict the capture precision to the struct itself.
An interesting edge case:
```rust
struct Foo(String);
let foo: Foo;
let c = || {
println!("{}", foo.0);
let x = foo.0;
}
```
Given how closures get desugared today, foo.0 will be moved into the
closure, making the `println!`, safe. However this can be very subtle
and also will be unsafe if the closure gets inline.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/33
Bump tracing-tree dependency
This bump fixes two small rendering things that were annoying me:
* The first level didn't have an opening line
* When wraparound happens, there was no warning, the levels just disappeared. Now there is a line that shows that wraparound is happening
See https://github.com/davidbarsky/tracing-tree/pull/31/files for how the look changes
Build rustdoc for run-make tests, not just run-make-fulldeps
Rustdoc almost never needs a full stage 2 compiler, and requiring
rustdoc tests to be in run-make-fulldeps adds a lot of compile time for
no reason.
This is the same change from https://github.com/rust-lang/rust/pull/81197, but separated into its own PR. I ran into this again today while working on https://github.com/rust-lang/docs.rs/issues/1302.
r? ```@Mark-Simulacrum```
Stabilize `unsafe_op_in_unsafe_fn` lint
This makes it possible to override the level of the `unsafe_op_in_unsafe_fn`, as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896.
Tracking issue: #71668
r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung```
# Stabilization report
This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`.
## Summary
Currently, the body of unsafe functions is an unsafe block, i.e. you can perform unsafe operations inside.
The `unsafe_op_in_unsafe_fn` lint, stabilized here, can be used to change this behavior, so performing unsafe operations in unsafe functions requires an unsafe block.
For now, the lint is allow-by-default, which means that this PR does not change anything without overriding the lint level.
For more information, see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md)
### Example
```rust
// An `unsafe fn` for demonstration purposes.
// Calling this is an unsafe operation.
unsafe fn unsf() {}
// #[allow(unsafe_op_in_unsafe_fn)] by default,
// the behavior of `unsafe fn` is unchanged
unsafe fn allowed() {
// Here, no `unsafe` block is needed to
// perform unsafe operations...
unsf();
// ...and any `unsafe` block is considered
// unused and is warned on by the compiler.
unsafe {
unsf();
}
}
#[warn(unsafe_op_in_unsafe_fn)]
unsafe fn warned() {
// Removing this `unsafe` block will
// cause the compiler to emit a warning.
// (Also, no "unused unsafe" warning will be emitted here.)
unsafe {
unsf();
}
}
#[deny(unsafe_op_in_unsafe_fn)]
unsafe fn denied() {
// Removing this `unsafe` block will
// cause a compilation error.
// (Also, no "unused unsafe" warning will be emitted here.)
unsafe {
unsf();
}
}
```
This is a breaking change for cases where the environment is
accessed in a Command::pre_exec closure. Except for
single-threaded programs these uses were not correct
anyway since they aren't async-signal safe.
### Add debug assertion to check `AbiDatas` ordering
This makes a small alteration to `Abi::index`, so that we include a
debug assertion to check that the index we are returning corresponds
with the same abi in our data array.
This will help prevent ordering bugs in the future, which can
manifest in rather strange errors.
### Using exhaustive ABI matches
This slightly modifies the changes from our previous commits,
favoring exhaustive matches in place of `_ => ...` fall-through
arms.
This should help with maintenance in the future, when additional
ABI's are added, or when existing ABI's are modified.
### List all `-unwind` ABI's in unstable book
This updates the `c-unwind` page in the unstable book to list _all_
of the other ABI strings that are introduced by this feature gate.
Now, all of the ABI's specified by RFC 2945 are shown.
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
### Integration Tests
This commit introduces some new fixtures to the `run-make-fulldeps`
test suite.
* c-unwind-abi-catch-panic: Exercise unwinding a panic. This
catches a panic across an FFI boundary and downcasts it into
an integer.
* c-unwind-abi-catch-lib-panic: This is similar to the previous
`*catch-panic` test, however in this case the Rust code that
panics resides in a separate crate.
### Add `rust_eh_personality` to `#[no_std]` alloc tests
This commit addresses some test failures that now occur in the
following two tests:
* no_std-alloc-error-handler-custom.rs
* no_std-alloc-error-handler-default.rs
Each test now defines a `rust_eh_personality` extern function, in
the same manner as shown in the "Writing an executable without
stdlib" section of the `lang_items` documentation here:
https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib
Without this change, these tests would fail to compile due to a
linking error explaining that there was an "undefined reference
to `rust_eh_personality'."
### Updated hash
* update 32-bit hash in `impl1` test
### Panics
This commit uses `panic!` macro invocations that return a string,
rather than using an integer as a panic payload.
Doing so avoids the following warnings that were observed during
rollup for the `*-msvc-1` targets:
```
warning: panic message is not a string literal
--> panic.rs:10:16
|
10 | panic!(x); // That is too big!
| ^
|
= note: `#[warn(non_fmt_panic)]` on by default
= note: this is no longer accepted in Rust 2021
help: add a "{}" format string to Display the message
|
10 | panic!("{}", x); // That is too big!
| ^^^^^
help: or use std::panic::panic_any instead
|
10 | std::panic::panic_any(x); // That is too big!
| ^^^^^^^^^^^^^^^^^^^^^
warning: 1 warning emitted
```
See: https://github.com/rust-lang-ci/rust/runs/1992118428
As these errors imply, panicking without a format string will be
disallowed in Rust 2021, per #78500.
### Changes
This commit implements unwind ABI's, specified in RFC 2945.
We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a
function that should be able to unwind when `panic=unwind` is in
use.
Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the
function ABI is used to determind whether it should abort, assuming
that the `panic=unwind` strategy is being used, and no explicit
unwind attribute was provided.
### Tests
Unit tests, checking that the behavior is correct for `C-unwind`,
`stdcall-unwind`, `system-unwind`, and `thiscall-unwind`, are
included. These alternative `unwind` ABI strings are specified in
RFC 2945, in the "_Other `unwind` ABI strings_" section.
Additionally, a test case is included to assert that the LLVM IR
generated for an external function defined with the `C-unwind` ABI
will be appropriately labeled with the `nounwind` LLVM attribute
when the `panic=abort` compilation flag is used.
### Ignore Directives
This commit uses `ignore-*` directives in two of our `*-unwind` ABI
test cases.
Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
ignore architectures that do not support `stdcall` and `thiscall`,
respectively.
These directives are cribbed from
`src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
`src/test/ui/extern/extern-thiscall.rs` for `thiscall`.
### Overview
This commit begins the implementation work for RFC 2945. For more
information, see the rendered RFC [1] and tracking issue [2].
A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI
boundaries is acceptable. The cases where each of these variants'
`unwind` member is true correspond with the `C-unwind`,
`system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
introduced in RFC 2945 [3].
### Feature Gate and Unstable Book
This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`,
which ensure that this feature gate works correctly for each of the
new ABIs.
A new language features entry in the unstable book is added as well.
### Further Work To Be Done
This commit does not proceed to implement the new unwinding ABIs,
and is intentionally scoped specifically to *defining* the ABIs and
their feature flag.
### One Note on Test Churn
This will lead to some test churn, in re-blessing hash tests, as the
deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
because we can no longer guarantee the ordering of the `Abi`
variants.
While this is a downside, this decision was made bearing in mind
that RFC 2945 states the following, in the "Other `unwind` Strings"
section [3]:
> More unwind variants of existing ABI strings may be introduced,
> with the same semantics, without an additional RFC.
Adding a new variant for each of these cases, rather than specifying
a payload for a given ABI, would quickly become untenable, and make
working with the `Abi` enum prone to mistakes.
This approach encodes the unwinding information *into* a given ABI,
to account for the future possibility of other `-unwind` ABI
strings.
### Ignore Directives
`ignore-*` directives are used in two of our `*-unwind` ABI test
cases.
Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
ignore architectures that do not support `stdcall` and
`thiscall`, respectively.
These directives are cribbed from
`src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
`src/test/ui/extern/extern-thiscall.rs` for `thiscall`.
This would otherwise fail on some targets, see:
fcf697f902
### Footnotes
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
This updates all places where match branches check on StatementKind or UseContext.
This doesn't properly implement them, but adds TODOs where they are, and also adds some best
guesses to what they should be in some cases.
Update Cargo
Output of `git log --oneline c68432f1e..970bc67c3`:
970bc67c3 (HEAD, origin/master, origin/auto-cargo, origin/HEAD) Auto merge of #9243 - wickerwaka:configurable-env-doc, r=ehuss
4d7a29b75 Document the configurable-env usntable option
f7a7a3f91 Auto merge of #9229 - alexcrichton:fix-borrow-mut, r=ehuss
3f2ece7a9 Fix a `BorrowMut` error when stdout is closed
7441e8c23 Auto merge of #8825 - Aaron1011:feature/report-future-incompat, r=ehuss
139ed73f5 Add future-incompat tracking issue number.
9ea350368 Fix some minor formatting issues.
f03d47ce4 Address review comments
6177c6584 Implement future incompatibility report support
c69409658 Auto merge of #9022 - nagisa:nagisa/manifest_path, r=alexcrichton
548300b20 Add the path to the manifest in json output
99e714c05 Auto merge of #9230 - kornelski:nobinaries, r=alexcrichton
61a31bc5f Auto merge of #9236 - kornelski:track-assert, r=Eh2406
3f7f0942c track_caller on custom assert functions
6977dee10 Explain `cargo install` is not for libraries
e4aebf0a0 Auto merge of #9231 - joshtriplett:clear-to-eol-if-color, r=alexcrichton
b219f0eb7 Auto merge of #9181 - jyn514:computer-says-no, r=ehuss
0b1816578 Remove unhelpful link to Cargo book
ea46f5ce3 Use ANSI clear-to-EOL if color is force-enabled
a6394bcc1 Remove unnecessary `config` argument to `Features::add`
3a86ecf2d Fix TODO about nightly features
09677c83c Be less unix-centric in error messages
ecfdced0d Fix test that assumed tests always were run on the stable channel
eba541994 Update comment in build_script_env
a5720117f Make `nightly_features_allowed` a field instead of a function
169b09ce7 Compute `enable_nightly_features` once instead of on each call
8fc86e155 Remove unused thread_locals
4b096beae Fix `masquerade_as_nightly_cargo` in work threads
e56417c8c Suggest RUSTC_BOOTSTRAP=crate instead of RUSTC_BOOTSTRAP=1
418129dae Downgrade error to a warning when `RUSTC_BOOTSTRAP` is set or this is the nightly channel
6c422a2c0 Restrict RUSTC_BOOTSTRAP in build.rs
Change x64 size checks to not apply to x32.
Rust contains various size checks conditional on target_arch = "x86_64", but these checks were never intended to apply to x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the conditions.
or-patterns: disallow in `let` bindings
~~Blocked on https://github.com/rust-lang/rust/pull/81869~~
Disallows top-level or-patterns before type ascription. We want to reserve this syntactic space for possible future generalized type ascription.
r? ``@petrochenkov``
rustdoc: Cleanup `html::render::Context`
- Move most shared fields to `SharedContext` (except for `cache`, which
isn't mutated anyway)
- Replace a use of `Arc` with `Rc`
- Make a bunch of fields private
- Add static size assertion for `Context`
- Don't share `id_map` and `deref_id_map`
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.
See here for more information on new-style commands:
- https://github.com/WebAssembly/wasi-libc/pull/203
- https://reviews.llvm.org/D81689
diagnostics: Be clear about "crate root" and `::foo` paths in resolve diagnostics
Various changes to make sure the diagnostics are clear about the differences in `::foo` paths across editions:
- `::foo` will say "crate root" in 2015 and "list of imported crates" in 2018
- `crate::` will never reference imported crates in 2018
Fixes https://github.com/rust-lang/rust/issues/82876
Update minifier dependency version
Very small PR simply upgrading the minifier-rs version we use in rustdoc.
Some details might be useful: there were a few bug fixes and a lot of cleanup/code improvements.
r? `@camelid`
Let Cargo track CLIPPY_ARGS
This PR makes `clippy-driver` emit `CLIPPY_ARGS` in its `dep-info` output.
Just like #6441, this allows this workflow to work:
```shell
cargo clippy # warning: empty `loop {}` wastes CPU cycles
cargo clippy -- -A clippy::empty_loop # no warnings emitted
```
But without rebuilding all dependencies.
cc https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/CLIPPY_ARGS.20is.20not.20tracked.20by.20Cargo/near/228599088
changelog: Cargo now re-runs Clippy if arguments after `--` provided to `cargo clippy` are changed.
Disable destination propagation on all mir-opt-levels
The new `// compile-flags: -Zunsound-mir-opts` are inserted without an extra newline to avoid introducing a large mir-opt diff.
Implement built-in attribute macro `#[cfg_eval]` + some refactoring
This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in https://github.com/rust-lang/rust/pull/79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes.
The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input).
The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items.
`cfg_eval` was the first name suggested in https://github.com/rust-lang/rust/pull/79078, but other alternatives are also possible, e.g. `cfg_expand`.
```rust
#[cfg_eval]
#[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]`
struct S {
#[cfg(FALSE)]
field: u8,
}
```
Tracking issue: https://github.com/rust-lang/rust/issues/82679
Remove Item::kind, use tagged enum. Rename variants to match
Fixes#82299, by making the ItemEnum tagged. Doesn't remove ItemKind as it's still used in other places.
r? `````@jyn514`````
`````@rustbot````` label: +A-rustdoc-json +T-rustdoc
Add natvis for Result, NonNull, CString, CStr, and Cow
This adds natvis support (used for Windows debugging) to the following types: `Result`, `NonNull`, `CString`, `CStr`, and `Cow`.
expand: Refactor module loading
This is an accompanying PR to https://github.com/rust-lang/rust/pull/82399, but they can be landed independently.
See individual commits for more details.
Anyone should be able to review this equally well because all people actually familiar with this code left the project.
Backport some LLVM compile-time improvements
Pick up two LLVM patches that reduce number of alias analysis queries, to see whether that gives any visible improvement.
r? `@ghost`
Let a portion of DefPathHash uniquely identify the DefPath's crate.
This allows to directly map from a `DefPathHash` to the crate it originates from, without constructing side tables to do that mapping -- something that is useful for incremental compilation where we deal with `DefPathHash` instead of `DefId` a lot.
It also allows to reliably and cheaply check for `DefPathHash` collisions which allows the compiler to gracefully abort compilation instead of running into a subsequent ICE at some random place in the code.
The following new piece of documentation describes the most interesting aspects of the changes:
```rust
/// A `DefPathHash` is a fixed-size representation of a `DefPath` that is
/// stable across crate and compilation session boundaries. It consists of two
/// separate 64-bit hashes. The first uniquely identifies the crate this
/// `DefPathHash` originates from (see [StableCrateId]), and the second
/// uniquely identifies the corresponding `DefPath` within that crate. Together
/// they form a unique identifier within an entire crate graph.
///
/// There is a very small chance of hash collisions, which would mean that two
/// different `DefPath`s map to the same `DefPathHash`. Proceeding compilation
/// with such a hash collision would very probably lead to an ICE and, in the
/// worst case, to a silent mis-compilation. The compiler therefore actively
/// and exhaustively checks for such hash collisions and aborts compilation if
/// it finds one.
///
/// `DefPathHash` uses 64-bit hashes for both the crate-id part and the
/// crate-internal part, even though it is likely that there are many more
/// `LocalDefId`s in a single crate than there are individual crates in a crate
/// graph. Since we use the same number of bits in both cases, the collision
/// probability for the crate-local part will be quite a bit higher (though
/// still very small).
///
/// This imbalance is not by accident: A hash collision in the
/// crate-local part of a `DefPathHash` will be detected and reported while
/// compiling the crate in question. Such a collision does not depend on
/// outside factors and can be easily fixed by the crate maintainer (e.g. by
/// renaming the item in question or by bumping the crate version in a harmless
/// way).
///
/// A collision between crate-id hashes on the other hand is harder to fix
/// because it depends on the set of crates in the entire crate graph of a
/// compilation session. Again, using the same crate with a different version
/// number would fix the issue with a high probability -- but that might be
/// easier said then done if the crates in questions are dependencies of
/// third-party crates.
///
/// That being said, given a high quality hash function, the collision
/// probabilities in question are very small. For example, for a big crate like
/// `rustc_middle` (with ~50000 `LocalDefId`s as of the time of writing) there
/// is a probability of roughly 1 in 14,750,000,000 of a crate-internal
/// collision occurring. For a big crate graph with 1000 crates in it, there is
/// a probability of 1 in 36,890,000,000,000 of a `StableCrateId` collision.
```
Given the probabilities involved I hope that no one will ever actually see the error messages. Nonetheless, I'd be glad about some feedback on how to improve them. Should we create a GH issue describing the problem and possible solutions to point to? Or a page in the rustc book?
r? `@pnkfelix` (feel free to re-assign)
Output of `git log --oneline c68432f1e..970bc67c3`:
970bc67c3 (HEAD, origin/master, origin/auto-cargo, origin/HEAD) Auto merge of #9243 - wickerwaka:configurable-env-doc, r=ehuss
4d7a29b75 Document the configurable-env usntable option
f7a7a3f91 Auto merge of #9229 - alexcrichton:fix-borrow-mut, r=ehuss
3f2ece7a9 Fix a `BorrowMut` error when stdout is closed
7441e8c23 Auto merge of #8825 - Aaron1011:feature/report-future-incompat, r=ehuss
139ed73f5 Add future-incompat tracking issue number.
9ea350368 Fix some minor formatting issues.
f03d47ce4 Address review comments
6177c6584 Implement future incompatibility report support
c69409658 Auto merge of #9022 - nagisa:nagisa/manifest_path, r=alexcrichton
548300b20 Add the path to the manifest in json output
99e714c05 Auto merge of #9230 - kornelski:nobinaries, r=alexcrichton
61a31bc5f Auto merge of #9236 - kornelski:track-assert, r=Eh2406
3f7f0942c track_caller on custom assert functions
6977dee10 Explain `cargo install` is not for libraries
e4aebf0a0 Auto merge of #9231 - joshtriplett:clear-to-eol-if-color, r=alexcrichton
b219f0eb7 Auto merge of #9181 - jyn514:computer-says-no, r=ehuss
0b1816578 Remove unhelpful link to Cargo book
ea46f5ce3 Use ANSI clear-to-EOL if color is force-enabled
a6394bcc1 Remove unnecessary `config` argument to `Features::add`
3a86ecf2d Fix TODO about nightly features
09677c83c Be less unix-centric in error messages
ecfdced0d Fix test that assumed tests always were run on the stable channel
eba541994 Update comment in build_script_env
a5720117f Make `nightly_features_allowed` a field instead of a function
169b09ce7 Compute `enable_nightly_features` once instead of on each call
8fc86e155 Remove unused thread_locals
4b096beae Fix `masquerade_as_nightly_cargo` in work threads
e56417c8c Suggest RUSTC_BOOTSTRAP=crate instead of RUSTC_BOOTSTRAP=1
418129dae Downgrade error to a warning when `RUSTC_BOOTSTRAP` is set or this is the nightly channel
6c422a2c0 Restrict RUSTC_BOOTSTRAP in build.rs
rustdoc: Add an unstable option to print all unversioned files
This allows sharing those files between different doc invocations
without having to know their names ahead of time.
Helps with https://github.com/rust-lang/docs.rs/issues/1302.
r? ````@GuillaumeGomez```` cc ````@pietroalbini```` ````@Nemo157````
Cleanup rustdoc warnings
## Clean up error reporting for deprecated passes
Using `error!` here goes all the way back to the original commit, https://github.com/rust-lang/rust/pull/8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See https://github.com/rust-lang/rust/pull/81932#issuecomment-785291244 for further context.
- Use spans for deprecated attributes
- Use a proper diagnostic for unknown passes, instead of error logging
- Add tests for unknown passes
- Improve some wording in diagnostics
## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!`
This also adds a test for the output.
This was added in https://github.com/rust-lang/rust/pull/52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in https://github.com/rust-lang/rust/pull/50541.
Remove RefCell around `module_trait_cache`
This builds on https://github.com/rust-lang/rust/pull/82018 and should not be merged before.
## Don't require a `DocContext` for `report_diagnostic`
This is needed for the next commit, which needs mutable access to the `cx` from
within the `decorate` closure.
- Change `as_local_hir_id` to an associated function, since it only
needs a `TyCtxt`
- Change `source_span_for_markdown_range` to only take a `TyCtxt`
## Remove RefCell around module_trait_cache
This is mostly just changing lots of functions from `&DocContext` to `&mut DocContext`.
Change built-in kernel targets to be os = none throughout
Whether for Rust's own `target_os`, LLVM's triples, or GNU config's, the
OS-related have fields have been for code running *on* that OS, not code
hat is *part* of the OS.
The difference is huge, as syscall interfaces are nothing like
freestanding interfaces. Kernels are (hypervisors and other more exotic
situations aside) freestanding programs that use the interfaces provided
by the hardware. It's *those* interfaces, the ones external to the
program being built and its software dependencies, that are the content
of the target.
For the Linux Kernel in particular, `target_env: "gnu"` is removed for
the same reason: that `-gnu` refers to glibc or GNU/linux, neither of
which applies to the kernel itself.
Relates to #74247
Rust contains various size checks conditional on target_arch = "x86_64",
but these checks were never intended to apply to
x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the
conditions.
I don't think the boxing helped performance, in fact I think it
potentially made it worse. The data was still being copied, but now it
was through a pointer. Thinking about it more, I think boxing might only
help when you're passing a big object around by value all the time,
rather than the slowdown being that you're cloning it.
There was no need to clone `id_map` because it was reset before each
item was rendered. `deref_id_map` was not reset, but it was keyed by
`DefId` and thus was unlikely to have collisions (at least for now).
Now we just clone the fields that need to be cloned, and instead create
fresh versions of the others.
All the tests passed, so it doesn't seem they need to be shared.
Plus they should be item/page-specific.
I'm not sure why they were shared before. I think the reason `id_map`
worked as a shared value before is that it is cleared before rendering
each item (in `render_item`). And then I'm guessing `deref_id_map`
worked because it's a hashmap keyed by `DefId`, so there was no overlap
(though I'm guessing we could have had issues in the future).
Note that `id_map` currently still has to be cleared because otherwise
child items would inherit the `id_map` of their parent. I'm hoping to
figure out a way to stop cloning `Context`, but until then we have to
reset `id_map`.
It doesn't look like it's shared across threads, so it doesn't need to
be thread-safe. Of course, since we're using Rust, we'll get an error if
we try to share it across threads, so this should be safe :)
rustdoc: Use substrings instead of split to grab enum variant paths
Both versions are about equally readable, but this version avoids scanning the entire path and building an intermediate array (`split()` in Rust is a lazy iterator, but not in JavaScript).
Make rustc shim's verbose output include crate_name being compiled.
This change is mainly motivated by an issue with the environment printing I added in PR 82403: multiple rustc invocations progress in parallel, and the environment output, spanning multiple lines, gets interleaved in ways make it difficult to extra the enviroment settings.
(This aforementioned difficulty is more of a hiccup than an outright show-stopper, because the environment variables tend to be the same for all of the rustc invocations, so it doesn't matter too much if one mixes up which lines one is looking at. But still: Better to fix it.)
Warn on `#![doc(test(...))]` on items other than the crate root and use future incompatible lint
Part of #82672.
This PR does multiple things:
* Create a new `INVALID_DOC_ATTRIBUTE` lint which is also "future incompatible", allowing us to use it as a warning for the moment until it turns (eventually) into a hard error.
* Use this link when `#![doc(test(...))]` isn't used at the crate level.
* Make #82702 use this new lint as well.
r? ``@jyn514``
Make ItemKind::ExternCrate looks like hir::ItemKind::ExternCrate to make transition over hir::ItemKind simpler
It was surprisingly difficult to make this change, mostly because of two issues:
* We now store the `ExternCrate` name in the parent struct (`clean::Item`), which forced me to modify the json conversion code a bit more than expected.
* The second problem was that, since we now have a `Some(name)`, it was trying to render it, ending up in a panic because we ended up in a `unreachable` statement. The solution was simply to add `!item.is_extern_crate()` in `formats::renderer` before calling `cx.item(item, &cache)?;`.
I'll continue to replace all the `clean::ItemKind` variants one by one until it looks exactly like `hir::ItemKind`. Then we'll simply discard the rustdoc type. Once this done, we'll be able to discard `clean::Item` too to use `hir::Item`.
r? ``@jyn514``
When rustdoc lints were changed to be tool lints, the `rustdoc` group
was removed, leading to spurious warnings like
```
warning: unknown lint: `rustdoc`
```
The lint group still worked when rustdoc ran, since rustdoc added the group itself.
This renames the group to `rustdoc::all` for consistency with
`clippy::all` and the rest of the rustdoc lints.
Both versions are about equally readable, but this version avoids scanning
the entire path and building an intermediate array (`split()` in Rust is
a lazy iterator, but not in JavaScript).
enableSearchInput was called from two places:
- setupSearchLoader
- addSearchOptions, which is itself called from setupSearchLoader only
This commit can safely get rid of the addSearchOptions calls entirely,
and since the setupSearchLoader call is immediately preceded by other
method calls on search_input, there's no need to check if it's set.
1. I added `--test` based on review feedback from simulacrum: I decided I would
rather include such extra context than get confused later on by its absence.
(However, I chose to encode it differently than how `[RUSTC-TIMING]` does... I
don't have much basis for doing so, other than `--test` to me more directly
reflects what it came from.)
2. I also decided to include `[RUSTC-SHIM]` at start of all of these lines
driven by the verbosity level, to make to clear where these lines of text
originate from. (Basically, I skimmed over the output and realized that a casual
observer might not be able to tell where this huge set of new lines were coming
from.)
Remove unused code from main.js
It looks like `lev_distance` was used in a very old version of the function, since it was written but never read, and Blame reports that it was added before the `checkGenerics` function header itself.
`convertHTMLToPlaintext` is was removed by 768d5e9509
Add suggestion `.collect()` for iterators in iterators
Closes#81584
```
error[E0515]: cannot return value referencing function parameter `y`
--> main3.rs:4:38
|
4 | ... .map(|y| y.iter().map(|x| x + 1))
| -^^^^^^^^^^^^^^^^^^^^^^
| |
| returns a value referencing data owned by the current function
| `y` is borrowed here
| help: Maybe use `.collect()` to allocate the iterator
```
Added the suggestion: `help: Maybe use `.collect()` to allocate the iterator`
resolve: Reduce scope of `pub_use_of_private_extern_crate` deprecation lint
This lint was deny-by-default since July 2017, crater showed 7 uses on crates.io back then (https://github.com/rust-lang/rust/pull/42894#issuecomment-311921147).
Unfortunately, the construction `pub use foo as bar` where `foo` is `extern crate foo;` was used by an older version `bitflags`, so turning it into an error causes too many regressions.
So, this PR reduces the scope of the lint instead of turning it into a hard error, and only turns some more rarely used components of it into errors.
Implement NOOP_METHOD_CALL lint
Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g, calling `<&T as Clone>::clone()` when `T: !Clone`).
This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs:
* [ ] No UFCS support
* [ ] The warning message is pretty plain
* [ ] Doesn't work for `ToOwned`
The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance, it expects substitutions to have happened, which haven't yet performed, but we check first for `needs_subst` to ensure we're dealing with a monomorphic type.
Thank you to ```@davidtwco,``` ```@Aaron1011,``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.
Inherit `#[stable(..)]` annotations in enum variants and fields from its item
Lint changes for #65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.
It looks like `lev_distance` was used in a very old version of the function,
since it was written but never read, and Blame reports that it was added
before the `checkGenerics` function header itself.
`convertHTMLToPlaintext` is was removed by 768d5e9509
This ownership kind is only constructed in the case of path attributes like `#[path = ".."]` without a file name segment, which always represent some kind of directories and will produce and error on attempt to parse them as a module file.
This change is mainly motivated by an issue with the environment
printing I added in PR 82403: multiple rustc invocations progress
in parallel, and the environment output, spanning multiple lines,
gets interleaved in ways make it difficult to extra the enviroment settings.
(This aforementioned difficulty is more of a hiccup than an outright
show-stopper, because the environment variables tend to be the same for all of
the rustc invocations, so it doesn't matter too much if one mixes up which lines
one is looking at. But still: Better to fix it.)
Update rustdoc documentation
- Remove most of the information about passes. Passes are deprecated.
- Add `--document-private-items`; it was missing before.
- Update `--output-format json`; it was very outdated.
- Note that `--input-format` is deprecated.
- Move deprecated options to the very end.
Closes https://github.com/rust-lang/rust/issues/82675.
r? `@Manishearth`
Shorten html::render
The `mod.rs` for librustdoc's `html::render` was over 3,000 lines. This PR reduces it to around 2,300 by
1. Moving `Context` and associated `impl`s to a separate file
2. Moving the `print_item` function and its helpers to a separate file
3. Moving `write_shared` and `write_minify` to their own file
Related to issue #60302.
Edit 1: `SharedContext` and related `impl`s is only 72 lines and so will not be moved.
Pin es-check version to prevent unrelated CI failures
es-check v5.2.1 causes a lot of unrelated CI failures on mingw-check, e.g. https://github.com/rust-lang/rust/pull/80723#issuecomment-790294196.
es-check v5.2.2 fixes it but let's pin its version to prevent further failures.
- Remove most of the information about passes. Passes are deprecated.
- Add `--document-private-items`; it was missing before.
- Update `--output-format json`; it was very outdated.
- Note that `--input-format` is deprecated.
- Move deprecated options to the very end.
- Move `passes.html` to the end of the table of contents. Ideally it
would be removed altogether, but that causes mdbook not to generate the
docs.
This is needed for the next commit, which needs access to the `cx` from
within the `decorate` closure.
- Change `as_local_hir_id` to an associated function, since it only
needs a `TyCtxt`
- Change `source_span_for_markdown_range` to only take a `TyCtxt`
Upgrade to LLVM 12
This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far.
r? `@cuviper`
Pass `CrateNum` by value instead of by reference
It's more idiomatic to pass a small Copy type by value and `CrateNum` is
half the size of `&CrateNum` on 64-bit systems. The memory use change is
almost certainly insignificant, but why not!
Improve page load performance in rustdoc
Add an explicit height to icons (which already had an explicit width) to allow browsers to lay out the page more accurately before the icons have been loaded. https://web.dev/optimize-cls/.
Add min-width: 115px to the crate search dropdown. When the HTML first loads, this dropdown includes only the text "All crates." Later, JS loads the items underneath it, some of which are wider. That causes the dropdown to get wider, causing a distracting reflow. This sets a min-width based on the size that the dropdown eventually becomes based on the crates on doc.rust-lang.org, reducing page movement during load.
Add font-display: swap. Per https://web.dev/font-display/, this prevents "flash of invisible text" during load by using a system font until the custom font is available. I've noticed this flash of invisible text occasionally when reading Rust docs. Note that users without cached fonts will see text, and then see it reflow. For `docs.rust-lang.org`, [setting caching headers will help a lot](https://github.com/rust-lang/simpleinfra/issues/62).
Generated output at https://jacob.hoffman-andrews.com/rust/flow-improvements/std/string/struct.String.html.
It's more idiomatic to pass a small Copy type by value and `CrateNum` is
half the size of `&CrateNum` on 64-bit systems. The memory use change is
almost certainly insignificant, but why not!
On reflection on the issue in https://github.com/rust-lang/rust/pull/79540#discussion_r572572280, I think the bug was actually using the `compiler/` filter, not using `--author=bors`. 9a1d6174c9 has no CI artifacts because it was merged as part of a rollup:
```
$ curl -I https://ci-artifacts.rust-lang.org/rustc-builds/96e843ce6ae42e0aa519ba45e148269de347fd84/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz
HTTP/2 404
```
So 9a1d6174c9 is the correct commit to download, and that's what `--author=bors` does:
$ git log --author=bors 4aec8a5da5
commit 9a1d6174c9
Ideally it would look for "the most recent bors commit not followed by a change to `compiler/`", which would exclude things like documentation changes and avoid redownloading more than necessary, but
- Redownloading isn't the end of the world,
- That metric is hard to implement, and
- Documentation-only or library-only changes are very rare anyway since they're usually rolled up with changes to the compiler.
We previously used -Os to disable this pass, but since
https://reviews.llvm.org/D91673 this no longer works. Explicitly
disable it using -Cllvm-args instead.
Update tracing to 0.1.25
* Update tracing from 0.1.18 to 0.1.25
* Update tracing-subscriber from 0.2.13 to 0.2.16
* Update tracing-tree from 0.1.6 to 0.1.8
* Add pin-project-lite to the list of allowed dependencies (it is now a direct dependency of tracing).
enable atomic_min/max tests in Miri
Thanks to `@henryboisdequin` and `@GregBowyer,` Miri now supports these intrinsics. :)
Also includes the necessary Miri update.
Update cargo
12 commits in 572e201536dc2e4920346e28037b63c0f4d88b3c..c68432f1e5cbbc09833699a951b1b5b059651dff
2021-02-24 16:51:20 +0000 to 2021-03-02 18:26:29 +0000
- Don't panic when printing JSON with non-utf8 paths (rust-lang/cargo#9226)
- Detect changes for JSON spec targets. (rust-lang/cargo#9223)
- Fix `cargo_target_empty_cfg` test with env var. (rust-lang/cargo#9225)
- Correct default cargo new edition (rust-lang/cargo#9202)
- Update split-debuginfo docs around the default. (rust-lang/cargo#9224)
- Minor update to registry API error messages. (rust-lang/cargo#9213)
- Some minor code cleanup. (rust-lang/cargo#9214)
- doc: Fix spelling worksapce->workspace (rust-lang/cargo#9212)
- Update SPDX version in docs. (rust-lang/cargo#9209)
- Throw error if CARGO_TARGET_DIR is an empty string (rust-lang/cargo#8939)
- testsuite: Use split debuginfo on macos. (rust-lang/cargo#9207)
- testsuite: Improve performance when using rustup. (rust-lang/cargo#9206)
Revert non-power-of-two vector restriction
Removes the power of two restriction from rustc. As discussed in https://github.com/rust-lang/stdsimd/issues/63
r? ```@calebzulawski```
cc ```@workingjubilee``` ```@thomcc```
On most platforms and browsers, `sans-serif` is equivalent to Arial.
However, on Firefox on Ubuntu (and possibly other Linuxes), `sans-serif`
is DejaVu Sans, a much wider font. This creates a larger shift in text
when the custom fonts finally load. Arial is a web-safe font, and
specifying it explicitly gives us more cross-platform consistency, as
well as reducing the layout shift that happens when fonts load.
Add font-display: swap. Per https://web.dev/font-display/, this prevents
"flash of invisible text" during load by using a system font until the
custom font is available. I've noticed this flash of invisible text
occasionally when reading Rust docs.
Add an explicit height to icons (which already had an explicit width)
to allow browsers to lay out the page more accurately before the icons
have been loaded. https://web.dev/optimize-cls/.
Add min-width: 115px to the crate search dropdown. When the HTML first
loads, this dropdown includes only the text "All crates." Later, JS
loads the items underneath it, some of which are wider. That causes
the dropdown to get wider, causing a distracting reflow. This sets a
min-width based on the size that the dropdown eventually becomes based
on the crates on doc.rust-lang.org, reducing page movement during load.
Instead of being loaded on every page, the JS search index is now
loaded when either (a) there is a `?search=` param, or (b) the search
input is focused.
This saves both CPU and bandwidth. As of Feb 2021,
https://doc.rust-lang.org/search-index1.50.0.js is 273,838 bytes
gzipped or 2,544,939 bytes uncompressed. Evaluating it takes 445 ms
of CPU time in Chrome 88 on a i7-10710U CPU (out of a total ~2,100
ms page reload).
Generate separate JS file with crate names.
This is much smaller than the full search index, and is used in the "hot
path" to draw the page. In particular it's used to crate the dropdown
for the search bar, and to append a list of crates to the sidebar (on
some pages).
Skip early search that can bypass 500ms timeout.
This was occurring when someone had typed some text during the load of
search-index.js. Their query was usually not ready to execute, and the
search itself is fairly expensive, delaying the overall load, which
delayed the input / keyup events, which delayed eventually executing the
query.
- Use spans for deprecated attributes
- Use a proper diagnostic for unknown passes, instead of error logging
- Add tests for unknown passes
- Improve some wording in diagnostics
Update books
## reference
2 commits in 361367c126290ac17cb4089f8d38fd8b2ac43f98..3b6fe80c205d2a2b5dc8a276192bbce9eeb9e9cf
2021-02-15 09:58:13 -0800 to 2021-02-22 22:09:17 -0800
- Add an extra fn() entry to the variance table in the subtyping chapter (rust-lang-nursery/reference#874)
- Turbofish: Explain what the example is of. (rust-lang-nursery/reference#966)
## book
28 commits in db5e8a5105aa22979490dce30e33b68d8645761d..0f87daf683ae3de3cb725faecb11b7e7e89f0e5a
2021-02-12 16:58:20 -0500 to 2021-03-01 08:54:04 -0500
- Ohhh the should_panic was for mdbook test. Oops
- Fix bad regex in the update rustc script and regenerate broken output
- Clarify that we only mentioned unwrap_or_else, but haven't explained it
- Add ferris to some listings that don't compile. Fixesrust-lang/book#2598
- Remove fancy quote from a code comment
- Panic now points at our code, not stdlib slice code
- Disable playground on thread::sleep examples
- Disable playground button on listings in ch 12 that use CLI args
- Reword ambiguous sentence. Fixesrust-lang/book#2317.
- Rename shoes_in_my_size to shoes_in_size to be a better example
- Fix visible "ANCHOR: here" in listing 13-21 (rust-lang/book#2628)
- minor clarification about deriving Copy and Clone (rust-lang/book#2627)
- Clarify relationship of trait to mock object
- Fix "message" that should be "method"
- Fixrust-lang/book#2625 (rust-lang/book#2626)
- fix misleading hash claim (rust-lang/book#2621)
- Make link syntax consistent and word wrap
- Added hyperlinks to Appendices
- Use console syntax highlighting in some more places
- Merge remote-tracking branch 'origin/pr/2615'
- Fix broken blockquote
- Update one more bit of output caught by the update rust script
- Update and clarify some text affected by the rand update
- Update lock files and output
- Update error output for changes to chapter 10 listings
- Merge remote-tracking branch 'origin/pr/2542'
- Tweak wording in for loop explanation
- Merge remote-tracking branch 'origin/pr/2460'
## rust-by-example
1 commits in 551cc4bc8394feccea6acd21f86d9a4e1d2271a0..3e0d98790c9126517fa1c604dc3678f396e92a27
2021-02-03 17:12:37 -0300 to 2021-02-25 08:23:10 -0300
- Make flow_control/for/.into_iter() example run (rust-lang/rust-by-example#1415)
## rustc-dev-guide
530 commits in 7adfab42bab045a848126895c2f1e09927c1331a..c431f8c29a41413dddcb3bfa0d71c9cabe366317
2020-04-08 08:52:05 +0200 to 2021-02-28 16:35:20 -0500
... Many updates.
## embedded-book
1 commits in 4cf7981696a85c3e633076c6401611bd3f6346c4..a96d096cffe5fa2c84af1b4b61e1492f839bb2e1
2021-02-11 10:55:22 +0000 to 2021-02-17 08:08:52 +0000
- Add note about using more recent openocd interface file. Closesrust-embedded/book#277 and rust-embedded/book#263 (rust-embedded/book#284)
Add incomplete feature gate for inherent associate types.
Mentored by ``````@oli-obk``````
So far the only change is that instead of giving an automatic error, the following code compiles:
```rust
struct Foo;
impl Foo {
type Bar = isize;
}
```
The backend work to make it actually usable isn't there yet. In particular, this:
```rust
let x : Foo::Bar;
```
will give you:
```sh
error[E0223]: ambiguous associated type
--> /$RUSTC_DIR/src/test/ui/assoc-inherent.rs:15:13
|
LL | let x : Foo::Bar;
| ^^^^^^^^ help: use fully-qualified syntax: `<Foo as Trait>::Bar`
```
- Move MISSING_CRATE_LEVEL_DOCS to rustdoc directly
- Update documentation
This also takes the opportunity to make the `no-crate-level-doc-lint`
test more specific.
Tomasz Miąsko
Nixon Enraght-Moony
bors
François Mockers
Dylan DPC
Guillaume Gomez
Ralf Jung
Simonas Kazlauskas
Erin Power
Michael Howell
Camelid
Aman Arora
bstrie
Yuki Okushi
The8472
katelyn a. martin
Camille GILLOT
kadmin
Oli Scherer
Ömer Sinan Ağacan
Mara Bos
asquared31415
Henry Boisdequin
Dan Gohman
mark
Laurențiu Nicola
Joshua Nelson
hyd-dev
Aaron Hill
Manish Goregaokar
Esteban Küber
Erik Desjardins
Rune Tynan
Vadim Petrochenkov
Harald van Dijk
Santiago Pastorino
Marianna Rapoport
Nikita Popov
Felix S. Klock II
Dániel Buga
Ryan Levick
flip1995
yn0ga
Nicholas-Baron
Ryan Levick
Jacob Hoffman-Andrews
Eric Huss
