Encode types in SMIR
The first commit makes sure we can actually store a Ty<'tcx> (with the lifetime) in the thread local and get it back out. The second commit then introduces types.
r? `@spastorino`
Make alias bounds sound in the new solver (take 2)
Make alias bounds sound in the new solver (in a way that does not require coinduction) by only considering them for projection types whose corresponding trait refs come from a param-env candidate.
That is, given `<T as Trait>::Assoc: Bound`, we only *really* need to consider the alias bound if `T: Trait` is satisfied via a param-env candidate. If it's instead satisfied, e.g., via an user provided impl candidate or a , then that impl should have a concrete type to which we could otherwise normalize `<T as Trait>::Assoc`, and that concrete type is then responsible to prove the `Bound` on it.
Similar consideration is given to opaque types, since we only need to consider alias bounds if we're *not* in reveal-all mode, since similarly we'd be able to reveal the opaque types and prove any bounds that way.
This does not remove that hacky "eager projection replacement" logic from object bounds, which are somewhat like alias bounds. But removing this eager normalization behavior (added in #108333) would require full coinduction to be enabled. Compare to #110628, which does remove this object-bound custom logic but requires coinduction to be sound.
r? `@lcnr`
Support linking to rust dylib with --crate-type staticlib
This allows for example dynamically linking libstd, while statically linking the user crate into an executable or C dynamic library. For this two unstable flags (`-Z staticlib-allow-rdylib-deps` and `-Z staticlib-prefer-dynamic`) are introduced. Without the former you get an error. The latter is the equivalent to `-C prefer-dynamic` for the staticlib crate type to indicate that dynamically linking is preferred when both options are available, like for libstd. Care must be taken to ensure that no crate ends up being merged into two distinct staticlibs that are linked together. Doing so will cause a linker error at best and undefined behavior at worst. In addition two distinct staticlibs compiled by different rustc may not be combined under any circumstances due to some rustc private symbols not being mangled.
To successfully link a staticlib, `--print native-static-libs` can be used while compiling to ask rustc for the linker flags necessary when linking the staticlib. This is an existing flag which previously only listed native libraries. It has been extended to list rust dylibs too. Trying to locate libstd yourself to link against it is not supported and may break if for example the libstd of multiple rustc versions are put in the same directory.
For an example on how to use this see the `src/test/run-make-fulldeps/staticlib-dylib-linkage/` test.
Implement SSA-based reference propagation
Rust has a tendency to create a lot of short-lived borrows, in particular for method calls. This PR aims to remove those short-lived borrows with a const-propagation dedicated to pointers to local places.
This pass aims to transform the following pattern:
```
_1 = &raw? mut? PLACE;
_3 = *_1;
_4 = &raw? mut? *_1;
```
Into
```
_1 = &raw? mut? PLACE;
_3 = PLACE;
_4 = &raw? mut? PLACE;
```
where `PLACE` is a direct or an indirect place expression.
By removing indirection, this pass should help both dest-prop and const-prop to handle more cases.
This optimization is distinct from const-prop and dataflow const-prop since the borrow-reborrow patterns needs to preserve borrowck invariants, especially the uniqueness property of mutable references.
The pointed-to places are computed using a SSA analysis. We suppose that removable borrows are typically temporaries from autoref, so they are by construction assigned only once, and a SSA analysis is enough to catch them. For each local, we store both where and how it is used, in order to efficiently compute the all-or-nothing property. Thanks to `Derefer`, we only have to track locals, not places in general.
---
There are 3 properties that need to be upheld for this transformation to be legal:
- place constness: `PLACE` must refer to the same memory wherever it appears;
- pointer liveness: we must not introduce dereferences of dangling pointers;
- `&mut` borrow uniqueness.
## Constness
If `PLACE` is an indirect projection, if its of the form `(*LOCAL).PROJECTIONS` where:
- `LOCAL` is SSA;
- all projections in `PROJECTIONS` are constant (no dereference and no indexing).
If `PLACE` is a direct projection of a local, we consider it as constant if:
- the local is always live, or it has a single `StorageLive` that dominates all uses;
- all projections are constant.
# Liveness
When performing a substitution, we must take care not to introduce uses of dangling locals.
Using a dangling borrow is UB. Therefore, we assume that for any use of `*x`, where `x` is a borrow, the pointed-to memory is live.
Limitations:
- occurrences of `*x` in an `&raw mut? *x` are accepted;
- raw pointers are allowed to be dangling.
In those 2 case, we do not substitute anything, to be on the safe side.
**Open question:** we do not differentiate borrows of ZST and non-ZST. The UB rules may be
different depending on the layout. Having a different treatment would effectively prevent this
pass from running on polymorphic MIR, which defeats the purpose of MIR opts.
## Uniqueness
For `&mut` borrows, we also need to preserve the uniqueness property:
we must avoid creating a state where we interleave uses of `*_1` and `_2`.
To do it, we only perform full substitution of mutable borrows:
we replace either all or none of the occurrences of `*_1`.
Some care has to be taken when `_1` is copied in other locals.
```
_1 = &raw? mut? _2;
_3 = *_1;
_4 = _1
_5 = *_4
```
In such cases, fully substituting `_1` means fully substituting all of the copies.
For immutable borrows, we do not need to preserve such uniqueness property,
so we perform all the possible substitutions without removing the `_1 = &_2` statement.
Remove some `assume`s from slice iterators that don't do anything
Because the start pointer is iterators is already a `NonNull`, we emit the appropriate `!nonnull` metadata when loading the pointer to tell LLVM that it's non-null.
Probably the best way to see that it's the metadata that's important (and not the `assume`) is to observe that LLVM actually *removes* the `assume` from the optimized IR: <https://rust.godbolt.org/z/KhE6G963n>.
(I also checked that, yes, the if-not-ZST `assume` on `end` is still doing something: it's how there's a `!nonnull` metadata on its load, even though it's an ordinary raw pointer. The codegen test added in this PR fails if the other `assume` is removed.)
Various changes to name resolution of anon consts
Sorry this PR is kind of all over the place ^^'
Fixes#111012
- Rewrites anon const nameres to all go through `fn resolve_anon_const` explicitly instead of `visit_anon_const` to ensure that we do not accidentally resolve anon consts as if they are allowed to use generics when they aren't. Also means that we dont have bits of code for resolving anon consts that will get out of sync (i.e. legacy const generics and resolving path consts that were parsed as type arguments)
- Renames two of the `LifetimeRibKind`, `AnonConst -> ConcreteAnonConst` and `ConstGeneric -> ConstParamTy`
- Noticed while doing this that under `generic_const_exprs` all lifetimes currently get resolved to errors without any error being emitted which was causing a bunch of tests to pass without their bugs having been fixed, incidentally fixed that in this PR and marked those tests as `// known-bug:`. I'm fine to break those since `generic_const_exprs` is a very unstable incomplete feature and this PR _does_ make generic_const_exprs "less broken" as a whole, also I can't be assed to figure out what the underlying causes of all of them are. This PR reopens#77357#83993
- Changed `generics_of` to stop providing generics and predicates to enum variant discriminant anon consts since those are not allowed to use generic parameters
- Updated the error for non 'static lifetime in const arguments and the error for non 'static lifetime in const param tys to use `derive(Diagnostic)`
I have a vague idea why const-arg-in-const-arg.rs, in-closure.rs and simple.rs have started failing which is unfortunate since these were deliberately made to work, I think lifetime resolution being broken just means this regressed at some point and nobody noticed because the tests were not testing anything :( I'm fine breaking these too for the same reason as the tests for #77357#83993. I couldn't get `// known-bug` to work for these ICEs and just kept getting different stderr between CI and local `--bless` so I just removed them and will create an issue to track re-adding (and fixing) the bugs if this PR lands.
r? `@cjgillot` cc `@compiler-errors`
Revert "Populate effective visibilities in `rustc_privacy`"
This reverts commit cff85f22f5, cc #110907. It needs to be fixed, but there are too many issues being reported that I wanted to put up a revert until a proper fix can be committed.
Fixes a ton of issues where private but still reachable impls were missing during codegen:
Fixes#111320Fixes#111321Fixes#111334Fixes#111357Fixes#111368Fixes#111373Fixes#111377Fixes#111386Fixes#111387
`@bors` p=1
r? `@petrochenkov`
Min specialization improvements
- Don't allow specialization impls with no items, such implementations are probably not correct and only occur as mistakes in the compiler and standard library
- Fix a missing normalization call
- Adds spans for lifetime errors from overly general specializations
Closes#79457Closes#109815
Implement builtin # syntax and use it for offset_of!(...)
Add `builtin #` syntax to the parser, as well as a generic infrastructure to support both item and expression position builtin syntaxes. The PR also uses this infrastructure for the implementation of the `offset_of!` macro, added by #106934.
cc `@petrochenkov` `@DrMeepster`
cc #110680 `builtin #` tracking issue
cc #106655 `offset_of!` tracking issue
tweak "make mut" spans when assigning to locals
Work towards fixing #106857
This PR just cleans up a lot of spans which is helpful before properly fixing the issues. Best reviewed commit-by-commit.
r? `@estebank`
Tweak borrow suggestion span
Avoids a `span_to_snippet` call when we don't need to surround the expression in parentheses. The fact that the suggestion was using the whole span of the expression rather than just appending a `&` was prevented me from using `// run-rustfix` in another PR (https://github.com/rust-lang/rust/pull/110432#discussion_r1170500484).
Also some drive-by renames of functions that have been annoying me for a bit.
Add GNU Property Note
Fix#103001
Generates the missing property note:
```
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: IBT
```
Rollup of 6 pull requests
Successful merges:
- #104070 (Prevent aborting guard from aborting the process in a forced unwind)
- #109410 (Introduce `AliasKind::Inherent` for inherent associated types)
- #111004 (Migrate `mir_transform` to translatable diagnostics)
- #111118 (Suggest struct when we get colon in fileds in enum)
- #111170 (Diagnostic args are still args if they're documented)
- #111354 (Fix miscompilation when calling default methods on `Future`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Disable nrvo mir opt
See #111005 and #110902 . The ICE can definitely be hit on stable, the miscompilation I'm not sure about. The pass makes some pretty sketchy assumptions though, and we should not have it on while that's the case.
I'm not going to work on actually fixing this, it's probably not excessively difficult though.
r? rust-lang/mir-opt
Introduce `AliasKind::Inherent` for inherent associated types
Allows us to check (possibly generic) inherent associated types for well-formedness.
Type inference now also works properly.
Follow-up to #105961. Supersedes #108430.
Fixes#106722.
Fixes#108957.
Fixes#109768.
Fixes#109789.
Fixes#109790.
~Not to be merged before #108860 (`AliasKind::Weak`).~
CC `@jackh726`
r? `@compiler-errors`
`@rustbot` label T-types F-inherent_associated_types
ConstProp into PlaceElem::Index.
Noticed this while looking at keccak output MIR.
This pass aims to replace `ProjectionElem::Index` with `ProjectionElem::ConstantIndex` during ConstProp.
r? `@ghost`
Don't compute trait super bounds unless they're positive
Fixes#111207
The comment is modified to explain the rationale for why we even have this recursive call to supertraits in the first place, which doesn't apply to negative bounds since they don't elaborate at all.
Further normalize msvc-non-utf8-ouput
Fixes#111256 by normalizing this tests down to the essential part so that it only tests for the Unicode output we expect. Also uses a file name that should never occur outside of this test.
Fix some suggestions where a `Box<T>` is expected.
This fixes#111011, and also adds a suggestion for boxing a unit type when a `Box<T>` was expected and an empty block was found.
Fix lifetime suggestion for type aliases with objects in them
Fixes an issue identified in https://github.com/rust-lang/rust/issues/110761#issuecomment-1520678479
This suggestion, like many other borrowck suggestions, are very fragile and there are other ways to trigger strange behavior even after this PR, so this is just a small improvement and not a total rework 💀
Rename InstCombine to InstSimplify
```
╭ ➜ ben@archlinux:~/rust
╰ ➤ rg -i instcombine
src/doc/rustc-dev-guide/src/mir/optimizations.md
134:may have been misapplied. Examples of this are `InstCombine` and `ConstantPropagation`.
src/ci/docker/host-x86_64/disabled/dist-x86_64-haiku/llvm-config.sh
38: instcombine instrumentation interpreter ipo irreader lanai \
tests/codegen/slice_as_from_ptr_range.rs
4:// min-llvm-version: 15.0 (because this is a relatively new instcombine)
```
r? `@scottmcm`
Constify `[u8]::is_ascii` (unstably)
UTF-8 checking in `const fn`-stabilized back in 1.63 (#97367), but apparently somehow ASCII checking was never const-ified, despite being simpler.
New constness-tracking issue for `is_ascii`: #111090
I noticed this working on `ascii::Char`: #110998
Support return-type bounds on associated methods from supertraits
Support `T: Trait<method(): Bound>` when `method` comes from a supertrait, aligning it with the behavior of associated type bounds (both equality and trait bounds).
The only wrinkle is that I have to extend `super_predicates_that_define_assoc_type` to look for *all* items, not just `AssocKind::Ty`. This will also be needed to support `feature(associated_const_equality)` as well, which is subtly broken when it comes to supertraits, though this PR does not fix those yet. There's a slight chance there's a perf regression here, in which case I guess I could split it out into a separate query.
added TraitAlias to check_item() for missing_docs
As in issue #111025 the `missing_docs` was not being triggered for trait aliases. I added `TraitAlias` to the pattern match for check_item(), and the lint seems to be behaving appropriately
Operand::extract_field: only cast llval if it's a pointer and replace bitcast w/ pointercast.
Fixes#105439.
Also cc `@erikdesjardins,` looks like another place to cleanup as part of #105545
Output LLVM optimization remark kind in `-Cremark` output
Since https://github.com/rust-lang/rust/pull/90833, the optimization remark kind has not been printed. Therefore it wasn't possible to easily determine from the log (in a programmatic way) which remark kind was produced. I think that the most interesting remarks are the missed ones, which can lead users to some code optimization.
Maybe we could also change the format closer to the "old" one:
```
note: optimization remark for tailcallelim at /checkout/src/libcore/num/mod.rs:1:0: marked this call a tail call candidate
```
I wanted to programatically parse the remarks so that they could work e.g. with https://github.com/OfekShilon/optview2. However, now that I think about it, probably the proper solution is to tell rustc to output them to YAML and then use the YAML as input for the opt remark visualization tools. The flag for enabling this does not seem to work though (https://github.com/rust-lang/rust/issues/96705#issuecomment-1117632322).
Still I think that it's good to output the remark kind anyway, it's an important piece of information.
r? ```@tmiasko```
add hint for =< as <=
Adds a compiler hint for when `=<` is typed instead of `<=`
Example hint:
```rust
fn foo() {
if 1 =< 3 {
println!("Hello, World!");
}
}
```
```
error: expected type, found `3`
--> main.rs:2:13
|
2 | if 1 =< 3 {
| -- ^ expected type
| |
| help: did you mean: `<=`
```
This PR only emits the suggestion if there is no space between the `=` and `<`. This hopefully narrows the scope of when this error is emitted, however this still allows this error to be emitted in cases such as this:
```
error: expected expression, found `;`
--> main.rs:2:18
|
2 | if 1 =< [i32;; 3]>::hello() {
| -- ^ expected expression
| |
| help: did you mean: `<=`
```
Which could be a good reason not to merge since I haven't been able to think of any other ways of narrowing the scope of this diagnostic.
closes#111128
debuginfo: split method declaration and definition
When we're adding a method to a type DIE, we only want a DW_AT_declaration
there, because LLVM LTO can't unify type definitions when a child DIE is a
full subprogram definition. Now the subprogram definition gets added at the
CU level with a specification link back to the abstract declaration.
Both GCC and Clang write debuginfo this way for C++ class methods.
Fixes#109730.
Fixes#109934.
Make the BUG_REPORT_URL configurable by tools
This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.
I haven't changed clippy in case they want to make the change upstream instead of the subtree, but
I'm happy to do so here if the maintainers want - cc ````@rust-lang/clippy````
Fixes https://github.com/rust-lang/rust/issues/109486.
Use fulfillment to check `Drop` impl compatibility
Use an `ObligationCtxt` to ensure that a `Drop` impl does not have stricter requirements than the ADT that it's implemented for, rather than using a `SimpleEqRelation` to (more or less) syntactically equate predicates on an ADT with predicates on an impl.
r? types
### Some background
The old code reads:
```rust
// An earlier version of this code attempted to do this checking
// via the traits::fulfill machinery. However, it ran into trouble
// since the fulfill machinery merely turns outlives-predicates
// 'a:'b and T:'b into region inference constraints. It is simpler
// just to look for all the predicates directly.
```
I'm not sure what this means, but perhaps in the 8 years since that this comment was written (cc #23638) it's gotten easier to process region constraints after doing fulfillment? I don't know how this logic differs from anything we do in the `compare_impl_item` module. Ironically, later on it says:
```rust
// However, it may be more efficient in the future to batch
// the analysis together via the fulfill (see comment above regarding
// the usage of the fulfill machinery), rather than the
// repeated `.iter().any(..)` calls.
```
Also:
* Removes `SimpleEqRelation` which was far too syntactical in its relation.
* Fixes#110557
Add `force` option for `--extern` flag
When `--extern force:foo=libfoo.so` is passed to `rustc` and `foo` is not actually used in the crate, ~inject an `extern crate foo;` statement into the AST~ force it to be resolved anyway in `CrateLoader::postprocess()`. This allows you to, for instance, inject a `#[panic_handler]` implementation into a `#![no_std]` crate without modifying its source so that it can be built as a `dylib`. It may also be useful for `#![panic_runtime]` or `#[global_allocator]`/`#![default_lib_allocator]` implementations.
My work previously involved integrating Rust into an existing C/C++ codebase which was built with Buck and shipped on, among other platforms, Android. When targeting Android, Buck builds all "native" code with shared linkage* so it can be loaded from Java/Kotlin. My project was not itself `#![no_std]`, but many of our dependencies were, and they would fail to build with shared linkage due to a lack of a panic handler. With this change, that project can add the new `force` option to the `std` dependency it already explicitly provides to every crate to solve this problem.
*This is an oversimplification - Buck has a couple features for aggregating dependencies into larger shared libraries, but none that I think sustainably solve this problem.
~The AST injection happens after macro expansion around where we similarly inject a test harness and proc-macro harness. The resolver's list of actually-used extern flags is populated during macro expansion, and if any of our `--extern` arguments have the `force` option and weren't already used, we inject an `extern crate` statement for them. The injection logic was added in `rustc_builtin_macros` as that's where similar injections for tests, proc-macros, and std/core already live.~
(New contributor - grateful for feedback and guidance!)
rustdoc-search: add slices and arrays to index
This indexes them as primitives with generics, so `slice<u32>` is how you search for `[u32]`, and `array<u32>` for `[u32; 1]`. A future commit will desugar the square bracket syntax to search both arrays and slices at once.
Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool
This stabilizes the `raw-dylib` feature (#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures).
Changes:
* Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute.
* Mark the `raw_dylib` feature as stable.
* Stabilized the `-Zdlltool` argument as `-Cdlltool`.
* Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message).
* Adds tests for `-Cdlltool`.
* Adds tests for being unable to find the dlltool executable, and dlltool failing.
* Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`.
NOTE: As previously noted (https://github.com/rust-lang/rust/pull/104218#issuecomment-1315895618) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: https://github.com/rust-lang/rust/pull/104218#issuecomment-1318720482
Big thanks to ``````@tbu-`````` for the first version of this PR (#104218)
Such implementations are usually mistakes and are not used in the
compiler or standard library (after this commit) so forbid them with
`min_specialization`.
Improve check-cfg implementation
This PR makes multiple improvements into the implementation of check-cfg, it is a prerequisite to a follow-up PR that will introduce a simpler and more explicit syntax.
The 2 main area of improvements are:
1. Internal representation of expected values:
- now uses `FxHashSet<Option<Symbol>>` instead of `FxHashSet<Symbol>`, it made the no value expected case only possible when no values where in the `HashSet` which is now represented as `None` (same as cfg represent-it).
- a enum with `Some` and `Any` makes it now clear if some values are expected or not, necessary for `feature` and `target_feature`.
2. Diagnostics: Improve the diagnostics in multiple case and fix case where a missing value could have had a new name suggestion instead of the value diagnostic; and some drive by improvements
I highly recommend reviewing commit by commit.
r? `@petrochenkov`
Reduce MIR dump file count for MIR-opt tests
As referenced in issue #109502 , mir-opt tests previously used the -Zdump-mir=all flag, which generates very large output. This PR only dumps the passes under test, greatly reducing dump output.
Fix problems with backtraces in two ui tests.
`default-backtrace-ice.rs` started started failing for me recently,
because on my Ubuntu 23.04 system there are 100 stack frames, and the
current stack filtering pattern doesn't match on a stack frame with a
three digit number.
`issue-86800.rs` can also be improved, backtrace-wise.
r? `@Nilstrieb`
This test is supposed to ensure that full backtraces are used for ICEs.
But it doesn't actually do that -- the filtering done cannot distinguish
between a full backtrace versus a short backtrace.
So this commit changes the filtering to preserve the existence of
`__rust_{begin,end}_short_backtrace` markers, which only appear in full
backtraces. This change means the test now tests what it is supposed to
test.
Also, the existing filtering included a rule that excluded any line
starting with two spaces. This was too strong because it filtered out
some parts of the error message. (This was not a showstopper). It was
also not strong enough because it didn't work with three digit stack
frame numbers, which just started seeing after upgrading my Ubuntu
distro to 23.04 machine (this *was* a showstopper).
So the commit replaces that rule with two more precise rules, one for
lines with stack frame numbers, and one for "at ..." lines.
Because it then just has to be filtered out.
This change makes this test more like these other tests:
- tests/ui/treat-err-as-bug/err.rs
- tests/ui/treat-err-as-bug/delay_span_bug.rs
- tests/ui/mir/validate/storage-live.rs
- tests/ui/associated-inherent-types/bugs/ice-substitution.rs
- tests/ui/layout/valid_range_oob.rs
check array type of repeat exprs is wf
Fixes#111091
Also makes sure that we actually renumber regions in the length of repeat exprs which we previously weren't doing and would cause ICEs in `adt_const_params` + `generic_const_exprs` from attempting to prove the wf goals when the length was an unevaluated constant with `'erased` in the `ty` field of `Const`
The duplicate errors are caused by the fact that `const_arg_to_const`/`array_len_to_const` in `FnCtxt` adds a `WellFormed` goal for the created `Const` which is also checked by the added `WellFormed(array_ty)`. I don't want to change this to just emit a `T: Sized` goal for the element type since that would ignore `ConstArgHasType` wf requirements and generally uncomfortable with the idea of trying to sync up `wf::obligations` for arrays and the code in hir typeck for repeat exprs.
r? `@compiler-errors`
correctly recurse when expanding anon consts
recursing with `super_fold_with` is wrong in case `bac` is itself normalizable, the test that was supposed to test for this being wrong did not actually test for this in reality because of the usage of `{ (N) }` instead of `{{ N }}`. The former resulting in a simple `ConstKind::Param` instead of `ConstKind::Unevaluated`. Tbh generally this test seems very brittle and it will be a lot easier to test once we have normalization of assoc consts since then we can just test that `T::ASSOC` normalizes to some `U::OTHER` which normalizes to some third thing.
r? `@compiler-errors`
Encode def span for foreign return-position `impl Trait` in trait
Fixes#111031, yet another def-span encoding issue :/
Includes a smaller repro than the issue, but I can confirm it ICEs:
```
query stack during panic:
#0 [def_span] looking up span for `rpitit::Foo::bar::{opaque#0}`
#1 [object_safety_violations] determining object safety of trait `rpitit::Foo`
#2 [check_is_object_safe] checking if trait `rpitit::Foo` is object safe
#3 [typeck] type-checking `main`
#4 [used_trait_imports] finding used_trait_imports `main`
#5 [analysis] running analysis passes on this crate
```
Luckily since this only affects nightly, this desn't need to be backported.
Explicitly reject negative and reservation drop impls
Fixes#110858
It doesn't really make sense for a type to have a `!Drop` impl. Or at least, I don't want us to implicitly assign a meaning to it by the way the compiler *currently* handles it (incompletely), and rather I would like to see a PR (or an RFC...) assign a meaning to `!Drop` if we actually wanted one for it.
Add cross-language LLVM CFI support to the Rust compiler
This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395).
It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653.
Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).
Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
Implement tuple<->array convertions via `From`
This PR adds the following impls that convert between homogeneous tuples and arrays of the corresponding lengths:
```rust
impl<T> From<[T; 1]> for (T,) { ... }
impl<T> From<[T; 2]> for (T, T) { ... }
/* ... */
impl<T> From<[T; 12]> for (T, T, T, T, T, T, T, T, T, T, T, T) { ... }
impl<T> From<(T,)> for [T; 1] { ... }
impl<T> From<(T, T)> for [T; 2] { ... }
/* ... */
impl<T> From<(T, T, T, T, T, T, T, T, T, T, T, T)> for [T; 12] { ... }
```
IMO these are quite uncontroversial but note that they are, just like any other trait impls, insta-stable.
When we're adding a method to a type DIE, we only want a DW_AT_declaration
there, because LLVM LTO can't unify type definitions when a child DIE is a
full subprogram definition. Now the subprogram definition gets added at the
CU level with a specification link back to the abstract declaration.
This commit adds cross-language LLVM Control Flow Integrity (CFI)
support to the Rust compiler by adding the
`-Zsanitizer-cfi-normalize-integers` option to be used with Clang
`-fsanitize-cfi-icall-normalize-integers` for normalizing integer types
(see https://reviews.llvm.org/D139395).
It provides forward-edge control flow protection for C or C++ and Rust
-compiled code "mixed binaries" (i.e., for when C or C++ and Rust
-compiled code share the same virtual address space). For more
information about LLVM CFI and cross-language LLVM CFI support for the
Rust compiler, see design document in the tracking issue #89653.
Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and
-Zsanitizer-cfi-normalize-integers, and requires proper (i.e.,
non-rustc) LTO (i.e., -Clinker-plugin-lto).
Don't bail out early when checking invalid `repr` attr
Fixes#111051
An invalid repr delays a bug. If there are other invalid attributes on the item, we emit a warning and exit without re-checking the repr here, so no error is emitted and the delayed bug ICEs
Implement negative bounds for internal testing purposes
Implements partial support the `!` negative polarity on trait bounds. This is incomplete, but should allow us to at least be able to play with the feature.
Not even gonna consider them as a public-facing feature, but I'm implementing them because would've been nice to have in UI tests, for example in #110671.
Currently a `{D,Subd}iagnosticMessage` can be created from any type that
impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static,
str>`, which are reasonable. It also includes `&String`, which is pretty
weird, and results in many places making unnecessary allocations for
patterns like this:
```
self.fatal(&format!(...))
```
This creates a string with `format!`, takes a reference, passes the
reference to `fatal`, which does an `into()`, which clones the
reference, doing a second allocation. Two allocations for a single
string, bleh.
This commit changes the `From` impls so that you can only create a
`{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static,
str>`. This requires changing all the places that currently create one
from a `&String`. Most of these are of the `&format!(...)` form
described above; each one removes an unnecessary static `&`, plus an
allocation when executed. There are also a few places where the existing
use of `&String` was more reasonable; these now just use `clone()` at
the call site.
As well as making the code nicer and more efficient, this is a step
towards possibly using `Cow<'static, str>` in
`{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing
the `From<&'a str>` impls to `From<&'static str>`, which is doable, but
I'm not yet sure if it's worthwhile.
Mark`feature(return_position_impl_trait_in_trait)` and`feature(async_fn_in_trait)` as not incomplete
I think they've graduated, since as far as I'm aware, they don't cause compiler crashes or unsoundness anymore.
Fix elaboration with associated type bounds
When computing a trait's supertrait predicates, do not add any associated type *trait* bounds to that list of supertrait predicates. This is because supertrait predicates are expected to have the same `Self` type as the trait.
For example, given:
```rust
trait Foo: Bar<Assoc: Send>
```
Before, we would compute that the supertrait predicates of `T: Foo` are `T: Bar` and `<T as Bar>::Assoc: Send`. However, the last bound is a trait predicate for a totally different type than `T`, and existing code that uses supertrait bounds such as vtable construction, closure fn signature deduction, etc. all rely on the invariant that we have a list of predicates for self type `T`.
Fixes#76593
The reason for all the extra diagnostic noise is that we're recomputing predicates with a different filter now. These diagnostics should be deduplicated for any end-user though.
---
This does bring up an interesting question -- is the predicate `<T as Bar>::Assoc: Send` an implied bound of `T: Foo`? Because currently the only bounds implied by a (non-alias) trait are its supertraits. I guess I could fix this too, but it would require even more changes, and I'm inclined to punt this question along.
Stabilize debugger_visualizer
This stabilizes the `debugger_visualizer` attribute (#95939).
* Marks the `debugger_visualizer` feature as `accepted`.
* Marks the `debugger_visualizer` attribute as `ungated`.
* Deletes feature gate test, removes feature gate from other tests.
Closes#95939
Add `ConstParamTy` trait
This is a bit sketch, but idk.
r? `@BoxyUwU`
Yet to be done:
- [x] ~~Figure out if it's okay to implement `StructuralEq` for primitives / possibly remove their special casing~~ (it should be okay, but maybe not in this PR...)
- [ ] Maybe refactor the code a little bit
- [x] Use a macro to make impls a bit nicer
Future work:
- [ ] Actually™ use the trait when checking if a `const` generic type is allowed
- [ ] _Really_ refactor the surrounding code
- [ ] Refactor `marker.rs` into multiple modules for each "theme" of markers
Don't validate constants in const propagation
Validation is neither necessary nor desirable.
The constant validation is already omitted at mir-opt-level >= 3, so there there are not changes in MIR test output (the propagation of invalid constants is covered by an existing test in tests/mir-opt/const_prop/invalid_constant.rs).
This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.
- Switch clippy to the new hook
This also adds a `extra_info` callback so clippy can include its own version number, which differs
from rustc's.
- Call `install_ice_hook` in rustfmt
Round-trip encoding/decoding of many types is tested in
`compiler/rustc_serialize/tests/opaque.rs`. There is also a small amount
of encoding/decoding testing in three files in `tests/ui-fulldeps`.
There is no obvious reason why these three files are necessary. They
were originally added in 2014. Maybe it wasn't possible for a proc
macro to run in a unit test back then?
This commit just moves the testing from those three files into the unit
test.
Add `#[no_coverage]` to the test harness's `fn main`
There are two main motivations for adding `#[no_coverage]` to the test harness's entry point:
- The entry point is trivial compiler-generated code that doesn't correspond to user source, and it always runs, so there's no value in instrumenting it for coverage.
- Because it has dummy spans, it causes the instrumentor implementation to emit invalid coverage mappings that confuse `llvm-cov` and result in strange coverage reports.
Fixes#110749.
Leave promoteds untainted by errors when borrowck fails
Previously, when borrowck failed it would taint all promoteds within the MIR body. An attempt to evaluated the promoteds would subsequently fail with spurious "note: erroneous constant used". For example:
```console
...
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:9
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:14
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:19
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:24
|
7 | a = &0 * &1 * &2 * &3;
| ^^
```
Borrowck failure doesn't indicate that there is anything wrong with promoteds. Leave them untainted.
Fixes#110856.
Make `mem::replace` simpler in codegen
Since they'd mentioned more intrinsics for simplifying stuff recently,
r? `@WaffleLapkin`
This is a continuation of me looking at foundational stuff that ends up with more instructions than it really needs. Specifically I noticed this one because `Range::next` isn't MIR-inlining, and one of the largest parts of it is a `replace::<usize>` that's a good dozen instructions instead of the two it could be.
So this means that `ptr::write` with a `Copy` type no longer generates worse IR than manually dereferencing (well, at least in LLVM -- MIR still has bonus pointer casts), and in doing so means that we're finally down to just the two essential `memcpy`s when emitting `mem::replace` for a large type, rather than the bonus-`alloca` and three `memcpy`s we emitted before this ([or the 6 we currently emit in 1.69 stable](https://rust.godbolt.org/z/67W8on6nP)). That said, LLVM does _usually_ manage to optimize the extra code away. But it's still nice for it not to have to do as much, thanks to (for example) not going through an `alloca` when `replace`ing a primitive like a `usize`.
(This is a new intrinsic, but one that's immediately lowered to existing MIR constructs, so not anything that MIRI or the codegen backends or MIR semantics needs to do work to handle.)
My type ascription
Oh rip it out
Ah
If you think we live too much then
You can sacrifice diagnostics
Don't mix your garbage
Into my syntax
So many weird hacks keep diagnostics alive
Yet I don't even step outside
So many bad diagnostics keep tyasc alive
Yet tyasc doesn't even bother to survive!
Close parentheses for `offset_of` in AST pretty printing
HIR pretty printing already handles it correctly.
This will conflict with #110694 but it seems like that PR is gonna take bit more time.
Test precise capture with a multi-variant enum and exhaustive patterns
Add test checking that it is possible to capture fields of a multi-variant enum, when remaining variants are visibly uninhabited (under the `exhaustive_patterns` feature gate).
Remove wrong assertion in match checking.
This assertions is completely misguided, introduced by https://github.com/rust-lang/rust/pull/108504. The responsible PR is on beta, nominating for backport.
Instead of checking that this is not a `&&`, it would make sense to check that neither arms of that `&&` is a `let`. This seems like a lot of code for unclear benefit.
r? `@saethlin`
Tweak await span to not contain dot
Fixes a discrepancy between method calls and await expressions where the latter are desugared to have a span that *contains* the dot (i.e. `.await`) but method call identifiers don't contain the dot. This leads to weird suggestions suggestions in borrowck -- see linked issue.
Fixes#110761
This mostly touches a bunch of tests to tighten their `await` span.
Previously, when borrowck failed it would taint all promoteds within the MIR
body. An attempt to evaluated the promoteds would subsequently fail with
spurious "note: erroneous constant used". For example:
```console
...
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:9
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:14
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:19
|
7 | a = &0 * &1 * &2 * &3;
| ^^
note: erroneous constant used
--> tests/ui/borrowck/tainted-promoteds.rs:7:24
|
7 | a = &0 * &1 * &2 * &3;
| ^^
```
Borrowck failure doesn't indicate that there is anything wrong with
promoteds. Leave them untainted.
Add test checking that it is possible to capture fields of a
multi-variant enum, when remaining variants are visibly uninhabited
(under the `exhaustive_patterns` feature gate).
rustdoc: catch and don't blow up on impl Trait cycles
Fixes#110629
An odd feature of Rust is that `Foo` is invalid, but `Bar` is okay:
type Foo<'a, 'b> = Box<dyn PartialEq<Foo<'a, 'b>>>;
type Bar<'a, 'b> = impl PartialEq<Bar<'a, 'b>>;
To get it right, track every time rustdoc descends into a type alias, so if it shows up twice, it can be write the path instead of infinitely expanding it.
Don't accidentally ignore all output in `tests/run-make/coverage-reports` diffs
Because the literal pipe `|` character was not escaped, these regexes ended up accidentally ignoring every line in the coverage report output, so the tests would not fail even if the output was wrong.
An odd feature of Rust is that `Foo` is invalid, but `Bar` is okay:
type Foo<'a, 'b> = Box<dyn PartialEq<Foo<'a, 'b>>>;
type Bar<'a, 'b> = impl PartialEq<Bar<'a, 'b>>;
To get it right, track every time rustdoc descends into a type alias,
so if it shows up twice, it can be write the path instead of
infinitely expanding it.
rustdoc: Get `repr` information through `AdtDef` for foreign items
As suggested by `@notriddle,` this approach works too. The only downside is that the display of the original attribute isn't kept, but I think it's an acceptable downside.
r? `@notriddle`
Move most rustdoc-ui tests into subdirectories
This makes it easier to know where to add a new test, and makes the top-level directory less overwhelming.
Add test for warning-free builds of `core` under `no_global_oom_handling`
`tests/run-make/alloc-no-oom-handling` tests that `alloc` under `no_global_oom_handling` builds and is warning-free.
Do the same for `core` to prevent issues such as [1].
Link: https://github.com/rust-lang/rust/pull/110649 [1]
Fix Unreadable non-UTF-8 output on localized MSVC
Fixes#35785 by converting non UTF-8 linker output to Unicode using the OEM code page.
Before:
```text
= note: Non-UTF-8 output: LINK : fatal error LNK1181: cannot open input file \'m\x84rchenhaft.obj\'\r\n
```
After:
```text
= note: LINK : fatal error LNK1181: cannot open input file 'märchenhaft.obj'
```
The difference is more dramatic if using a non-ascii language pack for Windows.
rustdoc: fix weird margins between Deref impl items
## Before
## After
## Description
In the old setup, if the dereffed-to item has multiple impl blocks, each one gets its own `div.impl-items` in the section, but there are no headers separating them. Since the last method in a `div.impl-items` has no bottom margin, and there are no margins between these divs, there is no margin between the last method of one impl and the first method of the following impl.
This patch fixes it by simplifying the HTML. Each Deref block gets exactly one `div.impl-items`, no matter how many impl blocks it actually has.
Update tests for libtest `--format json`
This PR makes the test work on beta and stable, and adds a test ensuring the option is not available on beta and stable. Backported these commits from https://github.com/rust-lang/rust/pull/110414.
rustdoc: Add a new lint for broken inline code
This patch adds `rustdoc::unescaped_backticks`, a new rustdoc lint that will detect broken inline code nodes.
The lint woks by finding stray backticks and with some heuristics tries to guess where the second backtick might be missing.
Here is how it looks:
```rust
#![warn(rustdoc::unescaped_backticks)]
/// `add(a, b) is the same as `add(b, a)`.
pub fn add(a: i32, b: i32) -> i32 { a + b }
```
```text
warning: unescaped backtick
--> src/lib.rs:3:41
|
3 | /// `add(a, b) is the same as `add(b, a)`.
| ^
|
help: a previous inline code might be longer than expected
|
3 | /// `add(a, b)` is the same as `add(b, a)`.
| +
help: if you meant to use a literal backtick, escape it
|
3 | /// `add(a, b) is the same as `add(b, a)\`.
| +
```
If we can't get proper spans, for example if the doc comment comes from a macro expansion, we print the suggestion in help messages instead. Here's a [real-world example](https://docs.rs/tracing-subscriber/0.3.17/tracing_subscriber/layer/trait.Filter.html#method.max_level_hint):
```text
warning: unescaped backtick
--> /tracing-subscriber-0.3.17/src/layer/mod.rs:1400:9
|
1400 | / /// Returns an optional hint of the highest [verbosity level][level] that
1401 | | /// this `Filter` will enable.
1402 | | ///
1403 | | /// If this method returns a [`LevelFilter`], it will be used as a hint to
... |
1427 | | /// [`Interest`]: tracing_core::subscriber::Interest
1428 | | /// [rebuild]: tracing_core::callsite::rebuild_interest_cache
| |_____________________________________________________________________^
|
= help: a previous inline code might be longer than expected
change: Therefore, if the `Filter will change the value returned by this
to this: Therefore, if the `Filter` will change the value returned by this
= help: if you meant to use a literal backtick, escape it
change: [`rebuild_interest_cache`][rebuild] is called after the value of the max
to this: [`rebuild_interest_cache\`][rebuild] is called after the value of the max
```
You can find more examples [here](https://gist.github.com/lukas-code/7678ddf5c608aee97b3a669de80d3465).
A limitation of the current implementation is, that it cannot suggest removing misplaced backticks, for example [here](https://docs.rs/tikv-jemalloc-sys/0.5.3+5.3.0-patched/tikv_jemalloc_sys/fn.mallctl.html).
The lint is allowed by default ~~and nightly-only~~ for now, ~~but without a feature gate. This is similar to how `rustdoc::invalid_html_tags` and `rustdoc::bare_urls` were handled.~~
Improve niche placement by trying two strategies and picking the better result
Fixes#104807Fixes#105371
Determining which sort order is better requires calculating the struct size (so we can calculate the niche offset). But that in turn depends on the field order, so happens after sorting. So the simple way to solve that is to run the whole thing twice and pick the better result.
1st commit is just code motion, the meat is in the later ones.
Don't duplicate anonymous lifetimes for async fn in traits
`record_lifetime_params_for_async` needs to be called outside of the scope of the function, or else it'll end up collecting anonymous lifetimes twice (those on the function and those within the `AnonymousCreateParameter` rib). This matches how `record_lifetime_params_for_async` is being used for functions with bodies below.
This fixes (partially) #110963 when the lifetimes are late-bound, but does not do so when the lifetimes are early-bound (as seen from the known-bug that I added).
Clear response values for overflow in new solver
When we have an overflow, return a trivial query response. This fixes an ICE with the code described in #110544:
```rust
trait Trait {}
struct W<T>(T);
impl<T, U> Trait for W<(W<T>, W<U>)>
where
W<T>: Trait,
W<U>: Trait,
{}
fn impls<T: Trait>() {}
fn main() {
impls::<W<_>>()
}
```
Where, while proving `W<?0>: Trait`, we overflow but still apply the query response of `?0 = (W<?1>, W<?2>)`. Then while re-processing the query to validate that our evaluation result was stable, we get a different query response that looks like `?1 = (W<?3>, W<?4>), ?2 = (W<?5>, W<?6>)`, and so we trigger the ICE.
Also, by returning a trivial query response we also avoid the infinite-loop/OOM behavior of the old solver.
r? ``@lcnr``
Rollup of 8 pull requests
Successful merges:
- #110877 (Provide better type hints when a type doesn't support a binary operator)
- #110917 (only error combining +whole-archive and +bundle for rlibs)
- #110921 (Use `NonNull::new_unchecked` and `NonNull::len` in `rustc_arena`.)
- #110927 (Encoder/decoder cleanups)
- #110944 (share BinOp::Offset between CTFE and Miri)
- #110948 (run-make test: using single quotes to not trigger the shell)
- #110957 (Fix an ICE in conflict error diagnostics)
- #110960 (fix false negative for `unused_mut`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
For start-biased layout we want to avoid overpromoting so that
the niche doesn't get pushed back.
For end-biased layout we want to avoid promoting fields that
may contain one of the niches of interest.
fix false negative for `unused_mut`
fixes https://github.com/rust-lang/rust/issues/110849
We want to avoid double diagnostics for code like this, but only if an error actually occurs:
```rust
fn main() {
let mut x: (i32, i32);
x.0 = 1;
}
```
The first commit fixes the lint and the second one removes all the unused `mut`s it found.
run-make test: using single quotes to not trigger the shell
This test got added in #110801.
I'm no expert on Makefiles, but IIUC this command is passed to the shell, which usually tries to execute commands specified in between backticks in double-quoted strings.
Using single quotes should fix this, I think. (Note: Waiting for CI to test this, since I only have a web browser available right now).
r? ``@jyn514``
cc ``@WaffleLapkin``
Since this is breaking our build bot, even if it is not directly LLVM related: ``@rustbot`` label: +llvm-main
Provide better type hints when a type doesn't support a binary operator
For example, when checking whether `vec![A] == vec![A]` holds, we first evaluate the LHS's ty, then probe for any `PartialEq` implementations for that. If none is found, we report an error by evaluating `Vec<A>: PartialEq<?0>` for fulfillment errors, but the RHS is not yet evaluated and remains an inference variable `?0`!
To fix this, we evaluate the RHS and equate it to that RHS infer var `?0`, so that we are able to provide more detailed fulfillment errors for why `Vec<A>: PartialEq<Vec<A>>` doesn't hold (namely, the nested obligation `A: PartialEq<A>` doesn't hold).
Fixes#95285Fixes#110867
In the old setup, if the dereffed-to item has multiple impl blocks,
each one gets its own `div.impl-items` in the section, but there
are no headers separating them. Since the last method in a
`div.impl-items` has no bottom margin, and there are no margins
between these divs, there is no margin between the last method
of one impl and the first method of the following impl.
This patch fixes it by simplifying the HTML. Each Deref block gets
exactly one `div.impl-items`, no matter how many impl blocks it
actually has.
