On Tue, 27 Nov 2018, Richard Stallman wrote: > > Furthermore, you have unnamed entities - for example, in GCC machine > > descriptions, unnamed define_split constructs. > > If there is no way to name these entities, then what do hand-written > GCC change log entries say about them? Can the script do as well as that?
They use descriptions like (unnamed splitter) or (unnamed conditional branch define_insn). > > Furthermore, as I noted in January, there are cases in glibc where, while > > there is arguably a name, it's not a very helpful one - in makefiles, it > > can be something like > > > $(addprefix $(objpfx),$(filter-out $(tests-static) > $(libm-vec-tests),$(tests))) > > How have we historically described changes in such entities > in change log files? By using such names (which are more like code fragments than actual names), wrapped over multiple lines in the ChangeLog file as needed. > The cases I want this script to fix are those where entities have > meaningful names, and the git commands are sloppy about identifying > which entities are affected by the change. When the command is "git diff" (or "git show" or something else showing diffs), there is the issue discussed before that the name on the diff hunk header comes from the last funcname line before that diff hunk - so it doesn't correctly name the entity changed in the (common) case where the funcname line is within the diff context. (Which is only an issue for automated tools, not for a human looking at the diff because they can see the funcname line within the diff context in that case.) It's easy for the script to avoid that particular issue. When the command is "git blame", no such issue arises because the human has already identified what function they want to look at, and the git blame output reliably shows the last commit to change each line in that function (but that doesn't help if some relevant change only removed lines from the function without changing any lines that remained after the change). When the command is "git log -L", ultimately it's for the user deciding what argument to pass to -L to define the entity involved. The :<funcname> form is reliable when GNU-formatted C functions and file-scope variables are involved (even when the function name is generated by a macro, if the <funcname> you use is text that literally appears in the source file on the funcname line); when macro definitions are involved, the form with regular expressions can be used -- Joseph S. Myers [email protected]
