bors [Mon, 28 Jun 2021 03:43:39 +0000 (03:43 +0000)]
Auto merge of #85876 - jeanlucthumm:master, r=GuillaumeGomez
Add `go_to_first` query param to jump to first result
Fixes #84214
Note that while the issue initially wanted to navigate to an entry on exact match, the discussion settled on using a query parameter (`&go_to_first=true`) instead, regardless of exact or partial match.
bors [Sun, 27 Jun 2021 20:33:25 +0000 (20:33 +0000)]
Auto merge of #85359 - lrh2000:reserved-prefixes, r=nikomatsakis
Reserve prefixed identifiers and literals (RFC 3101)
This PR 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].
The tracking issue #84599 says we'll add a feature gate named `reserved_prefixes`, but I don't think I can do this because it is impossible for the lexer to know whether a feature is enabled or not. I guess determining the behavior by the edition information should be enough.
bors [Sun, 27 Jun 2021 18:10:35 +0000 (18:10 +0000)]
Auto merge of #86445 - sexxi-goose:box_fix, r=nikomatsakis
2229: Capture box completely in move closures
Even if the content from box is used in a sharef-ref context,
we capture the box entirerly.
This is motivated by:
1) We only capture data that is on the stack.
2) Capturing data from within the box might end up moving more data than
the user anticipated.
bors [Sun, 27 Jun 2021 15:45:29 +0000 (15:45 +0000)]
Auto merge of #86655 - jonas-schievink:const-arguments-as-str, r=kennytm
Make `fmt::Arguments::as_str` unstably const
Motivation: mostly to move "panic!() in const contexts" forward, making use of `as_str` was mentioned in https://github.com/rust-lang/rust/issues/85194#issuecomment-852345377 and seems like the simplest way forward.
bors [Sun, 27 Jun 2021 06:58:07 +0000 (06:58 +0000)]
Auto merge of #85448 - nanguye2496:nanguye2496/debuginfo_tests, r=Mark-Simulacrum
Add debug info tests for range, fix-sized array, and cell types
This PR add several debug info tests to guarantee that the displays of fixed sized arrays, range types, cell types, threads, locks, and mutexes in CDB are correct.
It also updates CDB tests for slices in pretty-std.rs after string visualization in WinDbg is fixed by this PR: #81898.
bors [Sun, 27 Jun 2021 00:15:49 +0000 (00:15 +0000)]
Auto merge of #86645 - FabianWolff:issue-82328, r=LeSeulArtichaut
Fix ICE with `-Zunpretty=hir,typed`
This PR fixes #82328. The `-Zunpretty=hir,typed` pretty-printer maintains an `Option` with type-checking results and sets the `Option` to `Some` when entering a body. However, this leads to an ICE if an expression occurs in a function signature (i.e. outside of a body), such as `128` in
```rust
fn foo(-128..=127: i8) {}
```
This PR fixes the ICE by checking (if necessary) whether the expression's owner has a body, and retrieving type-checking results for that on the fly.
bors [Sat, 26 Jun 2021 19:20:41 +0000 (19:20 +0000)]
Auto merge of #86267 - ZuseZ4:master, r=nagisa
Allow loading of llvm plugins on nightly
Based on a discussion in #82734 / with `@wsmoses.`
Mainly moves [this](https://github.com/wsmoses/rust/commit/0149bc4e7e596005c665b132877abebe5258a0f6) behind a -Z flag, so it can only be used on nightly,
as requested by `@nagisa` in https://github.com/rust-lang/rust/issues/82734#issuecomment-835863940
This change allows loading of llvm plugins like Enzyme.
Right now it also requires a shared library LLVM build of rustc for symbol resolution.
fn main() {
unsafe {
println!("Hello, world {} {}!", square(3.0), __enzyme_autodiff(square as usize, 3.0));
}
}
```
```
./rustc test.rs -Z llvm-plugins="./LLVMEnzyme-12.so" -C passes="enzyme"
./test
Hello, world 9 6!
```
I will try to figure out how to simplify the usage and get this into stable in a later iteration,
but having this on nightly will already help testing further steps.
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>`
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.
Aman Arora [Fri, 18 Jun 2021 20:35:10 +0000 (16:35 -0400)]
2229: Capture box completely in move closures
Even if the content from box is used in a sharef-ref context,
we capture the box entirerly.
This is motivated by:
1) We only capture data that is on the stack.
2) Capturing data from within the box might end up moving more data than
the user anticipated.
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.
projects / rust.git / log