When dlltool fails, show the full command that was executed. In
particular, llvm-dlltool is not very helpful, printing a generic usage
message rather than what actually went wrong, so stdout and stderr
aren't of much use when troubleshooting.
loongarch64-unknown-none*: Set default relocation model to static
This PR sets the default relocation model to `static` for `loongarch64-unknown-none*` targets. This change aims to streamline the development of the bare-metal project by removing the need for the executable program loader to implement relocation.
Suggest using `ptr::null_mut` when user provided `ptr::null` to a function expecting `ptr::null_mut`
```
error[E0308]: mismatched types
--> $DIR/ptr-null-mutability-suggestions.rs:9:24
|
LL | expecting_null_mut(ptr::null());
| ------------------ ^^^^^^^^^^^
| | |
| | types differ in mutability
| | help: consider using `core::ptr::null_mut` instead: `core::ptr::null_mut()`
| arguments to this function are incorrect
|
= note: expected raw pointer `*mut u8`
found raw pointer `*const _`
note: function defined here
--> $DIR/ptr-null-mutability-suggestions.rs:6:4
|
LL | fn expecting_null_mut(_: *mut u8) {}
| ^^^^^^^^^^^^^^^^^^ ----------
```
Closes#85184.
Dont compute `opt_suggest_box_span` span for TAIT
Fixes#112434
Also a couple more commits on top, pruning some dead code and fixing another weird suggestion encountered in the above issue.
iat selection: normalize self ty & completely erase bound vars
Erase bound vars (most notably late-bound regions) irrespective of their binding level instead of just at the innermost one.
Fixes#111404.
Instead of linking to the old Rust Reference site on static.rust-lang.org,
link to the current website doc.rust-lang.org/stable/reference instead in
diagnostic about incorrect literals.
Adjust span labels for `HIDDEN_GLOB_REEXPORTS`
Addresses https://github.com/rust-lang/rust/pull/111378#issuecomment-1581226063.
### Before This PR
The possibility that the private item comes before the glob re-export was not account for, causing the span label messages to say "but private item here shadows it" before "the name `Foo` in the type namespace is supposed to be publicly re-exported here".
### After This PR
```rust
warning: private item shadows public glob re-export
--> $DIR/hidden_glob_reexports.rs:9:5
|
LL | struct Foo;
| ^^^^^^^^^^^ the private item here shadows the name `Foo` in the type namespace
...
LL | pub use self::inner::*;
| -------------- but it is supposed to be publicly re-exported here
|
= note: `#[warn(hidden_glob_reexports)]` on by default
warning: private item shadows public glob re-export
--> $DIR/hidden_glob_reexports.rs:27:9
|
LL | pub use self::inner::*;
| -------------- the name `Foo` in the type namespace is supposed to be publicly re-exported here
LL |
LL | use self::other::Foo;
| ^^^^^^^^^^^^^^^^ but the private item here shadows it
```
Update field-offset and enable unstable_offset_of
This makes the compiler use the builtin `offset_of!()` macro, through the wrappers in memoffset and then in field-offset.
cc #111839
Uplift `clippy::cmp_nan` lint
This PR aims at uplifting the `clippy::cmp_nan` lint into rustc.
## `invalid_nan_comparisons`
~~(deny-by-default)~~ (warn-by-default)
The `invalid_nan_comparisons` lint checks comparison with `f32::NAN` or `f64::NAN` as one of the operand.
### Example
```rust,compile_fail
let a = 2.3f32;
if a == f32::NAN {}
```
### Explanation
NaN does not compare meaningfully to anything – not even itself – so those comparisons are always false.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
expand: Change how `#![cfg(FALSE)]` behaves on crate root
Previously it removed all other attributes from the crate root.
Now it removes only attributes below itself (during both regular expansion and pre-configuration).
So it becomes possible to configure some global crate properties even for fully unconfigured crates.
Fixes https://github.com/rust-lang/rust/issues/104633
Part of https://github.com/rust-lang/rust/issues/110082
increase the accuracy of effective visibilities calculation
Effective visibilities are calculated lazily due to performance restrictions. Therefore
- crate should be walked at least 1 time in `compute_effective_visibilities` pass
- Impl's should always be in the effective visibilities table
to ensure that the table is filled in correctly.
r? `@petrochenkov`
Previously it removed all other attributes from the crate root.
Now it removes only attributes below itself.
So it becomes possible to configure some global crate properties even for fully unconfigured crates.
Support float-like tuple indices in offset_of!()
Supports invocations like `offset_of!((((), ()), ()), 0.0)`. This `0.0` gets tokenized as float literal, so it has to be broken up again.
The code that did the breaking up was returning a finished `Expr`, while we need a `Ident`, so this PR splits up the `parse_expr_tuple_field_access_float` function into:
* a function that breaks up the float literal (similar to `TokenKind::break_two_token_op`, but we do access the parser during this splitting operation, so we keep it as an inherent function on the parser)
* and a function that constructs an `Expr` from it
The former we can then re-use in `offset_of` parsing. The edge cases especially involving whitespaces are tricky so this adds a bunch of new tests as well.
fixes#112204
Rollup of 3 pull requests
Successful merges:
- #112260 (Improve document of `unsafe_code` lint)
- #112429 ([rustdoc] List matching impls on type aliases)
- #112442 (Deduplicate identical region constraints in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Deduplicate identical region constraints in new solver
the new solver doesn't track whether we've already proven a goal like the fulfillment context's obligation forest does, so we may be instantiating a canonical response (and specifically, its nested region obligations) quite a few times.
This may lead to exponentially gathering up identical region constraints for things like auto traits, so let's deduplicate region constraints when in `compute_external_query_constraints`.
r? ``@lcnr``
Uplift `clippy::undropped_manually_drops` lint
This PR aims at uplifting the `clippy::undropped_manually_drops` lint.
## `undropped_manually_drops`
(warn-by-default)
The `undropped_manually_drops` lint check for calls to `std::mem::drop` with a value of `std::mem::ManuallyDrop` which doesn't drop.
### Example
```rust
struct S;
drop(std::mem::ManuallyDrop::new(S));
```
### Explanation
`ManuallyDrop` does not drop it's inner value so calling `std::mem::drop` will not drop the inner value of the `ManuallyDrop` either.
-----
Mostly followed the instructions for uplifting an clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::undropped_manually_drops` into rustc
Write to stdout if `-` is given as output file
With this PR, if `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (those of type `obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together.
This implements https://github.com/rust-lang/compiler-team/issues/431
The idea behind the changes is to introduce an `OutFileName` enum that represents the output - be it a real path or stdout - and to use this enum along the code paths that handle different output types.
