Skip to content

Improve coverage test naming #32443

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

Merged
merged 1 commit into from
Jul 16, 2020

Conversation

keith
Copy link
Member

@keith keith commented Jun 17, 2020

@keith
Copy link
Member Author

keith commented Jun 17, 2020

cc @compnerd

// RUN: cd %t/foo/bar
// RUN: mkdir -p %t/root/nested
// RUN: echo "func coverage() {}" > %t/root/nested/coverage_relative_path.swift
// RUN: cd %t/root
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really we only needed 2 levels of nesting to validate we had the absolute path in the output in the first case

//
// ABSOLUTE: @__llvm_coverage_mapping = {{.*"\\01.*foo.*bar.*baz.*coverage_relative_path\.swift}}
// ABSOLUTE: @__llvm_coverage_mapping = {{.*"\\01.*root.*nested.*coverage_relative_path\.swift}}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this doesn't check for / vs \ in paths, we don't need to force the command line to only contain /

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it matter how the path is encoded? I suspect not, but, since I don't know definitively, I'll ask.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not as far as I know but I won't claim to be an expert here

Copy link
Member

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for cleaning this up.

@compnerd
Copy link
Member

@swift-ci please test

@keith
Copy link
Member Author

keith commented Jun 18, 2020

the windows failure here is from a diff test, known issue?

@keith
Copy link
Member Author

keith commented Jul 2, 2020

@compnerd Mind checking up on this one

@compnerd
Copy link
Member

@swift-ci please test Windows platform

@keith
Copy link
Member Author

keith commented Jul 15, 2020

windows failure looks unrelated 😬

@compnerd
Copy link
Member

The CI bots seem green, the build failure is:

 S:\jenkins\workspace\swift-PR-windows\lldb\source\Plugins\ExpressionParser\Swift\SwiftExpressionParser.cpp(1671,22): error: no matching function for call to 'performIRGeneration'
    auto GenModule = swift::performIRGeneration(
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~

CC: @JDevlieghere in case Jonas has ideas

@compnerd
Copy link
Member

@swift-ci please test

@JDevlieghere
Copy link
Contributor

The CI bots seem green, the build failure is:

 S:\jenkins\workspace\swift-PR-windows\lldb\source\Plugins\ExpressionParser\Swift\SwiftExpressionParser.cpp(1671,22): error: no matching function for call to 'performIRGeneration'
    auto GenModule = swift::performIRGeneration(
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~

CC: @JDevlieghere in case Jonas has ideas

I think this was a race between PR from @hamishknight and @varungandhi-apple backporting the explicit std::string conversion.

Copy link
Member

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the cleanup!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants