As a followup to the previous AST changes, the next step is to generate
the proper expressions in Sema. This patch does so for +,*,&,|,^ by
modeling them as compound operators.
This also causes the legality of some expressions to change, as these
have to be legal operations, but were previously unchecked, so there are
some test changes.
This does not yet generate any CIR, that will happen in the next patch.
Better test coverage.
The round-tripping test makes sure that if we ever change
`llvm::dwarf::toDW_Lang` or `llvm::dwarf::toDW_LName`, we don't break
the `LanguageDescription` API.
The round-tripping test found an incorrect version check in
`llvm::dwarf::toDW_Lang`, which I corrected as part of this PR (see the
table at the bottom of https://dwarfstd.org/languages-v6.html for
reference).
Lately, I've been using 'getBaseOriginalType' in ArraySectionExpr
incorrectly: it gets the base-ist of element type, when in reality, I
want a single type of indirection. This patch corrects the handful of
uses that I had for it.
Depends on:
* https://github.com/llvm/llvm-project/pull/162050
Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite
clear what language the expression ran as. It may also reduce confusion
around why the expression evaluator ran an expression in a language it
wasn't asked to run (a softer alternative to what I attempted in
https://github.com/llvm/llvm-project/pull/156648).
Here are some example outputs:
```
# Without target
(lldb) expr blah
note: Falling back to default language. Ran expression as 'Objective C++'.
# Stopped in target
(lldb) expr blah
note: Ran expression as 'C++14'.
(lldb) expr -l objc -- blah
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.
(lldb) expr -l c -- blah
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.
(lldb) expr -l c++14 -- blah
note: Ran expression as 'C++14'
(lldb) expr -l c++20 -- blah
note: Ran expression as 'C++20'
(lldb) expr -l objective-c++ -- blah
note: Ran expression as 'Objective C++'
(lldb) expr -l D -- blah
note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'.
```
I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.
Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).
rdar://160297649
rdar://159669244
API tests in the `libc++` category will try their best to build against
a locally built libc++. If none exists, the `Makefile.rules` currently
fall back to using the system libc++.
The issue with falling back to the system libc++ is that we are now
potentially not testing what we intended to. But we also can't rely on
certain libc++ features being available that the tests are trying to
use. On Apple platforms this is a configuration error (because libc++ is
the only stdlib supported), but we can't make it an error on Linux
because a user might want to run the API tests with libstdc++.
The Ubunutu 22.04 bots on the Apple fork are failing to run following
tests are failing:
* `TestLibcxxInternalsRecognizer.py`
* `TestDataFormatterStdRangesRefView.py` because the system stdlib
doesn't have `std::ranges` support yet. And the tests just fail to
build. Building libc++ on those bots is also not possible because the
system compiler is too old (and the Apple fork builds all the
subprojects standalone, so it requires the system compiler).
This patch marks tests in the `libc++` category as `UNSUPPORTED` if no
local libc++ is available.
The downside is that we will inevitably lose coverage on bots that were
running these tests without a local libc++. Arguably those weren't
really testing the right thing. But for vendors with LLDB forks it might
have been useful to at least know that the tests on the fork don't fail
against the system libc++.
Confirmed that the libc++ pre-merge CI still runs these tests (since it
uses the explicit `--category libc++` dotest flag). Also confirmed that
LLDB pre-merge CI runs the tests (because it builds `libcxx` locally).
**Workaround**
If you do need want to run libc++ tests against the system stdlib, you
can invoke `lldb-dotest` with the `--category libc++` flag:
```
./path/to/build/lldb-dotest --category libc++
OR
./path/to/build/bin/llvm-lit -sv --param dotest-args='--category libc++' "/path/to/monorepo/lldb/test/API
```
rdar://136231390
This paper removes the constraint that a static variable or function
cannot be used within an extern inline function. The diagnostic is still
being produced in earlier language modes for conformance reasons but has
always been accepted as an extension.
The compiler can't defer the conversion of legacy DATA-style
/initializers/ in component declarations to their init() expressions to
the general DATA statement conversion pass, since default component
values must be present during structure constructor analysis. So move
their conversions into name resolution and handle them at the same times
as standard '=' initializers are processed. Avoid any potential problems
with type parameters being used as repetition counts or values by
disallowing legacy DATA-style initializers in PDTs.
Fixes https://github.com/llvm/llvm-project/issues/161989.
When processing the KIND= values of type specifications in parameterized
derived type component declarations, it turns out to be necessary to
analyze their expressions' parse trees rather than to just fold their
typed expression representations. The types of the subexpressions may
depend on the values of KIND parameters.
Further, when checking the values of KIND= actual arguments to type
conversion intrinsic functions (e.g., INT(..., KIND=)) that appear in
KIND specifiers for PDT component declarations, don't emit an error for
the derived type definition, but instead emit them for derived type
instantiations.
Fixes https://github.com/llvm/llvm-project/issues/161961.
Audit the use of std::optional<bool> as a tri-state logical value in
flang, correct a couple cases that need ".value_or()", add some explicit
".has_value()" calls, and document the possible pitfalls.
As a common language extension, this compiler accepts a structure
constructor whose first value has no keyword and whose type matches an
ancestral type as if the constructor had had a keyword whose name was
the ancestral type. For example, given
TYPE PARENT; REAL X; END TYPE
TYPE, EXTENDS(PARENT) :: CHILD; END TYPE
we accept the nonconforming constructor "child(parent(1.))" as if it had
been the conforming "child(1.)" or "child(parent=parent(1.))".
The detection of this case needs to be constrained a bit to avoid a
false positive misinterpretation of conforming code in the case where
the actual first component of the derived type is a POINTER or
ALLOCATABLE whose type and rank would allow it to correspond with the
keywordless first value in the component value list.
Fixes https://github.com/llvm/llvm-project/issues/161887.
Currently AFAICT we don't have a way to get the MCP server socket after
it started. So this change introduces a new `protocol-server` subcommand
that allows us to query the location of a running server:
```
(lldb) protocol-server start MCP listen://localhost:0
MCP server started with connection listeners: connection://[::1]:36051, connection://[127.0.0.1]:36051
(lldb) protocol-server get MCP
MCP server connection listeners: connection://[::1]:36051, connection://[127.0.0.1]:36051
(lldb) protocol-server stop MCP
(lldb) protocol-server get MCP
error: MCP server is not running
```
Making the choice more clear from the API name, otherwise it'd be very easy for one to just "not bother" with the `MDFrom`, especially since it is optional and follows the optional `Name` - but this time we'd have a harder time detecting it's effectivelly dropped metadata.
This PR adds some tests for covering some useful corner cases.
1. more tests for `vector.shape_cast` distribution.
2. testing for `MoveFuncBodyToWarpOp` pattern that was not possible
before.
#140210 added `#include "clang/Frontend/FrontendDiagnostic.h"` to
clang/lib/Sema/SemaAMDGPU.cpp, but Frontend itself has a dependency on
Sema. This creates a layering issue as described in
https://llvm.org/docs/CodingStandards.html#library-layering.
Fortunately, d076608d58 made this easy to
fix, as clang/Frontend/FrontendDiagnostic.h just forwards to
clang/Basic/DiagnosticFrontend.h, so it's trivial to make this depend on
basic instead of frontend.
This patch updates the FP-to-Int conversion handling:
- For signed integers: use `ftrunc` followed by clamping to the target
integer range.
- For unsigned integers: apply `fabs` + `ftrunc`, then clamp.
This removes the previous dependence on `nsz` and ensures correct
lowering for both signed and unsigned cases.
I've tested the code generation of -mtriple=amdgcn. It seems that the
assembly code is expected, but I'm not sure how to write a general
testcase for every target.
Fixes#160623.
ec28b95b74 made liblldb delayloaded, but
the supplied command line parameter is only valid for MSVC style builds.
For mingw builds using LLD, we can easily pass a similar option. For
mingw builds with ld.bfd, we can't quite as easily delayload it - for
these cases, just keep linking it like we usually do, and warn if the
user tried to set LLDB_PYTHON_DLL_RELATIVE_PATH in a build where it
won't have any effect.
Also change the setting for MSVC style builds, to use the simpler
`$<TARGET_FILE_NAME:liblldb>` instead of
`$<TARGET_FILE_BASE_NAME:liblldb>.dll`. The former pattern is what we
use for mingw targets, and it makes the code clearer to use that for
both, as that same expression should do the right thing for both.
Since 4feae05c6a, most of the handling of
warning options was rewritten to add such options based on hardcoded
knowledge about what compilers support which options, and since which
versions. This avoids a number of configure time checks, speeding up the
cmake configuration.
This avoids erroneously adding this option with GCC, which doesn't
really support it.
If testing for a warning option like -Wno-<foo> with GCC, GCC won't
print any diagnostic at all, leading to the options being accepted
incorrectly. However later, if compiling a file that actually prints
another warning, GCC will also print warnings about these -Wno-<foo>
options being unrecognized.
This avoids extra warning spam like this, for every source file that
does produce warnings with GCC:
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-pass-failed’ may have been intended to silence earlier diagnostics
This fixes building LLDB for mingw with libstdc++, after
8ae30a3fac.
Previously, building errored out with errors like these:
In file included from llvm-project/lldb/include/lldb/Protocol/MCP/Transport.h:12,
from llvm-project/lldb/include/lldb/Protocol/MCP/Server.h:16,
from llvm-project/lldb/source/Plugins/Protocol/MCP/ProtocolServerMCP.h:15,
from llvm-project/lldb/source/Plugins/Protocol/MCP/ProtocolServerMCP.cpp:9:
llvm-project/lldb/include/lldb/Host/JSONTransport.h:608:23: error: field ‘replied’ has incomplete type ‘std::atomic<bool>’
608 | std::atomic<bool> replied = {false};
| ^~~~~~~
In file included from gcc-mingw/x86_64-w64-mingw32/include/c++/12.1.0/bits/shared_ptr_atomic.h:33,
from gcc-mingw/x86_64-w64-mingw32/include/c++/12.1.0/memory:78,
from llvm-project/lldb/include/lldb/Host/Socket.h:12,
from llvm-project/lldb/include/lldb/Core/ProtocolServer.h:13,
from llvm-project/lldb/source/Plugins/Protocol/MCP/ProtocolServerMCP.h:12:
gcc-mingw/x86_64-w64-mingw32/include/c++/12.1.0/bits/atomic_base.h:162:12: note: declaration of ‘struct std::atomic<bool>’
162 | struct atomic;
| ^~~~~~
I did this when I converted it but never stated so. Adding a comment
stating so. We'll probably forget at some point but might as well.
Also moved the x packet to the last place, after wasm which was
added to the end recently.
The uArch infrastructure provides:
- A set data structures to represent, uArch and it's necessary
components (e.g., instructions, register-files, caches).
- A set of utility interfaces that are common to a family of ops (e.g.,
mma ops, 2DBlockIO ops). The implementation of these interfaces are
provided by the specific instructions. Each family of ops provides these
5 common APIs. However, some family of ops may have more utility APIs.
The common 5 APIs are:
- getSupportedShapes
- getSupportedTypes
- checkSupportedShapesAndTypes
- checkSupportedTypes
- validate
Add support for PVC and BMG architectures.
Add support for DPAS instruction.
DW_OP_LLVM_extract_bits_zext and DW_OP_LLVM_extract_bits_sext can end up
emitting "DW_OP_constu 0; DW_OP_shr" when given certain arguments.
However, a shift by zero is not useful, and so it can be omitted.
