[lld] r280947 - Handle globs in global symbol names.

[Sean Silva via llvm-commits]

On Thu, Sep 8, 2016 at 3:59 PM, Rui Ueyama <ruiu at google.com> wrote:

> I was wrong -- the current implementation correctly handles "*" as "zero
> ore more", so there's no bug.
>

Do we test that? I don't see any corresponding test case in wildcards.s.

-- Sean Silva


>
> On Thu, Sep 8, 2016 at 12:46 PM, Sean Silva via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> Oh, sorry, I wasn't aware that we were testing the generic infrastructure
>> elsewhere (it seems like wildcards.s? Sorry, it is a bit hard to grep for).
>> I guess I'm confused, because we have version-script-complex-wildcards.s
>> and version-script-extern-wildcards.s that seem to be trying to test
>> different globbing cases too. Are those also covered by other tests?
>> Neither of those seems to test that `*` matches zero or multiple characters
>> though.
>>
>> It seems like an organization like the following might be useful:
>> - version-script-extern.s: checks that we match against the demangled
>> name for extern "C++"
>> - version-script-glob.s: checks all supported matching constructs (or is
>> just a basic sanity check with a comment pointing to a file with more
>> thorough generic pattern matching tests)
>>
>> -- Sean Silva
>>
>> On Thu, Sep 8, 2016 at 12:28 PM, Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> On 8 September 2016 at 15:04, Sean Silva <chisophugis at gmail.com> wrote:
>>> > The glob `*` can match zero, one, or many characters. Can you make
>>> sure that
>>> > the test covers those cases?
>>> >
>>> > Currently this test only verifies that it matches a single character,
>>> and
>>> > the test would pass if we treated `foo*` as `foo?`.
>>>
>>> True, but the patch used the existing matching infrastructure that is
>>> tested elsewhere. Do you thing expanding the test would add much
>>> value?
>>>
>>> Cheers,
>>> Rafael
>>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160908/206a431b/attachment.html>