Disallow setting some built-in cfg via set the command-line
This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.
This implements MCP https://github.com/rust-lang/compiler-team/issues/610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.
------
The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.
*(deny-by-default)*
### Example
```text
rustc --cfg unix
```
```rust,ignore (needs command line option)
fn main() {}
```
This will produce:
```text
error: unexpected `--cfg unix` flag
|
= note: config `unix` is only supposed to be controlled by `--target`
= note: manually setting a built-in cfg can and does create incoherent behaviours
= note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
```
### Explanation
Setting builtin cfgs can and does produce incoherent behaviour, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.
-----
r? `@petrochenkov`
cc `@jyn514`
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
try-job: dist-various-1
Don't arbitrarily choose one upper bound for hidden captured region error message
You could argue that the error message is objectively worse, even though it's more accurate. I guess we could also add a note explaining like "cannot capture the intersection of two regions" or something, though I'm not sure if that is confusing due to being totally technical jargon.
This addresses the fact that #128752 says "add `+ 'b`" even though it does nothing to fix the issue. It doesn't fix the issue's root cause, though.
r? `@spastorino`
More information for fully-qualified suggestion when there are multiple impls
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> $DIR/E0283.rs:30:21
|
LL | fn create() -> u32;
| ------------------- `Coroutine::create` defined here
...
LL | let cont: u32 = Coroutine::create();
| ^^^^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation
|
LL | let cont: u32 = <Impl as Coroutine>::create();
| ++++++++ +
LL | let cont: u32 = <AnotherImpl as Coroutine>::create();
| +++++++++++++++ +
```
minor `effects` cleanups
* remove the fixme comment about not needing defaults because it turns out we do need defaults (if I made it None instead it would ice a bunch of tests)
* remove the part that special cased trait args when lowering them. This is now historical because effects doesn't add host args to traits anymore (we use associated types now)
Make create_dll_import_lib easier to implement
This will make it easier to implement raw-dylib support in cg_clif and cg_gcc. This PR doesn't yet include an create_dll_import_lib implementation for cg_clif as I need to correctly implement dllimport in cg_clif first before raw-dylib can work at all with cg_clif.
Required for https://github.com/rust-lang/rustc_codegen_cranelift/issues/1345
We can replace some tricky iterator-mutation code with a much simpler version
that uses `while let` to shrink a slice.
We also check whether a subpattern would be a wildcard _before_ hoisting it,
which will be very useful when trying to get rid of `print::PatKind` later.
Version 0.3.1 has added support for writing import libraries. Version
0.3.2 fixed creating archives containing members of import libraries.
Version 0.3.3 fixed building on big-endian systems.
The object crate was recently updated to recognize the 32-bit SPARC
ELF targets EM_SPARC and EM_SPARC32PLUS, so the proper architecture
for 32-bit SPARC can now be set in rustc_codegen_ssa.
Add `f16` and `f128` math functions
This adds intrinsics and math functions for `f16` and `f128` floating point types. Support is quite limited and some things are broken so tests don't run on many platforms, but this provides a starting point.
The two altered expectation messages both seem like improvements:
- `coerce-expect-unsized-ascribed.stderr` says you can go
`Box<char> -> Box<dyn Debug>`, which you can.
- `upcast_soundness_bug.stderr` used to say that you could go
`Box<dyn Trait<u8, u8>> -> Box<dyn Trait>`, which you can't,
because the type parameters are missing in the destination
and the only ones that work aren't what's needed.
Don't ICE when getting an input file name's stem fails
Fixes#128681
The file stem is only used as a user-friendly prefix on intermediary files. While nice to have, it's not the end of the world if it fails so there's no real reason to emit an error here. We can continue with a fixed name as we do when an anonymous string is used.
interpret: refactor function call handling to be better-abstracted
Add a new function `init_stack_frame` that pushes a stack frame and passes the arguments, and use that basically everywhere that the raw underlying `push_stack_frame` used to be called. This splits the previous monster function `eval_fn_call` into two parts: figuring out the MIR to call and the arguments to pass, and then actually setting up the stack frame.
Also re-organize the files a bit:
- The previous `terminator.rs` is split into a new `call.rs` with all the argument-passing logic, and the rest goes into `step.rs` where the other main dispatcher functions already live (in particular, `eval_statement`).
- All the stack frame handling from `eval_context.rs` is moved to a new `stack.rs`.
Pass the right `ParamEnv` to `might_permit_raw_init_strict`
Fixes#119620
`might_permit_raw_init_strict` currently passes an empty `ParamEnv` to the `InterpCx`, instead of the actual `ParamEnv` that was passed in to `check_validity_requirement` at callsite.
This leads to ICEs such as the linked issue where for `UnsafeCell<*mut T>` we initially get the layout with the right `ParamEnv` (which suceeds because it can prove that `T: Sized` and therefore `UnsafeCell<*mut T>` has a known layout) but then do the rest with an empty `ParamEnv` where `T: Sized` is not known to hold so getting the layout for `*mut T` later fails.
This runs into an assertion in other layout code where it's making the (valid) assumption that, when we already have a layout for a struct (`UnsafeCell<*mut T>`), getting the layout of one of its fields (`*mut T`) should also succeed, which wasn't the case here due to using the wrong `ParamEnv`.
So, this PR changes it to just use the same `ParamEnv` all the way throughout.
Fix ICE Caused by Incorrectly Delaying E0107
Fixes #128249
For the following code:
```rust
trait Foo<T> {}
impl Foo<T: Default> for u8 {}
```
#126054 added some logic to delay emitting E0107 as the names of associated type `T` in the impl header and generic parameter `T` in `trait Foo` match.
But it failed to ensure whether such unexpected associated type bounds are coming from a impl block header. This caused an ICE as the compiler was delaying E0107 for code like:
```rust
trait Trait<Type> {
type Type;
fn method(&self) -> impl Trait<Type: '_>;
}
```
because it assumed the associated type bound `Type: '_` is for the generic parameter `Type` in `trait Trait` since the names are same.
This PR adds a check to ensure that E0107 is delayed only in the context of impl block header.
