Skip to content
This repository has been archived by the owner on Aug 2, 2020. It is now read-only.

Added support for testsuite #602

Merged
merged 12 commits into from
Jun 13, 2018
Merged

Added support for testsuite #602

merged 12 commits into from
Jun 13, 2018

Conversation

chitrak7
Copy link
Contributor

@chitrak7 chitrak7 commented May 13, 2018

@snowleopard @angerman
Validation result after this push:
SUMMARY for test run started at Mon May 14 00:32:42 2018 IST
0:20:37 spent to go through
6359 total tests, which gave rise to
23523 test cases, of which
17231 were skipped

  42 had missing libraries
6098 expected passes
  94 expected failures

   0 caused framework failures
   0 caused framework warnings
   1 unexpected passes
  55 unexpected failures
   2 unexpected stat failures

f :: Stage -> Package -> Action FilePath
f stage pkg | isLibrary pkg = pkgConfFile (Context stage pkg (read "v"))
| otherwise = programPath =<< programContext stage pkg

needTestBuilders :: Action ()
needTestBuilders = do
needBuilder $ Ghc CompileHs Stage2
needBuilder $ GhcPkg Update Stage1
needBuilder Hp2Ps
Copy link
Owner

Choose a reason for hiding this comment

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

Hp2Ps is already included into testsuitePackages, so I guess we can drop this line?

check_ppr <- f checkPpr
check_api_annotations <- f checkApiAnnotations
return ["TEST_HC=" ++ test_hc, "CHECK_PPR=" ++ check_ppr, "CHECK_API_ANNOTATIONS=" ++ check_api_annotations]
where
Copy link
Owner

Choose a reason for hiding this comment

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

Let's rename f to something more informative, perhaps, fullPath.

Copy link
Owner

Choose a reason for hiding this comment

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

Also, a type signature might help.

need targets
where
f :: Stage -> Package -> Action FilePath
f stage pkg | isLibrary pkg = pkgConfFile (Context stage pkg (read "v"))
Copy link
Owner

Choose a reason for hiding this comment

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

I think you need vanillaContext here.

Copy link
Owner

Choose a reason for hiding this comment

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

Btw, are there testsuite-only libraries? If yes, are you sure vanilla is sufficient for the testsuite?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This bit of code is taken directly from Rules.hs.
There are many errors coming from rts library (40). Although I still couldn't figure out from where errors are coming, I have added this part just in case.

targets <- mapM (f Stage1) =<< testsuitePackages
need targets
where
f :: Stage -> Package -> Action FilePath
Copy link
Owner

Choose a reason for hiding this comment

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

Please choose a more informative name instead of f.

@@ -63,13 +64,24 @@ testRules = do
-- Execute the test target.
buildWithCmdOptions env $ target (vanillaContext Stage2 compiler) RunTest [] []

-- | Build extra programs required by testsuite
Copy link
Owner

Choose a reason for hiding this comment

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

The code below suggests that there are not only testsuite programs, but also testsuite libraries.

Copy link
Owner

Choose a reason for hiding this comment

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

@chitrak7 So, do you really need to handle libraries here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have to handle rts library. I just cannot yet figure out how.

Copy link
Owner

Choose a reason for hiding this comment

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

Why do you need to handle rts here? How is it related to the testsuite?

Copy link
Owner

@snowleopard snowleopard Jun 12, 2018

Choose a reason for hiding this comment

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

I still don't understand why needTestsuiteBuilders needs libraries. Can testsuitePackages contain library packages? Right now there are only contain programs. If testsuitePackages can contain libraries, then you need to rename this function to something like needTestsuitePackages (instead of Builders).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some files are missing in rts library causing multiple failures. At the moment, I cannot figure out which files are missing. Or they may be missing includes. I have to look into this matter further.

Copy link
Owner

Choose a reason for hiding this comment

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

I don't understand how rts relates to this question. You don't have rts in testsuitePackages.

The comment for this function says "Build extra programs required by testsuite", but the implementation can also build libraries. This is an inconsistency that should be fixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay! I think I should create an issue regarding this and temporarily install required programs only.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Resolved

@snowleopard
Copy link
Owner

@chitrak7 Thanks! I've added some comments.

@alpmestan
Copy link
Collaborator

@chitrak7 Do you have any idea at this point of why we're still skipping so many tests? (this is not a comment/request on the actual patch, I'm just curious and this still feels like the best place to ask)

src/GHC.hs Outdated
hsc2hs, hp2ps, hpc, hpcBin, integerGmp, integerSimple, iservBin, libffi,
mtl, parsec, parallel, pretty, primitive, process, rts, runGhc, stm,
templateHaskell, terminfo, text, time, touchy, transformers, unlit, unix,
win32, xhtml, ghcPackages, isGhcPackage, defaultPackages, testsuitePackages,
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: this diff looks unnecessarily big

Copy link
Owner

Choose a reason for hiding this comment

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

@izgzhen At the moment this is unavoidable. We might refactor this to one package per line at some point if such large diffs look distracting, but it would be better to do it in a separate PR.

@chitrak7
Copy link
Contributor Author

@alpmestan I do not exactly know that, Can you give me pointers on where to look. More importantly, why does testsuite decide to skip a test.

@chitrak7
Copy link
Contributor Author

@snowleopard Can you please see why recursive rule failure is coming?

@alpmestan
Copy link
Collaborator

@alpmestan I do not exactly know that, Can you give me pointers on where to look. More importantly, why does testsuite decide to skip a test.

You should see some information about this in the testsuite driver initialization part of the output (early on, when you look at the full log).

@chitrak7
Copy link
Contributor Author

@alpmestan I believe skipped tests are because of using "fast" option with testsuite.

@alpmestan
Copy link
Collaborator

@chitrak7 OK. If you ever get a chance to, it would be terrific to add a way to run the equivalent of ./validate --slow. If not, I'll do it. But not in this PR of course. Thanks for the reply and taking a look at what was going on 👍

@snowleopard
Copy link
Owner

@chitrak7 Please resolve merge conflicts.

@snowleopard
Copy link
Owner

Can you please see why recursive rule failure is coming?

@chitrak7 The recursive rule failure is unrelated to your PR. I think the reason is #599.

@snowleopard
Copy link
Owner

@chitrak7 Something is wrong, looks like you've duplicated the recent commits instead of rebasing.

@chitrak7
Copy link
Contributor Author

@snowleopard I have reset my repository and made necessary changes. It is currently failing due to "llvm" issue. I will resend it once that PR Lands.

@sighingnow
Copy link
Contributor

Should the title of this PR be "Add support for nofib testsuite" ? We already support hadrian test.

@alpmestan
Copy link
Collaborator

No, support for nofib was the goal of #599, not this PR. This PR is about supporting the execution of more tests, and about building things that are required by some of them which were not built previously. It still skips a whole bunch of tests but maybe @chitrak7 could provide an overview of the state of things with/without the commits from his branch? In terms of # of tests being run, # of broken test expectations.

@sighingnow
Copy link
Contributor

I just noticed that this PR also add a new file src/Rules/Nofib.hs...

@alpmestan
Copy link
Collaborator

Right, my commits somehow did not get merged properly apparently. But you cann tell they've already been merged because they refer to the PR number.

@chitrak7 chitrak7 force-pushed the master branch 2 times, most recently from 4a04db1 to b439d95 Compare June 4, 2018 18:53
@chitrak7
Copy link
Contributor Author

chitrak7 commented Jun 4, 2018

Hi @snowleopard @angerman, I have pushed the work done with validation implementation.

@snowleopard
Copy link
Owner

@chitrak7 Thanks! Let's come back to this PR once we fix Hadrian.

@@ -481,3 +484,6 @@ renderUnicorn ls =
ponyPadding = " "
boxLines :: [String]
boxLines = ["", "", ""] ++ (lines . renderBox $ ls)

data TestSpeed = Slow | Average | Fast deriving (Show, Eq)
Copy link
Owner

Choose a reason for hiding this comment

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

I'm not sure TestSpeed is a generally useful data type. It's certainly useful for the GHC build system, but other build systems may have different settings or may not even need a testsuite (remember, Hadrian.* namespace is for generic functionality that may be useful not only for building GHC).

I suggest to move TestSpeed to the CommandLine module.

compiler <- expr $ fullpath ghc
checkPpr <- expr $ fullpath checkPpr
checkApiAnnotations <- expr $ fullpath checkApiAnnotations
let t = show $ max 4 (threads - 2)
Copy link
Owner

Choose a reason for hiding this comment

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

Since the validation script will likely be the only running thread, we do not need to reduce parallelism like we do with other Make invocations. I suggest we use the threads settings as is.


readTestWays :: Maybe String -> Either String (CommandLineArgs -> CommandLineArgs)
readTestWays ways =
Copy link
Owner

Choose a reason for hiding this comment

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

I don't understand, does this argument correspond to (multiple) ways or to a single way? Looking below, you expect to see a single way in Just. Shall this be renamed? If you worry about the clash of names, you can use maybeWay here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Every argument takes a single way. Multiple ways can be specified by this taking one way at a time.
eg: --test-way=way1 --test-way=way2

Copy link
Owner

Choose a reason for hiding this comment

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

Then this function should be renamed to readTestWay, since it reads a single way.

, Option [] ["test-verbose"] (OptArg readTestVerbose "TEST_VERBOSE")
"A verbosity value between 0 and 5. 0 is silent, 4 and higher activates extra output."
, Option [] ["test-way"] (OptArg readTestWays "TEST_WAY")
"only run these ways" ]
Copy link
Owner

Choose a reason for hiding this comment

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

We need to document all these flags. You don't need to do this right in this PR, but at least please create an issue so that we don't forget about this.

, testJUnit :: Maybe FilePath
, testConfigs :: [String] }
, testThreads :: Maybe String
, testVerbosity:: Maybe String
Copy link
Contributor

Choose a reason for hiding this comment

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

Hadrian (or Shake) already has -jN option, which is enough to control the speed of running testsuite. We don't need the testThreads here.

Copy link
Owner

Choose a reason for hiding this comment

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

@sighingnow Indeed! Well spotted.

@@ -30,7 +30,7 @@ module Hadrian.Utilities (
(<&>), (%%>), cmdLineLengthLimit,

-- * Useful re-exports
Dynamic, fromDynamic, toDyn, TypeRep, typeOf
Dynamic, fromDynamic, toDyn, TypeRep, typeOf,
Copy link
Owner

Choose a reason for hiding this comment

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

Drop the comma

compiler <- expr $ fullpath ghc
checkPpr <- expr $ fullpath checkPpr
checkApiAnnotations <- expr $ fullpath checkApiAnnotations
return [ "fast"
Copy link
Owner

Choose a reason for hiding this comment

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

Is the "fast" above related to TestSpeed.Fast?

Copy link
Contributor Author

@chitrak7 chitrak7 Jun 12, 2018

Choose a reason for hiding this comment

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

No, this is the default validate argument. Speed can be specified by running ./build.sh test and not validate.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Worst case, we can later arrange to support --slow and --fast flags, like the actual validate script, can't we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah. I can do that right now.

Copy link
Owner

Choose a reason for hiding this comment

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

OK, I guess we can leave this for later.

@snowleopard
Copy link
Owner

OK, I think we can merge this -- there are a few minor issues but we can fix them later.

@alpmestan Do you have any further comments?

@alpmestan
Copy link
Collaborator

No, let's merge 👍

, testSummary :: Maybe FilePath
, testJUnit :: Maybe FilePath
, testConfigs :: [String] }
, testVerbosity:: Maybe String
Copy link
Contributor

Choose a reason for hiding this comment

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

Shake already provides a --verbose option, let's reuse it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The verbose option of Shake is boolean, whereas test suite supports 5 levels of verbosity. This is why I chose to pass a separate verbose argument.

Copy link
Owner

Choose a reason for hiding this comment

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

I think that it may be convenient to control these two verbosity settings separately: you might want verbose testing, but not Shake diagnostic info. And vice versa. So, let's keep this flag.

@snowleopard snowleopard merged commit ef4137d into snowleopard:master Jun 13, 2018
@snowleopard
Copy link
Owner

Merged. Many thanks @chitrak7, and everyone else for the review!

@chitrak7 chitrak7 mentioned this pull request Jun 15, 2018
8 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants