| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
[rustdoc] Box ItemKind to reduce the size of `Item`
This brings the size of `Item` from
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 536
```
to
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 136
```
This is an alternative to https://github.com/rust-lang/rust/pull/79967; I don't think it makes sense to make both changes.
Helps with #79103.
|
|
|
|
Add regression test for #80375
This will also make sure that #80375 is handled if #79135 has to be reverted (which won't happen 🤞).
Closes #80375.
r? `@lcnr`
|
|
rustdoc book: fix example
`lib.rs` file is created only if `--lib` flag is specified
|
|
Add links to the source for the rustc and rustdoc books.
This adds a little icon in the upper-right corner of the books so that readers can find the source if they want to make changes or file issues. This is already included in several of the other books.
|
|
bootstrap: put the component name in the tarball temp dir path
This should not matter right now, but if we ever parallelize rustbuild this will avoid tarball contents being merged together.
r? `@Mark-Simulacrum`
|
|
Document rustc_macros on nightly-rustc
Fixes https://github.com/rust-lang/rust/issues/80345.
r? ``@ehuss``
|
|
Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121
Previously, using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example:
```rust
fn f() -> i32 { 0 }
fn fn_ptr() -> _ { f }
fn closure() -> _ { || 0 }
```
would result in this diagnostic:
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32 {f}`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `[closure@<anon>:3:21: 3:25]`
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen, it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally, closures cause a papercut as unique closure types (notated in this case as `[closure@<anon>:3:21: 3:25]`) are not valid syntax either.
Instead, this PR implements this version of the diagnostic (this example is for the same code featured above):
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^ not allowed in type signatures
|
= help: consider using an `Fn`, `FnMut`, or `FnOnce` trait bound
= note: for more information on `Fn` traits and closure types, see https://doc.rust-lang.org/book/ch13-01-closures.html
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen in this diagnostic, the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures, it's suggested to use an `Fn`, `FnMut`, or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment, therefore someone in the future may want to implement that. Also, it's possible to use either `impl Trait` syntax, generics, or generics with a `where` clause, and some users may not want to use `impl Trait` syntax for their own reasons.
This PR fixes #80179.
|
|
This should not matter right now, but if we ever parallelize rustbuild
this will avoid tarball contents being merged together.
|
|
Use package name for top-level directory in bare tarballs
This fixes a bug introduced by #79788.
r? `@pietroalbini`
|
|
Fix intra-doc links for non-path primitives
This does *not* currently work for associated items that are
auto-implemented by the compiler (e.g. `never::eq`), because they aren't
present in the source code. I plan to fix this in a follow-up PR.
Fixes https://github.com/rust-lang/rust/issues/63351 using the approach mentioned in https://github.com/rust-lang/rust/issues/63351#issuecomment-683352130.
r? `@Manishearth`
cc `@petrochenkov` - this makes `rustc_resolve::Res` public, is that ok? I'd just add an identical type alias in rustdoc if not, which seems a waste.
|
|
|
|
Ignore proc-macros when assembling rustc libdir
Fixes #80294.
|
|
|
|
rustdoc: stabilise --default-theme command line option
As discussed in #77213, this seems like it has bedded in and can be safely and usefully made stable.
(rustdoc already has other stable options that interact quite intimately with the rustdoc-supplied CSS, and also an option for supplying entirely different CSS, so exposing the theme names this way seems a very minor step.)
There is also a commit to do some minor grammar fixes to the help message.
|
|
stabilize `#![feature(min_const_generics)]` in 1.51
*A new Kind*
*A Sort long Prophesized*
*Once Fragile, now Eternal*
blocked on #79073.
# Stabilization report
This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878), a subset of `#![feature(const_generics)]` (tracking issue #44580), based on rust-lang/rfcs#2000.
The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta, 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta, 2021-03-25 => stable).
This report is a collaborative effort of `@varkor,` `@shepmaster` and `@lcnr.`
## Summary
It is currently possible to parameterize functions, type aliases, types, traits and implementations by types and lifetimes.
With `#![feature(min_const_generics)]`, it becomes possible, in addition, to parameterize these by constants.
This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics, `min_const_generics` is limited to parameterization by integers, and constants of type `char` or `bool`.
We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples.
Generic const arguments, for now, are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either:
1. const expressions that do not depend on any generic parameters, e.g. `{ foo() + 1 }`, where `foo` is a `const fn`
1. standalone const parameters, e.g. `{N}`
### Example
```rust
#![feature(min_const_generics)]
trait Foo<const N: usize> {
fn method<const M: usize>(&mut self, arr: [[u8; M]; N]);
}
struct Bar<T, const N: usize> {
inner: [T; N],
}
impl<const N: usize> Foo<N> for Bar<u8, N> {
fn method<const M: usize>(&mut self, arr: [[u8; M]; N]) {
for (elem, s) in self.inner.iter_mut().zip(arr.iter()) {
for &x in s {
*elem &= x;
}
}
}
}
fn function<const N: u16>() -> u16 {
// Const parameters can be used freely inside of functions.
(N + 1) / 2 * N
}
fn main() {
let mut bar = Bar { inner: [0xff; 3] };
// This infers the value of `M` from the type of the function argument.
bar.method([[0b11_00, 0b01_00], [0b00_11, 0b00_01], [0b11_00, 0b00_11]]);
assert_eq!(bar.inner, [0b01_00, 0b00_01, 0b00_00]);
// You can also explicitly specify the value of `N`.
assert_eq!(function::<17>(), 153);
}
```
## Motivation
Rust has the built-in array type, which is parametric over a constant. Without const generics, this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example, this meant that, for a long time, the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics.
Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values, rather than by types. For example, using const generics, many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters, improving compilation time as well as code readability and diagnostics.
The subset described by `min_const_generics` is self-contained, but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore, it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved.
## In-depth feature description
### Declaring const parameters
*Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently, const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace.
`Type` must be one of `u8`, `u16`, `u32`, `u64`, `u128`, `usize`, `i8`, `i16`, `i32`, `i64`, `i128`, `isize`, `char` and `bool`. This restriction is implemented in two places:
1. during name resolution, where we forbid generic parameters
1. during well-formedness checking, where we only allow the types listed above
The updated syntax of parameter listings is:
```
GenericParams:
(OuterAttr* LifetimeParam),* (OuterAttr* TypeParam),* (OuterAttr* ConstParam),*
OuterAttr: '#[' ... ']'
LifetimeParam: ...
TypeParam: ...
ConstParam: 'const' IDENT ':' Type
```
Unlike type and lifetime parameters, const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed:
```rust
struct Foo<const N: usize>;
enum Bar<const M: usize> { A, B }
```
### Const arguments
Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter, most expressions must be contained within a block, with two exceptions:
1. literals and single-segment path expressions
1. array lengths
This syntactic restriction is necessary to avoid ambiguity, or requiring infinite lookahead when parsing an expression as a generic argument.
In the cases where a generic argument could be resolved as either a type or const argument, we always interpret it as a type. This causes the following test to fail:
```rust
type N = u32;
struct Foo<const N: usize>;
fn foo<const N: usize>() -> Foo<N> { todo!() } // ERR
```
To circumvent this, the user may wrap the const parameter with braces, at which point it is unambiguously accepted.
```rust
type N = u32;
struct Foo<const N: usize>;
fn bar<const N: usize>() -> Foo<{ N }> { todo!() } // ok
```
Operations depending on generic parameters are **not** allowed, which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]`, which is not yet being stabilised.
Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]`, we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details.
Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized, we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error, this is theoretically a breaking change, as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed, causing the following snippet to break:
```rust
fn late_bound<'a>() {
let _ = [0; {
let _: &'a (); // ICE ==> ERR
3
}];
}
fn early_bound<'a>() where &'a (): Sized {
let _ = [0; {
let _: &'a (); // ok ==> ERR
3
}];
}
```
### Using const parameters
Const parameters can be used almost everywhere ordinary constants are allowed, except that they may not be used in the construction of consts, statics, functions, or types inside a function body and are subject to the generic argument restrictions mentioned above.
Expressions containing const parameters are eligible for promotion:
```rust
fn test<const N: usize>() -> &'static usize {
&(3 + N)
}
```
### Symbol mangling
See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known, or `Kp` where the value is not known, where:
- `[type]` is any integral type, `bool`, or `char`.
- `[value]` is the unsigned hex value for integers, preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`.
### Exhaustiveness checking
We do not check the exhaustiveness of impls, meaning that the following example does **not** compile:
```rust
struct Foo<const B: bool>;
trait Bar {}
impl Bar for Foo<true> {}
impl Bar for Foo<false> {}
fn needs_bar(_: impl Bar) {}
fn generic<const B: bool>() {
let v = Foo::<B>;
needs_bar(v);
}
```
### Type inference
The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays, which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825.
### Equality of constants
`#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter.
### Associated constants
Associated constants can use const parameters without restriction, see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details.
## Future work
As this is a limited subset of rust-lang/rfcs#2000, there are quite a few extensions we will be looking into next.
### Lazy normalization of constants
Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics`, and unblocks operations on const parameters.
### Relaxing ordering requirements between const and type parameters
We currently restrict the order of generic parameters so that types must come before consts. We could relax this, as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time.
Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters.
### Allowing more parameter types
We would like to support const parameters of more types, especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo<T, const N: T>` will be a lot harder and is unlikely to be implemented in the near future.
### Default values of const parameters
We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384).
### Generic const operations
With `#![feature(min_const_generics)]`, only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However, supporting generic const operations, such as `N + 1` or `std::mem::size_of::<T>()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`.
## Implementation history
Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here!
[valtrees]: https://github.com/rust-lang/rust/issues/72396
---
r? `@varkor`
|
|
lint-docs: Warn on missing lint when documenting.
In #79522, I missed converting one of the errors to a warning, in the situation where a lint is missing. This was unearthed by the renaming of overlapping-patterns (#78242). This will still be validated during the test phase.
|
|
This fixes a bug introduced by #79788.
|
|
|
|
|
|
|
|
|
|
|
|
Include rustdoc in the compiler docs index.
This should help ensure that the index page at https://doc.rust-lang.org/nightly/nightly-rustc/ includes a link to the rustdoc docs as well.
Fixes #80307
|
|
Remove pointer comparison from slice equality
This resurrects #71735.
Fixes #71602, helps with #80140.
r? `@Mark-Simulacrum`
|
|
This resurrects #71735.
Fixes #71602, helps with #80140.
r? `@Mark-Simulacrum`
|
|
Prevent caching normalization results with a cycle
When normalizing a projection which results in a cycle, we would cache the result of `project_type` without the nested obligations (because they're not needed for inference). This would result in the nested obligations only being handled once in fulfill, which would avoid the cycle error. `get_paranoid_cache_value_obligation` used to add an obligation that resulted in a cycle in this case previously, but was removed by #73905.
This PR makes the projection cache not cache the value of a projection if it was ever normalized in a cycle (except in a snapshot that's rolled back).
Fixes #79714.
r? `@nikomatsakis`
|
|
Bump version to 1.51
r? `@Mark-Simulacrum`
|
|
|
|
wesleywiser:revert_missing_fragment_specifier_hard_error, r=Mark-Simulacrum
Revert missing fragment specifier hard error
Closes #76605
Reopens #40107
r? `@Mark-Simulacrum`
|
|
Highlight edition-specific keywords correctly in code blocks, accounting for code block edition modifiers
Previously, edition-specific keywords (such as `async` and `await`) were not highlighted in code blocks, regardless of what edition was set. With this PR, this issue is fixed.
Now, the following behavior happens:
- When a code block is explicitly set to edition X, keywords from edition X are highlighted
- When a code block is explicitly set to a version that does not contain those keywords from edition X (e.g. edition Y), keywords from edition X are **not** highlighted
- When a code block has no explicit edition, keywords from the edition passed via `--edition` to rustdoc are highlighted
For example, a project set with `edition = "2015"` in its `Cargo.toml` would not highlight `async`/`await` unless the code block was set to `edition2018`. Additionally, a project set with `edition = "2018"` in its `Cargo.toml` *would* highlight `async`/`await` unless the code block was set to a version that did not contain those keywords (e.g. `edition2015`).
This PR fixes #80004.
r? `@jyn514`
|
|
Exclude unnecessary info from CodegenResults
`foreign_module` and `wasm_import_module` are not needed for linking, and hence can be removed from CodegenResults.
Fixes #77857
|
|
Rollup of 11 pull requests
Successful merges:
- #79213 (Stabilize `core::slice::fill`)
- #79999 (Refactored verbose print into a function)
- #80160 (Implemented a compiler diagnostic for move async mistake)
- #80274 (Rename rustc_middle::lint::LintSource)
- #80280 (Add installation commands to `x` tool README)
- #80319 (Fix elided lifetimes shown as `'_` on async functions)
- #80327 (Updated the match with the matches macro)
- #80330 (Fix typo in simplify_try.rs)
- #80340 (Don't unnecessarily override attrs for Module)
- #80342 (Fix typo)
- #80352 (BTreeMap: make test cases more explicit on failure)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't unnecessarily override attrs for Module
They were never changed from the default, which you can get with `tcx.get_attrs()`.
|
|
Fix elided lifetimes shown as `'_` on async functions
Closes https://github.com/rust-lang/rust/issues/63037.
r? `@tmandry` on the implementation, `@Darksonn` on the test cases.
|
|
Add installation commands to `x` tool README
|
|
Rename rustc_middle::lint::LintSource
Rename [`rustc_middle::lint::LintSource`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html) to `rustc_middle::lint::LintLevelSource`.
This enum represents the source of a *lint level*, not a lint. This should improve code readability.
Update: Also documents `rustc_middle::lint::LevelSource` to clarify.
|
|
Implemented a compiler diagnostic for move async mistake
Fixes #79694
First time contributing, so I hope I'm doing everything right.
(If not, please correct me!)
This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it.
Checked code:
```rust
fn main() {
move async { };
}
```
Previous output:
```txt
PS C:\Repos\move_async_test> cargo build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: expected one of `|` or `||`, found keyword `async`
--> src\main.rs:2:10
|
2 | move async { };
| ^^^^^ expected one of `|` or `||`
error: aborting due to previous error
error: could not compile `move_async_test`
```
New output:
```txt
PS C:\Repos\move_async_test> cargo +dev build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: the order of `move` and `async` is incorrect
--> src\main.rs:2:13
|
2 | let _ = move async { };
| ^^^^^^^^^^
|
help: try switching the order
|
2 | let _ = async move { };
| ^^^^^^^^^^
error: aborting due to previous error
error: could not compile `move_async_test`
```
Is there a file/module where these kind of things are tested?
Would love some feedback 😄
|
|
Refactored verbose print into a function
Also handle Tuple and Array separately, which was not explicitly checked.
Fixes #79799.
|
|
Remap instrument-coverage line numbers in doctests
This uses the `SourceMap::doctest_offset_line` method to re-map line
numbers from doctests. Remapping columns is not yet done, and rustdoc
still does not output the correct filename when running doctests in a
workspace.
Part of #79417 although I dont consider that fixed until both filenames
and columns are mapped correctly.
r? `@richkadel`
I might jump on zulip the comming days. Still need to figure out how to properly write tests for this, and deal with other doctest issues in the meantime.
|
|
These caused several false positives when documenting rustc, which means
there will likely be many more false positives in the rest of the
ecosystem.
|
|
|
|
accounting for code block edition modifiers
This is a squash of these commits:
- Highlight edition-specific keywords correctly in code blocks,
accounting for code block edition modifiers
- Fix unit tests
- Revert changes to rustc_span::symbol to prepare for merge of #80272
- Use new Symbol::is_reserved API from #80272
- Remove unused import added by accident when merging
|
|
Update cargo
10 commits in a3c2627fbc2f5391c65ba45ab53b81bf71fa323c..75d5d8cffe3464631f82dcd3c470b78dc1dda8bb
2020-12-14 17:21:26 +0000 to 2020-12-22 18:10:56 +0000
- Update git2 (rust-lang/cargo#9009)
- Stabilize RUSTC_WORKSPACE_WRAPPER (rust-lang/cargo#8976)
- Make cargo metadata and tree respect target (rust-lang/cargo#8987)
- Update git2 (rust-lang/cargo#8998)
- Revert rust-lang/cargo#8954 - changing rustdoc's cwd (rust-lang/cargo#8996)
- With debug HTTP mode log curl's version (rust-lang/cargo#8991)
- Reject ambiguous git dependency declaration. (rust-lang/cargo#8984)
- Fix tests not working with a different CARGO_TARGET_DIR. (rust-lang/cargo#8982)
- Add version to credential dependencies. (rust-lang/cargo#8983)
- Clarify FAQ entry wording about lockfiles (rust-lang/cargo#8978)
|
|
r=Nemo157
Move tooltips messages out of html
First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up.
So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice.
So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other).
Don't hesitate if a part of my explanations isn't clear.
r? `@jyn514`
|
|
Rework beautify_doc_string so that it returns a Symbol instead of a String
This commit comes from https://github.com/rust-lang/rust/pull/80261, the goal here is to inspect the impact on performance of this change on its own.
The idea of rewriting `beautify_doc_string` is to not go through `String` if we don't need to update the doc comment to be able to keep the original `Symbol` and also to have better performance.
r? `@jyn514`
|
|
Added better error message for shared borrow treated as unique for purposes of lifetimes
Part of Issue #76630
r? `@jyn514`
|
|
update rustfmt to v1.4.30
Contains fixes for a few reported bugs on current nightly (1.4.29)
Notes in: https://github.com/rust-lang/rustfmt/releases/tag/v1.4.30
|
|
They were never changed from the default, which you can get with
`tcx.get_attrs()`.
|
