Adding #embed #810
Adding #embed #810
Conversation
|
yeah hooking the preprocessor that way is what is intended... im glad you are working on this, I've been thinking maybe you are right, and the language specifications for C23 and C++17 are low-hanging fruit that should be addressed sooner rather than later... i rewrote the VS projects last night so you might have to redo a little work... |
Moreso I'm interested in the hook between the preprocessor back to the declaration engine, since in order to make this fast we need to actually be able to insert the values into the declaration during compile, otherwise we're doing a lot of extra tokenization for little-to-no value. In terms of effort this amounts of a minor rewrite of the declaration engine in its entirety as far as I'm aware to deal with this fact. |
|
you wouldn't have to modify the entire declaration sequence, just the initialization aggregrator. I would be tempted to use some kind of trick, like when intialize finds a structure/array to initialize it saves the current symbol somewhere, then when #embed is encountered it calls some callback that fills in the data for the variable (and maybe sets its size if it is an array????) and finally when it is all done a 'special' token is put into the input stream which tells initialize_aggregate_type not to do any processing... that would also scale well if you have a structure where you want to use #embed for one part of the structure but want to fill in things in code for another part of it... but i guess there would have to be a check somewhere if you are initializing a structure or sized array that would that you don't overrun the end... |
My thoughts were that during the declaration/initialization sequence after the declarator is found we set the embed_function callback I made with the current information required from the lexer captured as part of it (since std::function can allow for that) for the declaration then continue during the initialization sequence we just append new bytes as needed, so that constructs such as: char thingy[] = {
0, 1, 2, 3,
#embed <file> limit(12) prefix(4, 5, 6) postfix(19, 20, 21)
, 22, 23, 24 // (note the first comma)
};Work correctly. I may not actually do this portion on this PR but I will definitely be thinking about it during it... |
|
that would work; you might further be able to further speed it up by making some class 'Embedded Data' which has an accessor to return the next byte of data... then make a new lexeme type that would take a pointer to that class as data. Then in expression_primary when you run into it you get the next byte of data and make an 'expression', 'type' pair for it which you return as normal. That way the rest of the code for parsing initializers remains completely unchanged. You wouldn't call getsym() until you ran out of data so it would keep processing the same lexeme token over and over until it was done... All that would get around having to build a ton of lexeme structures to reflecting the incoming data... |
There was a problem hiding this comment.
hi chuggafan! This is looking good. But the way the project is now organized, occparse.exe depends on ocpp.lib... so files in ocpp.lib don't need to be added in occparse.lib they will just automatically be propagated.
There was a problem hiding this comment.
it was a good catch, that 'embed' should only be available in the compiler. not the assembler. For your reference ocpplib could be used elsewhere though, for example it is used in the rc compiler. I think that will probably fit in with the rest of your design though.
There was a problem hiding this comment.
To be honest I forget about orc half the time simply because I've never used windows resources (I have, sadly used COM apis though)
|
@chuggafan, I finally read the docs for this, and I was thinking, we might have an extension that changes word size and endianness... that could be added later though. Anyway I'm mostly through with the C23 stuff although haven't pushed the latest yet... that leaves this as pretty much the only outstanding issue for C23. I was wondering what the status is? Will you have time to work at it sometime soon? I can work with you on the interface to the compiler if that is worrying you... |
|
I was working on the interface change, but between vacation + other things (and the fact that the change is just so large) I have been on a semi-pause, I have uploaded my current work so you can see what I'm doing, if you want me to pursue that method still instead of going after another in a bit, I'll continue working on it in the background, here's the current work, it doesn't compile at all (in fact just compiling for the preprocessor gives me 302 errors), but it still requires some extraneous work (e.g. substituting the static IsSymbolChar in main() for the proper one, giving PreProcessor a default (which will happen last), etc.) |
|
i took a quick look and what you are doing seems reasonable. But we are possibly going to have to update the compiler for those function-pointer-as-template argument things you've got going, I don't know what it will do with them. We aren't in any hurry on finishing up the 'embed' tag I guess, so you can keep going along these lines if you want. |
|
I'm currently not done with the work on this draft pr, as it's SIGNIFICANTLY ballooned in scope (the change from cpp files to .h files for a number of things including I am also debugging some random MS issues with my code that aren't exactly clear in their error reports, so I am also trying to diagnose that (what fun). In the meantime, this PR may die for quite some time and I might even switch to trying to send patches another way because github is requiring 2fa via some phone or secret app for my account, and because this account is tied with my "public" identity rather than my "private" (offline) identity I am not putting a phone number within lightyears of this account. So this may languish for quite some time if I am no longer able to do things such as make commits as of tomorrow. I will try to upload all of my current work tonight, however. |
|
my interpretation is if I didn't do the 2fa by the deadline, I would lose access to my github account going forward.... after the deadline there is no longer a way to log into the account if you don't have 2fa... so that was something to think about... i ended up using 1password for 2fa, as I could put it on my computer and it didn't bother the login process terribly, but that is something you buy. Don't know if the other alternative I was given was any better; at that point I didn't much care as I was very confused by the whole process anyway and just wanted it over with lol... I didn't care much if they had my phone number so I got the github app as a backup... hope to see you around going forward 😄 |
|
I've did the two factor with aegis 2fa, no private linking or mobile needed.
|
|
I'm not sure why one would need (or even use) a proprietary 2 factor application when not explicit needed. Aegis works really well on Android https://getaegis.app/ and if running Windows 11 you can also use it via the Windows Subsystem for Android. On Linux Waydroid works quite fine, too. So @chuggafan Are you still there? |
|
Apparently Github is doing a discord style "We will bother you once a week until you comply", which means I can continue to converse, which is nice. In other news: I have begun on namespacing the entirety of ocpp in order to help with one of the issues I pointed out in my most recent commit's infodump. |
|
how are things looking? |
|
I've been kind of held-up by other commitments at the moment but I've found
the parent issue function.
For __compressed_pair the issue seems to be that initialize_aggregate_type
is not passing in the current namespace... presumably somewhere the fact
that we're still in the std:: namespace at the callsite (because this is
the callsite namespace) got dumpstered by the lexer but I have absolutely
no idea why, perhaps it being inside of a class is the cause?
If you want to take a crack at it, go ahead, I won't stop you, I've been
moving slowly at this in all fairness.
If you want the erroring callstack, I have my breakpoint set at ccerr.cpp
436 for err == 232, and the relevant callstack is:
occparse.exe!Parser::GetOverloadedFunction(Parser::Type * * tp,
Parser::expr * * exp, Parser::sym * sp, Parser::CallSite * args,
Parser::Type * atp, int toErr, bool maybeConversion, int flags) Line 6404
C++
occparse.exe!Parser::callConstructor(Parser::Type * * tp, Parser::expr *
* exp, Parser::CallSite * params, bool checkcopy, Parser::expr * arrayElms,
bool top, bool maybeConversion, bool implicit, bool pointer, bool
usesInitList, bool isAssign, bool toErr) Line 3078 C++
occparse.exe!Parser::initialize_aggregate_type(Parser::LexList * lex,
Parser::sym * funcsp, Parser::sym * base, int offset, Parser::StorageClass
sc, Parser::Type * itype, std::list<Parser::Initializer
*,std::allocator<Parser::Initializer *>> * * init,
std::list<Parser::Initializer *,std::allocator<Parser::Initializer *>> * *
dest, bool arrayMember, int flags) Line 3215 C++
…On Tue, Aug 20, 2024 at 5:08 PM David Lindauer ***@***.***> wrote:
how are things looking?
—
Reply to this email directly, view it on GitHub
<#810 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADSPBTWYWH2SELPUW3GIB53ZSOV4JAVCNFSM6AAAAAAZZEIDAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJZG43DQOBQGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
yeah i get having to do other stuff, that is why things are going so dreadfully slowly for me too right now. so the way namespaces are supposed to work is, when you use something like std::map or std::pair which uses __compressed pair, instantiating the outer template should use PushTemplateNameSpace() and PopTemplateNameSpace() to switch to the namespace the template was defined in so that references to other things in that namespace can be picked up. Maybe there is a hole in that logic somewhere... maybe if you start by selecting something via using statement it is broken? I'm going to leave it for you for right now but if you get tired of looking at it feel free to write an issue and I'll get to it lol... |
|
I just realized:
At no point does the callSite have a namespace injected into it during an
initialize_aggregate_type call during this chain, I even put a breakpoint
on the two callConstructor calls (and compiled the failing file, to be
fair) funcparams has arguments, but not a namespace....
Huh....
Why this is the case, I have no idea, but at least my original suspicion is
replaced with a "huh, that's weird." now.
…On Wed, Aug 21, 2024 at 9:01 PM David Lindauer ***@***.***> wrote:
yeah i get having to do other stuff, that is why things are going so
dreadfully slowly for me too right now.
so the way namespaces are supposed to work is, when you use something like
std::map or std::pair which uses __compressed pair, instantiating the outer
template should use PushTemplateNameSpace() and PopTemplateNameSpace() to
switch to the namespace the template was defined in so that references to
other things in that namespace can be picked up. Maybe there is a hole in
that logic somewhere... maybe if you start by selecting something via using
statement it is broken? I'm going to leave it for you for right now but if
you get tired of looking at it feel free to write an issue and I'll get to
it lol...
—
Reply to this email directly, view it on GitHub
<#810 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADSPBTT7PYX2JUPLZGMRW33ZSUZ7XAVCNFSM6AAAAAAZZEIDAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBTGM3TANBSHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
the namespaces I mentioned above are associated with the function symbol... but while we are on the topic of arguments one of the things that is supposed to happen (in GetOverloadedFunction) is that the namespace associated with the argument is used as part of the lookup. so namespaces generally aren't a part of the callsite unless they are explicitly specified as part of the call... can't really put the namespace in the callsite without doing overload resolution as the same function signature may be found in multple namespaces.... One thing that may be happening (Im not sure it is as i don't remember the code well enough) is that if the argument type is a type defined in a class, it might not have an associated namespace as the namespace is associated with the class (or the outer class of a class tree). If I could verify the type of an argument was in the namespace I expect the function to be in that might be the issue... just a guess... |
Templatereduce.cpp change TemplateDeduceArgList to actually check if the nested type has any data before getting any values out of it. omake make it show where the command that failed is, should be made to be togglable and should ignore recursive make calls but I added it to track down where errors happen in massive parallel builds. ppEmbed needed some changes simply to get it to a stage where it only really complains about <variant> Compiler.h has added FALLTHROUGH because C++17 mandates warning about that, so deal with it.
|
@LADSoft well, I just took down your changes and they definitely
helped and even moved the next issue from being generic to being
more... interesting....
I think there's an error in the template -> actual code generation
scheme for variadic templates, as I'm now getting:
Error( 17) c:\ORANGEC\include\memory(3573): Multiple declaration
of 'std::forward_as_tuple<basic_string<char, char_traits<char>,
allocator<char>>&>(basic_string<char, char_traits<char>,
allocator<char>>&)'
note: c:\ORANGEC\include\memory(3571): Referenced in
instantiation of 'std::__shared_ptr_emplace<ErrorToken,
allocator<ErrorToken>>::__shared_ptr_emplace<basic_string<char,
char_traits<char>, allocator<char>>&>(allocator<ErrorToken>,
basic_string<char, char_traits<char>, allocator<char>>&)'
note: c:\ORANGEC\include\memory(4394): Referenced in
instantiation of 'std::make_shared<ErrorToken, basic_string<char,
char_traits<char>, allocator<char>>&>(basic_string<char,
char_traits<char>, allocator<char>>&)'
note: ..\ocpp\Token.h(228): Referenced in instantiation of
'Tokenizer<kw>::Next()'
note: DefFile.cpp(180): Referenced in instantiation of
'DefFile::NextToken()'
I'll try to take a look at that over the next week as a break from
"wow, I have to reparse the entire linux command line so that I can
break it into argvs, how wonderful" that is posix_spawn since I'm not
going to even try to deal with fork().
…On Sat, Aug 24, 2024 at 12:42 AM David Lindauer ***@***.***> wrote:
the namespaces I mentioned above are associated with the function symbol... but while we are on the topic of arguments one of the things that is supposed to happen (in GetOverloadedFunction) is that the namespace associated with the argument is used as part of the lookup. so namespaces generally aren't a part of the callsite unless they are explicitly specified as part of the call... can't really put the namespace in the callsite without doing overload resolution as the same function signature may be found in multple namespaces....
One thing that may be happening (Im not sure it is as i don't remember the code well enough) is that if the argument type is a type defined in a class, it might not have an associated namespace as the namespace is associated with the class (or the outer class of a class tree). If I could verify the type of an argument was in the namespace I expect the function to be in that might be the issue... just a guess...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
yeah i fixed a lot of different stuff, it has been slow going because some of it is making me refactor established areas of the compiler... I've already had to refactor the using (non-aliased) directive twice in the last few weeks to cope with new aspects of C++17.... it was getting tiresome toward the end... There are a couple of things left to do in terms of variants, the test program I grabbed from the web still won't compile. but I think mostly it is going to be a matter of bug fixes from here rather than dealing with new aspects of C++17... im going to be optimistic and hope I can get it done before this weekend :) |
|
@LADSoft it appears one of my crashes at the moment is caused by gen_expr
not actually being able to deal with templateselector_
I have *no idea* what your plans for gen_expr and templateselector_ are,
and it's causing MakeStubs.cpp on my latest push to completely break, it's
possible that it's also contributing to why I'm having <variant> issues if
I'd hazard to guess somehow, as it could be why gen_expr isn't reusing
exprs somehow, though I have no idea why that would be the case...
Either way, something to put to your attention in particular.
…On Mon, Sep 23, 2024 at 2:59 PM David Lindauer ***@***.***> wrote:
yeah i fixed a lot of different stuff, it has been slow going because some
of it is making me refactor established areas of the compiler... I've
already had to refactor the using (non-aliased) directive twice in the last
few weeks to cope with new aspects of C++17.... it was getting tiresome
toward the end...
There are a couple of things left to do in terms of variants, the test
program I grabbed from the web still won't compile. but I think mostly it
is going to be a matter of bug fixes from here rather than dealing with new
aspects of C++17... im going to be optimistic and hope I can get it done
before this weekend :)
—
Reply to this email directly, view it on GitHub
<#810 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADSPBTXUE3GLAJKQ3OCFNATZYBQHRAVCNFSM6AAAAAAZZEIDAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRZGEYTSNJRGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
yeah probably nodes with ExpressionNode::templateselector_ shouldn't make it that far down the pipeline. FWIW I have it in my plans that the next thing I'm going to do after I finally get my variant example to compile and run is review this branch and see if I can clean up any compiler bugs you are running into... |
|
Sorry im taking so long on the variant stuff, it is one thing after another.... i had to rework some more stuff and now I've got to do a small rewrite as to how 'auto' return types are done, because the way I did it didn't account for the fact you can chain auto-return function calls and it has to resolve to the innermost returned value sigh.... meanwhile i've needed to use my time for other things.... |
|
Nah, it's fine, I've barely been working on this as well, especially
since I've had my weekends vacuumed up entirely for the past few weeks
without any sort of reprieve.
I'm moreso working on the omake for linux changes right now and
figured out that I'm right about the environment paths, I just now
need to parse the command line as argvs... which is awesome, right?
Yhea....
…On Thu, Oct 3, 2024 at 3:36 PM David Lindauer ***@***.***> wrote:
Sorry im taking so long on the variant stuff, it is one thing after another.... i had to rework some more stuff and now I've got to do a small rewrite as to how 'auto' return types are done, because the way I did it didn't account for the fact you can chain auto-return function calls and it has to resolve to the innermost returned value sigh.... meanwhile i've needed to use my time for other things....
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
great that you are working on omake! I wasn't sure from what you were saying whether you knew or whether it would even be relevant to what you are doing... but in CmdSwitch.cpp (in the src\util directory) there is code to convert a c++ string into an argv/argc sequence then parse it using the normal mechanisms.... it is used to parse config files and environment variables that have command line options from what I remember. |
|
It happens to turn out that there's actually a way to parse a line into
argc/argv built into both windows AND linux, so I'm probably going to go
with that route since that will also do shell expansions for me, which I
have a distinct feeling is needed as some syntax allows calling weird local
variables after doing shell expansions... I won't be able to really work on
this all of next week sadly, but I can keep up through email/github and see
what is up.
https://www.man7.org/linux/man-pages/man3/wordexp.3.html this is the
documentation for the expansions, this shouldn't be too bad.
…On Fri, Oct 4, 2024 at 12:53 PM David Lindauer ***@***.***> wrote:
great that you are working on omake!
I wasn't sure from what you were saying whether you knew or whether it
would even be relevant to what you are doing... but in CmdSwitch.cpp (in
the src\util directory) there is code to convert a c++ string into an
argv/argc sequence then parse it using the normal mechanisms.... it is used
to parse config files and environment variables that have command line
options from what I remember.
—
Reply to this email directly, view it on GitHub
<#810 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADSPBTUIGFRKRTNBG4UKBZTZZ3BZPAVCNFSM6AAAAAAZZEIDAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJUGEYDSNBVHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
ok that sounds good. Whenever you get back to it, would you be open to putting that functionality into CmdSwitch.cpp so we have it in a common place? |
|
last weekend I fixed a bunch of bugs and did more rewrites; then I ran into a wall because the ellipse expansions are somewhat scatterbrained and need rework... I'm going to completely redesign that to make it work better.... see if i can get it done this weekend I guess.... |
|
Small update,
I took a look over the weeked at my weird issue with my forward_as_tuple
issue, I think I tracked down what the problem is, but I don't have an
immediate solution to this problem as I would need to sit down and stare at
code for quite some time to fix it.
The issue at heart is that during template instantiation of my shared_ptr
based Tokenizer::Next, something is going on where the function is
instantiated in my new variant of Next that I added when I templatized the
function (that stores a shared_ptr so I don't have to think about "how long
does this token live" if I need to parse something, a perfect use-case),
the matchOverload function in occparse fails to match two similar
declarations, but the AddOverload function notices that the two
declarations have the exact same decorated name. This indicates to me
either a problem in our overload matching solution or an issue with the
name decoration system. I'm inclined to believe the former is at fault and
not the latter, but I'm going to have to trudge through the entire overload
matching schema in C++17 to see what should be going on here.
…On Thu, Oct 10, 2024 at 12:55 PM David Lindauer ***@***.***> wrote:
last weekend I fixed a bunch of bugs and did more rewrites; then I ran
into a wall because the ellipse expansions are somewhat scatterbrained and
need rework... I'm going to completely redesign that to make it work
better.... see if i can get it done this weekend I guess....
—
Reply to this email directly, view it on GitHub
<#810 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADSPBTSHPUACZBJVTUJG3G3Z22WP7AVCNFSM6AAAAAAZZEIDAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBVGYYTIMZZG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
so i fixed some stuff back in october but apparently never pushed it, I pushed it now but forgot to see if it builds first sigh... so im building... BTW if you are in the US happy thanksgiving! |
|
Happy thanksgiving as well!
I've checked the build, but it doesn't seem to fix the issue at hand
for why stuff doesn't build (once I remove variant).
The change I made to the build here for the Tokenizer related to
shared_ptr is far more necessary than what I had originally
remembered, as I'm extending the lifetime of the token well past its
normal expiration date from ocpp so that I can feed all of them into
the processing stages in the compiler whenever I get around to adding
the functionality of preventing reparsing.
Anyways, the error dump actually got an extra message, and it's
indicating to me that the new template declaration code most likely
causes the system to assume that the tuple has something being default
constructed, I'd need to sit down and read this error message for a
good hour, but the first error message is the exact same error message
we had before, just a new static assert has come along with it:
Error( 17) c:\ORANGEC\include\memory(3573): Multiple declaration
of 'std::forward_as_tuple<basic_string<char, char_traits<char>,
allocator<char>>&>(basic_string<char, char_traits<char>,
allocator<char>>&)'
note: c:\ORANGEC\include\memory(3571): Referenced in
instantiation of 'std::__shared_ptr_emplace<ErrorToken,
allocator<ErrorToken>>::__shared_ptr_emplace<basic_string<char,
char_traits<char>, allocator<char>>&>(allocator<ErrorToken>,
basic_string<char, char_traits<char>, allocator<char>>&)'
note: c:\ORANGEC\include\memory(4394): Referenced in
instantiation of 'std::make_shared<ErrorToken, basic_string<char,
char_traits<char>, allocator<char>>&>(basic_string<char,
char_traits<char>, allocator<char>>&)'
Error(510) c:\ORANGEC\include\tuple(199): static_assert generated:
Attempted to default construct a reference element in a tuple
note: c:\ORANGEC\include\tuple(383): Referenced in
instantiation of 'std::__tuple_impl<__tuple_indices<...unsigned int=0,
unsigned int=1>, basic_string<char, char_traits<char>,
allocator<char>>&, unordered_map<basic_string<char, char_traits<char>,
allocator<char>>, kw, hash<basic_string<char, char_traits<char>,
allocator<char>>>, equal_to<basic_string<char, char_traits<char>,
allocator<char>>>, allocator<pair< const basic_string<char,
char_traits<char>, allocator<char>>, kw>>>*&>::__tuple_impl<...,
unsigned int=0, basic_string<char, char_traits<char>,
allocator<char>>&, unordered_map<basic_string<char, char_traits<char>,
allocator<char>>, kw, hash<basic_string<char, char_traits<char>,
allocator<char>>>, equal_to<basic_string<char, char_traits<char>,
allocator<char>>>, allocator<pair< const basic_string<char,
char_traits<char>, allocator<char>>, kw>>>*&, ..., unsigned int=1,
unordered_map<basic_string<char, char_traits<char>, allocator<char>>,
kw, hash<basic_string<char, char_traits<char>, allocator<char>>>,
equal_to<basic_string<char, char_traits<char>, allocator<char>>>,
allocator<pair< const basic_string<char, char_traits<char>,
allocator<char>>, kw>>>*&, basic_string<char, char_traits<char>,
allocator<char>>&>(__tuple_indices<...unsigned int=0>,
__tuple_types<basic_string<char, char_traits<char>, allocator<char>>&,
unordered_map<basic_string<char, char_traits<char>, allocator<char>>,
kw, hash<basic_string<char, char_traits<char>, allocator<char>>>,
equal_to<basic_string<char, char_traits<char>, allocator<char>>>,
allocator<pair< const basic_string<char, char_traits<char>,
allocator<char>>, kw>>>*&>, __tuple_indices<...unsigned int=1>,
__tuple_types<unordered_map<basic_string<char, char_traits<char>,
allocator<char>>, kw, hash<basic_string<char, char_traits<char>,
allocator<char>>>, equal_to<basic_string<char, char_traits<char>,
allocator<char>>>, allocator<pair< const basic_string<char,
char_traits<char>, allocator<char>>, kw>>>*&>, basic_string<char,
char_traits<char>, allocator<char>>&)'
note: c:\ORANGEC\include\tuple(816): Referenced in
instantiation of 'std::tuple<basic_string<char, char_traits<char>,
allocator<char>>&, unordered_map<basic_string<char, char_traits<char>,
allocator<char>>, kw, hash<basic_string<char, char_traits<char>,
allocator<char>>>, equal_to<basic_string<char, char_traits<char>,
allocator<char>>>, allocator<pair< const basic_string<char,
char_traits<char>, allocator<char>>,
kw>>>*&>::tuple<basic_string<char, char_traits<char>,
allocator<char>>&, bool=0>(basic_string<char, char_traits<char>,
allocator<char>>&)'
note: c:\ORANGEC\include\tuple(1146): Referenced in
instantiation of 'std::forward_as_tuple<basic_string<char,
char_traits<char>, allocator<char>>&>(basic_string<char,
char_traits<char>, allocator<char>>&)'
note: c:\ORANGEC\include\memory(3571): Referenced in
instantiation of 'std::__shared_ptr_emplace<ErrorToken,
allocator<ErrorToken>>::__shared_ptr_emplace<basic_string<char,
char_traits<char>, allocator<char>>&>(allocator<ErrorToken>,
basic_string<char, char_traits<char>, allocator<char>>&)'
note: c:\ORANGEC\include\memory(4394): Referenced in
instantiation of 'std::make_shared<ErrorToken, basic_string<char,
char_traits<char>, allocator<char>>&>(basic_string<char,
char_traits<char>, allocator<char>>&)'
2 Errors
…On Tue, Nov 26, 2024 at 5:45 PM David Lindauer ***@***.***> wrote:
so i fixed some stuff back in october but apparently never pushed it, I pushed it now but forgot to see if it builds first sigh... so im building...
BTW if you are in the US happy thanksgiving!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This does NOT include features such as the prefix and postfix or limit, which are needed for standards compliance.
This draft PR is KNOWN to not build, half of this PR's purpose is allowing me to show a proposal for the design of the internal hook mechanism of the compiler so that we're not wasting cycles making the compiler recompute known values.
The other half is that it seems like the compiler chokes on #809 and this needs to be investigated separately, for the immediate future it seems like I can just do a boolean check instead of comparing against nullptr.
Furthermore, I added a commit that temporarily alleviate #809 (
30673702e59b78222fef71d4986d2bdab260cf44) however that has a different access violation with a nullptr'dstd::list.It's been awhile so I will try debugging these but I'm dropping this here as I have no idea the source for the latter and the former should 100% be fixed, I don't know what I did with this file but it just breaks things.