search

Ericsson / clang

Cross Translation Unit analysis capability for Clang Static Analyzer. (Fork of official clang at http://llvm.org/git/clang)
http://clang.llvm.org/
Other
15 stars 10 forks source link

Create ODR handling strategies #597

Closed martong closed 4 years ago

martong commented 5 years ago

In case of ODR errors, it is not trivial what the client of the merged AST wants. The client may provide strategies via handleNameConflict. We identified 3 strategies so far: 1) Conservative. In case of name conflict propagate the error. 2) Liberal. In case of name conflict create a new node with the same name and do not propagate the error. 3) Rename. In case of name conflict create a new node with a different name (e.g. with a prefix of the TU's name). Do not propagate the error.

balazske commented 5 years ago

Should we separate "name conflict" from ODR error? This can be a problem at template specialization: A specialization is to be imported and with the same argument values there is an existing one. This is not a "name" conflict and can not be solved by simple rename. But it is an ODR error. Probably for the first time it is enough to handle the name conflict cases when a rename can solve the problem.

martong commented 5 years ago

Should we separate "name conflict" from ODR error? This can be a problem at template specialization: A specialization is to be imported and with the same argument values there is an existing one. This is not a "name" conflict and can not be solved by simple rename. But it is an ODR error. Probably for the first time it is enough to handle the name conflict cases when a rename can solve the problem.

This is a good question. A simple rename indeed could not solve it. But the liberal and conservative strategies should handle it without problem. When we really implement the renaming strategy then we will come out with a solution.

balazske commented 5 years ago

Probably yes but this must be tried out. This is an other type of case when not Decls with same name exist multiple times, instead a template specialization. For this case the function "handleNameConflict" is probably not sufficient (it makes no sense to return a new name), probably a new function can be used? The main question was now that the name "ODRHandling" is OK to use or "NameConflictHandling" is better, now it looks like that ODRHandling is good (if these template specializations are handled too).

martong commented 5 years ago

Strictly speaking, all name conflicts are ODR violations, aren't they? So maybe we should just have ODRHandling.

balazske commented 5 years ago

Maybe find better names instead of Conservative, Liberal? It can be DoNotAllowODRConflict (or Strict) and AllowODRConflict or other. (Rename is OK.)