@@ -8001,6 +8001,12 @@ NamedDecl *Sema::ActOnVariableDeclarator(
}
}
+ if (getLangOpts().HLSL) {
+if (R->isHLSLSpecificType() && !NewVD->isImplicit()) {
+ Diag(D.getBeginLoc(), diag::err_hlsl_intangible_type_cannot_be_declared);
llvm-beanz wrot
@@ -8001,6 +8001,12 @@ NamedDecl *Sema::ActOnVariableDeclarator(
}
}
+ if (getLangOpts().HLSL) {
+if (R->isHLSLSpecificType() && !NewVD->isImplicit()) {
+ Diag(D.getBeginLoc(), diag::err_hlsl_intangible_type_cannot_be_declared);
llvm-beanz wrot
@@ -0,0 +1,33 @@
+//===-- HLSLIntangibleTypes.def - HLSL standard intangible types *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
@@ -12335,6 +12335,10 @@ def warn_hlsl_availability_unavailable :
Warning,
InGroup, DefaultError;
+def err_hlsl_intangible_type_cannot_be_declared : Error<
+"HLSL intangible type cannot be declared here">;
+def err_hlsl_intangible_type_as_function_arg_or_return : Error<
+"
@@ -3428,6 +3428,12 @@ void CXXNameMangler::mangleType(const BuiltinType *T) {
Out << 'u' << type_name.size() << type_name;
\
break;
#include "clang/Basic/AMDGPUTypes.def"
+#define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId)
@@ -8001,6 +8001,12 @@ NamedDecl *Sema::ActOnVariableDeclarator(
}
}
+ if (getLangOpts().HLSL) {
+if (R->isHLSLSpecificType() && !NewVD->isImplicit()) {
+ Diag(D.getBeginLoc(), diag::err_hlsl_intangible_type_cannot_be_declared);
llvm-beanz wrot
https://github.com/llvm-beanz commented:
Few comments, but mostly I really like this direction!
https://github.com/llvm/llvm-project/pull/97362
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/ll
https://github.com/llvm-beanz edited
https://github.com/llvm/llvm-project/pull/97362
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvm-beanz wrote:
> I don't know if the pre-commit testing guarantees that. Configuration
> settings will permit the files to be checked out in either Unix (`\n`) or
> Windows (`\r\n`) line-endings.
Today on Windows you basically have to check out LLVM as unix line endings.
There are a bunch
https://github.com/llvm-beanz approved this pull request.
I'm happy with this approach. We can adjust and iteratively address issues if
any appear.
https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits mailing list
lldb-commits@lists.llvm.o
llvm-beanz wrote:
> I'm a bit confused. Are you saying that as I've expressed it, `autocrlf=true`
> won't work correctly? I _think_ you're saying you're in favour of this patch
> _in principal_, but I need to fix the mixed line endings case?
Sorry for being unclear. I meant to express that I'm
llvm-beanz wrote:
> This ^ seems a bit problematic to me, though (where the contents of the repo
> isn't representative of the bits we want - but perhaps it's schrodinger's
> line endings & it doesn't matter if it's always checked out as crlf - though
> if we one day converted to another sourc
llvm-beanz wrote:
> I am not saying this isn't a problem at all, but how often has anyone done a
> one line change and caused a 50k diff, and submitted it without noticing?
Way more often than you would hope. I don't have numbers but if you search
through the git history for `crlf` or `dos2uni
llvm-beanz wrote:
Philosophically I agree with this change, but I think some subprojects may need
to adopt specific policies about how they handle files that are expected to be
specific line endings. Specifically, Clang needs testing that verifies correct
behavior on both CRLF and LF files in
14 matches
Mail list logo
