| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 8 pull requests
Successful merges:
- #89258 (Make char conversion functions unstably const)
- #90578 (add const generics test)
- #90633 (Refactor single variant `Candidate` enum into a struct)
- #90800 (bootstap: create .cargo/config only if not present)
- #90942 (windows: Return the "Not Found" error when a path is empty)
- #90947 (Move some tests to more reasonable directories - 9.5)
- #90961 (Suggest removal of arguments for unit variant, not replacement)
- #90990 (Arenas cleanup)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Suggest removal of arguments for unit variant, not replacement
|
|
Move some tests to more reasonable directories - 9.5
cc #73494
r? `@petrochenkov`
|
|
bootstap: create .cargo/config only if not present
In some situations we should want on influence into the .cargo/config
when we use vendored source. One example is #90764, when we want to
workaround some references to crates forked and living in git, that are
missing in the vendor/ directory.
This commit will create the .cargo/config file only when the .cargo/
directory needs to be created.
|
|
add const generics test
cc https://github.com/rust-lang/rust/pull/89829#issuecomment-948921310
r? rust-lang/project-const-generics
|
|
Try all stable method candidates first before trying unstable ones
Currently we try methods in this order in each step:
* Stable by value
* Unstable by value
* Stable autoref
* Unstable autoref
* ...
This PR changes it to first try pick methods without any unstable candidates, and if none is found, try again to pick unstable ones.
Fix #90320
CC #88971, hopefully would allow us to rename the "unstable_*" methods for integer impls back.
`@rustbot` label T-compiler T-libs-api
|
|
Rollup of 8 pull requests
Successful merges:
- #90386 (Add `-Zassert-incr-state` to assert state of incremental cache)
- #90438 (Clean up mess for --show-coverage documentation)
- #90480 (Mention `Vec::remove` in `Vec::swap_remove`'s docs)
- #90607 (Make slice->str conversion and related functions `const`)
- #90750 (rustdoc: Replace where-bounded Clean impl with simple function)
- #90895 (require full validity when determining the discriminant of a value)
- #90989 (Avoid suggesting literal formatting that turns into member access)
- #91002 (rustc: Remove `#[rustc_synthetic]`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
rustc: Remove `#[rustc_synthetic]`
This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
Noticed while reviewing https://github.com/rust-lang/rust/pull/90947.
|
|
notriddle:notriddle/rustc-suggest-float-ending-in-dot, r=sanxiyn
Avoid suggesting literal formatting that turns into member access
Fixes #90974
|
|
rustdoc: Replace where-bounded Clean impl with simple function
This is the first step in removing the Clean impls for tuples. Either way, this
significantly simplifies the code since it reduces the amount of "trait magic".
(To clarify, I'm referring to impls like `impl Clean for (A, B)`, not Clean impls
that work on tuples in the user's program.)
cc ``@jyn514``
|
|
Clean up mess for --show-coverage documentation
It was somewhat duplicated for some reasons... Anyway, this remove this duplication and clean up a bit.
r? ```@camelid```
|
|
Add `-Zassert-incr-state` to assert state of incremental cache
Closes #85864.
|
|
std: Get the standard library compiling for wasm64
This commit goes through and updates various `#[cfg]` as appropriate to
get the wasm64-unknown-unknown target behaving similarly to the
wasm32-unknown-unknown target. Most of this is just updating various
conditions for `target_arch = "wasm32"` to also account for `target_arch
= "wasm64"` where appropriate. This commit also lists `wasm64` as an
allow-listed architecture to not have the `restricted_std` feature
enabled, enabling experimentation with `-Z build-std` externally.
The main goal of this commit is to enable playing around with
`wasm64-unknown-unknown` externally via `-Z build-std` in a way that's
similar to the `wasm32-unknown-unknown` target. These targets are
effectively the same and only differ in their pointer size, but wasm64
is much newer and has much less ecosystem/library support so it'll still
take time to get wasm64 fully-fledged.
|
|
|
|
|
|
This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
|
|
Update cargo
11 commits in 2e2a16e983f597da62bc132eb191bc3276d4b1bb..ad50d0d266213e0cc4f6e526a39d96faae9a3842
2021-11-08 15:13:38 +0000 to 2021-11-17 18:36:37 +0000
- Warn when alias shadows external subcommand (rust-lang/cargo#10082)
- Implement escaping to allow clean -p to delete all files when directory contains glob characters (rust-lang/cargo#10072)
- Match any error when failing to find executables (rust-lang/cargo#10092)
- Enhance error message for target auto-discovery (rust-lang/cargo#10090)
- Include note about bug while building on macOS in mdbook (rust-lang/cargo#10073)
- Improve the help text of the --quiet args for all commands (rust-lang/cargo#10080)
- `future-incompat-report` checks both stdout and stderr for color support (rust-lang/cargo#10024)
- Remove needless borrow to make clippy happy (rust-lang/cargo#10081)
- Describe the background color of the timing graph (rust-lang/cargo#10076)
- Make ProfileChecking comments a doc comments (rust-lang/cargo#10077)
- Fix test: hash value depends on endianness and bitness. (rust-lang/cargo#10011)
|
|
Fixes #90974
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #89610 (warn on must_use use on async fn's)
- #90667 (Improve diagnostics when a static lifetime is expected)
- #90687 (Permit const panics in stable const contexts in stdlib)
- #90772 (Add Vec::retain_mut)
- #90861 (Print escaped string if char literal has multiple characters, but only one printable character)
- #90884 (Fix span for non-satisfied trivial trait bounds)
- #90900 (Remove workaround for the forward progress handling in LLVM)
- #90901 (Improve ManuallyDrop suggestion)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Improve ManuallyDrop suggestion
closes https://github.com/rust-lang/rust/issues/90585
* Fixes the recommended change to use ManuallyDrop as per the issue
* Changes the note to a help
* improves the span so it only points at the type.
|
|
Fix span for non-satisfied trivial trait bounds
The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before.
Now they only reference the obligation itself (`String: Copy`)
Address #90869
|
|
Print escaped string if char literal has multiple characters, but only one printable character
Fixes #90857
I'm not sure about the error message here, it could get rather long and *maybe* using the names of characters would be better? That wouldn't help the length any, though.
|
|
Permit const panics in stable const contexts in stdlib
Without this change, it is not possible to use `panic!` and similar (including `assert!`) in stable const contexts inside of stdlib. See #89542 for a real-world case that currently fails for this reason. This does _not_ affect any user code.
For example, this snippet currently fails to compile:
```rust
#[stable(feature = "foo", since = "1.0.0")]
#[rustc_const_stable(feature = "foo", since = "1.0.0")]
const fn foo() {
assert!(false);
assert!(false, "foo");
}
```
With the addition of `#[rustc_const_unstable]` to `core::panicking::panic`, the error no longer occurs. This snippet has been added verbatim in this PR as a UI test.
To avoid needing to add `#![feature(core_panic)]` to libcore, the two instances of direct calls to `core::panicking::panic` have been switched to use the `panic!` macro.
I am requesting prioritization because this is holding up other stabilizations such as #89542 (which is otherwise ready to merge and succeeds with this change)
|
|
Improve diagnostics when a static lifetime is expected
Makes progress towards https://github.com/rust-lang/rust/issues/90600
The diagnostics here were previously entirely removed due to giving a misleading suggestion but if we instead provide an informative label in that same location it should better help the user understand the situation.
I included the example from the issue as it demonstrates an area where the diagnostics are still lacking.
Happy to remove that if its just adding noise atm.
|
|
warn on must_use use on async fn's
As referenced in #78149
This only works on `async` fn's for now, I can also look into if I can get `Box<dyn Future>` and `impl Future` working at this level (hir)
|
|
Update llvm submodule
- [DIArgList] Re-unique after changing operands to fix non-determinism
- [AArch64][GlobalISel] Fix an crash in RBS due to a new regclass being added.
|
|
update miri
This is needed to fix https://github.com/rust-lang/miri-test-libstd
r? ````@ghost````
|
|
Alphabetize language features
This should significantly reduce the frequency of merge conflicts.
r? ````@joshtriplett````
````@rustbot```` label: +A-contributor-roadblock +S-waiting-on-review
|
|
Fix await suggestion on non-future type
Remove a match block that would suggest to add `.await` in the case where the expected type's `Future::Output` equals the found type. We only want to suggest `.await`ing in the opposite case (the found type's `Future::Output` equals the expected type).
The code sample is here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6ba6b83d4dddda263553b79dca9f6bcb
Before:
```
➜ ~ rustc --edition=2021 --crate-type=lib test.rs
error[E0308]: `match` arms have incompatible types
--> test.rs:4:14
|
2 | let x = match 1 {
| _____________-
3 | | 1 => other(),
| | ------- this is found to be of type `impl Future`
4 | | 2 => other().await,
| | ^^^^^^^^^^^^^ expected opaque type, found enum `Result`
5 | | };
| |_____- `match` arms have incompatible types
|
= note: expected type `impl Future`
found enum `Result<(), ()>`
help: consider `await`ing on the `Future`
|
4 | 2 => other().await.await,
| ++++++
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
```
After:
```
➜ ~ rustc +stage1 --edition=2021 --crate-type=lib test.rs
error[E0308]: `match` arms have incompatible types
--> test.rs:4:14
|
2 | let x = match 1 {
| _____________-
3 | | 1 => other(),
| | ------- this is found to be of type `impl Future`
4 | | 2 => other().await,
| | ^^^^^^^^^^^^^ expected opaque type, found enum `Result`
5 | | };
| |_____- `match` arms have incompatible types
|
= note: expected type `impl Future`
found enum `Result<(), ()>`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
```
Fixes #90931
|
|
:arrow_up: rust-analyzer
r? ``@ghost``
|
|
Build musl dist artifacts with debuginfo enabled
Since our musl targets link to a version of musl we build and bundle
with the targets, if users need to debug into musl or generate
backtraces which contain parts of the musl library, they will be unable
to do so unless we enable and ship the debug info.
This patch changes our dist builds so they enabled debug info when
building musl. This patch also includes a fix for CFI detection in
musl's `configure` script which has been [posted upstream](https://www.openwall.com/lists/musl/2021/10/21/2).
The net effect of this is that we now ship debug info for musl in those
targets. This adds ~90kb to those artifacts but running `strip` on
binaries produced removes all of that. For a "hello world" Rust binary
on x86_64, the numbers are:
| | debug | release | release + strip |
| - | - | - | - |
| without musl debuginfo | 507kb | 495kb | 410kb |
| with musl debuginfo | 595kb | 584kb | 410kb |
Once stripped, the final binaries are the same size (down to the byte).
Fixes #90103
r? `@Mark-Simulacrum`
|
|
|
|
|
|
|
|
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
|
|
|
|
|
|
|
|
Add a regression test for #80772
Closes #80772
|
|
Use a different server for checking clock drift
The detectportal.firefox.com server seems to return a random-ish date; for
example I see the following across 5 curl's done consecutively locally, where
the real date is approximately 15 Nov 2021 06:36 UTC.
Date: Mon, 15 Nov 2021 13:34:53 GMT
Date: Mon, 15 Nov 2021 12:20:21 GMT
Date: Mon, 15 Nov 2021 00:06:47 GMT
Date: Mon, 15 Nov 2021 17:14:33 GMT
Date: Mon, 15 Nov 2021 13:33:21 GMT
|
|
fix getting the discriminant of a zero-variant enum
Fixes https://github.com/rust-lang/rust/issues/89765
|
|
Fixes incorrect handling of TraitRefs when emitting suggestions.
Closes #90804 , although there were more issues here that were hidden by the thing that caused this ICE.
Underlying problem was that substitutions were being thrown out, which not only leads to an ICE but also incorrect diagnostics. On top of that, in some cases the self types from the root obligations were being mixed in with those from derived obligations.
This makes a couple diagnostics arguable worse ("`B<C>` does not implement `Copy`" instead of "`C` does not implement `Copy`") but the worse diagnostics are at least still correct and that downside is in my opinion clearly outweighed by the benefits of fixing the ICE and unambiguously wrong diagnostics.
|
|
Suggest `&str.chars()` on attempt to `&str.iter()`
closes #90786
|
|
r=jackh726
Normalize both arguments of `equate_normalized_input_or_output`
Fixes https://github.com/rust-lang/rust/issues/90638
Fixes https://github.com/rust-lang/rust/issues/90612
Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck.
r? ````@jackh726````
|
