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.
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.
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]
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.
`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]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Report allocation errors as panics
OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`.
This should be review one commit at a time:
- The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics.
- The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API.
ACP: https://github.com/rust-lang/libs-team/issues/192Closes#51540Closes#51245
By placing the stdout in a CDATA block we avoid almost all escaping, as
there's only two byte sequences you can't sneak into a CDATA and you can
handle that with some only slightly regrettable CDATA-splitting. I've
done this in at least two other implementations of the junit xml format
over the years and it's always worked out. The only quirk new to this
(for me) is smuggling newlines as 
 to avoid literal newlines in the
output.
Fix `tests/run-make-translation` when download-rustc is enabled
When building locally, we never generate a `share` directory in the local sysroot. However, when we download the `rustc` component from ci, it includes a `share/man` directory in the sysroot. The `run-make/translation` test assumed that it didn't exist, and would create a link from `fakeroot` to the real share directory, and write symbolic links into it. Change it not to create the link, so that rustc doesn't try to load multiple copies of the same `.ftl` file.
Fixes https://github.com/rust-lang/rust/issues/110357.
When building locally, we never generate a `share` directory in the
local sysroot. However, when we download the `rustc` component from ci,
it includes a `share/man` directory in the sysroot. The
`run-make/translation` test assumed that it didn't exist, and would
create a link from `fakeroot` to the real share directory, and write
symbolic links into it. Change it not to create the link, so that rustc
doesn't try to load multiple copies of the same `.ftl` file.
Fix diff option conflict in UI test
Trivial fix for test case `tests/run-make/rustdoc-verify-output-files`,
it's failing on MacOS, the `-u` option specifies the unified context format, while the `-q` option specifies only brief output. These two options are incompatible, since the unified context format produces a more detailed output than the brief output format.
