Files
rust/tests/ui
bors bcfea1f8d2 Auto merge of #133194 - khuey:master, r=jieyouxu
Drop debug info instead of panicking if we exceed LLVM's capability to represent it

Recapping a bit of history here:

In #128861 I made debug info correctly represent parameters to inline functions by removing a fake lexical block that had been inserted to suppress LLVM assertions and by deduplicating those parameters.

LLVM, however, expects to see a single parameter _with distinct locations_, particularly distinct inlinedAt values on the DILocations. This generally worked because no matter how deep the chain of inlines it takes two different call sites in the original function to result in the same function being present multiple times, and a function call requires a non-zero number of characters, but macros threw a wrench in that in #131944. At the time I thought the issue there was limited to proc-macros, where an arbitrary amount of code can be generated at a single point in the source text.

In #132613 I added discriminators to DILocations that would otherwise be the same to repair #131944[^1]. This works, but LLVM's capacity for discriminators is not infinite (LLVM actually only allocates 12 bits for this internally). At the time I thought it would be very rare for anyone to hit the limit, but #132900 proved me wrong. In the relatively-minimized test case it also became clear to me that the issue affects regular macros too, because the call to the inlined function will (without collapse_debuginfo on the macro) be attributed to the (repeated, if the macro is used more than once) textual callsite in the macro definition.

This PR fixes the panic by dropping debug info when we exceed LLVM's maximum discriminator value. There's also a preceding commit for a related but distinct issue: macros that use collapse_debuginfo should in fact have their inlinedAts collapsed to the macro callsite and thus not need discriminators at all (and not panic/warn accordingly when the discriminator limit is exhausted).

Fixes #132900

r? `@jieyouxu`

[^1]: Editor's note: `fix` is a magic keyword in PR description that apparently will close the linked issue (it's closed already in this case, but still).
2024-11-20 02:10:50 +00:00
..
2024-10-28 14:20:28 +11:00
2024-11-10 17:43:46 +09:00
2024-07-18 00:00:04 +00:00
2024-04-21 15:43:43 -03:00
2024-11-05 21:54:45 +00:00
2024-08-10 12:07:17 +02:00
2024-11-03 18:59:31 +00:00
2024-09-20 01:20:10 +03:00
2024-09-05 06:37:38 -04:00
2024-11-13 22:35:39 +02:00
2024-11-17 21:49:10 +01:00
2024-10-30 16:47:47 -07:00
2024-11-16 20:03:31 +00:00
2024-10-30 16:47:47 -07:00
2024-09-20 10:02:14 -07:00
2024-04-29 14:53:38 +02:00
2024-11-12 13:28:05 +00:00
2024-11-16 20:03:31 +00:00
2024-10-24 04:33:14 +08:00
2024-10-28 14:20:28 +11:00
2024-11-04 12:06:19 +01:00
2024-08-18 19:46:53 +02:00
2024-05-28 12:31:12 +02:00
2024-09-27 14:40:38 +01:00
2024-11-02 21:29:59 +01:00
2024-10-22 12:55:16 +00:00
2024-08-03 07:57:31 -04:00
2024-10-12 13:01:36 +02:00
2024-10-11 11:30:08 -04:00
2024-10-30 10:48:08 +00:00
2024-11-07 18:18:34 -08:00
2024-11-02 03:08:04 +00:00
2024-11-15 16:37:18 +01:00
2024-11-17 22:15:54 +00:00
2024-10-28 14:12:17 +08:00
2024-11-07 20:56:36 +00:00
2024-11-16 20:03:31 +00:00
2024-10-28 14:20:28 +11:00
2024-10-28 14:20:28 +11:00
2024-06-25 18:06:22 +02:00
2024-10-30 16:47:47 -07:00

UI Tests

This folder contains rustc's UI tests.

Test Directives (Headers)

Typically, a UI test will have some test directives / headers which are special comments that tell compiletest how to build and intepret a test.

As part of an on-going effort to rewrite compiletest (see https://github.com/rust-lang/compiler-team/issues/536), a major change proposal to change legacy compiletest-style headers // <directive> to ui_test-style headers //@ <directive> was accepted (see https://github.com/rust-lang/compiler-team/issues/512.

An example directive is ignore-test. In legacy compiletest style, the header would be written as

// ignore-test

but in ui_test style, the header would be written as

//@ ignore-test

compiletest is changed to accept only //@ directives for UI tests (currently), and will reject and report an error if it encounters any comments // <content> that may be parsed as an legacy compiletest-style test header. To fix this, you should migrate to the ui_test-style header //@ <content>.