Rollup of 15 pull requests #88824
Merged
Rollup of 15 pull requests #88824
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It was accidentally changed to use `opts()` in rust-lang#86451. I also renamed `opts()` to `main_body_opts()` to make this kind of accidental change less likely.
This fixes odd renderings when these features are used in the first paragraph of documentation for an item. This is an extension of rust-lang#87270.
Previous version wrongly used `but` while the two parts of the sentence are not contradicting but completing with each other.
this also renders them as `_`, which rustdoc previously did not.
Note that this incorrectly suggests a shared borrow, but at least we know it's happening.
These were deleted in https://reviews.llvm.org/D108614, and in C++ I definitely see the argument for their removal. I didn't try and propagate the changes up into higher layers of rustc in this change because my initial goal was to get rustc working against LLVM HEAD promptly, but I'm happy to follow up with some refactoring to make the API on the Rust side match the LLVM API more directly (though the way the enum works in Rust makes the API less scary IMO). r? @nagisa cc @nikic
Otherwise we're kind of reimplementing the inverse of the well-named methods, and that's not a direction we want to go.
Turns out we can also use Attribute::get*() methods here, and avoid the AttrBuilder and an extra helper method here.
See rust-lang#88545 for more details
This commit focuses on emitting clean errors for the following syntax
error:
```
Some(42).map(|a|
dbg!(a);
a
);
```
Previous implementation tried to recover after parsing the closure body
(the `dbg` expression) by replacing the next `;` with a `,`, which made
the next expression belong to the next function argument. As such, the
following errors were emitted (among others):
- the semicolon token was not expected,
- a is not in scope,
- Option::map is supposed to take one argument, not two.
This commit allows us to gracefully handle this situation by adding
giving the parser the ability to remember when it has just parsed a
closure body inside a function call. When this happens, we can treat the
unexpected `;` specifically and try to parse as much statements as
possible in order to eat the whole block. When we can't parse statements
anymore, we generate a clean error indicating that the braces are
missing, and return an ExprKind::Err.
…r tuple struct fields.
…akis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes rust-lang#84647. Derived implementations of `Clone` and `Debug` always trivially read all fields, so "field is never read" dead code warnings are never triggered. Arguably, though, a user most likely will only be interested in whether _their_ code ever reads those fields, which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct, this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in rust-lang#84647, `@matklad` said > Doesn't seem easy to fix though :( However, it _was_ pretty straightforward to fix, so did I perhaps overlook something obvious? `@matklad,` could you weigh in on this?
…tolnay
Add proc_macro::Span::{before, after}.
This adds `proc_macro::Span::before()` and `proc_macro::Span::after()` to get a zero width span at the start or end of the span.
These are equivalent to rustc's `Span::shrink_to_lo()` and `Span::shrink_to_hi()` but with a less cryptic name. They are useful when generating diagnostlics like "missing \<thing\> after \<thing\>".
E.g.
```rust
syn::Error::new(ident.span().after(), "missing `:` after field name").into_compile_error()
```
Fix stray notes when the source code is not available Fixes rust-lang#87060. To reproduce it with a local build of rustc, you have to copy the compiler (e.g. `build/x86_64-unknown-linux-gnu/stage1/`) somewhere and then rename the compiler source directory (maybe there is a smarter way as well). Then, rustc won't find the standard library sources and report stray notes such as ``` note: deref defined here ``` with no location for "here". Another example I've found is this: ```rust use std::ops::Add; fn foo<T: Add<Output=()>>(x: T) { x + x; } fn main() {} ``` ``` error[E0382]: use of moved value: `x` --> binop.rs:4:9 | 3 | fn foo<T: Add<Output=()>>(x: T) { | - move occurs because `x` has type `T`, which does not implement the `Copy` trait 4 | x + x; | ----^ | | | | | value used here after move | `x` moved due to usage in operator | note: calling this operator moves the left-hand side help: consider further restricting this bound | 3 | fn foo<T: Add<Output=()> + Copy>(x: T) { | ^^^^^^ error: aborting due to previous error ``` where, again, the note is supposed to point somewhere but doesn't. I have fixed this by checking whether the corresponding source code is actually available before emitting the note.
Emit suggestion when passing byte literal to format macro Closes rust-lang#86865
…races, r=estebank
Emit proper errors when on missing closure braces
This commit focuses on emitting clean errors for the following syntax
error:
```
Some(42).map(|a|
dbg!(a);
a
);
```
Previous implementation tried to recover after parsing the closure body
(the `dbg` expression) by replacing the next `;` with a `,`, which made
the next expression belong to the next function argument. As such, the
following errors were emitted (among others):
- the semicolon token was not expected,
- a is not in scope,
- Option::map is supposed to take one argument, not two.
This commit allows us to gracefully handle this situation by adding
giving the parser the ability to remember when it has just parsed a
closure body inside a function call. When this happens, we can treat the
unexpected `;` specifically and try to parse as much statements as
possible in order to eat the whole block. When we can't parse statements
anymore, we generate a clean error indicating that the braces are
missing, and return an ExprKind::Err.
Closes rust-lang#88065.
r? `@estebank`
…erence-to-for-loop-iter, r=nagisa fix(rustc): suggest `items` be borrowed in `for i in items[x..]` Fixes rust-lang#87994
Fix issues with Markdown summary options - Use `summary_opts()` for Markdown summaries - Enable all main body Markdown options for summaries
…lds-count, r=Manishearth Rustdoc coverage fields count Follow-up of rust-lang#88688. Instead of requiring enum tuple variant fields and tuple struct fields to be documented, we count them if they are documented, otherwise we don't include them in the count. r? `@Manishearth`
RustWrapper: avoid deleted unclear attribute methods These were deleted in https://reviews.llvm.org/D108614, and in C++ I definitely see the argument for their removal. I didn't try and propagate the changes up into higher layers of rustc in this change because my initial goal was to get rustc working against LLVM HEAD promptly, but I'm happy to follow up with some refactoring to make the API on the Rust side match the LLVM API more directly (though the way the enum works in Rust makes the API less scary IMO). r? ``@nagisa`` cc ``@nikic``
…ks, r=nbdd0121 Fix table in docblocks "Overwrite" of rust-lang#88702. Instead of adding a z-index to the sidebar (which only hides the issue, doesn't fix it), I wrap `<table>` elements inside a `<div>` and limit all chidren of `.docblock` elements' width to prevent having the scrollbar on the whole doc block.  Thanks `@nbdd0121` for `overflow-x: auto;`. ;) r? `@notriddle`
…ements_grid_bug, r=GuillaumeGomez Workaround blink/chromium grid layout limitation of 1000 rows I made this in case we don't come up with a better solution in time. See rust-lang#88545 for more details. A rendered version of the standard library is hosted here: https://data.estada.ch/rustdoc-nightly_497ee321af_2021-09-09/core/arch/arm/index.html r? `@GuillaumeGomez` `@jsha`
…plett Fix typo in docs for iterators
Fix typo `option` -> `options`.
|
@bors r+ p=1 might as well get this ready for when the tree reopens |
|
📌 Commit f77311b has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
bors
added
the
S-waiting-on-bors
|
@bors p=3 should probabyl take some priority over submodule updates |
|
☀️ Test successful - checks-actions |
This was referenced Sep 11, 2021
|
Finished benchmarking commit (22719ef): comparison url. Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
|
Cachegrind diff of the (using https://github.com/rust-lang/rustc-perf,
It looks like some of the attribute checks added in that PR are unused, I'll open a PR to remove them and see if it helps. Edit: opened #89454 |
erikdesjardins
added a commit
to erikdesjardins/rust
that referenced
this pull request
Oct 2, 2021
The checks removed here caused a small perf regression: rust-lang#88824 (comment) Since the attribute is currently only applied to traits, I don't think it's worth keeping the additional checks for now. If/when we decide to apply the attribute somewhere else, we can (partially) revert this and evaluate if the perf impact is acceptable.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 7, 2021
…atsakis perf: only check for `rustc_trivial_field_reads` attribute on traits, not items, impls, etc. The checks that are removed in this PR (originally added in rust-lang#85200) caused a small perf regression: rust-lang#88824 (comment) Since the attribute is currently only applied to traits, I don't think it's worth keeping the additional checks for now. If/when we decide to apply the attribute somewhere else, we can (partially) revert this and reevaluate the perf impact. r? `@nikomatsakis` cc `@FabianWolff`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
itemsbe borrowed infor i in items[x..]#88578 (fix(rustc): suggestitemsbe borrowed infor i in items[x..])doc(hidden)on tuple variant fields #88639 (rustdoc: Fix ICE withdoc(hidden)on tuple variant fields)write_fmtdoc. #88667 (Tweakwrite_fmtdoc.)option->options. #88812 (Fix typooption->options.)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup