| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Always use the Rust version in package names
The format of the tarballs produced by CI is roughly the following:
{component}-{release}-{target}.{ext}
While on the beta and nightly channels `{release}` is just the channel name, on the stable channel is either the Rust version or the version of the component we're shipping:
cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz
clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz
llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz
miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz
rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz
rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz
...
This makes it really hard to get the package URL without having access to the manifest (and there is no manifest on ci-artifacts.rlo), as there is no consistent version number to use.
This PR addresses the problem by always using the Rust version number as `{release}` for the stable channel, regardless of the version number of the component we're shipping. I chose that instead of "stable" to avoid breaking the URL scheme *that* much.
Rustup should not be affected by this change, as it fetches the URLs from the manifest. Unfortunately we don't have a way to test other clients before making a stable release, as this change only affects the stable channel.
r? `@Mark-Simulacrum`
|
|
Warn on broken intra-doc links added to cross-crate re-exports
This emits `broken_intra_doc_links` for docs applied to pub use statements that point to external items and are inlined.
Does not address #77200 - any existing broken links from the original crate will not show warnings.
r? `@jyn514`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update Clippy
Biweekly Clippy update.
This includes a `Cargo.lock` update: 7ea42be
r? `@Manishearth`
|
|
Remove redundant backslashes from `lldb_commands`
|
|
The format of the tarballs produced by CI is roughly the following:
{component}-{release}-{target}.{ext}
While on the beta and nightly channels `{release}` is just the channel
name, on the stable channel is either the Rust version or the version of
the component we're shipping:
cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz
clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz
llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz
miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz
rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz
rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz
...
This makes it really hard to get the package URL without having access
to the manifest (and there is no manifest on ci-artifacts.rlo), as there
is no consistent version number to use.
This commit addresses the problem by always using the Rust version
number as `{release}` for the stable channel, regardless of the version
number of the component we're shipping. I chose that instead of "stable"
to avoid breaking the URL scheme *that* much.
Rustup should not be affected by this change, as it fetches the URLs
from the manifest. Unfortunately we don't have a way to test other
clients before making a stable release, as this change only affects the
stable channel.
|
|
|
|
rust-demangler tool strips crate disambiguators with < 16 digits
Addresses Issue #77615.
|
|
suggest `MAX` constant if -1 is assigned to unsigned type
Fixes #76413.
Fixes #77416.
|
|
Resolve intra-doc links on additional documentation for re-exports in lexical scope
Fixes https://github.com/rust-lang/rust/issues/77254.
- Preserve the parent module of `DocFragment`s
+ Add `parent_module` to `DocFragment`
+ Require the `parent_module` of the item being inlined
+ Preserve the hir_id for ExternCrates so rustdoc can find the parent module later
+ Take an optional `parent_module` for `build_impl` and `merge_attrs`.
Preserve the difference between parent modules for each doc-comment.
+ Support a single additional re-exports in from_ast. Originally this took a vec but I ended up not using it.
+ Don't require the parent_module for all `impl`s, just inlined items
In particular, this will be `None` whenever the attribute is not on a
re-export.
+ Only store the parent_module, not the HirId
When re-exporting a re-export, the HirId is not available. Fortunately,
`collect_intra_doc_links` doesn't actually need all the info from a
HirId, just the parent module.
- Introduce `Divider`
This distinguishes between documentation on the original from docs on the re-export.
- Use the new module information for intra-doc links
+ Make the parent module conditional on whether the docs are on a re-export
+ Make `resolve_link` take `&Item` instead of `&mut Item`
Previously the borrow checker gave an error about multiple mutable
borrows, because `dox` borrowed from `item`.
+ Fix `crate::` for re-exports
`crate` means something different depending on where the attribute
came from.
+ Make it work for `#[doc]` attributes too
This required combining several attributes as one so they would keep
the links.
r? `@GuillaumeGomez`
|
|
Implementation of RFC2867
https://github.com/rust-lang/rust/issues/74727
So I've started work on this, I think my next steps are to make use of the `instruction_set` value in the llvm codegen but this is the point where I begin to get a bit lost. I'm looking at the code but it would be nice to have some guidance on what I've currently done and what I'm doing next :smile:
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #76750 (Don't discourage implementing `core::fmt::Write`)
- #77449 (BTreeMap: comment why drain_filter's size_hint is somewhat pessimistic)
- #77660 ((docs): make mutex error comment consistent with codebase)
- #77663 (Add compile fail test for issue 27675)
- #77673 (Remove unnecessary lamda on emitter map.)
- #77701 (Make `max_log_info` easily greppable (for figuring out why debug logging is disabled))
- #77702 (Remove not needed lambda.)
- #77710 (Update submodule llvm to get LVI bugfix)
Failed merges:
r? `@ghost`
|
|
|
|
Downgrade string_lit_as_bytes to nursery
Between #1402 (regarding `to_owned`) and #4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default.
I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error.
As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned.
---
changelog: Remove string_lit_as_bytes from default set of enabled lints
|
|
Update submodule llvm to get LVI bugfix
The LLVM LVI mitigations used register %rcs as a clobber register. This is problematic when rust uses this register to return (part of) function values. The problem was fixed upstream in:
https://reviews.llvm.org/D88924
https://reviews.llvm.org/D88925
PR https://github.com/rust-lang/llvm-project/pull/79 merged it in the llvm_project. This PR updates the submodule
Bug report: https://bugs.llvm.org/show_bug.cgi?id=47740
Fixes #77607
cc: @jethrogb
|
|
r=Aaron1011
Add compile fail test for issue 27675
A recently merged PR (#73905) strengthened the checks on bounds of associated items. This rejects the attack path of #27675 which consisted of constructing a `dyn Trait<Item=T>` where `T` would not fulfill the bounds required on `Item` of the `Trait` behind the dyn object.
This regression test, extracted from [the weaponized instance](https://github.com/rust-lang/rust/issues/27675#issuecomment-696956878), checks that this is rejected.
|
|
Suggest removing `&mut` from a `&mut borrow`
Modify the code added in #54720.
Closes #75871
|
|
Addresses Issue #77615.
|
|
|
|
|
|
Fix a typo: minding -> binding
Add test for &mut &mut
|
|
Upgrade to tracing-subscriber 0.2.13
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
r? `@Mark-Simulacrum`
cc `@hawkw` ❤️
|
|
Bump to 1.48 bootstrap compiler
r? `@pietroalbini` (but anyone can feel free to review)
|
|
Fix tooltip text display
Currently, when we hover the icon, the text doesn't show up:
The bug was spotted by `@Nemo157`
r? `@jyn514`
|
|
|
|
Make src/bootstrap/CHANGELOG.md more helpful
Addresses https://github.com/rust-lang/rust/commit/fe6fc555acd51bd7ba8755d9fbc7060feb67be25#r42949241.
r? `@RalfJung`
cc `@Mark-Simulacrum`
|
|
- Make the parent module conditional on whether the docs are on a re-export
- Make `resolve_link` take `&Item` instead of `&mut Item`
Previously the borrow checker gave an error about multiple mutable
borrows, because `dox` borrowed from `item`.
- Fix `crate::` for re-exports
`crate` means something different depending on where the attribute
came from.
- Make it work for `#[doc]` attributes too
This required combining several attributes as one so they would keep
the links.
|
|
This distinguishes between documentation on the original from docs on
the re-export
|
|
- Add `parent_module` to `DocFragment`
- Require the `parent_module` of the item being inlined
- Preserve the hir_id for ExternCrates so rustdoc can find the parent module later
- Take an optional `parent_module` for `build_impl` and `merge_attrs`.
Preserve the difference between parent modules for each doc-comment.
- Support arbitrarily many re-exports in from_ast. In retrospect this is
probably not used and could be simplified to a single
`Option<(Attrs, DefId)>`.
- Don't require the parent_module for all `impl`s, just inlined items
In particular, this will be `None` whenever the attribute is not on a
re-export.
- Only store the parent_module, not the HirId
When re-exporting a re-export, the HirId is not available. Fortunately,
`collect_intra_doc_links` doesn't actually need all the info from a
HirId, just the parent module.
|
|
Unset GIT_DIR in pre-commit hook
Works around https://github.com/rust-lang/rust/issues/77620. This won't help any other hooks you write manually, but hopefully people won't feel the need to do that now there's an 'official' one.
r? `@Mark-Simulacrum`
cc `@caass`
|
|
Detect blocks that could be struct expr bodies
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
Partially address last remaining part of #34255.
|
|
|
|
Works around https://github.com/rust-lang/rust/issues/77620
|
|
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
- Remove useless test
This was testing for an ICE when passing `RUST_LOG=rustc_middle`. I
noticed it because it started giving the tracing warning (because tests
are not run with debug-logging enabled). Since this bug seems unlikely
to re-occur, I just removed it altogether.
|
|
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
Partially address last part of #34255.
|
|
Give `impl Trait` in a `const fn` its own feature gate
...previously it was gated under `#![feature(const_fn)]`.
I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer.
cc #77463
r? `@oli-obk`
|
|
Eliminate bounds checking in slice::Windows
This is how `<core::slice::Windows as Iterator>::next` looks right now:
```rust
fn next(&mut self) -> Option<&'a [T]> {
if self.size > self.v.len() {
None
} else {
let ret = Some(&self.v[..self.size]);
self.v = &self.v[1..];
ret
}
}
```
The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()`, so `self.v` can be empty if `self.size` is zero. In practice, since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero, `self.size` is never zero. However, the compiler doesn't know about this check, so it keeps the code which checks bounds and panics.
Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a, u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
<details>
<summary>Before</summary>
```
example::next:
push rax
mov rcx, qword ptr [rdi + 8]
mov rdx, qword ptr [rdi + 16]
cmp rdx, rcx
jbe .LBB0_2
xor eax, eax
pop rcx
ret
.LBB0_2:
test rcx, rcx
je .LBB0_5
mov rax, qword ptr [rdi]
mov rsi, rax
add rsi, 4
add rcx, -1
mov qword ptr [rdi], rsi
mov qword ptr [rdi + 8], rcx
pop rcx
ret
.LBB0_5:
lea rdx, [rip + .L__unnamed_1]
mov edi, 1
xor esi, esi
call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL]
ud2
.L__unnamed_2:
.ascii "./example.rs"
.L__unnamed_1:
.quad .L__unnamed_2
.asciz "\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"
```
</details>
<details>
<summary>After</summary>
```
example::next:
mov rcx, qword ptr [rdi + 8]
mov rdx, qword ptr [rdi + 16]
cmp rdx, rcx
jbe .LBB0_2
xor eax, eax
ret
.LBB0_2:
mov rax, qword ptr [rdi]
lea rsi, [rax + 4]
add rcx, -1
mov qword ptr [rdi], rsi
mov qword ptr [rdi + 8], rcx
ret
```
</details>
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet.
#### Possible reasons _not_ to merge this PR:
* this changes the error message on panic in `[T]::windows`. However, AFAIK this messages are not covered by backwards compatibility policy.
|
|
r=estebank
resolve: improve "try using the enum's variant"
Fixes #73427.
This PR improves the "try using the enum's variant" suggestion:
- Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have).
- Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided.
- A help message is added which mentions the variants which are no longer suggested.
All of the diagnostic logic introduced by this PR is separated from the normal code path for a successful compilation.
r? `@estebank`
|
|
|
|
builtin_macros: Fix use of interpolated identifiers in `asm!`
Fixes https://github.com/rust-lang/rust/issues/77584
|
|
Unclosed html tag lint
Part of #67799.
I think `@ollie27` will be interested (`@Manishearth` too since they opened the issue ;) ).
r? `@jyn514`
|
|
|
|
Update cargo
3 commits in 75615f8e69f748d7ef0df7bc0b064a9b1f5c78b2..9d1a4863abd9237dbf9d1b74c78632b6a205f6bb
2020-09-29 18:42:19 +0000 to 2020-10-05 18:29:52 +0000
- Add LTO to the metadata filename hash. (rust-lang/cargo#8755)
- Fix dylib+rlib with LTO. (rust-lang/cargo#8754)
- Homepage doc cargo metadata (rust-lang/cargo#8744)
|
