You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it legal to send a block of responses that is shorter than the block of requests provided the last response is ERROR? This line from the documentation would suggest that it's not:
The compiler sends a block of one or more requests to the builder, then waits for a block of responses to all of those requests.
On the other hand, it's not always clear what sensible thing a mapper could respond with to the subsequent requests (other than maybe duplicating the same ERROR for all of them). Perhaps this should be relaxed to allow an incomplete response block provided the last one is an ERROR? If that causes an undue complexity, then we could further restrict this case by requiring that such an ERROR be the last response (i.e., followed by EOF).
The text was updated successfully, but these errors were encountered:
Yeah, I've kind of left that underspecified. It wasn't clear what the best behaviour would be. I'm not quite sure what the GCC behaviour is.
It does seem reasonable that a truncated block of responses could be sent, once an ERROR response is to be sent, and it does seem reasonable that that causes a disconnection.
It does seem reasonable that a truncated block of responses could be sent, once an ERROR response is to be sent, and it does seem reasonable that that causes a disconnection.
Ok, I will proceed with this semantics then. Specifically, in certain cases I reply with ERROR, truncate the block (so this ERROR is the last response) and close both ends of the pipe.
I'm not quite sure what the GCC behaviour is.
I've tried to reply ERROR to HELLO (which is batched with the MODULE-REPO request), truncate the block and close the pipe. Here is the transcript:
g++-m -std=c++2a -fmodules-ts -fmodule-mapper=<> -x c++ -E -fdirectives-only -o hello.o.ii hello.cxx
> HELLO 1 GCC '' ;
MODULE-REPO
< ERROR 'malformed request HELLO'
hello.cxx: error: failed mapper handshake malformed request HELLO
hello.cxx:3:10: error: cannot determine ‘#include’ translation of /home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/cassert: communication error:Unknown error -1
[... the same error for each include ...]
So while it seems to be ok with the truncated block, it doesn't seem to handle the closed pipe well. Perhaps an error response and closed communication should be interpreted as a fatal error?
Is it legal to send a block of responses that is shorter than the block of requests provided the last response is
ERROR
? This line from the documentation would suggest that it's not:On the other hand, it's not always clear what sensible thing a mapper could respond with to the subsequent requests (other than maybe duplicating the same
ERROR
for all of them). Perhaps this should be relaxed to allow an incomplete response block provided the last one is anERROR
? If that causes an undue complexity, then we could further restrict this case by requiring that such anERROR
be the last response (i.e., followed by EOF).The text was updated successfully, but these errors were encountered: