Rollup merge of #99579 - CleanCut:expect-warning, r=joshtriplett
Add same warning to Result::expect as Result::unwrap
I was reading a recent blog post by Jimmy Hartzell and [he noted](https://www.thecodedmessage.com/posts/2022-07-14-programming-unwrap/#context):
> I will however note that the documentation of `unwrap` comes with [a warning not to use it](https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap). The warning is framed in terms of the fact that `unwrap` may panic, but the [documentation of `expect`](https://doc.rust-lang.org/std/result/enum.Result.html#method.expect), where this is equally true, does not come with such a warning.
It _is_ equally true. Let's add the same warning to `expect`. This PR is a copy-and-paste of the warning text from the docstring for `unwrap`.
Rollup merge of #99539 - compiler-errors:bidirectional-block-suggestions, r=fee1-dead
Improve suggestions for returning binding
Fixes #99525
Also reworks the cause codes for match and if a bit, I think cleaning them up in a positive way.
We no longer need to call `could_remove_semicolon` in successful code, which might save a few cycles?
Rollup merge of #98868 - tmiasko:unreachable-coverage, r=wesleywiser
Fix unreachable coverage generation for inlined functions
To generate a function coverage we need at least one coverage counter,
so a coverage from unreachable blocks is retained only when some live
counters remain.
The previous implementation incorrectly retained unreachable coverage,
because it didn't account for the fact that those live counters can
belong to another function due to inlining.
Rollup merge of #98174 - Kixunil:rename_ptr_as_mut_const_to_cast, r=scottmcm
Rename `<*{mut,const} T>::as_{const,mut}` to `cast_`
This renames the methods to use the `cast_` prefix instead of `as_` to
make it more readable and avoid confusion with `<*mut T>::as_mut()`
which is `unsafe` and returns a reference.
Sorry, didn't notice ACP process exists, opened https://github.com/rust-lang/libs-team/issues/51
This implements the scheme discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/338: vtable pointers should be considered entirely opaque and not even readable by Rust code, similar to function pointers.
- We have a new kind of `GlobalAlloc` that symbolically refers to a vtable.
- Miri uses that kind of allocation when generating a vtable.
- The codegen backends, upon encountering such an allocation, call `vtable_allocation` to obtain an actually dataful allocation for this vtable.
- We need new intrinsics to obtain the size and align from a vtable (for some `ptr::metadata` APIs), since direct accesses are UB now.
I had to touch quite a bit of code that I am not very familiar with, so some of this might not make much sense...
r? `@oli-obk`
Auto merge of #99501 - lcnr:check-regions-infcx, r=oli-obk
move `considering_regions` to the infcx
it seems weird to prove some obligations which constrain inference vars while ignoring regions in a context which considers regions. This is especially weird because even for a fulfillment context with ignored regions, we still added region outlives bounds when directly relating regions.
tbh our handling of regions is still very weird, but at least this is a step in the right direction imo.
Auto merge of #99567 - matthiaskrgr:rollup-08hh3r4, r=matthiaskrgr
Rollup of 11 pull requests
Successful merges:
- #98707 (std: use futex-based locks on Fuchsia)
- #99413 (Add `PhantomData` marker for dropck to `BTreeMap`)
- #99454 (Add map_continue and continue_value combinators to ControlFlow)
- #99523 (Fix the stable version of `AsFd for Arc<T>` and `Box<T>`)
- #99526 (Normalize the arg spans to be within the call span)
- #99528 (couple of clippy::perf fixes)
- #99549 (Add regression test for #52304)
- #99552 (Rewrite `orphan_check_trait_ref` to use a `TypeVisitor`)
- #99557 (Edit `rustc_index::vec::IndexVec::pick3_mut` docs)
- #99558 (Fix `remap_constness`)
- #99559 (Remove unused field in ItemKind::KeywordItem)
Rollup merge of #98707 - joboet:fuchsia_locks, r=m-ou-se
std: use futex-based locks on Fuchsia
This switches `Condvar` and `RwLock` to the futex-based implementation currently used on Linux and some BSDs. Additionally, `Mutex` now has its own, priority-inheriting implementation based on the mutex in Fuchsia's `libsync`. It differs from the original in that it panics instead of aborting when reentrant locking is detected.
Rename `<*{mut,const} T>::as_{const,mut}` to `cast_`
This renames the methods to use the `cast_` prefix instead of `as_` to
make it more readable and avoid confusion with `<*mut T>::as_mut()`
which is `unsafe` and returns a reference.
Auto merge of #98162 - nextsilicon:support_lto_embed_bitcode, r=davidtwco
Allow to disable thinLTO buffer to support lto-embed-bitcode lld feature
Hello
This change is to fix issue (https://github.com/rust-lang/rust/issues/84395) in which passing "-lto-embed-bitcode=optimized" to lld when linking rust code via linker-plugin-lto doesn't produce the expected result.
Instead of emitting a single unified module into a llvmbc section of the linked elf, it emits multiple submodules.
This is caused because rustc emits the BC modules after running llvm `createWriteThinLTOBitcodePass` pass.
Which in turn triggers a thinLTO linkage and causes the said issue.
This patch allows via compiler flag (-Cemit-thin-lto=<bool>) to select between running `createWriteThinLTOBitcodePass` and `createBitcodeWriterPass`.
Note this pattern of selecting between those 2 passes is common inside of LLVM code.
The default is to match the old behavior.
Auto merge of #93718 - thomcc:used-macho, r=pnkfelix
Only compile #[used] as llvm.compiler.used for ELF targets
This returns `#[used]` to how it worked prior to the LLVM 13 update. The intention is not that this is a stable promise.
I'll add tests later today. The tests will test things that we don't actually promise, though.
It's a deliberately small patch, mostly comments. And assuming it's reviewed and lands in time, IMO it should at least be considered for uplifting to beta (so that it can be in 1.59), as the change broke many crates in the ecosystem, even if they are relying on behavior that is not guaranteed.
# Background
LLVM has two ways of preventing removal of an unused variable: `llvm.compiler.used`, which must be present in object files, but allows the linker to remove the value, and `llvm.used` which is supposed to apply to the linker as well, if possible.
Prior to LLVM 13, `llvm.used` and `llvm.compiler.used` were the same on ELF targets, although they were different elsewhere. Prior to our update to LLVM 13, we compiled `#[used]` using `llvm.used` unconditionally, even though we only ever promised behavior like `llvm.compiler.used`.
In LLVM 13, ELF targets gained some support for preventing linker removal of `llvm.used` via the SHF_RETAIN section flag. This has some compatibility issues though: Concretely: some older versions `ld.gold` (specifically ones prior to v2.36, released in Jan 2021) had a bug where it would fail to place a `#[used] #[link_section = ".init_array"]` static in between `__init_array_start`/`__init_array_end`, leading to code that does this failing to run a static constructor. This is technically not a thing we guarantee will work, is a common use case, and is needed in `libstd` (for example, to get access to `std::env::args()` even if Rust does not control `main`, such as when in a `cdylib` crate).
As a result, when updating to LLVM 13, we unconditionally switched to using `llvm.compiler.used`, which mirror the guarantees we make for `#[used]` and doesn't require the latest ld.gold. Unfortunately, this happened to break quite a bit of things in the ecosystem, as non-ELF targets had come to rely on `#[used]` being slightly stronger. In particular, there are cases where it will even break static constructors on these targets[^initinit] (and in fact, breaks way more use cases, as Mach-O uses special sections as an interface to the OS/linker/loader in many places).
As a result, we only switch to `llvm.compiler.used` on ELF[^elfish] targets. The rationale here is:
1. It is (hopefully) identical to the semantics we used prior to the LLVM13 update as prior to that update we unconditionally used `llvm.used`, but on ELF `llvm.used` was the same as `llvm.compiler.used`.
2. It seems to be how Clang compiles this, and given that they have similar (but stronger) compatibility promises, that makes sense.
[^initinit]: For Mach-O targets: It is not always guaranteed that `__DATA,__mod_init_func` is a GC root if it does not have the `S_MOD_INIT_FUNC_POINTERS` flag which we cannot add. In most cases, when ld64 transformed this section into `__DATA_CONST,__mod_init_func` it gets applied, but it's not clear that that is intentional (let alone guaranteed), and the logic is complex enough that it probably happens sometimes, and people in the wild report it occurring.
[^elfish]: Actually, there's not a great way to tell if it's ELF, so I've approximated it.
This is pretty ad-hoc and hacky! We probably should have a firmer set of guarantees here, but this change should relax the pressure on coming up with that considerably, returning it to previous levels.
---
Unsure who should review so leaving it open, but for sure CC `@nikic`
Auto merge of #99540 - Mark-Simulacrum:bump-beta, r=jyn514
Bump to latest beta bootstrap compiler
Hopefully this will address https://github.com/rust-lang/rust/issues/99538, but I'm not sure we can confirm that without rolling it out. Should be safe in general, so likely little risk to just landing this.
The Atelier [Thu, 21 Jul 2022 00:23:46 +0000 (17:23 -0700)]
Fix doctest imports using as_crate feature
Within core, `use self::` does not work to import these items.
And because core is not core_simd, neither does the existing `use`.
So, use this quirky hack instead, switching the import on a feature.
Auto merge of #99058 - michaelwoerister:remove-stable-set-and-map, r=nagisa
Remove the unused StableSet and StableMap types from rustc_data_structures.
The current implementation is not "stable" in the same sense that `HashStable` and `StableHasher` are stable, i.e. across compilation sessions. So, in my opinion, it's better to remove those types (which are basically unused anyway) than to give the wrong impression that these are safe for incr. comp.
I plan to provide new "stable" collection types soon that can be used to replace `FxHashMap` and `FxHashSet` in query results (see [draft](https://github.com/michaelwoerister/rust/commit/69d03ac7a7d651a397ab793e9d78f8fce3edf7a6)). It's unsound that `HashMap` and `HashSet` implement `HashStable` (see https://github.com/rust-lang/rust/issues/98890 for a recent P-critical bug caused by this) -- so we should make some progress there.
Auto merge of #99520 - matthiaskrgr:rollup-05uuv5s, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #99212 (introduce `implied_by` in `#[unstable]` attribute)
- #99352 (Use `typeck_results` to avoid duplicate `ast_ty_to_ty` call)
- #99355 (better error for bad depth parameter on macro metavar expr)
- #99480 (Diagnostic width span is not added when '0$' is used as width in format strings)
- #99488 (compiletest: Allow using revisions with debuginfo tests.)
- #99489 (rustdoc UI fixes)
- #99508 (Avoid `Symbol` to `String` conversions)
- #99510 (adapt assembly/static-relocation-model test for LLVM change)
- #99516 (Use new tracking issue for proc_macro::tracked_*.)
Discovered in our experimental rust + llvm at head ci:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/12104#0182195b-8791-4f88-853c-bb23a1e4b54c
Rollup merge of #99480 - miam-miam100:arg-format, r=oli-obk
Diagnostic width span is not added when '0$' is used as width in format strings
When the following code is run rustc does not add diagnostic spans for the width argument. Such spans are necessary for a clippy lint that I am currently writing.
```rust
println!("Hello {1:0$}!", 5, "x");
// ^^
// Should have a span here
```
Rollup merge of #99212 - davidtwco:partial-stability-implies, r=michaelwoerister
introduce `implied_by` in `#[unstable]` attribute
Requested by the library team [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/better.20support.20for.20partial.20stabilizations/near/285581519).
If part of a feature is stabilized and a new feature is added for the remaining parts, then the `implied_by` meta-item can be added to `#[unstable]` to indicate which now-stable feature was used previously.
```diagnostic
error: the feature `foo` has been partially stabilized since 1.62.0 and is succeeded by the feature `foobar`
--> $DIR/stability-attribute-implies-using-unstable.rs:3:12
|
LL | #![feature(foo)]
| ^^^
|
note: the lint level is defined here
--> $DIR/stability-attribute-implies-using-stable.rs:2:9
|
LL | #![deny(stable_features)]
| ^^^^^^^^^^^^^^^
help: if you are using features which are still unstable, change to using `foobar`
|
LL | #![feature(foobar)]
| ~~~~~~
help: if you are using features which are now stable, remove this line
|
LL - #![feature(foo)]
|
```
When a `#![feature(..)]` attribute still exists for the now-stable attribute, then there this has two effects:
- There will not be an stability error for uses of items from the implied feature which are still unstable (until the `#![feature(..)]` is removed or updated to the new feature).
- There will be an improved diagnostic for the remaining use of the feature attribute for the now-stable feature.
```rust
/// If part of a feature is stabilized and a new feature is added for the remaining parts,
/// then the `implied_by` attribute is used to indicate which now-stable feature previously
/// contained a item.
///
/// ```pseudo-Rust
/// #[unstable(feature = "foo", issue = "...")]
/// fn foo() {}
/// #[unstable(feature = "foo", issue = "...")]
/// fn foobar() {}
/// ```
///
/// ...becomes...
///
/// ```pseudo-Rust
/// #[stable(feature = "foo", since = "1.XX.X")]
/// fn foo() {}
/// #[unstable(feature = "foobar", issue = "...", implied_by = "foo")]
/// fn foobar() {}
/// ```
```
In the Zulip discussion, this was envisioned as `implies` on `#[stable]` but I went with `implied_by` on `#[unstable]` because it means that only the unstable attribute needs to be changed in future, not the new stable attribute, which seems less error-prone. It also isn't particularly feasible for me to detect whether items from the implied feature are used and then only suggest updating _or_ removing the `#![feature(..)]` as appropriate, so I always do both.
There's some new information in the cross-crate metadata as a result of this change, that's a little unfortunate, but without requiring that the `#[unstable]` and `#[stable]` attributes both contain the implication information, it's necessary:
```rust
/// This mapping is necessary unless both the `#[stable]` and `#[unstable]` attributes should
/// specify their implications (both `implies` and `implied_by`). If only one of the two
/// attributes do (as in the current implementation, `implied_by` in `#[unstable]`), then this
/// mapping is necessary for diagnostics. When a "unnecessary feature attribute" error is
/// reported, only the `#[stable]` attribute information is available, so the map is necessary
/// to know that the feature implies another feature. If it were reversed, and the `#[stable]`
/// attribute had an `implies` meta item, then a map would be necessary when avoiding a "use of
/// unstable feature" error for a feature that was implied.
```
I also change some comments to documentation comments in the compiler, add a helper for going from a `Span` to a `Span` for the entire line, and fix a incorrect part of the pre-existing stability attribute diagnostics.
David Wood [Wed, 13 Jul 2022 14:10:19 +0000 (15:10 +0100)]
passes: improved partial stabilization diagnostic
Improves the diagnostic when a feature attribute is specified
unnecessarily but the feature implies another (i.e. it was partially
stabilized) to refer to the implied feature.
David Wood [Wed, 13 Jul 2022 14:02:23 +0000 (15:02 +0100)]
span: add `span_extend_to_line` helper
Adds a simple helper function to the `SourceMap` for extending a `Span`
to encompass the entire line it is on - useful for suggestions where
removing a line is the suggested action.
David Wood [Wed, 13 Jul 2022 12:10:37 +0000 (13:10 +0100)]
middle: add `implies_by` to `#[unstable]`
If part of a feature is stabilized and a new feature is added for the
remaining parts, then the `implied_by` attribute can be used to indicate
which now-stable feature previously contained a item. If the now-stable
feature is still active (if the user has only just updated rustc, for
example) then there will not be an stability error for uses of the item
from the implied feature.
Auto merge of #99506 - Dylan-DPC:rollup-q3msucx, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #98101 (stdlib support for Apple WatchOS)
- #99345 (Do not allow typeck children items to constrain outer RPITs)
- #99383 (Formalize defining_use_anchor)
- #99436 (Add flag to configure `noalias` on `Box<T>`)
- #99483 (Fix a numerical underflow in tuple wrap suggestion)
- #99485 (Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations)
- #99486 (Refactor: remove a string comparison between types in `check_str_addition`)
Discovered in our experimental rust + llvm at head ci:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/12104#0182195b-8791-4f88-853c-bb23a1e4b54c
Rollup merge of #99485 - mdholloway:unused-qualifications-in-derive, r=oli-obk
Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations
Currently, the `#[derive]` attribute always injects an `#[allow(unused_qualifications)]` attribute in the generated implementation. This results in an error when a derive is used in combination with `#![forbid(unused_qualifications)]`, because the `forbid` rule by definition cannot be overridden by `allow`.
It appears that the original issue that prompted the inclusion of `#[allow(unused_qualifications)]` (#19102) is no longer present in the current stable release, and the associated [test case](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-19102.rs) still passes, so the `allow` is simply removed here.
projects / rust.git / log