Always create elided lifetimes, even if inferred.
`PathSource` gives the context in which a path is encountered. The same `PathSource` is used for the full path and the `QSelf` part.
Therefore, we can only rely on `PathSource` to know whether typechecking will be able to infer the lifetimes, not whether we need to insert them at all.
Fixes https://github.com/rust-lang/rust/issues/99949
Some `is_useful` cleanups
#98582 was reverted because it was a perf regression.
https://github.com/rust-lang/rust/pull/99806 reintroduces the changes, but this PR picks individual ones that have no regressions.
Rollup of 6 pull requests
Successful merges:
- #98771 (Add support for link-flavor rust-lld for iOS, tvOS and watchOS)
- #98835 (relate `closure_substs.parent_substs()` to parent fn in NLL)
- #99746 (Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`)
- #99786 (Recover from C++ style `enum struct`)
- #99795 (Delay a bug when failed to normalize trait ref during specialization)
- #100029 (Prevent ICE for `doc_alias` on match arm, statement, expression)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Prevent ICE for `doc_alias` on match arm, statement, expression
Fixes#99777.
This is a pretty minimal fix that should be safe, since rustdoc doesn't generate documentation for match arms, statements, or expressions. I mentioned in the linked issue that the `doc_alias` target checking should probably be improved to avoid future ICEs, but as a new contributor, I'm not confident enough with the HIR types to make a larger change.
Delay a bug when failed to normalize trait ref during specialization
The error messages still kinda suck here but they don't ICE anymore...
Fixes#45814Fixes#43037
r? types
Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`
Not sure if this change is worthwhile, but couldn't hurt re: chalkification
r? types
relate `closure_substs.parent_substs()` to parent fn in NLL
Fixes#98589
The discrepancy between early- and late-bound lifetimes is because we map early-bound lifetimes into those found in the `closure_substs` while late-bound lifetimes are mapped into liberated free regions:
5f98537eb7/compiler/rustc_borrowck/src/universal_regions.rs (L255-L261)
r? `@rust-lang/types`
Add support for link-flavor rust-lld for iOS, tvOS and watchOS
This adds support for rust-lld for Apple *OS targets.
This was tested against targets ``aarch64-apple-ios`` and ``aarch64-apple-ios-sim`` with [a simple test program](https://github.com/Thog/rust-lld-apple-target_test).
It currently doesn't work with targets ``armv7-apple-ios`` and ``armv7s-apple-ios`` because of ``symbols.o`` not being generated with the correct CPU subtype. This will require changes in the ``object`` crate to expose an API.
As ``ld64.lld`` requires ``-platform_version`` with the minimal version supported and an sdk version, I made ``rustc_target::apple_base`` public to get access to ``*os_deployment_target`` helper functions and also added ``tvos_deployment_target`` as it was missing.
This adds support for rust-lld for Apple *OS targets.
This was tested against targets "aarch64-apple-ios" and "aarch64-apple-ios-sim".
For targets "armv7-apple-ios" and "armv7s-apple-ios", it doesn't link because of
"symbols.o" not being generated with the correct CPU subtype (changes in
the "object" crate needs to be done to support it).
Rollup of 6 pull requests
Successful merges:
- #99933 (parallelize HTML checking tool)
- #99958 (Improve position named arguments lint underline and formatting names)
- #100008 (Update all pre-cloned submodules on startup)
- #100049 (⬆️ rust-analyzer)
- #100070 (Clarify Cargo.toml comments)
- #100074 (rustc-docs: Be less specific about the representation of `+bundle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
remove `commit_unconditionally`
`commit_unconditionally` is a noop unless we somehow inspect the current state of our snapshot. The only thing which does that is the leak check which was only used in one place where `commit_if_ok` is probably at least as, or even more, correct.
r? rust-lang/types
Improve position named arguments lint underline and formatting names
For named arguments used as implicit position arguments, underline both
the opening curly brace and either:
* if there is formatting, the next character (which will either be the
closing curl brace or the `:` denoting the start of formatting args)
* if there is no formatting, the entire arg span (important if there is
whitespace like `{ }`)
This should make it more obvious where the named argument should be.
Additionally, in the lint message, emit the formatting argument names
without a dollar sign to avoid potentially confusion.
Fixes#99907
Properly reject the `may_unwind` option in `global_asm!`
This was accidentally accepted even though it had no effect in
`global_asm!`. The option only makes sense for `asm!` which runs within
a function.
Always include a position span in `rustc_parse_format::Argument`
Moves the spans from the `Position` enum to always be included in the `Argument` struct. Doesn't make any changes to use it in rustc, but it will be useful for some upcoming Clippy lints
make `PlaceholderConst` not store the type of the const
Currently the `Placeholder` variant on `ConstKind` is 28 bytes when with this PR its 8 bytes, i am not sure this is really useful at all rn since `Unevaluated` and `Value` variants are huge still but eventually it should be possible to get both down to 16 bytes 🤔. Mostly opening this to see if this change has any perf impact when done before it can make `ConstKind`/`ConstS` smaller
For named arguments used as implicit position arguments, underline both
the opening curly brace and either:
* if there is formatting, the next character (which will either be the
closing curl brace or the `:` denoting the start of formatting args)
* if there is no formatting, the entire arg span (important if there is
whitespace like `{ }`)
This should make it more obvious where the named argument should be.
Additionally, in the lint message, emit the formatting argument names
without a dollar sign to avoid potentially confusion.
Fixes#99907
Use Parser's `restrictions` instead of `let_expr_allowed`
This also means that the `ALLOW_LET` flag is reset properly for subexpressions, so we can properly deny things like `a && (b && let c = d)`. Also the parser is a tiny bit smaller now.
It doesn't reject _all_ bad `let` expr usages, just a bit more.
cc `@c410-f3r`
`codegen_fulfill_obligation` expect erased regions
it's a query, so by erasing regions before calling it, we get better caching.
This doesn't actually change anything as its already the status quo.
Thin `AssocItem`
This PR removes a few fields from `AssocItem` that should be easily computed using other queries.
This simplifies some of the metadata decoding.
Add tests for raw-dylib with vectorcall, and fix vectorcall code generation
* Adds tests for using `raw-dylib` (#58713) with `vectorcall`.
* Fixed code generation for `vectorcall` (parameters have to be marked with `InReg`, just like `fastcall`).
* Enabled running the `raw-dylib` `fastcall` tests when using MSVC (since I had to add support in the test for running MSVC-only tests since GCC doesn't support `vectorcall`).
Rollup of 8 pull requests
Successful merges:
- #99340 (Fix ICE in Definitions::create_def)
- #99629 (Improve `cannot move out of` error message)
- #99864 (bootstrap: don't emit warn about duplicated deps with same/different features if some of sets actually empty)
- #99911 (Remove some uses of `guess_head_span`)
- #99976 (Make Rustdoc exit with correct error code when scraping examples from invalid files)
- #100003 (Improve size assertions.)
- #100012 (Avoid `Ty` to `String` conversions)
- #100020 (better error when python is not found in x - issue #99648)
Failed merges:
- #99994 (Replace `guess_head_span` with `opt_span`)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve size assertions.
- For any file with four or more size assertions, move them into a
separate module (as is already done for `hir.rs`).
- Add some more for AST nodes and THIR nodes.
- Put the `hir.rs` ones in alphabetical order.
r? `@lqd`
Fix ICE in Definitions::create_def
`Debug` implementation for `LocalDefId` uses global `Definitions`. Normally it’s ok, but we can’t do it while holding a mutable reference to `Definitions`, since it causes ICE or deadlock (depending on whether `parallel_compiler` is enabled).
This PR effectively copies the `Debug` implementation into the problematic method. I don’t particularly love this solution (since it creates code duplication), but I don’t see any other options.
This issue was discovered when running `rustdoc` with `RUSTDOC_LOG=trace` on the following file:
```rust
pub struct SomeStruct;
fn asdf() {
impl SomeStruct {
pub fn qwop(&self) {
println!("hidden function");
}
}
}
```
I’m not sure how to create a test for this behavior.
Limit symbols exported from proc macros
Only `__rustc_proc_macro_decls_*__` and `rust_metadata_*` need to be
exported for proc macros to work. All other symbols only increase binary
size and have the potential to conflict with symbols from the host
compiler.
Fixes https://github.com/rust-lang/rust/issues/99909Fixes#59998
cc `@eddyb`
Rollup of 7 pull requests
Successful merges:
- #99519 (Remove implicit names and values from `--cfg` in `--check-cfg`)
- #99620 (`-Z location-detail`: provide option to disable all location details)
- #99932 (Fix unwinding on certain platforms when debug assertions are enabled)
- #99973 (Layout things)
- #99980 (Remove more Clean trait implementations)
- #99984 (Fix compat.rs for `cfg(miri)`)
- #99986 (Add wrap suggestions for record variants)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
- For any file with four or more size assertions, move them into a
separate module (as is already done for `hir.rs`).
- Add some more for AST nodes and THIR nodes.
- Put the `hir.rs` ones in alphabetical order.
From 72 bytes to 12 bytes (on x86-64).
There are two parts to this:
- Changing various source code offsets from 64-bit to 32-bit. This is
not a problem because the rest of rustc also uses 32-bit source code
offsets. This means `Token` is no longer `Copy` but this causes no
problems.
- Removing the `RawStrError` from `LiteralKind`. Raw string literal
invalidity is now indicated by a `None` value within
`RawStr`/`RawByteStr`, and the new `validate_raw_str` function can be
used to re-lex an invalid raw string literal to get the `RawStrError`.
There is one very small change in behaviour. Previously, if a raw string
literal matched both the `InvalidStarter` and `TooManyHashes` cases,
the latter would override the former. This has now changed, because
`raw_double_quoted_string` now uses `?` and so returns immediately upon
detecting the `InvalidStarter` case. I think this is a slight
improvement to report the earlier-detected error, and it explains the
change in the `test_too_many_hashes` test.
The commit also removes a couple of comments that refer to #77629 and
say that the size of these types don't affect performance. These
comments are wrong, though the performance effect is small.
Fix cloning from a BitSet with a different domain size
The previous implementation incorrectly assumed that the
number of words in a bit set is equal to the domain size.
The new implementation delegates to `Vec::clone_from` which
is specialized for `Copy` elements.
Fixes#99006.
Add wrap suggestions for record variants
This PR adds a suggestions to wrap an expression in a record struct/variant when encountering mismatched types, similarly to a suggestion to wrap expression in a tuple struct that was added before.
An example:
```rust
struct B {
f: u8,
}
enum E {
A(u32),
B { f: u8 },
}
fn main() {
let _: B = 1;
let _: E = 1;
}
```
```text
error[E0308]: mismatched types
--> ./t.rs:11:16
|
11 | let _: B = 1;
| - ^ expected struct `B`, found integer
| |
| expected due to this
|
help: try wrapping the expression in `B`
|
11 | let _: B = B { f: 1 };
| ++++++ +
error[E0308]: mismatched types
--> ./t.rs:12:16
|
12 | let _: E = 1;
| - ^ expected enum `E`, found integer
| |
| expected due to this
|
help: try wrapping the expression in a variant of `E`
|
12 | let _: E = E::A(1);
| +++++ +
12 | let _: E = E::B { f: 1 };
| +++++++++ +
```
r? `@compiler-errors`
Layout things
These two commits are pretty independent, but didn't seem worth doing individual PRs for:
- Always check that size is a multiple of align, even without debug assertions
- Change Layout debug printing to put `variants` last, since it often huge and not usually the part we are most interested in
Cc `@eddyb`
`-Z location-detail`: provide option to disable all location details
As reported [here](https://github.com/rust-lang/rust/pull/89920#issuecomment-1190598924), when I first implemented the `-Z location-detail` flag there was a bug, where passing an empty list was not correctly supported, and instead rejected by the compiler. This PR fixes that such that passing an empty list results in no location details being tracked, as originally specified in https://github.com/rust-lang/rfcs/pull/2091 .
This PR also adds a test case to verify that this option continues to work as intended.
Remove implicit names and values from `--cfg` in `--check-cfg`
This PR remove the implicit names and values from `--cfg` in `--check-cfg` because the behavior is quite surprising but also because it's really easy to inadvertently really on the implicitness and when the `--cfg` is not set anymore to have an unexpected warning from an unexpected condition that pass with the implicitness.
This change in behavior will also enable us to warn when an unexpected `--cfg` is passed, ex: the user wrote `--cfg=unstabl` instead of `--cfg=unstable`. The implementation of the warning will be done in a follow-up PR.
cc `@petrochenkov`
Suggest removing a semicolon and boxing the expressions for if-else
`InferCtxt::suggest_remove_semi_or_return_binding` was not working well, so I fixed it and added a ui test.
Introduce an ArchiveBuilderBuilder
This avoids monomorphizing all linker code for each codegen backend and will allow passing in extra information to the archive builder from the codegen backend. I'm going to use this in https://github.com/rust-lang/rust/pull/97485 to allow passing in the right function to extract symbols from object files to a generic archive builder to be used by cg_llvm, cg_clif and cg_gcc.
Use `impl`'s generics when suggesting fix on bad `impl Copy`
See the UI test for a more complicated example, but we weren't correctly suggesting to add bounds given a manual `impl` whose generics didn't match the struct generics.
```rust
#[derive(Clone)]
struct Wrapper<T>(T);
impl<S> Copy for Wrapper<S> {}
```
Coincidentally this fix didn't cause any regressions for `derive(Copy)` impls, I think because those use the same spans in the impl generics as the struct generics, so the machinery still applies the same change.
Fix the size of niche enums with ZST alignment
For enums with an aligned ZST variant, like `[T; 0]`, the niche layout
was not computing a sufficient size to be consistent with alignment. Now
we pad that size up to the alignment, and also make sure to only use the
niche variant's ABI when the size and alignment still match.
Fixes#99836
r? `@eddyb`
Also gate AllocatedPointer and AllocAlign definitions by LLVM_VERSION_GE
Fixes a warning:
```
warning: llvm-wrapper/RustWrapper.cpp:159:11: warning: enumeration values 'AllocatedPointer' and 'AllocAlign' not handled in switch [-Wswitch]
warning: switch (Kind) {
warning: ^
```
Which was fall out from 130a1df71e.
Fixes#99955
For enums with an aligned ZST variant, like `[T; 0]`, the niche layout
was not computing a sufficient size to be consistent with alignment. Now
we pad that size up to the alignment, and also make sure to only use the
niche variant's ABI when the size and alignment still match.
Rollup of 5 pull requests
Successful merges:
- #99311 (change maybe_body_owned_by to take local def id)
- #99862 (Improve type mismatch w/ function signatures)
- #99895 (don't call type ascription "cast")
- #99900 (remove some manual hash stable impls)
- #99903 (Add diagnostic when using public instead of pub)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fixes a warning:
warning: llvm-wrapper/RustWrapper.cpp:159:11: warning: enumeration values 'AllocatedPointer' and 'AllocAlign' not handled in switch [-Wswitch]
warning: switch (Kind) {
warning: ^
Which was fall out from 130a1df71e.
Add diagnostic when using public instead of pub
Forwarding from https://github.com/rust-lang/rust/pull/99706
I accidentally broke something(??) in git and the commits in that PR are absolutely not what I did in that branch
Anyways, this is the PR for this now. Adding tests again in a minute.
cc `@davidtwco`
Improve type mismatch w/ function signatures
This PR makes use of `note: expected/found` (instead of labeling types in labels) in type mismatch with function signatures. Pros: it's easier to compare the signatures, cons: the error is a little more verbose now.
This is especially nice when
- The signatures differ in a small subset of parameters (same parameters are elided)
- The difference is in details, for example `isize` vs `usize` (there is a better chance that the types align)
Also this PR fixes the inconsistency in variable names in the edited code (`expected` and `found`).
A zulip thread from which this pr started: [[link]](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Type.20error.20regression.3F.2E.2E.2E/near/289756602).
An example diagnostic:
<table>
<tr>
<th>this pr</th>
<th>nightly</th>
</tr>
<tr>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected due to this
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature defined here
|
= note: expected function signature `fn(usize, _, Vec<u64>) -> _`
found function signature `fn(isize, _, Vec<u32>) -> _`
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast from `fn(isize, u8, Vec<u32>) {f}` to the object type `dyn Trait`
```
</td>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected signature of `fn(usize, u8, Vec<u64>) -> _`
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature of `fn(isize, u8, Vec<u32>) -> _`
|
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast to the object type `dyn Trait`
```
</td>
</tr>
</table>
<details><summary>code</summary>
<p>
```rust
fn main() {
fn expect(_: &dyn Trait) {}
expect(&f);
}
trait Trait {}
impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
fn f(_: isize, _: u8, _: Vec<u32>) {}
```
</p>
</details>
r? `@compiler-errors`
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
r? `@petrochenkov`
Only __rustc_proc_macro_decls_*__ and rust_metadata_* need to be
exported for proc macros to work. All other symbols only increase binary
size and have the potential to conflict with symbols from the host
compiler.
use `check_region_obligations_and_report_errors` to avoid ICEs
If we don't call `process_registered_region_obligations` before `resolve_regions_and_report_errors` then we'll ICE if we have any region obligations, and `check_region_obligations_and_report_errors` just does both of these for us in a nice convenient function.
Fixes#53475
r? types
proc_macro: use crossbeam channels for the proc_macro cross-thread bridge
This is done by having the crossbeam dependency inserted into the `proc_macro` server code from the server side, to avoid adding a dependency to `proc_macro`.
In addition, this introduces a -Z command-line option which will switch rustc to run proc-macros using this cross-thread executor. With the changes to the bridge in #98186, #98187, #98188 and #98189, the performance of the executor should be much closer to same-thread execution.
In local testing, the crossbeam executor was substantially more performant than either of the two existing `CrossThread` strategies, so they have been removed to keep things simple.
r? `@eddyb`
Rollup of 8 pull requests
Successful merges:
- #99227 (Fix thumbv4t-none-eabi frame pointer setting)
- #99518 (Let-else: break out scopes when a let-else pattern fails to match)
- #99671 (Suggest dereferencing index when trying to use a reference of usize as index)
- #99831 (Add Fuchsia platform support documentation)
- #99881 (fix ICE when computing codegen_fn_attrs on closure with non-fn parent)
- #99888 (Streamline lint checking)
- #99891 (Adjust an expr span to account for macros)
- #99904 (Cleanup html whitespace)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Adjust an expr span to account for macros
Fix this erroneous suggestion:
```
error[E0529]: expected an array or slice, found `Vec<{integer}>`
--> /home/gh-compiler-errors/test.rs:2:9
|
2 | let [..] = vec![1, 2, 3];
| ^^^^ pattern cannot match with input type `Vec<{integer}>`
|
help: consider slicing here
--> /home/gh-compiler-errors/rust2/library/alloc/src/macros.rs:50:36
|
50~ $crate::__rust_force_expr!(<[_]>::into_vec(
51+ #[rustc_box]
52+ $crate::boxed::Box::new([$($x),+])
53~ )[..])
```
Streamline lint checking
The early (AST) and late (HIR) lint checkers have a number of functions that aren't used by rustc or clippy. Might as well remove them -- it's not like there's a canonical API here, as shown by the ad hoc use of `check_foo`/`check_foo_post` combinations.
r? `@cjgillot`
fix ICE when computing codegen_fn_attrs on closure with non-fn parent
Other call sites check `has_codegen_attrs` first, so let's do that too.
Fixes#99876
Let-else: break out scopes when a let-else pattern fails to match
This PR will commit to a new behavior so that values from initializer expressions are dropped earlier when a let-else pattern fails to match.
Fix#98672.
Close#93951.
cc `@camsteffen` `@est31`
Fix thumbv4t-none-eabi frame pointer setting
The `thumb_base` profile has changed since I last remember seeing it, and now it sets the frame pointer to "always keep", which is not desired for this target. Hooking a debugger to the running program is not really done, it's preferable to have the register available for actual program use, so the default "may omit" is now set.
I thought that the target was already using "may omit" when I checked on it last month, because I forgot that the target was previously based on `thumb_base` rather than `Default::default()`. I only noticed the issue just now when creating the `armv4t-none-eabi` target (https://github.com/rust-lang/rust/pull/99226), though this PR is not in any way conditional on that one.
This is done by having the crossbeam dependency inserted into the
proc_macro server code from the server side, to avoid adding a
dependency to proc_macro.
In addition, this introduces a -Z command-line option which will switch
rustc to run proc-macros using this cross-thread executor. With the
changes to the bridge in #98186, #98187, #98188 and #98189, the
performance of the executor should be much closer to same-thread
execution.
In local testing, the crossbeam executor was substantially more
performant than either of the two existing CrossThread strategies, so
they have been removed to keep things simple.
Rollup of 8 pull requests
Successful merges:
- #99686 (add suggestion when there is a impl of external trait on pointer with wrong coherence rules)
- #99760 (doc/rustc: describe the uefi target platforms)
- #99766 (Htmldocck: Substitute the doc channel when blessing)
- #99781 (Use String::from_utf8_lossy in CStr demo)
- #99803 (Update mentions to `rustc_metadata::rmeta::Lazy`)
- #99845 (Remove `$` prefix for bash scripts in doc)
- #99850 (rustdoc: Remove more Clean trait implementations)
- #99872 (Clone the `src/llvm-project` submodule if profiling is enabled)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update mentions to `rustc_metadata::rmeta::Lazy`
While working on https://github.com/rust-lang/rustc-dev-guide/pull/1411, I noticed there are still some mentions of `Lazy`. This updates them to `LazyValue`, `LazyArray`, or `LazyTable`.
r? ````@compiler-errors````
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
add suggestion when there is a impl of external trait on pointer with wrong coherence rules
Closes https://github.com/rust-lang/rust/issues/99572
This will try to improve the node in the error message by suggesting a general solution because the solution, in this case, is application depended.
I'm not super happy regarding the code quality, but I'm happy to have feedback on it.
`@rustbot` r? `@compiler-errors`
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
Generate correct suggestion with named arguments used positionally
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Fixes#99265Fixes#99266
LLVM 15 compatibility fixes
These are LLVM 15 compatibility fixes split out from #99464. There are three changes here:
* Emit elementtype attribtue for ldrex/strex intrinsics. This is requires as part of the opaque pointers migration.
* Make more tests compatible with opaque pointers. These are either new or aren't run on x86.
* Remove a test for `#[rustc_allocator]`. Since #99574 there are more requirement on the function signature. I dropped the test entirely, since we already test the effect of the attribute elsewhere.
* The main change: When a worker thread emits an error, wait for other threads to finish before unwinding the main thread and exiting. Otherwise workers may end up using globals for which destructors have already been run. This was probably never quite correct, but became an active problem with LLVM 15, because it started using global dtors in critical places, as part of ManagedStatic removal.
Fixes#99432 (and probably also #95679).
r? `@cuviper`
Prior to this fix, `-Z location-detail` provided no mechanism for
disabling all location details. This commit also adds a test case
to verify that this option continues to work as intended, and
clarifies the documentation of this option.
fix: remove fake no_dead_strip for osx
Closes https://github.com/rust-lang/rust/issues/99788
Link arg `-no_dead_strip` doesn't exist on OSX at all.
The `no_gc_sections` function was never called before export-executable-symols implementation, and `export-executable-symbols` still works, so we just remove it.
r? `@bjorn3`
Use line numbers relative to the function in mir-opt tests
As shown in #99770, the line numbers can be a big source of needless and confusing diffs. This PR adds a new flag `-Zmir-pretty-relative-line-numbers` to make them relative to the function declaration, which avoids most needless diffs from attribute changes.
`@JakobDegen` told me that there has been a zulip conversation about disabling line numbers with mixed opinions, so I'd like to get some feedback here, for this hopefully better solution.
r? rust-lang/wg-mir-opt
This avoids monomorphizing all linker code for each codegen backend and
will allow passing in extra information to the archive builder from the
codegen backend.
This initial implementation handles transmutations between types with specified layouts, except when references are involved.
Co-authored-by: Igor null <m1el.2027@gmail.com>
lint: add bad opt access internal lint
Prompted by [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/sess.2Ecrate_types.28.29.20vs.20sess.2Eopts.2Ecrate_types/near/290682847).
Some command-line options accessible through `sess.opts` are best accessed through wrapper functions on `Session`, `TyCtxt` or otherwise, rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed through a wrapper function so that this is prohibited. Options are annotated with a new attribute `rustc_lint_opt_deny_field_access` which can specify the error message (i.e. "use this other function instead") to be emitted.
A simpler alternative would be to simply rename the options in the option type so that it is clear they should not be used, however this doesn't prevent uses, just discourages them. Another alternative would be to make the option fields private, and adding accessor functions on the option types, however the wrapper functions sometimes rely on additional state from `Session` or `TyCtxt` which wouldn't be available in an function on the option type, so the accessor would simply make the field available and its use would be discouraged too.
**Leave a comment if there's an option I should add this to.**
Deeply deny fn and raw ptrs in const generics
I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter.
We now reject both of these in the same way:
```
#![feature(adt_const_params)]
#[derive(Eq, PartialEq)]
struct Wrapper();
fn foo<const W: Wrapper>() {}
fn foo2<const F: fn()>() {}
```
This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place.
cc: ``@b-naber`` who introduced that test^
fixes#99641
Remove let-chain close brace check.
#98633 added some checks to forbid let-expressions that aren't in a let chain. This check looks at the preceding token to determine if it is a valid let-chain position. One of those tokens it checks is the close brace `}`. However, to my understanding, it is not possible for a let chain to be preceded by a close brace. This PR removes the check to avoid any confusion.
This is a followup to the discussion at https://github.com/rust-lang/rust/pull/98633#pullrequestreview-1030962803. It wasn't clear what issues the original PR ran into, but I have run the full set of CI tests and nothing failed. I also can't conceive of a situation where this would be possible. This doesn't reject any valid code, I'm just removing it to avoid confusion to anyone looking at this code in the future.
Replace the separate AbortCodegenOnDrop guard by integrating this
functionality into OngoingCodegen (or rather, the Coordinator part
of it). This ensures that we send a CodegenAborted message and
wait for workers to finish even if the panic occurs outside
codegen_crate() (e.g. inside join_codegen()).
This requires some minor changes to the handling of CodegenAborted,
as it can now occur when the main thread is LLVMing rather than
Codegenning.
Some command-line options accessible through `sess.opts` are best
accessed through wrapper functions on `Session`, `TyCtxt` or otherwise,
rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed
through a wrapper function so that this is prohibited. Options are
annotated with a new attribute `rustc_lint_opt_deny_field_access` which
can specify the error message (i.e. "use this other function instead")
to be emitted.
A simpler alternative would be to simply rename the options in the
option type so that it is clear they should not be used, however this
doesn't prevent uses, just discourages them. Another alternative would
be to make the option fields private, and adding accessor functions on
the option types, however the wrapper functions sometimes rely on
additional state from `Session` or `TyCtxt` which wouldn't be available
in an function on the option type, so the accessor would simply make the
field available and its use would be discouraged too.
Signed-off-by: David Wood <david.wood@huawei.com>
If an internal lint uses `typeck_results` or similar queries then that
can result in rustdoc checking code that it shouldn't (e.g. from other
platforms) and emit compilation errors.
Signed-off-by: David Wood <david.wood@huawei.com>
Sync rustc_codegen_cranelift
I did a large refactoring of the intrinsics module to remove the intrinsic_match macro which is not very clear to other people. This also enables rustfmt to run on this code. While I already did a sync yesterday, I am going to do another sync again to avoid potential conflicts as those will likely be painful to resolve.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Check that RPITs constrained by a recursive call in a closure are compatible
Fixes#99073
Adapts a similar visitor pattern to `find_opaque_ty_constraints` (that we use to check TAITs), but with some changes:
0. Only walk the "OnlyBody" children, instead of all items in the RPIT's defining scope
1. Only walk through the body's children if we found a constraining usage
2. Don't actually do any inference, just do a comparison and error if they're mismatched
----
r? `@oli-obk` -- you know all this impl-trait stuff best... is this the right approach? I can explain the underlying issue better if you'd like, in case that might reveal a better solution. Not sure if it's possible to gather up the closure's defining usages of the RPIT while borrowck'ing the outer function, that might be a better place to put this check...
Add a brief comment explaining why the diagnostic migration lints aren't
included in the `rustc::internal` diagnostic group.
Signed-off-by: David Wood <david.wood@huawei.com>
passes: port more of `check_attr` module
Continues from #99213.
Port more diagnostics in `rustc_passes::check_attr` to using the diagnostic derive and translation machinery.
r? `@compiler-errors`
Prefer visibility map parents that are not `doc(hidden)` first
Far simpler approach to #98876.
This only fixes the case where the parent is `doc(hidden)`, not where the child is `doc(hidden)` since I don't know how to get the attrs on the import statement given a `ModChild`... I'll try to follow up with that, but this is a good first step.
codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
r? `@nikic`
