[clang][Parser] Improve error recovery for missing semicolons in class members. (#190744)
This is something I discovered when doing the investigation for
https://github.com/llvm/llvm-project/pull/188123#issuecomment-4162665482.
This patch improves recovery when a semicolon is missing after a class
member declarations.
When the parser expects a semicolon but encounters a token that is at
the start of a line and is a valid declaration specifier, it injects a
`;` instead of skipping tokens, this allows us to preserve the
declaration after the missing ";" instead of discarding it.
[clang] Fix crash in isAtEndOfMacroExpansion at FileID boundary. (#191734)
During error recovery, a synthetic token (whose length is 0) can be
inserted past the end of a FileID, e.g. inserting ")" when a macro-arg
containing a comma should be guarded by parentheses.
When calculating the location after this token, the calculated
`AfterLoc` can point exactly to the start of the next FileID
(`NextLocalOffset`), any source manager operations on the `AfterLoc` are
invalid.
This patch adds a safe guard in `Lexer::isAtEndOfMacroExpansion` to
prevent passing this invalid location to `SourceManager`.
Fixes #115007
Fixes #21755
acpi: Return "unknown D-state" in acpi_d_state_to_str() if unknown
Some ACPI debugging prints call acpi_d_state_to_str() on unset D-states
(i.e. ACPI_STATE_UNKNOWN), so return a string explicitly saying "unknown
D-state" instead of just panicking.
Fixes: 84bbfc32a3f4 ("acpi_powerres: D3cold support")
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
[clangd] Introduce --skip-preamble-build command line option (#189284)
This option allows to disable preamble optimization in clangd. By
default it's false, but became true for TUs which import modules (and
experimental modules support is enabled).
This PR is a try to address C++20 modules problems described here
https://github.com/llvm/llvm-project/pull/187432
Fixes https://github.com/llvm/llvm-project/issues/181770
[MC] Fix .prefalign oscillation when body contains a .p2align (#192402)
The intervening FT_Align's padding depends on where this prefalign
lands, so body_size can oscillate across relaxOnce iterations. When a
downstream section reacts (e.g. .debug_line DWARF deltas crossing a
special-opcode boundary), the outer loop never terminates -- originally
reported as a hang with -O1 -g on
https://github.com/llvm/llvm-project/pull/184032#issuecomment-4235991852
```
static int a;
void b() {}
int c() { for (;;) { int d; for (; a;) return 0; } }
void e() { for (;;) ; }
```
X86 sets both the preferred function alignment
and the loop-header alignment to 16 (X86ISelLowering
setPrefLoopAlignment),
[3 lines not shown]
[lldb] Add synthetic variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_synthetic_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include synthetic variables or not and leave comments explaining the decision.
As a consequence of producing synthetic variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no synthetic variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
[C++20] [Modules] Write comments in C++20 modules' module file (#192398)
Previously we avoid writing the comments in C++20 modules' module file.
But this prevents LSP tools to read the comments in it. Although we
thought to add a new option for it and ask LSP to use the new option,
the cost of comments seems to be low and new option raises complexity,
so I prefer to write comments in C++20 modules' module file by default
now.
