rust/tests/ui/consts/const-extern-fn/const-extern-fn-requires-unsafe.thir.stderr

error[E0133]: call to unsafe function `foo` is unsafe and requires unsafe function or block
  --> $DIR/const-extern-fn-requires-unsafe.rs:9:17
   |
LL |     let a: [u8; foo()];
   |                 ^^^^^ call to unsafe function
   |
   = note: consult the function's documentation for information on how to avoid undefined behavior

error: aborting due to previous error

For more information about this error, try `rustc --explain E0133`.
add `DefId` to unsafety violations and display function path in E0133 this enables consumers to access the function definition that was reported to be unsafe 2022-04-24 14:08:23 +02:00			error[E0133]: call to unsafe function `foo` is unsafe and requires unsafe function or block
Test `-Zthir-unsafeck` for unsafe function calls 2021-03-14 20:11:37 +01:00			`--> $DIR/const-extern-fn-requires-unsafe.rs:9:17`
Add support for 'extern const fn' This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. 2019-09-29 19:22:18 -04:00			`\|`
			`LL \| let a: [u8; foo()];`
only show a simple description in E0133 span label 2022-04-24 14:42:30 +02:00			`\| ^^^^^ call to unsafe function`
Add support for 'extern const fn' This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. 2019-09-29 19:22:18 -04:00			`\|`
			`= note: consult the function's documentation for information on how to avoid undefined behavior`

Remove some errors in UI tests As we now need to run THIR unsafeck before MIR build, errors in unsafeck can cause the compilation to be aborted earlier. 2021-05-15 11:42:10 +02:00			`error: aborting due to previous error`
Add support for 'extern const fn' This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. 2019-09-29 19:22:18 -04:00
			For more information about this error, try `rustc --explain E0133`.