bors [Wed, 9 Feb 2022 09:41:48 +0000 (09:41 +0000)]
Auto merge of #92306 - Aaron1011:opaque-type-op, r=oli-obk
Improve opaque type higher-ranked region error message under NLL
Currently, any higher-ranked region errors involving opaque types
fall back to a generic "higher-ranked subtype error" message when
run under NLL. This PR adds better error message handling for this
case, giving us the same kinds of error messages that we currently
get without NLL:
```
error: implementation of `MyTrait` is not general enough
--> $DIR/opaque-hrtb.rs:12:13
|
LL | fn foo() -> impl for<'a> MyTrait<&'a str> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough
|
= note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>`, for any lifetime `'1`...
= note: ...but it actually implements `MyTrait<&'2 str>`, for some specific lifetime `'2`
error: aborting due to previous error
```
To accomplish this, several different refactoring needed to be made:
* We now have a dedicated `InstantiateOpaqueType` struct which
implements `TypeOp`. This is used to invoke `instantiate_opaque_types`
during MIR type checking.
* `TypeOp` is refactored to pass around a `MirBorrowckCtxt`, which is
needed to report opaque type region errors.
* We no longer assume that all `TypeOp`s correspond to canonicalized
queries. This allows us to properly handle opaque type instantiation
(which does not occur in a query) as a `TypeOp`.
A new `ErrorInfo` associated type is used to determine what
additional information is used during higher-ranked region error
handling.
* The body of `try_extract_error_from_fulfill_cx`
has been moved out to a new function `try_extract_error_from_region_constraints`.
This allows us to re-use the same error reporting code between
canonicalized queries (which can extract region constraints directly
from a fresh `InferCtxt`) and opaque type handling (which needs to take
region constraints from the pre-existing `InferCtxt` that we use
throughout MIR borrow checking).
Yuki Okushi [Wed, 9 Feb 2022 05:12:24 +0000 (14:12 +0900)]
Rollup merge of #93751 - eholk:issue-93648-drop-tracking-projection, r=tmiasko
Drop tracking: track borrows of projections
Previous efforts to ignore partially consumed values meant we were also not considering borrows of a projection. This led to cases where we'd miss borrowed types which MIR expected to be there, leading to ICEs.
This PR also includes the `-Zdrop-tracking` flag from #93313. If that PR lands first, I'll rebase to drop the commit from this one.
Yuki Okushi [Wed, 9 Feb 2022 05:12:18 +0000 (14:12 +0900)]
Rollup merge of #93694 - jsha:font-sizes-spacing, r=GuillaumeGomez
rustdoc: tweak line spacing and paragraph spacing for accessibility
The [W3C Web Content Accessibility Guidelines](https://www.w3.org/WAI/WCAG21/Understanding/visual-presentation.html) specify a minimum line spacing of 1.5 and a minimum paragraph spacing of 1.5 times the line spacing. Our current line spacing (implemented by line-height) is 1.4, so it's a small bump to go up to 1.5. Similarly, we have a paragraph spacing of 0.6em. Bump that to 0.75em (which is 1.5 times the 0.5em distance between lines).
Also, fix all the font sizes so instead of being round-ish numbers in rem (like 1.1rem, 1.2rem), they are round numbers in pixels: 16px, 18px, 20px, 22px, 24px. Ensure each font size is at least 2 pixels different than the nearest other font size, so distinctions can be clearly seen. Overall the font-sizes are mostly staying the same, being rounded up or down as appropriate. This will make reasoning about consistent layout sizes much easier.
Remove a few unused styles.
Simplify the display of the mobile-topbar location, by setting its margins to auto rather than trying to size it exactly to the topbar.
Yuki Okushi [Wed, 9 Feb 2022 05:12:17 +0000 (14:12 +0900)]
Rollup merge of #93445 - yaahc:exitcode-constructor, r=dtolnay
Add From<u8> for ExitCode
This should cover a mostly cross-platform subset of supported exit codes.
We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s, but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no`, so there's some ambiguity there when returning exit codes > 127, but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`.
## Related
- Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426
- https://github.com/rust-lang/rust/issues/48711
- https://github.com/rust-lang/rust/issues/43301
- https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization
bors [Wed, 9 Feb 2022 04:05:55 +0000 (04:05 +0000)]
Auto merge of #93793 - ehuss:update-cargo, r=ehuss
Update cargo
5 commits in 25fcb135d02ea897ce894b67ae021f48107d522b..c082648646cbb2be266df9ecbcdc253058158d68
2022-02-01 01:32:48 +0000 to 2022-02-08 14:55:05 +0000
- Add rustup link (rust-lang/cargo#10371)
- Improve startup time of bash completion. (rust-lang/cargo#10365)
- Stabilize `-Ztimings` as `--timings` (rust-lang/cargo#10245)
- Remove needless borrow (rust-lang/cargo#10360)
- Compute non custom build and non transitive deps for doc (rust-lang/cargo#10341)
bors [Wed, 9 Feb 2022 01:18:06 +0000 (01:18 +0000)]
Auto merge of #93778 - matthiaskrgr:rollup-yfngdao, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #91950 (Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`)
- #92715 (Do not suggest char literal for zero-length strings)
- #92917 (Don't constrain projection predicates with inference vars in GAT substs)
- #93206 (Use `NtCreateFile` instead of `NtOpenFile` to open a file)
- #93732 (add fut/back compat tests for implied trait bounds)
- #93764 (:arrow_up: rust-analyzer)
- #93767 (deduplicate `lcnr` in mailmap)
Aaron Hill [Sun, 19 Dec 2021 00:06:53 +0000 (19:06 -0500)]
Improve opaque type higher-ranked region error message under NLL
Currently, any higher-ranked region errors involving opaque types
fall back to a generic "higher-ranked subtype error" message when
run under NLL. This PR adds better error message handling for this
case, giving us the same kinds of error messages that we currently
get without NLL:
```
error: implementation of `MyTrait` is not general enough
--> $DIR/opaque-hrtb.rs:12:13
|
LL | fn foo() -> impl for<'a> MyTrait<&'a str> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough
|
= note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>`, for any lifetime `'1`...
= note: ...but it actually implements `MyTrait<&'2 str>`, for some specific lifetime `'2`
error: aborting due to previous error
```
To accomplish this, several different refactoring needed to be made:
* We now have a dedicated `InstantiateOpaqueType` struct which
implements `TypeOp`. This is used to invoke `instantiate_opaque_types`
during MIR type checking.
* `TypeOp` is refactored to pass around a `MirBorrowckCtxt`, which is
needed to report opaque type region errors.
* We no longer assume that all `TypeOp`s correspond to canonicalized
queries. This allows us to properly handle opaque type instantiation
(which does not occur in a query) as a `TypeOp`.
A new `ErrorInfo` associated type is used to determine what
additional information is used during higher-ranked region error
handling.
* The body of `try_extract_error_from_fulfill_cx`
has been moved out to a new function `try_extract_error_from_region_constraints`.
This allows us to re-use the same error reporting code between
canonicalized queries (which can extract region constraints directly
from a fresh `InferCtxt`) and opaque type handling (which needs to take
region constraints from the pre-existing `InferCtxt` that we use
throughout MIR borrow checking).
Matthias Krüger [Tue, 8 Feb 2022 15:40:49 +0000 (16:40 +0100)]
Rollup merge of #93206 - ChrisDenton:ntopenfile, r=nagisa
Use `NtCreateFile` instead of `NtOpenFile` to open a file
Generally the internal `Nt*` functions should be avoided but when we do need to use one we should stick to the most commonly used for the job. To that end, this PR replaces `NtOpenFile` with `NtCreateFile`.
NOTE: The initial version of this comment hypothesised that this may help with some recent false positives from malware scanners. This hypothesis proved wrong. Sorry for the distraction.
Matthias Krüger [Tue, 8 Feb 2022 15:40:48 +0000 (16:40 +0100)]
Rollup merge of #92917 - jackh726:issue-91762-2, r=nikomatsakis
Don't constrain projection predicates with inference vars in GAT substs
cc #91762
Not a fix, but a mitigation to prevent a backwards-compatible hazard where we normalize using a predicate only because it's the only one available, but shouldn't. This would constrain an inference variable which didn't really want. We already do this when selecting a projection candidate, which isn't always correct. But changing that is a problem for a different day.
Also found out that a suggestion for `await`ing a future was using the wrong substs.
The W3C Web Content Accessibility Guidelines specify a minimum line
spacing of 1.5 and a minimum paragraph spacing of 1.5 times the line
spacing. Our current line spacing (implemented by line-height) is 1.4,
so it's a small bump to go up to 1.5. Similarly, we have a paragraph
spacing of 0.6em. Bump that to 0.75em (which is 1.5 times the 0.5em
distance between lines).
Also, fix all the font sizes so instead of being round-ish numbers in
rem (like 1.1rem, 1.2rem), they are round numbers in pixels. Ensure each
font size is at least 2 pixels different than the nearest other font
size, so distinctions can be clearly seen. Overall the font-sizes are
mostly staying the same, being rounded up or down as appropriate.
Remove a few unused styles.
Simplify the display of the mobile-topbar location, by setting its
margins to auto rather than trying to size it exactly to the topbar.
bors [Tue, 8 Feb 2022 10:05:05 +0000 (10:05 +0000)]
Auto merge of #93626 - wesleywiser:fix_hashmap_natvis, r=michaelwoerister
Fix HashMap not displaying correctly in VS debugger
The natvis to render HashMaps was not working correctly in Visual Studio
because the type names for tuples changed from `tuple$<A, B>` to
`tuple$<A,B>` (notice the missing space). WinDbg and cdb continued to
parse this type name which is why no tests in CI broke. VS however is
slightly more strict and this caused the visualizer to break.
Since we cannot test the VS debugger in CI, I'm not checking in any
test changes.
Matthias Krüger [Tue, 8 Feb 2022 05:47:38 +0000 (06:47 +0100)]
Rollup merge of #93728 - JulianKnodt:toterm, r=oli-obk
Add in ValuePair::Term
This adds in an enum when matching on positions which can either be types or consts.
It will default to emitting old special cased error messages for types.
Matthias Krüger [Tue, 8 Feb 2022 05:47:37 +0000 (06:47 +0100)]
Rollup merge of #93721 - jyn514:less-macro-special-casing, r=petrochenkov
rustdoc: Special-case macro lookups less
Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`
Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
struct S;
macro_rules! mac { () => {} }
// `mac`'s scope starts here
/// `mac` <- `resolve_str_path_error` won't see this
struct Z;
//`mac`'s scope ends here
}
```
This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.
This is a smaller version of https://github.com/rust-lang/rust/pull/91427.
Matthias Krüger [Tue, 8 Feb 2022 05:47:35 +0000 (06:47 +0100)]
Rollup merge of #93672 - lcnr:const-param-defaults-xx, r=matthewjasper
update comment wrt const param defaults
after #93669 i looked through all other uses of `GenericParamKind::Const` again to detect if we missed the `default` there as well, but afaict we really only missed lifetime resolution '^^ at least i found an outdated comment :3
Matthias Krüger [Tue, 8 Feb 2022 05:47:33 +0000 (06:47 +0100)]
Rollup merge of #93568 - willcrichton:scrape-examples-leading-whitespace, r=CraftSpider
Include all contents of first line of scraped item in Rustdoc
This fixes #93528. When scraping examples, it extends the span of the enclosing item to include all characters up to the start of the first line of the span.
Matthias Krüger [Tue, 8 Feb 2022 05:47:32 +0000 (06:47 +0100)]
Rollup merge of #93521 - jsha:sidebar-hover, r=GuillaumeGomez
Fix hover effects in sidebar
The dark and ayu themes have a menu-like highlight on sidebar items. The light theme used to, but it was accidentally lost in the sidebar unification. The change brings back the hover effect in the light theme.
It also makes the hover effect apply consistently to all links in the sidebar, including headings.
It also simplifies the "In _path_" heading so it's one big link. The breadcrumbs are still readily available at the top of the page.
Note that a small number of headings are not linkified and so don't get the hover effect. That will be fixed with #92957.
Matthias Krüger [Tue, 8 Feb 2022 05:47:32 +0000 (06:47 +0100)]
Rollup merge of #92695 - Swatinem:cover-nested, r=wesleywiser
Add `#[no_coverage]` tests for nested functions
I was playing around a bit trying to figure out how `#[no_coverage]` behaves for nested functions and thought I might as well add this as a testcase.
The "nesting covered fn inside not covered fn" case looks pretty much as expected.
The "nesting not covered fn inside a covered fn" case however seems a bit counterintuitive.
Essentially the region of the outer function "covers" its whole lexical range. And the inner function does not generate any region at all. 🤷🏻♂️
Matthias Krüger [Tue, 8 Feb 2022 05:47:31 +0000 (06:47 +0100)]
Rollup merge of #86497 - clarfonthey:nearest_char_boundary, r=scottmcm
Add {floor,ceil}_char_boundary methods to str
This is technically already used internally by the standard library in the form of `truncate_to_char_boundary`.
Essentially these are two building blocks to allow for approximate string truncation, where you want to cut off the string at "approximately" a given length in bytes but don't know exactly where the character boundaries lie. It's also a good candidate for the standard library as it can easily be done naively, but would be difficult to properly optimise. Although the existing code that's done in error messages is done naively, this code will explicitly only check a window of 4 bytes since we know that a boundary must lie in that range, and because it will make it possible to vectorise.
Although this method doesn't take into account graphemes or other properties, this would still be a required building block for splitting that takes those into account. For example, if you wanted to split at a grapheme boundary, you could take your approximate splitting point and then determine the graphemes immediately following and preceeding the split. If you then notice that these two graphemes could be merged, you can decide to either include the whole grapheme or exclude it depending on whether you decide splitting should shrink or expand the string.
This takes the most conservative approach and just offers the raw indices to the user, and they can decide how to use them. That way, the methods are as useful as possible despite having as few methods as possible.
(Note: I'll add some tests and a tracking issue if it's decided that this is worth including.)
Eric Holk [Tue, 8 Feb 2022 00:01:27 +0000 (16:01 -0800)]
Drop tracking: track borrows of projections
Previous efforts to ignore partially consumed values meant we were also
not considering borrows of a projection. This led to cases where we'd
miss borrowed types which MIR expected to be there, leading to ICEs.
bors [Mon, 7 Feb 2022 23:40:26 +0000 (23:40 +0000)]
Auto merge of #92007 - oli-obk:lazy_tait2, r=nikomatsakis
Lazy type-alias-impl-trait
Previously opaque types were processed by
1. replacing all mentions of them with inference variables
2. memorizing these inference variables in a side-table
3. at the end of typeck, resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type
This worked okayish for `impl Trait` in return position, but required lots of roundabout type inference hacks and processing.
This PR instead stops this process of replacing opaque types with inference variables, and just keeps the opaque types around.
Whenever an opaque type `O` is compared with another type `T`, we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it, we grab the recorded type (`T`) and compare that against `U`. This makes implementing
* https://github.com/rust-lang/rfcs/pull/2515
much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities).
bors [Mon, 7 Feb 2022 20:32:56 +0000 (20:32 +0000)]
Auto merge of #87869 - thomcc:skinny-io-error, r=yaahc
Make io::Error use 64 bits on targets with 64 bit pointers.
I've wanted this for a long time, but didn't see a good way to do it without having extra allocation. When looking at it yesterday, it was more clear what to do for some reason.
This approach avoids any additional allocations, and reduces the size by half (8 bytes, down from 16). AFAICT it doesn't come additional runtime cost, and the compiler seems to do a better job with code using it.
Additionally, this `io::Error` has a niche (still), so `io::Result<()>` is *also* 64 bits (8 bytes, down from 16), and `io::Result<usize>` (used for lots of io trait functions) is 2x64 bits (16 bytes, down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally, it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`.
(For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this)
On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it, since one of the fields it stores is a `i32`, so we can't get below that, and it's already about as close as we can get to it.
---
### Isn't Pointer Tagging Dodgy?
The details of the layout, and why its implemented the way it is, are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be, but I didn't trim it down that much, since there's a lot of stuff I did deliberately, that might have not seemed that way.
There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error.
I believe the scheme used to tag it is not UB, and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add`, and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation, so it would follow the safety contract of `core::ptr::{add,sub}`.
The other pointer this had to encode is not tagged — or rather, the tagged repr is equivalent to untagged (it's tagged with 0b00, and has >=4b alignment, so we can reuse the bottom bits). And the other variants we encode are just integers, which (which can be untagged using bitwise operations without worry — they're integers).
CC `@RalfJung` for the stuff in repr_bitpacked.rs, as my comments are informed by a lot of the UCG work, but it's possible I missed something or got it wrong (even if the implementation is okay, there are parts of the header comment that says things like "We can't do $x" which could be false).
---
### Why So Many Changes?
The repr change was mostly internal, but changed one widely used API: I had to switch how `io::Error::new_const` works.
This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static`, rather than just the string. This would have been really tedious, but I made a macro that made it much simpler, but it was a wide change since `io::Error::new_const` is used everywhere.
This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things), so I expect there to be spottiness in CI initially, unless luck is on my side.
Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file), whereas the packing stuff is all in commit 2.
---
P.S. I haven't looked at all of this since writing it, and will do a pass over it again later, sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such.
(It probably could use more tests too. I did some basic testing, and made it so we `debug_assert!` in cases the decode isn't what we encoded, but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal, especially around error cases, although I have no idea).
The dark and ayu themes have a menu-like highlight on sidebar items. The
light theme used to, but it was accidentally lost in the sidebar
unification. The change brings back the hover effect in the light theme.
It also makes the hover effect apply consistently to all links in the
sidebar, including headings.
It also simplifies the "In _path_" heading so it's one big link. The
breadcrumbs are still readily available at the top of the page.
Mara Bos [Mon, 7 Feb 2022 14:08:39 +0000 (14:08 +0000)]
Rollup merge of #93723 - jyn514:rerun-if-changed, r=Mark-Simulacrum
Rerun bootstrap's build script when RUSTC changes
Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:
```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
Finished dev [unoptimized] target(s) in 11.18s
failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```
This fixes the error. Reusing the same build directory is useful if you want to test path-related things in
bootstrap itself, without having to recompile it each time.
For good measure, this also reruns the build script when PATH changes.
Mara Bos [Mon, 7 Feb 2022 14:08:37 +0000 (14:08 +0000)]
Rollup merge of #93682 - PatchMixolydic:where-in-the-world-is-const_fn_trait_bound, r=oli-obk
Update tracking issue for `const_fn_trait_bound`
It previously pointed to #57563, the conglomerate issue for `const fn` (presumably under the feature gate `const_fn`). This tracking issue doesn't mention anything about `const_fn_trait_bound`(the only occurrence of "trait bound" is for the now-removed `?const Trait` syntax), which can be confusing to people who want to find out more about trait bounds on `const fn`s. This pull request changes the tracking issue to one meant specifically for `const_fn_trait_bound`, #93706, which can help collect information on this feature's stabilization and point users towards `const_trait_impl` if they're looking for const-in-const-contexts trait bounds.
Mara Bos [Mon, 7 Feb 2022 14:08:35 +0000 (14:08 +0000)]
Rollup merge of #93673 - jsha:linkify-sidebar-headings, r=GuillaumeGomez
Linkify sidebar headings for sibling items
Also adjust CSS so this doesn't produce excess padding/margin.
Note: I tried and failed to write a test with browser-UI-test. First I tried to `assert-property: (".block.mod h3 a", {"href": "index.html#macros"})`. But the `href` that gets read out is the fully-quallified URL, starting with `file:///`. That URL will differ depending on what path the test is run from, so that doesn't work.
Next I tried clicking on the appropriate sidebar link, and verifying that the appropriate heading on the next page is highlighted with the right background color. However, that also didn't work: according to browser-UI-test, the targeted heading was plain white. However, running with no-headless, I could see that it actually was yellow. I suspect this is a bug in the older version of Chromium used with browser-UI-test's bundled puppeteer, since it doesn't reproduce on latest Chrome.
Fix linking stage1 toolchain in `./x.py setup`. I guess this can be considered a follow up to https://github.com/rust-lang/rust/pull/89212 by `````@Sl1mb0.`````
We create 2 directories and 1 file that are required by rustup to [link a custom toolchain from path](https://github.com/rust-lang/rustup/blob/5225e87a5d974ab5f1626bcb2a7b43f76ab883f0/src/toolchain.rs#L479-L497).
cc `````@jyn514````` and `````@Mark-Simulacrum````` as they were active in https://github.com/rust-lang/rust/issues/89206
Mara Bos [Mon, 7 Feb 2022 14:08:32 +0000 (14:08 +0000)]
Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl, r=m-ou-se
Impl {Add,Sub,Mul,Div,Rem,BitXor,BitOr,BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0
Tracking issue #93204
This is about adding basic integer operations to the `Wrapping` type:
```rust
let mut value = Wrapping(2u8);
value += 3u8;
value -= 1u8;
value *= 2u8;
value /= 2u8;
value %= 2u8;
value ^= 255u8;
value |= 123u8;
value &= 2u8;
```
Because this adds stable impls on a stable type, it runs into the following issue if an `#[unstable(...)]` attribute is used:
```
an `#[unstable]` annotation here has no effect
note: see issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information
```
This means - if I understood this correctly - the new impls have to be stabilized instantly.
Which in turn means, this PR has to kick of an FCP on the tracking issue as well?
Mara Bos [Mon, 7 Feb 2022 14:08:31 +0000 (14:08 +0000)]
Rollup merge of #91530 - bobrippling:suggest-1-tuple-parens, r=camelid
Suggest 1-tuple parentheses on exprs without existing parens
A follow-on from #86116, split out from #90677.
This alters the suggestion to add a trailing comma to create a 1-tuple - previously we would only apply this if the relevant expression was parenthesised. We now make the suggestion regardless of parentheses, which reduces the fragility of the check (w.r.t formatting).
e.g.
```rust
let a: Option<(i32,)> = Some(3);
```
gets the below suggestion:
```rust
let a: Option<(i32,)> = Some((3,));
// ^ ^^
```
This change also improves the suggestion in other ways, such as by only making the suggestion if the types would match after the suggestion is applied and making the suggestion a multipart suggestion.
Mara Bos [Mon, 7 Feb 2022 14:08:29 +0000 (14:08 +0000)]
Rollup merge of #88313 - jyn514:pre-push, r=Mark-Simulacrum
Make the pre-commit script pre-push instead
This should make it substantially less annoying, and hopefully more
people will find it useful. In particular, it will no longer run tidy
each time you run `git commit --amend` or rebase a branch.
This also warns if you have the old script in pre-commit; see the HACK
comment for details.
kadmin [Mon, 7 Feb 2022 04:57:45 +0000 (04:57 +0000)]
Add in ValuePair::Term
This adds in an enum when matching on positions which can either be types or consts.
It will default to emitting old special cased error messages for types.
Joshua Nelson [Mon, 7 Feb 2022 01:54:35 +0000 (19:54 -0600)]
Rerun bootstrap's build script when RUSTC changes
Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:
```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
Finished dev [unoptimized] target(s) in 11.18s
failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```
This fixes the error. Reusing the same build directory is useful if you want to test path-things in
bootstrap itself, without having to recompile it each time.
For good measure, this also reruns the build script when PATH changes.
Joshua Nelson [Mon, 7 Feb 2022 00:39:42 +0000 (18:39 -0600)]
rustdoc: Special-case macro lookups less
Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`
Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
struct S;
macro_rules! mac { () => {} }
// `mac`'s scope starts here
/// `mac` <- `resolve_str_path_error` won't see this
struct Z;
//`mac`'s scope ends here
}
```
This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.
This also adds a failing test case which will catch trying to remove `all_macros`.
bors [Mon, 7 Feb 2022 00:26:52 +0000 (00:26 +0000)]
Auto merge of #93179 - Urgau:unreachable-2021, r=m-ou-se,oli-obk
Fix invalid special casing of the unreachable! macro
This pull-request fix an invalid special casing of the `unreachable!` macro in the same way the `panic!` macro was solved, by adding two new internal only macros `unreachable_2015` and `unreachable_2021` edition dependent and turn `unreachable!` into a built-in macro that do dispatching. This logic is stolen from the `panic!` macro.
~~This pull-request also adds an internal feature `format_args_capture_non_literal` that allows capturing arguments from formatted string that expanded from macros. The original RFC #2795 mentioned this as a future possibility. This feature is [required](https://github.com/rust-lang/rust/issues/92137#issuecomment-1018630522) because of concatenation that needs to be done inside the macro:~~
```rust
$crate::concat!("internal error: entered unreachable code: ", $fmt)
```
**In summary** the new behavior for the `unreachable!` macro with this pr is:
Edition 2021:
```rust
let x = 5;
unreachable!("x is {x}");
```
```
internal error: entered unreachable code: x is 5
```
Edition <= 2018:
```rust
let x = 5;
unreachable!("x is {x}");
```
```
internal error: entered unreachable code: x is {x}
```
Also note that the change in this PR are **insta-stable** and **breaking changes** but this a considered as being a [bug](https://github.com/rust-lang/rust/issues/92137#issuecomment-998441613).
If someone could start a perf run and then a crater run this would be appreciated.
Ruby Lazuli [Sat, 5 Feb 2022 21:02:00 +0000 (15:02 -0600)]
Fix tracking issue for `const_fn_trait_bound`
It previously pointed to #57563, the conglomerate issue for
`const fn` (presumably under the feature gate `const_fn`).
`const_fn_trait_bounds` weren't mentioned here, so this commit changes
its tracking issue to a new one.
Matthias Krüger [Sun, 6 Feb 2022 09:43:51 +0000 (10:43 +0100)]
Rollup merge of #93489 - Amanieu:panic_no_unwind, r=nagisa
Mark the panic_no_unwind lang item as nounwind
This has 2 effects:
- It helps LLVM when inlining since it doesn't need to generate landing pads for `panic_no_unwind`.
- It makes it sound for a panic handler to unwind even if `PanicInfo::can_unwind` returns true. This will simply cause another panic once the unwind tries to go past the `panic_no_unwind` lang item. Eventually this will cause a stack overflow, which is safe.
Matthias Krüger [Sun, 6 Feb 2022 09:43:50 +0000 (10:43 +0100)]
Rollup merge of #90998 - jhpratt:require-const-stability, r=oli-obk
Require const stability attribute on all stable functions that are `const`
This PR requires all stable functions (of all kinds) that are `const fn` to have a `#[rustc_const_stable]` or `#[rustc_const_unstable]` attribute. Stability was previously implied if omitted; a follow-up PR is planned to change the fallback to be unstable.
bors [Sun, 6 Feb 2022 08:34:48 +0000 (08:34 +0000)]
Auto merge of #90414 - thomcc:count-chars-faster, r=nagisa
Optimize `core::str::Chars::count`
I wrote this a while ago after seeing this function as a bottleneck in a profile, but never got around to contributing it. I saw it again, and so here it is. The implementation is fairly complex, but I tried to explain what's happening at both a high level (in the header comment for the file), and in line comments in the impl. Hopefully it's clear enough.
This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below), for a wide variety of workloads, without regressing performance on any of the workload sizes I've tried.
I also improved the benchmarks for this code, so that they explicitly check text in different languages and of different sizes (err, the cross product of language x size). The results of the benchmarks are here:
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s, which is surprising given how thorough they are, but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though, so... hopefully I'm not about to embarrass myself).
This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066, so I'm going to request review from the same person who reviewed that one. That said am not particularly picky, and might not have the correct syntax for requesting a review from someone (so it goes).
projects / rust.git / log