lrh2000 [Sun, 16 May 2021 03:10:05 +0000 (11:10 +0800)]
Reserve prefixed identifiers and string literals (RFC 3101)
This commit denies any identifiers immediately followed by
one of three tokens `"`, `'` or `#`, which is stricter than
the requirements of RFC 3101 but may be necessary according
to the discussion at [Zulip].
This will now render properly including the `for<'a>`
![image](https://user-images.githubusercontent.com/39732259/116808426-fe6ce600-ab38-11eb-9452-f33f554fbb8e.png)
I do not know if this covers all cases, it only covers everything that I could think of that includes `for` and lifetimes in where bounds.
Also someone need to mentor me on how to add a proper rustdoc test for this.
bors [Sat, 26 Jun 2021 08:24:31 +0000 (08:24 +0000)]
Auto merge of #86586 - Smittyvb:https-everywhere, r=petrochenkov
Use HTTPS links where possible
While looking at #86583, I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation, there are a few other HTTP links that are used by CI that are changed to HTTPS.
Notes:
- I didn't change any to or in licences
- Some links don't support HTTPS :(
- Some `http` links were dead, in those cases I upgraded them to their new places (all of which used HTTPS)
bors [Sat, 26 Jun 2021 02:28:45 +0000 (02:28 +0000)]
Auto merge of #86622 - FabianWolff:issue-83475, r=jonas-schievink
Check that `#[cmse_nonsecure_entry]` is applied to a function definition
This PR fixes #83475. The compiler currently neglects to check whether `#[cmse_nonsecure_entry]` is applied to a function (and not, say, a struct) definition, leading to an ICE later on when the type checker attempts to retrieve the function signature. I have fixed this problem by adding an appropriate check to the `check_attr` pass, so that an error is reported instead of an ICE.
bors [Fri, 25 Jun 2021 23:47:56 +0000 (23:47 +0000)]
Auto merge of #86015 - jyn514:revert-revert, r=Mark-Simulacrum
Move LLVM submodule updates back to native.rs
Time to find more bugs!
The first commit is a straight revert of https://github.com/rust-lang/rust/pull/85647, the second is a fix for https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/x.2Epy.20always.20updates.20LLVM.20submodule/near/240113320 and https://github.com/rust-lang/rust/pull/82653#issuecomment-846755631. I haven't been able to replicate https://github.com/rust-lang/rust/pull/82653#issuecomment-849013698.
bors [Fri, 25 Jun 2021 18:16:37 +0000 (18:16 +0000)]
Auto merge of #86627 - JohnTitor:rollup-ey29pc1, r=JohnTitor
Rollup of 5 pull requests
Successful merges:
- #86330 (Change how edition based future compatibility warnings are handled)
- #86513 (Rustdoc: Do not list impl when trait has doc(hidden))
- #86592 (Use `#[non_exhaustive]` where appropriate)
- #86608 (chore(rustdoc): remove unused members of RenderType)
- #86624 (Update compiler-builtins)
Yuki Okushi [Fri, 25 Jun 2021 15:42:12 +0000 (00:42 +0900)]
Rollup merge of #86592 - jhpratt:non_exhaustive, r=JohnTitor
Use `#[non_exhaustive]` where appropriate
Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`).
Yuki Okushi [Fri, 25 Jun 2021 15:42:06 +0000 (00:42 +0900)]
Rollup merge of #86330 - rylev:update-fcw-handling, r=nikomatsakis
Change how edition based future compatibility warnings are handled
This fixes https://github.com/rust-lang/rust/issues/85894 by updating how future compatibility lints work. This makes it more apparent that future compatibility warnings can happen for several different reasons.
For now `FutureCompatibilityReasons` are limited to three reasons, but we can easily add more.
This also updates the generated warning for FCW's that signal code that will error in a future edition. This makes the diagnostics between FCWs at edition boundaries more distinct from those not happening at an edition boundary.
bors [Fri, 25 Jun 2021 06:47:30 +0000 (06:47 +0000)]
Auto merge of #86151 - scottmcm:simple-hash-of, r=joshtriplett
Add `BuildHasher::hash_one` as unstable
Inspired by https://github.com/rust-lang/rust/pull/86140/files#diff-246941135168fbc44fce120385ee9c3156e08a1c3e2697985b56dcb8d728eedeR2416, where I wanted to write a quick test for a `Hash` implementation and it took more of a dance than I'd hoped.
It looks like this would be handy in hashtable implementations, too -- a quick look at hashbrown found two places where it needs to do the same dance:
https://github.com/rust-lang/hashbrown/blob/6302512a8a514fe5bd442464ebcd78139c82e1e2/src/map.rs#L247-L270
I wanted to get a "seems plausible" from a libs member before making a tracking issue, so random-sampling the intersection of highfive and governance gave me...
r? `@joshtriplett`
(As always, bikeshed away! And let me know if I missed something obvious again that I should have used instead.)
bors [Fri, 25 Jun 2021 01:23:16 +0000 (01:23 +0000)]
Auto merge of #86574 - m-ou-se:or-pattern-lint-fix, r=petrochenkov
Don't lint :pat when re-parsing a macro from another crate.
`compile_macro` is used both when compiling the original definition in the crate that defines it, and to compile the macro when loading it when compiling a crate that uses it. We should only emit lints in the first case.
This adds a `is_definition: bool` to pass this information in, so we don't warn about things that only concern the definition site.
bors [Thu, 24 Jun 2021 22:42:26 +0000 (22:42 +0000)]
Auto merge of #86272 - nagisa:nagisa/tidy-llvm-components, r=Mark-Simulacrum
tidy: verify that test revisions with --target have associated needs-llvm-components directives
This ensures that people who tend to write `--target` `#[no_core]` tests don't miss specifying the `needs-llvm-components` directive. This is necessary for the test suite to pass when LLVM is compiled with a subset of components enabled.
While here I also took the opportunity to implement a more fine-grained handling of the ignore directives, so that they are evaluated for each revision, rather than for the entire test. With this even if people have `arm` component disabled, only the revision that depends on the arm component will not run.
Otherwise something that ought to seemingly work like `//[x86]
needs-llvm-components: x86` or `//[nll_beyond]should-fail` do not get
evaluated properly.
Herein we verify that all of the tests that specify a `--target`
compile-flag, are also annotated with the minimal set of required llvm
components necessary to run that test.
bors [Thu, 24 Jun 2021 20:01:39 +0000 (20:01 +0000)]
Auto merge of #85651 - dns2utf8:rustdoc_flexbox, r=GuillaumeGomez
rustdoc: staggered layout for module contents on mobile
This PR adds the container `<item-table>` with its two children `<item-left>` and `<item-right>`.
It uses grid-layout on desktop and flexbox on mobile to make better use of the available space.
Additionally it allows to share parts of the CSS with the search function.
bors [Thu, 24 Jun 2021 17:37:29 +0000 (17:37 +0000)]
Auto merge of #86467 - ChrisDenton:win-env-clear, r=JohnTitor
Windows: Fix `Command::env_clear` so it works if no variables are set
Previously, it would error unless at least one new environment variable was added. The missing null presumably meant that Windows was reading random memory in that case.
See: [CreateProcessW](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) (scroll down to `lpEnvironment`). Essentially the environment block is a null terminated list of null terminated strings and an empty list is `\0\0` and not `\0`.
EDIT: Oh, [CreateEnvironmentBlock](https://docs.microsoft.com/en-gb/windows/win32/api/userenv/nf-userenv-createenvironmentblock) states this much more explicitly.
bors [Thu, 24 Jun 2021 14:56:28 +0000 (14:56 +0000)]
Auto merge of #85427 - ehuss:fix-use-placement, r=jackh726
Fix use placement for suggestions near main.
This fixes an edge case for the suggestion to add a `use`. When running with `--test`, the `main` function will be annotated with an `#[allow(dead_code)]` attribute. The `UsePlacementFinder` would end up using the dummy span of that synthetic attribute. If there are top-level inner attributes, this would place the `use` in the wrong position. The solution here is to ignore attributes with dummy spans.
In the process of working on this, I discovered that the `use_suggestion_placement` test was broken. `UsePlacementFinder` is unaware of active attributes. Attributes like `#[derive]` don't exist in the AST since they are removed. Fixing that is difficult, since the AST does not retain enough information. I considered trying to place the `use` towards the top of the module after any `extern crate` items, but I couldn't find a way to get a span for the start of a module block (the `mod` span starts at the `mod` keyword, and it seems tricky to find the spot just after the opening bracket and past inner attributes). For now, I just put some comments about the issue. This appears to have been a known issue in #44215 where the test for it was introduced, and the fix seemed to be deferred to later.
Jacob Pratt [Thu, 24 Jun 2021 08:16:11 +0000 (04:16 -0400)]
Use `#[non_exhaustive]` where appropriate
Due to the std/alloc split, it is not possible to make
`alloc::collections::TryReserveError::AllocError` non-exhaustive without
having an unstable, doc-hidden method to construct (which negates the
benefits from `#[non_exhaustive]`.
bors [Thu, 24 Jun 2021 07:29:59 +0000 (07:29 +0000)]
Auto merge of #86279 - JohnTitor:transparent-zero-size-fields, r=nikomatsakis
Permit zero non-zero-field on transparent types
Fixes #77841
This makes the transparent fields meet the below:
> * A `repr(transparent)` type `T` must meet the following rules:
> * It may have any number of 1-ZST fields
> * In addition, it may have at most one other field of type U
Yuki Okushi [Thu, 24 Jun 2021 04:47:37 +0000 (13:47 +0900)]
Rollup merge of #86560 - ehuss:update-cargo, r=ehuss
Update cargo
This also updates `opener` used in bootstrap (to try to keep dependencies unified).
18 commits in 44456677b5d1d82fe981c955dc5c67734b31f340..9233aa06c801801cff75df65df718d70905a235e
2021-06-12 18:00:01 +0000 to 2021-06-22 21:32:55 +0000
- Detect incorrectly named cargo.toml (rust-lang/cargo#9607)
- Unify weak and namespaced features. (rust-lang/cargo#9574)
- Change `rustc-cdylib-link-arg` error to a warning. (rust-lang/cargo#9563)
- Updates to future-incompatible reporting. (rust-lang/cargo#9606)
- Add a compatibility notice for diesel and the new resolver. (rust-lang/cargo#9602)
- Don't allow config env to modify vars set by cargo (rust-lang/cargo#9579)
- Disambiguate is_symlink. (rust-lang/cargo#9604)
- Update opener requirement from 0.4 to 0.5 (rust-lang/cargo#9583)
- Avoid quadratic complexity when splitting output into lines (rust-lang/cargo#9586)
- Bump to 0.56.0, update changelog (rust-lang/cargo#9597)
- Fix dep-info files including non-local build script paths. (rust-lang/cargo#9596)
- Relax doc collision error. (rust-lang/cargo#9595)
- Handle "jobs = 0" case in cargo config files (rust-lang/cargo#9584)
- Enhancements to testsuite error output. (rust-lang/cargo#9589)
- Fix typo (rust-lang/cargo#9590)
- Enable support for fix --edition for 2021. (rust-lang/cargo#9588)
- Add more details for installing git repository errors (rust-lang/cargo#9582)
- More information for links conflicting (rust-lang/cargo#9568)
Yuki Okushi [Thu, 24 Jun 2021 04:47:35 +0000 (13:47 +0900)]
Rollup merge of #86533 - inquisitivecrystal:lower-case-error-explain, r=petrochenkov
Support lowercase error codes in `--explain`
This enables `rustc --explain` to accept a lowercase error code. Thus, for instance, `rustc --explain e0573` would be valid after this change, where before a user would have needed to do `rustc --explain E0573`. Although the upper case form of an error code is canonical, the user may prefer the easier-to-type lowercase form, and there's nothing to be gained by forcing them to type the upper case version.
Yuki Okushi [Thu, 24 Jun 2021 04:47:34 +0000 (13:47 +0900)]
Rollup merge of #86415 - Kmeakin:iterator-associativity-docs, r=dtolnay
Document associativity of iterator folds.
Document the associativity of `Iterator::fold` and
`DoubleEndedIterator::rfold` and add examples demonstrating this.
Add links to direct users to the fold of the opposite associativity.
Yuki Okushi [Thu, 24 Jun 2021 04:47:26 +0000 (13:47 +0900)]
Rollup merge of #86137 - GuillaumeGomez:error-code-cleanup, r=Mark-Simulacrum
Error code cleanup and enforce checks
Fixes #86097.
It now checks if an error code is unused, and if so, will report an error if the error code wasn't commented out in the `error_codes.rs` file. It also checks that the constant used in the tidy check is up-to-date.
bors [Wed, 23 Jun 2021 21:35:46 +0000 (21:35 +0000)]
Auto merge of #86138 - FabianWolff:issue-85871, r=nikomatsakis
Check whether the closure's owner is an ADT in thir-unsafeck
This pull request fixes #85871. The code in `rustc_mir_build/src/check_unsafety.rs` incorrectly assumes that a closure's owner always has a body, but only functions, closures, and constants have bodies, whereas a closure can also appear inside a struct or enum:
```rust
struct S {
arr: [(); match || 1 { _ => 42 }]
}
enum E {
A([(); { || 1; 42 }])
}
```
This pull request fixes the resulting ICE by checking whether the closure's owner is an ADT and only deferring to `thir_check_unsafety(owner)` if it isn't.
bors [Wed, 23 Jun 2021 08:45:17 +0000 (08:45 +0000)]
Auto merge of #86548 - GuillaumeGomez:fix-crate-filter-search-reset, r=jsha
Fix crate filter search reset
I found a fun bug when using rustdoc recently: I made a search, cut the search input content, changed the crate filter, pasted back the input content. To my surprise, the crate filter wasn't applied. It's because that our search input was empty when receiving the `<select>` "onchange" event. To fix this issue, I reset the `currentResults` variable to `null`.
It's using the first commit from #86542 so it needs to wait for it before getting merged.
bors [Wed, 23 Jun 2021 03:16:04 +0000 (03:16 +0000)]
Auto merge of #86386 - inquisitivecrystal:better-errors-for-display-traits-v3, r=estebank
Better errors for Debug and Display traits
Currently, if someone tries to pass value that does not implement `Debug` or `Display` to a formatting macro, they get a very verbose and confusing error message. This PR changes the error messages for missing `Debug` and `Display` impls to be less overwhelming in this case, as suggested by #85844. I was a little less aggressive in changing the error message than that issue proposed. Still, this implementation would be enough to reduce the number of messages to be much more manageable.
After this PR, information on the cause of an error involving a `Debug` or `Display` implementation would suppressed if the requirement originated within a standard library macro. My reasoning was that errors originating from within a macro are confusing when they mention details that the programmer can't see, and this is particularly problematic for `Debug` and `Display`, which are most often used via macros. It is possible that either a broader or a narrower criterion would be better. I'm quite open to any feedback.
bors [Tue, 22 Jun 2021 23:58:03 +0000 (23:58 +0000)]
Auto merge of #86559 - Dylan-DPC:rollup-aixg3q5, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #86223 (Specify the kind of the item for E0121)
- #86521 (Add comments around code where ordering is important due for panic-safety)
- #86523 (Improvements to intra-doc link macro disambiguators)
- #86542 (Line numbers aligned with content)
- #86549 (Add destructuring example of E0508)
- #86557 (Update books)
Dylan DPC [Tue, 22 Jun 2021 22:20:24 +0000 (00:20 +0200)]
Rollup merge of #86557 - ehuss:update-books, r=ehuss
Update books
## nomicon
10 commits in 55de6fa3c1f331774da19472c9ee57d2ae9eb039..b9ca313e687c991223e23e5520529815dc281205
2021-05-12 00:31:01 +0900 to 2021-06-22 12:02:20 -0400
- The #[repr(C)] attribute on the callback example is not necessary, since the type is not used in C.
- Reorganize some chapters (rust-lang-nursery/nomicon#282)
- Mention "extern types" on the opaque structs section (rust-lang-nursery/nomicon#273)
- Clarify the conditions on the aliasing section (rust-lang-nursery/nomicon#272)
- Upgrade to edition 2018 (rust-lang-nursery/nomicon#280)
- Update some wording making reference to issues/RFCs (rust-lang-nursery/nomicon#271)
- Some improvements on the "subtyping" chapter (rust-lang-nursery/nomicon#278)
- Clarify casting between the same size fixed ints (rust-lang-nursery/nomicon#277)
- Add a link to show why unused lifetimes on structs are forbidden (rust-lang-nursery/nomicon#276)
- Fix small typo in the Drop Check chapter (rust-lang-nursery/nomicon#275)
## reference
8 commits in 8f598e2af6c25b4a7ee88ef6a8196d9b8ea50ca8..d9699fa8f3186440fdaadd703d63d8d42322c176
2021-06-01 19:00:46 +0100 to 2021-06-21 12:23:10 -0700
- Make explicit reference to scrutinee expression in grammar snippet (rust-lang-nursery/reference#1044)
- Document sub-namespaces. (rust-lang-nursery/reference#1043)
- Default all examples to 2018 edition. (rust-lang-nursery/reference#1041)
- Minor update to macros. (rust-lang-nursery/reference#1048)
- (rust-lang-nursery/reference#1049)
- Add a note why the same size int casting is a no-op (rust-lang-nursery/reference#1046)
- Add notes on `#[target_feature]` for wasm (rust-lang-nursery/reference#1047)
- Make statement about variable visibility more precise (rust-lang-nursery/reference#1045)
## rustc-dev-guide
8 commits in c8da5bfd1c7c71d90ef1646f5e0a9f6609d5c78a..fe34beddb41dea5cb891032512a8d5b842b99696
2021-06-04 09:08:56 +0200 to 2021-06-21 21:50:12 +0200
- Update "Inference variables" section (rust-lang/rustc-dev-guide#1145)
- Document how to run unit tests (rust-lang/rustc-dev-guide#1141)
- We stopped using allow_internal_unstable a while ago (rust-lang/rustc-dev-guide#1142)
- Change the feature used as an example of stabilizing lib features (rust-lang/rustc-dev-guide#1143)
- We use HIR to do type inference, trait solving and type checking (rust-lang/rustc-dev-guide#1139)
- Add suggested settings note for coc (rust-lang/rustc-dev-guide#1144)
- move 7/8 to prose
- Add a section on keeping things up to date in the git section
Dylan DPC [Tue, 22 Jun 2021 22:20:22 +0000 (00:20 +0200)]
Rollup merge of #86542 - GuillaumeGomez:line-numbers-aligned-with-content, r=jyn514
Line numbers aligned with content
We had the issue a few times in the past where the source code pages' content wasn't aligned with the line numbers but completely below. This test will prevent this change to go unnoticed.
The first commit comes from https://github.com/rust-lang/rust/pull/86541 so it needs it to be merged first.
Dylan DPC [Tue, 22 Jun 2021 22:20:21 +0000 (00:20 +0200)]
Rollup merge of #86523 - LeSeulArtichaut:macros-disambiguators, r=jyn514
Improvements to intra-doc link macro disambiguators
A few small improvements around macro disambiguators:
- display the link text as it was entered: previously `[macro!()]` would be displayed without the parantheses (fixes #86309)
- support `!{}` and `![]` as macro disambiguators (fixes #86310)
Dylan DPC [Tue, 22 Jun 2021 22:20:20 +0000 (00:20 +0200)]
Rollup merge of #86521 - the8472:add-footgun-comments, r=RalfJung
Add comments around code where ordering is important due for panic-safety
Iterators contain arbitrary code which may panic. Unsafe code has to be
careful to do its state updates at the right point between calls that may panic.
As requested in https://github.com/rust-lang/rust/pull/86452#discussion_r655153948
bors [Tue, 22 Jun 2021 17:34:55 +0000 (17:34 +0000)]
Auto merge of #86045 - jsgf:fix-emit-path-hashing, r=bjorn3
Fix emit path hashing
With `--emit KIND=PATH`, the PATH should not affect hashes used for dependency tracking. It does not with other ways of specifying output paths (`-o` or `--out-dir`).
Also updates `rustc -Zls` to print more info about crates, which is used here to implement a `run-make` test.
It seems there was already a test explicitly checking that `OutputTypes` hash *is* affected by the path. I think this behaviour is wrong, so I updated the test.
The8472 [Mon, 21 Jun 2021 19:29:43 +0000 (21:29 +0200)]
Add comments around code where ordering is important due for panic-safety
Iterators contain arbitrary code which may panic. Unsafe code has to be
careful to do its state updates at the right point between calls
that may panic.