-
Notifications
You must be signed in to change notification settings - Fork 10.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No custom C++11 attributes are parsed #57748
Comments
The C++ standard doesn't specify anything about diagnostic strength. What it does say in [dcl.attr]p6 (http://eel.is/c++draft/dcl.attr#grammar-6): For an attribute-token (including an attribute-scoped-token) not specified in this document, the behavior is implementation-defined. Any attribute-token that is not recognized by the implementation is ignored. "Ignored" doesn't mean "not diagnosed" (our implementation-defined behavior is to diagnose unknown attributes by default because of the potential for hard-to-debug problems stemming from vendor-specified attributes that we don't support).
Correct.
Yes, but it's a qualified yes. What we'd like to do is introduce a new That said, I'm not aware of anyone actively working on this. |
@llvm/issue-subscribers-clang-frontend |
I didn't mean no diagnosis but no error. From what I can see, most interpretations of the C ++ standard (and implementation) agree with this concept. Before C ++ 17, there was no ignore condition, making the whole thing dependent on the implementation (allowing you to throw a hard bug in any case, for example). Thank you very much for a comprehensive answer. From my point of view, the list of tokens would be sufficient (almost even the mere presence of the element in children along with the location in the code would be amazing).
Pity. It seems to me that this is not a good issue to get into a clang (PR) project on the other hand as I think about parsing that regex (not for the first time) I get seizures. While external parsing things in a "preamble" of type is okay for arguments etc. is monstrous. |
We don't diagnose as an error (unless you opt-in to doing that with
As far as the standard is concerned, the implementation is... everything. It's the compiler, the linker, and the standard library (everything needed to meet the requirements of the abstract machine). That said, I think it's quite reasonable for this to not be handled at the parsing level for
That's good to know, thanks! If we're storing actual
I think I agree that this isn't a good first issue for getting into Clang. But I also think it wouldn't be the hardest thing to support either. For example, an initial pass at this could ignore the problem with the attribute arguments by instead exposing the left paren and right paren location for the argument list. At least with that amount of information, an enterprising person can go back through the source manager to get the source text for the arguments (so you could still pretty print from the AST back to source, for example), but we've made a good step towards at least retaining the unknown attribute in the AST. |
I know. Maybe I didn't express myself clearly / I fell into digressions too much;)
Good point. I haven't thought of any attributes that might change the parsing context. My biggest disappointment was the complete absence of unknown attributes in the element's children's list. With this, perhaps without even a token list, just knowing the loops in the code, the use of attribute information is now within reach. |
That's my thinking as well. |
Hi.
The C ++ 17 standard specifies that attributes not defined in the compiler implementation will be ignored without error. I am using the C ++ 17 clang parser module to extract information (being strict, python bins but it doesn't matter now).
Clang ignores unfamiliar attributes at the stage of parsing the code.
This is quite a problem for my project, libclang is a great parser, and information about unfamiliar attributes (even as UNEXPOSED_ATTR) along with parsing their arguments would make it easier to use it as part of an advanced processor (something I do in my own project).
Is it possible to expose this information in clang lib and ignore it at another stage?
The text was updated successfully, but these errors were encountered: